AI Operating Model: From Experiments to Enterprise Adoption

Why do AI experiments not scale by themselves?

A pilot proves that a model can do something. It does not prove that an organisation can run it. Each isolated project rebuilds ingestion, retrieval, evaluation and security, and ends up with its own quality bar.

On the DILA platform, the shift was to stop building each application independently and to assemble standardised, governed components instead.

The cost of skipping that shift is rarely visible in the first project. It appears at the third or fourth, when the same questions about data access, quality and security have been answered differently by every team and nobody can compare the results.

What does an AI operating model actually contain?

I describe it as a few layers that depend on each other. None of them is exotic, but organisations tend to fund the first and skip the rest, which is why so many pilots stay pilots.

• A shared platform: document processing, retrieval, orchestration, tool integrations and security that teams assemble rather than rebuild.
• Governance defined with the platform: who owns a component, who may change it, what data it may touch and what happens when it fails.
• Evaluation gates: a fixed set of scenarios and metrics that a release must pass before it reaches users.
• Adoption: training, support and a clear path for a new team to ship its first use case.
• Ownership: a named team that runs the platform as a product, with a backlog and users, not as a one-off project.

What changes at each maturity stage?

The table below is the way I read an organisation's position. It is a working checklist, not a formal standard, and most organisations sit between two rows.

How do you build the platform and its rules together?

Shared document processing, retrieval, evaluation and security capabilities are only reused if teams trust them. That trust comes from governance defined with the platform, not added after it. If rules arrive later, every team has already made its own choices, and the platform becomes one more option rather than the default.

Agentic applications can then build on existing orchestration patterns and tool integrations instead of reinventing them. The DILA programme is a good public example of the payoff: delivery time of a RAG application fell by 60%, from 10 weeks to 4, and 75% of common technical capabilities were reused. The team behind it was nine people, which is the point: a small team can only serve many projects if the components are shared.

What did we measure on the DILA platform?

DILA is a public-sector organisation attached to the services of the Prime Minister. The figures below come from the published case study, and I give them as reported, without extrapolating to other contexts.

• Content creation became 70% faster.
• Delivery time of a RAG application dropped by 60%, from 10 weeks to 4.
• 75% of common technical capabilities were reused across applications.
• Cost per AI request fell by 30%, through optimisation and reuse.
• Prototyping implementation time for agentic workflows fell by 50%.
• The RAG chain scored 0.94 on faithfulness, 0.91 on answer relevancy, 0.89 on context precision and 0.92 on context recall, with 85% of priority RAG scenarios covered.

Why is adoption a people problem?

A platform nobody can use is a cost. Training belongs to the operating model: at Devoteam, the LEAP programme, run by a team of five, trained 1,500+ professionals in generative AI, agentic AI and RAG, and NOVA reached 800 employees across a group of 10,000+ consultants in 25 countries.

I saw the same pattern on the transformation side at Decathlon, where a programme with a budget of €4M and a team of 13 people reported 2.6x productivity gains from augmented teams. The lesson I take from both is that the tooling is rarely the bottleneck. People adopt what they were shown how to use, and what they trust.

What are the most common mistakes when scaling AI?

Most failures I see are organisational, not technical. They repeat across sectors, and they are cheap to avoid if you name them early rather than discovering them after the third pilot has stalled.

• Funding use cases but not the platform, so every team pays the same setup cost again and again.
• Writing governance as a document that nobody can execute, instead of checks that run automatically in the delivery pipeline.
• Judging a release on a demo, when only a fixed scenario set shows whether a change is an improvement or a regression.
• Treating training as a launch event, when people need support and examples long after the first workshop.
• Giving agents wide permissions on day one, instead of letting autonomy grow with the evidence that the checks catch problems.

How do you govern agents that act, not only answer?

For agents that act, the same logic applies to control. An agent that can call tools needs limits that are checked every time, not only at design time. TrustRail, a public repository, explores policies, human approvals and signed receipts: for each protected operation it records which agent asked, who authorised it, what limits applied and what evidence supports the outcome. It runs on synthetic sandboxes, so it is a design study, not a production claim.

The agentic-sdlc framework applies the same idea to coding agents, under the name earned autonomy: an agent gets more freedom where automated checks can prove its work, and loses it where they cannot. It is a working framework that has not been validated by an independent study, and I present it as such.