DEV Community

Cralgo
Cralgo

Posted on

AI Operating Model: Why Scaling AI Is an Organisational Design Problem

#ai #management #leadership #architecture

AI adoption is getting easier. Scaling AI is not.

Models are more capable. APIs are easier to access. Copilots can be deployed quickly. Teams can prototype useful workflows in days.

Yet many organisations still struggle to turn that activity into durable capability.

The reason is increasingly clear: AI does not scale through technology alone. It scales through an operating model.

That means deciding who owns AI, how use cases are selected, how risk is governed, how learning is shared, how human judgement stays in the loop, and how successful experiments become part of normal work.

This is why the phrase AI operating model is becoming more important. In 2026, Deloitte reported a striking gap: while many technology leaders believe they can deploy and govern AI at scale, nearly three-quarters still expect their operating model to change within 12 to 18 months. The problem is moving from “Can we use AI?” to “Can the organisation absorb it well?”

That is a different question.

What is an AI operating model?

An AI operating model is the organisational system that determines how AI decisions are made, governed, funded, built, adopted and improved.

It is not simply an AI strategy document. It is not an AI governance policy. And it is not a central AI team with a new name.

A useful AI operating model connects at least six things:

  • decision rights — who can approve, stop or escalate AI use cases;
  • ownership — who is accountable for the business outcome, not just the model;
  • governance — what evidence, controls and reviews are required;
  • delivery — how ideas move from experiment to production;
  • capability — how teams learn to use AI well and safely;
  • feedback — how real outcomes change future AI decisions.

The technology matters. But the model around the technology determines whether it becomes capability or remains experimentation.

Why AI pilots multiply faster than AI capability

Most organisations do not have an idea shortage.

They have use-case lists.

Customer support wants summarisation. Finance wants forecasting. Marketing wants content acceleration. Product wants research synthesis. Engineering wants coding assistance. Operations wants automation. Leadership wants better decision support.

The common response is to launch pilots.

Pilots are useful because they lower the cost of learning. But when each team pilots independently, the organisation can create a new kind of fragmentation:

  • duplicate tools;
  • inconsistent data handling;
  • unclear model ownership;
  • different review standards;
  • no shared evaluation method;
  • no common approach to human oversight;
  • successful experiments that never become repeatable practice.

The result can look like “lots of AI” without much institutional capability.

This is where an AI operating model becomes useful. It creates a way for learning to compound rather than reset inside every team.

The three systems inside every AI operating model

One way to read AI adoption is through three interacting lenses: psychology, technology and organisations.

That matters because AI changes all three at the same time.

1. Psychology: people decide whether AI is actually used

An AI system can be technically excellent and still fail if people do not trust it, understand it or know when to override it.

Adoption is shaped by questions such as:

  • Do employees believe AI will help them or replace them?
  • Do managers understand when AI output should be challenged?
  • Are people comfortable admitting that a model may be wrong?
  • Does the interface encourage verification or passive acceptance?
  • Are incentives aligned with responsible use, or only with speed?

This is why “training” is too narrow a word for AI adoption.

The real issue is behaviour.

An AI operating model has to create confidence without creating complacency. It should make good judgement easier, not merely make AI available.

2. Technology: systems determine what AI can safely do

The second layer is technical.

AI needs access to data, tools, workflows and applications. As capability increases, so does the importance of architecture and controls.

Organisations therefore need clear answers to questions such as:

  • Which models and platforms are approved?
  • What data can each system access?
  • Where must retrieval, redaction or permission controls sit?
  • How are prompts, outputs and model versions logged?
  • How is quality evaluated before and after deployment?
  • What happens when an agent can take actions rather than only generate text?

This is where standards and risk frameworks matter. NIST’s AI Risk Management Framework and its Generative AI Profile emphasise lifecycle risk management, while ISO/IEC 42001 treats AI as a management-system question rather than a one-off technical control.

Those frameworks are useful because they reinforce a simple point: responsible AI requires repeatable organisational processes around the technology.

3. Organisations: structure determines whether AI becomes capability

The third layer is organisational.

Someone has to own the decisions.

That sounds obvious, but AI often crosses existing boundaries. A customer-facing AI feature may involve product, technology, legal, security, data, operations and customer support. A coding assistant may affect engineering quality, intellectual property, security and productivity measurement. An internal agent may touch systems owned by several teams.

Traditional organisational charts do not automatically resolve these questions.

