Why we stopped using Cloud AI

1. The unease using AI with company data

For a long time, building enterprise AI felt like a matter of careful optimisation. Better retrieval. Better prompts. Better integration. Better governance. Each improvement made the system more capable and more presentable, yet something fundamental remained unresolved.

The unease did not come from performance limitations. The models were improving rapidly. Nor did it come from a lack of organisational interest. Demand was clearly there. The discomfort came from a growing mismatch between what these systems were being asked to do and the assumptions built into how they were designed.

As AI moved closer to the core of organisational decision-making, the questions changed. Not simply: “Does it work?” But: “Who is accountable when it fails?” Not only: “Is it secure?” But: “Can we explain this to an auditor, a regulator or a board?” Not: “Can it scale?” But: “Can we stop it, inspect it and override it when necessary?”

These are not questions that can be answered by adding another layer on top of a cloud-hosted model.¹

2. The governance gap

The default response in the market has been to soften the edges of the existing architecture. Hybrid deployments. Private clouds. Confidential computing. Governance frameworks wrapped around externally hosted models.²,³

These approaches are often well-intentioned, but they avoid confronting the underlying issue: intelligence that operates outside the organisational boundary cannot be fully governed from within it.

An organisation may control access, define policies and monitor usage, but that is not the same as controlling the intelligence itself. When decision-critical capabilities depend on an external service, authority remains divided. The organisation may be accountable for the outcome without having full control over the system that produced it.

At some point, continuing to optimise within that constraint began to feel intellectually dishonest. The problem was no longer how to make the existing architecture slightly safer or more efficient. The question was whether it was the right architecture for the work being asked of it.

3. Refusing the trade-off

Stepping away from the usual path was not an ideological decision. It was a design decision.

Certain trade-offs that once seemed acceptable no longer were: convenience at the cost of inspectability, speed at the cost of authority and scale at the cost of clarity.

Refusing those trade-offs has consequences. It means saying no to some opportunities. It means walking away from projects that require intelligence to be delivered primarily as a remote service rather than developed as an embedded organisational capability. It also means accepting that progress may appear slower when measured against conventional software or startup metrics.

But it creates a different kind of momentum.

Once systems are designed around decision-critical use cases, constraints stop being limitations and start becoming anchors. Locality becomes a governance requirement rather than a deployment preference. Transparency becomes a condition for trust rather than an additional feature. Human oversight becomes a structural necessity rather than a compliance checkbox.

The objective is no longer to make an external model feel sufficiently integrated. It is to build intelligence that the organisation can genuinely own, inspect and direct.

4. Architecture is the product

This shift changes how enterprise AI should be understood.

The model becomes one component among many. The system becomes the product. Architecture becomes the differentiator.

A serious enterprise intelligence environment must combine models with organisational data, decision logic, human knowledge, security controls and mechanisms for intervention. It must understand the relationships between products, suppliers, customers, assets, processes, contracts and decisions. It must operate within defined boundaries and make its reasoning traceable to the information on which it relies.⁴

This is why embedded intelligence requires more than deploying an AI assistant. It requires the construction of a company-specific intelligence layer: grounded in the organisation’s own corpus, structured through a graph and enriched by the knowledge of the people who understand the business and its industry.^5,6

The resulting capability is not centred on a single model. Models will continue to improve and can be replaced over time. The durable asset is the organisational context built around them.

5. Intelligence within the boundary

Most importantly, this direction clarifies who the work is for.

It is not primarily for experimentation at the edges, but for organisations that cannot afford silent failure. Not for novelty, but for continuity. Not for abstract intelligence, but for intelligence operating inside real institutional, operational and regulatory boundaries.

This does not reject cloud AI. Cloud-based models will continue to play an important role in many contexts. What it rejects is the assumption that one architecture can serve every purpose equally well.

There is a significant difference between using AI to produce marketing copy and using it to influence production, inventory, sourcing, maintenance or customer commitments. As the consequences of a decision increase, so do the requirements for ownership, transparency and control.

Enterprise AI is entering a phase in which the cost of being wrong can outweigh the benefit of being fast. Designing for that reality requires a different starting point.

That is the work we have chosen to do.