Building at the Edge of What's Possible

What happens when we stop assuming that every AI workload needs to live in the cloud?

Future Caribbean hosted a deep-dive workshop with Lawrence O'Connor, Founder & CEO of OWC, exploring the future of AI infrastructure, on-premise computing, data sovereignty, hardware optimization, security and what these technologies could mean for Caribbean builders.

Rather than treating cloud computing as the default, O'Connor challenged builders to think more deliberately about where their data lives, where computation happens and how much control they retain over the infrastructure powering their products.

The cloud isn't always the answer

O'Connor's argument wasn't that businesses should abandon the cloud. It was that they should understand what they're paying for and choose where each workload belongs.

He described how organizations can move into the cloud because it seems convenient, only to discover later that running large amounts of storage and compute there can become extremely expensive. One client, he explained, had expected an annual cloud budget to last a year but exhausted it in roughly six weeks after moving workloads to the cloud.

His recommendation was straightforward: own your data, own your compute and understand your options.

The real question isn't cloud or no cloud. It's: what should be local, what should be in the cloud, and why?

More hardware doesn't always mean more performance

One of the philosophies behind OWC is that people can often get dramatically more out of hardware they already own.

O'Connor described how systems frequently contain specific bottlenecks — insufficient memory, inadequate storage or poor configuration — that prevent them from reaching their full potential. Instead of immediately replacing a machine, identifying and eliminating those bottlenecks can sometimes deliver a significant performance improvement for far less money.

He recalled seeing schools repeatedly replace computers that could have remained useful with relatively inexpensive upgrades. The lesson applies just as much to AI infrastructure today: the newest machine isn't necessarily the best-performing machine. The right configuration matters.

Enter Stack AI

A major focus of the workshop was OWC's Stack AI technology.

The system uses extremely fast SSD storage to augment a machine's existing DRAM and GPU memory, allowing it to handle larger AI models and switch between models more efficiently. O'Connor explained that systems with insufficient memory can be constrained to smaller models, while Stack AI can extend the capabilities of existing hardware by intelligently using SSD and KV-cache space.

The objective is not simply to make a computer faster. It's to make existing hardware capable of doing more AI work locally, reducing the need to constantly send workloads to expensive cloud infrastructure. That has particular relevance for smaller businesses, startups and regions where access to large-scale compute can be limited or expensive.

AI infrastructure is becoming an orchestration problem

The conversation went beyond hardware. O'Connor described Stack AI as evolving into a broader platform that combines orchestration, model routing, optimization and security.

Instead of a developer manually deciding which AI model should handle every task, the system could determine:

• Which model is best suited to the task
• Whether the work can be done locally
• Whether cloud compute is necessary
• How quickly the result is required
• How much the user is willing to spend
• Which model can accomplish the task with the least token usage

If a result can be generated locally and the user doesn't need it immediately, there may be no reason to pay for cloud compute. If a task requires a faster or more powerful model, the system can route the appropriate portion to the cloud.

The goal is essentially to make the complexity disappear from the user's experience. You specify what you want done. The infrastructure figures out how to do it.

The future isn't one AI model

O'Connor doesn't envision a future where everyone simply chooses one AI model and sticks with it. Instead, he expects orchestration across multiple models and agents to become increasingly important.

Different models will be better at different things, and the system should be able to select the most appropriate one automatically. Users shouldn't spend their time asking, "Which model should I use today?" — they should be focused on their actual work, while the infrastructure determines which models, agents and resources are best suited to the outcome.

That becomes even more important as companies begin managing teams of AI agents rather than individual prompts.

Security may be the biggest problem

For O'Connor, the most important trend builders should be watching isn't simply performance. It's security.

He compared today's AI environment to the early internet, when connecting systems to one another often meant operating without the sophisticated security layers we now take for granted. With AI agents increasingly able to access data, write code and execute tasks, he argued that there needs to be a stronger security layer between sensitive information and AI models.

The risk becomes especially serious when dealing with medical information, financial records, personal identification, customer databases, proprietary code, government information and business-critical data.

The question isn't only whether an AI model is supposedly private. It's whether you actually control what information reaches that model in the first place.

Tokenization: keeping sensitive data out of the model

One solution O'Connor discussed is tokenization.

Instead of sending something like a person's name or identification number to an AI model, that information can be replaced with a randomized token. The model can work with the token without needing to know the underlying identity. Once the result returns to the controlled environment, the original information can be restored — or "rehydrated."

This creates an important principle: the AI doesn't necessarily need access to everything in your database to do useful work with your database.

O'Connor also discussed building permissions directly into applications. Different users can be given access to different levels of information based on what they actually need to perform their jobs. Security shouldn't just be a wall around the entire database — it can be embedded into the way the application itself operates.

Less data can mean more security

When Lily asked about security and building models, O'Connor returned to a simple principle: less is more.

Builders should understand exactly what data their model needs, who needs access to it, what information should remain private, and what actually needs to leave the local environment. The goal isn't simply to meet a minimum certification requirement. It's to minimize unnecessary exposure in the first place.

