Enterprise AI Is Not a Bigger Copilot
The market defines enterprise AI as a scope. Scope is not a standard — what makes AI enterprise-grade is that a process can be trusted to it.
Ask three vendors what enterprise AI is and you get the same sentence back, more or less: artificial intelligence integrated into business operations at scale. As a description of where the technology sits in a company, it is accurate. As a definition it is close to useless, because it describes a scope — how much of the organisation the software touches — and scope is not a standard. You cannot procure against it. You cannot fail an audit against it. It tells a CIO nothing about whether the system in front of them survives contact with a process that has a regulator attached.
A more useful definition starts at the moment that actually matters: the point at which an organisation is willing to let software run part of a process rather than help someone do it faster. That is the bar, and it is why we treat enterprise AI as an engineering property rather than a market category. Four things have to be true before a process can be trusted to a machine:
Nothing in that list is a model capability. That is the point.
Why copilots plateau
A copilot is a good product, and the productivity is real. Someone drafts a reply in a third of the time, gets through a legal review before lunch, finally writes the tests. Every one of those wins is genuine, and every one of them is personal.
The trouble starts when you try to add them up. A thousand people each working slightly faster is a thousand private improvements; the process running between those thousand people takes exactly as long as it did before. When the tab closes, the context goes with it. The next person starts from nothing. The assistant knows what was pasted into it and nothing about the approval rules, the last time this case ran, or why the exception was granted in March.
So the plateau is structural, not a sign that the model needs replacing. It is the difference between personal AI and organisational AI, and it shows up in four places at once.
| Personal AI — the copilot | Organisational AI | |
|---|---|---|
| Unit of improvement | One person, one task at a time | One process, end to end |
| Context | Lives in a tab and dies with it | Held in the model of the business, across runs |
| Authority | Suggests; a human retypes the result into the system | Acts on the system of record, under a policy |
| Evidence | A chat log, if anyone kept it | An audit trail produced by running |
| What it changes | How fast someone works | How long the process takes, and what it costs |
Most pilots do not fail on the model
The pattern is familiar enough to be boring. The demo works. Everyone is impressed. Then someone asks the four questions that decide whether it ships — and the pilot has no answers, because none of them are model problems.
Grounding is a data problem before it is an AI problem. An ontology — the entities, relationships and rules your business actually runs on, mapped onto the systems that hold them — is what lets an agent retrieve meaning rather than plausible text, and lets it write back to an operational system without guessing at what a record means. It is unglamorous work and it is the work.
Governance is the second. An agent that acts on real systems needs the same treatment as a member of staff: a named identity, permissions that follow the work rather than a shared super-user, policy enforced where the workload cannot switch it off, and an audit trail produced as a by-product of running rather than reconstructed later. That is what AI governance has to mean in practice, and it is why bolting a review step onto a chatbot does not produce it.
Orchestration is the third, and it is the one most organisations discover last. Real processes are not one prompt; they are a sequence of steps across several systems with people in some of them. Something has to hold that sequence, resume it, escalate it, and know which human owns which decision. That runtime is what we call an AI OS — the layer between the models and the business, doing for agents roughly what an operating system does for programmes.
Swapping in a stronger model moves none of these. It is the platform around the model that decides whether the pilot becomes a process.
The four questions above, expanded into about thirty — and a score per dimension.
Enterprise AI to production: the checklist
About thirty questions to put to your own team, grouped under grounding, governance, orchestration and sovereignty. Tick what is true for you today and see a score per dimension. One page, yours to print.
What European organisations have to design for
The American explainers on this topic are competent and they all stop at the same place: benefits, risks, a stack diagram, a product call to action. What is missing is the set of constraints that European organisations have to design for from the first architecture meeting, not retrofit before go-live.
| What applies | What it puts on you | What it changes in the architecture |
|---|---|---|
| EU AI Act | Obligations on the deployer, not only on the companies building models: classification, meaningful human control, logs, informing the people affected, use within the terms the system was placed on the market under | Know which of your systems are high-risk before anything is built, keep the human decision point in the flow, and retain the record by default |
| DORA | AI services treated as ICT third-party dependencies | A register, resilience testing and an exit plan for every model and service the process leans on |
| NIS2 | An agent's access to operational systems is a security-governance question, with accountability that reaches management | Agent identity and permissions have to be auditable facts, not conventions in a runbook |
| Cloud and AI Development Act Commission proposal, 3 June 2026 — not law yet | A cloud sovereignty framework with four assurance levels, from processing inside the Union up to demonstrated control over the whole supply chain, plus a joint procurement framework for public administrations | If you are a public body or sell to one, the assurance level your architecture can honestly claim turns into a procurement criterion — and it is decided by where the workload runs and who controls it, not by a clause |
| Data that cannot leave the building | A meaningful set of European workloads, with no network path out | Air-gapped operation as a property of the whole system — including how models are updated and how evidence is exported |
Sovereignty is not a badge you apply at the end; it is a property of where the thing runs.
The honest part
Most organisations we meet have capable people, processes that are broken in ways everyone can describe, and data they cannot use. Our position on that has not changed: We fix two out of three. Deliberately.
That is a scope statement, not modesty. The processes and the data are engineering problems, and we will take them: the ontology gets built and owned, agents get identities and policies, the audit trail becomes a by-product of running. The third one stays with you. Who owns which process, which decisions a human keeps, what Human+AI actually means in your operating model — none of that ships in a licence, and any vendor implying otherwise is selling you the pilot rather than the production system.
The cost is real and worth stating plainly. This is a platform decision with a data project inside it, and the first year buys fewer, deeper things than a copilot rollout does. What it buys instead is a process that compounds.
If this is the argument on your desk right now, we are running it live on 13 October: From personal AI to organisational AI: why copilots plateau, and what an AI operating system changes — 45 minutes, slides and a working system, and the organisational side as well as the technical one. If you would rather start on your own, the checklist above turns the four properties into the questions to put to your own team — tick what is already true and it scores each dimension — before anyone writes a business case.