Why do AI programmes stall after the first pilot?
Because readiness gets treated as a technology question. Pick a model, build a proof-of-concept, demonstrate it works — and then discover the organisation around it was never designed to run it. AI readiness is an operating-model problem first, and a solution problem second.
Solution thinking vs. operating-model thinking
Both matter — but the order matters more. Solution-first programmes answer "can we build it?" and leave "can we run it, govern it, afford it and scale it?" for later. Operating-model-first programmes answer the second set before the first, so every solution lands in an organisation ready to hold it.
The solution-only lens asks
Which model? Which framework? Can the demo impress? What does the pilot cost? — questions that produce impressive proofs-of-concept, shadow AI in every department, unbudgeted consumption bills, and a growing gap between what was demonstrated and what the organisation can actually operate.
The operating-model lens asks
Who may use what, on which data, at what cost, for which declared purposes, enforced where, and watched how? — questions that make every subsequent solution faster to ship and safer to run, because the organisation around it already knows the answers.
The six questions an AI operating model answers
- Who may use what? — personas and capability entitlements, from business users to AI engineers, so boundaries are enforced by what people can access, not by policy documents alone.
- On which data? — a data classification scheme mapped to AI endpoint tiers, so sensitive data never reaches an endpoint that isn't contracted and controlled for it.
- At what cost? — budget structures that separate per-seat productivity AI, per-seat developer AI, and usage-based platform consumption, so spend is governable before the invoice arrives.
- For which purposes? — a use-case registry recording what each AI application is declared to do, creating accountability the moment reality drifts from the declaration.
- Enforced where? — classification applied at source, access enforced once at the data layer, endpoints gated by tier: enforcement in the architecture, not in the training deck.
- Watched how? — monitoring that audits adoption, appropriateness, use-case drift, and value against cost, continuously rather than annually.
The operating model, as concrete artefacts
An operating model is only real when it exists as implementable specifications — matrices your platform engineers can enforce and your leadership can fund. This is what a Datuza AI operating-model engagement produces.
Persona & entitlement framework
A tiered persona model — business users, citizen analysts, architects, engineers, AI specialists — with sanctioned outcomes, tool entitlements and hard boundaries per persona. The design principle: capability entitlement over policy alone.
Data protection & endpoint tiering
A data classification scheme mapped to your platform's layers and crossed with AI endpoint tiers — in-tenant no-egress, contracted enterprise, and public — producing a single master matrix of who may use which data, where.
Budget & cost governance
A budget architecture separating productivity, developer and platform-consumption AI — with the consumption guardrails that prevent the mid-month surprise every finance team has now met.
Enforcement architecture
The chain that makes it real: classify at source, enforce once at the data layer, gate endpoints by tier, register use cases, monitor reality against declarations — engineered into the platform, not appended to it.
The risks only an operating model catches
These are the failure modes that never appear in a proof-of-concept — and surface in production, at scale, in front of an auditor.
Retrieval permission inheritance
A chatbot with a broadly-privileged service identity quietly shows lower-privileged users data they could never query directly. Access must be evaluated as the user, not as the application.
Grounding-set exposure
Sensitive fields must be masked before data reaches a model's context — not filtered from the answer afterwards, when the model has already seen them.
Prompt-injection exfiltration
Agentic systems that read documents and call tools can be turned into data-exfiltration channels by the content they ingest. Tool scopes and egress controls are operating-model decisions, not prompt engineering.
Output controls & training posture
Where AI output may travel, and contractual assurance that your data trains no one else's model — commercial and architectural questions that no amount of solution excellence answers.
From assessment to enforcement
Readiness assessment
A structured view of your current AI usage — sanctioned and shadow — against the six operating-model questions, with prioritised gaps.
Operating model design
The full artefact set: personas, entitlements, classification-to-endpoint matrix, budget architecture and governance cadence — fundable and implementable.
Enforcement delivery
Working with your platform team to engineer the model into the estate — data-layer enforcement, endpoint gating, registry and monitoring.
Related: AI & Agentic Solutions · Data Governance · Strategy & CoE