AI that works without the internet

One of the most compelling possibilities discussed was edge AI.

O'Connor argued that once an AI system has been developed and its ongoing inference requirements are understood, significant portions of the workload can potentially run locally. That becomes especially valuable when connectivity is unreliable — or disappears entirely.

Imagine a disaster scenario where a business, hospital or government agency can't reach the cloud. An AI system that can continue operating locally doesn't simply save money. It remains functional when the network isn't.

For Caribbean islands, where infrastructure resilience and connectivity can be particularly important, this opens up an interesting architectural possibility: AI systems that don't stop working when the internet does.

The Caribbean's data sovereignty question

This naturally led into a broader question: where should Caribbean data actually live?

Lily raised the possibility of countries and industries developing modular, private infrastructure on-island rather than relying entirely on centralized external cloud providers. O'Connor strongly supported the idea for large-scale workloads, suggesting systems could be built locally, potentially across multiple locations, while still selectively using the cloud where it makes economic or technical sense.

The point isn't to isolate Caribbean infrastructure from the rest of the world. It's to make sure that Caribbean countries and organizations retain control over critical infrastructure and data.

The economics could be dramatic

Over a three-to-five-year lifecycle, O'Connor suggested that storage costs at scale could be dramatically lower on-premise than in the cloud — potentially around 1/40th of the cost, depending on the circumstances.

He stressed that the exact economics depend on factors such as power and scale, but argued that organizations often underestimate the cumulative cost of continuously storing data in the cloud. What begins as a relatively inexpensive service can eventually become thousands or tens of thousands of dollars per year. By contrast, owning infrastructure can provide a more predictable cost structure while also giving the organization greater control over its data.

Local infrastructure could change Caribbean AI

Instead of every country, ministry, hospital or company independently sending its growing volume of data to external cloud providers, there could be locally controlled infrastructure, potentially distributed across multiple locations.

O'Connor emphasized that this doesn't mean eliminating the cloud. Smaller workloads may still be more economical to run through services such as AWS. But for large amounts of data and sustained workloads, locally controlled infrastructure can make sense from the perspectives of cost, speed, accessibility and sovereignty. That could create the foundations for a more resilient regional AI ecosystem.

Data transfer is a hidden cost

Another overlooked issue is simply moving data.

Large datasets can take significant amounts of time and money to move into and out of cloud environments. O'Connor pointed out that transferring massive datasets locally can be dramatically faster than moving them over a network — he gave the example of being able to move around 12 TB locally within a few hours, something considerably more difficult when the same data has to travel to and from a remote cloud environment.

For industries handling enormous datasets, the question isn't only "How much does the compute cost?" It's also: "How much does moving the data cost?"

Healthcare is a particularly important use case

Much of the region's healthcare data and processes remain highly fragmented and, in some cases, very analog. Digitizing those systems will inevitably create increased demand for storage, compute and AI.

That makes infrastructure architecture a foundational question — not something to figure out after the applications have already been built. Sensitive healthcare information also makes the security discussion particularly important. If AI systems can perform useful analysis without exposing personally identifiable medical information to external models, the technology could enable new applications while reducing unnecessary data exposure.

Build for the world after free compute

The buildathon provides access to substantial cloud compute — but what happens when those credits disappear?

O'Connor's answer was essentially: don't design a system that only works while someone else is paying for unlimited compute.

Cloud resources can be extremely useful for developing and training early systems. But once an application is working, builders should consider how much of the workload can be optimized to run on fixed, local hardware.

Instead of Build → Cloud → Bigger Cloud → More Cloud, the architecture can become: Build → Optimize → Run locally where possible → Use the cloud selectively.

The future is invisible infrastructure

Perhaps the most interesting vision O'Connor described was one where all of this complexity eventually becomes invisible. A user shouldn't have to think about which model is running, where the computation happens, how many tokens it costs, whether the model is local or cloud-based, which agent should perform a task, or whether sensitive information needs to be redacted.

The system should simply understand the objective and orchestrate everything underneath it — allowing people to focus on what they're actually trying to accomplish rather than the infrastructure required to accomplish it.

Building at the edge

The future isn't necessarily about having access to the biggest cloud cluster. It may be about having the right combination of local and cloud resources, intelligently orchestrated around the needs of the application.

For Caribbean builders, that could mean developing AI systems that are:

• Sovereign — critical data remains under local control.
• Resilient — applications can continue operating when connectivity fails.
• Efficient — expensive cloud compute is used only when necessary.
• Secure — sensitive information is tokenized, redacted and access-controlled.
• Scalable — local infrastructure can be expanded as demand grows.
• Intelligent — different AI models and agents are automatically selected according to the task.

The biggest takeaway from O'Connor's workshop was therefore not simply "use on-premise infrastructure." It was more fundamental: don't let infrastructure become an invisible dependency you don't understand.

Know what you own. Know where your data lives. Know what you're paying for. Know what actually needs the cloud.

And build systems that can keep working — even when the cloud can't.