The AI operating model therefore has to define:

  • who owns the use case;
  • who owns the model or platform decision;
  • who owns risk acceptance;
  • who can approve production use;
  • who monitors performance after launch;
  • who decides when an AI system should be retired.

Without this clarity, governance becomes a queue and delivery becomes negotiation.

Centralised or federated? Usually both

A common AI operating model question is whether AI should be centralised.

There are good reasons to centralise parts of it. Shared standards, architecture, security, evaluation, vendor decisions and governance can become expensive and inconsistent when every business unit rebuilds them independently.

But centralising every use case creates another problem: the people closest to the work lose ownership.

That is why many enterprise AI models are moving toward a federated structure.

The centre holds the things that should be common:

  • principles and policies;
  • approved platforms;
  • model and vendor standards;
  • reusable architecture;
  • evaluation methods;
  • high-risk review;
  • shared knowledge and playbooks.

Business and product teams hold the things that require context:

  • problem definition;
  • workflow design;
  • user behaviour;
  • domain-specific quality thresholds;
  • adoption;
  • outcome ownership.

The centre should not become the place where every AI decision waits.

Its job is to make good distributed decisions possible.

An AI Centre of Excellence should distribute capability, not collect authority

This is where a Centre of Excellence can help — if it is designed correctly.

A weak AI CoE becomes a committee that reviews requests.

A stronger one becomes an organisational mechanism for making AI capability repeatable.

Its role may include:

  • maintaining shared AI architecture and standards;
  • defining evaluation and governance requirements;
  • maintaining reusable patterns and playbooks;
  • helping teams structure high-value use cases;
  • building internal capability;
  • connecting lessons across departments;
  • creating escalation paths for high-risk decisions.

The test is simple: does the CoE make the organisation more capable without making it more dependent?

Cralgo explores this broader capability question in its work on Centres of Excellence and technology as an organisational system.

Governance has to move at the speed of execution

AI governance is often discussed as a control problem.

It is also an execution-design problem.

If governance only happens at the end of a project, teams will either wait too long or work around it. If every use case receives the same review, low-risk experimentation becomes unnecessarily slow while genuinely important risks can receive too little attention.

A better AI operating model makes governance proportional.

For example:

Low-risk internal assistance

A meeting-summary tool using approved enterprise data may require lightweight controls, clear retention rules and basic quality checks.

Medium-risk workflow automation

An AI system that recommends operational actions may require stronger logging, human approval and explicit rollback paths.

High-risk decision support

AI used in areas such as healthcare, employment, financial decisions or safety-sensitive operations may require independent validation, documented evidence, tighter monitoring and formal accountability.

The point is not to make governance smaller.

It is to make governance fit the consequence of the decision.

The missing capability is often judgement

As AI systems become more capable, organisations can be tempted to move more decisions into the system.

But capability and authority are not the same thing.

A model may be able to recommend an action without being the right place to own that action.

That distinction becomes especially important with agents that can call tools, update systems, trigger workflows or communicate with customers.

The key design question changes from:

What can the AI do?

To:

What should the AI be allowed to do, under what conditions, with whose judgement around it?

This is one reason the human side of AI cannot be separated from the technical side. Trust, attention, decision-making and accountability all shape the outcome.

A practical AI operating model checklist

Before scaling AI across an organisation, leadership teams should be able to answer these questions clearly:

  1. What outcomes are we trying to improve with AI?
  2. Who owns each use case after the pilot ends?
  3. Which AI capabilities are central and which are distributed?
  4. What technology standards are shared across the organisation?
  5. How are use cases classified by risk?
  6. What evidence is required before production deployment?
  7. Where is human judgement mandatory?
  8. How are model performance and business outcomes monitored separately?
  9. How does one team’s learning become reusable knowledge for another?
  10. What capability should remain inside the organisation even if vendors change?

If these answers are vague, the organisation probably does not yet have an AI operating model. It has AI activity.

Those are not the same thing.

The operating model is what turns AI into organisational capability

The next phase of enterprise AI will not be decided only by who has access to the strongest model.

Access is becoming easier.

The harder advantage is organisational: the ability to decide well, deploy safely, learn quickly, distribute capability and retain judgement as AI becomes embedded in normal work.

That is why AI operating models matter.

The technology changes what becomes possible.

People determine how it is understood and used.

Organisations determine whether that possibility becomes repeatable capability.

The outcome emerges from all three.

Cralgo is a research and technology company exploring how psychology, technology and organisations shape better outcomes.

Explore Cralgo, Technology, and the Operating Model.

References

Top comments (0)