Why enterprise AI fails on the platform, not the model

AI-generated content: this article was created with AI.

Most large organisations now have a portfolio of AI pilots that work. A chatbot answers policy questions, an assistant drafts claims summaries, a prototype agent reconciles invoices. Yet the number of agents that run in production, with real users, real data and real consequences, remains small. When architecture boards look for the reason, they rarely find it in answer quality. Current models are good enough for a large share of enterprise tasks.

The blocker is a set of questions that a pilot never had to answer. Under which identity does the agent act? Which documents is it allowed to retrieve for this particular person? Who pays for the tokens, and which cost centre carries them? How do we prove to internal audit, months later, what the agent did and why? A pilot can ignore all of this. A production system cannot. The gap between the two is not a model gap. It is a platform gap.

We summarise our position in six principles. They are deliberately short, because they are meant to be discussed in an architecture board, not filed in a strategy document.

Models are replaceable, platforms are not. Models change every quarter, and the right model for a task today will probably not be the right one in eighteen months. Identity, data access, usage metering and audit trails, on the other hand, stay. They are tied to the organisation, its directory, its data classification and its control framework. Investment pays off where the half-life is long. That means building the surrounding capabilities carefully and keeping the model behind a stable interface.

Every agent needs its own identity. A shared API key used by many agents cannot be attributed, cannot be rotated per agent and cannot be revoked without an outage. Each agent should receive a workload identity issued by the platform, with its own permissions and its own audit trail. When the agent acts on behalf of a person, both the person and the agent must remain visible, for example through OAuth 2.0 Token Exchange.

Knowledge only with permissions. Retrieval-augmented generation without access control is a data leak with a search box. When documents are split into chunks and embedded, their access lists stay behind in the source system unless they are carried along deliberately. Permissions from the identity provider must reach the index and be enforced at retrieval time, for the person who is actually asking.

Nothing ships unmeasured. Evaluations act as a release gate, tokens are metered per cost centre, and every call produces a trace. Quality, latency and cost are operating metrics that a platform team watches every day, not numbers that appear once on a steering committee slide. A prompt change without an evaluation report is an unreviewed release.

Governance as code, not as a committee. Policies, model allowlists, permitted data classes and budgets live versioned in the platform. The committee still sets the rules, but the platform enforces them on every request. This changes the role of governance from approving individual projects to maintaining defaults that every project inherits.

One platform, many use cases. The capabilities above should be built once, centrally, and reused by every team. If each project solves identity, retrieval permissions, metering and audit trails on its own, the organisation pays for the same work many times and ends up with inconsistent controls that are hard to audit.

These principles come with a clear limit. A central platform is not a project with an end date. It is a product, with a roadmap, users, service levels and an operations team. Organisations that treat it as a one-off infrastructure build tend to see it decay once the project team moves on. Product ownership has to be funded and staffed, either internally or through a managed service. A second limit is that a platform does not remove the need for domain work. Golden datasets, approval rules and use-case design still belong to the business.

For an architecture team, the next steps are concrete. First, take inventory of the agents and pilots that exist today and note for each one which identity it uses, which data it reads and who pays for it. Second, decide which of the six capabilities are already available centrally and which are rebuilt per project. Third, define the interfaces that applications should depend on, so that models and vector stores can change behind them. Fourth, assign product ownership for the platform before the next wave of use cases arrives, not after.

The question for the board is simple: if a new use case were approved tomorrow, how much of identity, permissions, measurement and governance would it inherit, and how much would it have to build again?

cloudstrata builds and operates AI platforms for enterprises. AI Foundry is our managed runtime for AI agents, with multi-tenant workspaces, routing of models and tools, knowledge retrieval, evaluation hooks, usage and cost metering, audit trails and central governance. If you want to discuss how these principles apply to your landscape, you can arrange a technical introductory conversation via cloudstrata.io/contact.