The enterprise AI strategy consulting market produces one output with remarkable consistency: a prioritised roadmap of AI use cases, sequenced by effort and return, with an accompanying technology architecture recommendation and a multi-year transformation programme. The roadmap is usually well-researched, coherently structured, and commercially sensible on its own terms.
It is the wrong deliverable.
The gap between a prioritised AI use case roadmap and a functioning production AI system generating EBITDA is not a planning gap. It is a design gap — specifically, a gap in the design of the operating model that the AI system must run inside. Strategy consulting fills the planning gap. Operating model design fills the design gap. The EBITDA comes from closing the design gap, not from adding more planning.
This piece presents the AI operating model design framework: what it contains, how it is structured, and how it translates into production outcomes within a 90-day timeline.
I. What an Operating Model Is (and What It Isn't)
An operating model is the answer to a specific question: how does work get done? It specifies the structure of teams, the workflows between them, the decision rights that govern ambiguous cases, the skills required at each node, the technology that enables the work, and the performance metrics that make the output visible and accountable.
A technology deployment is not an operating model. A model serving predictions from an API endpoint has no workflow, no decision rights, no accountability structure, and no performance management. The model is a component. The operating model is the architecture that converts the model's outputs into business outcomes.
The distinction matters because the failure of enterprise AI is almost always an operating model failure, not a technology failure. The models perform. The predictions are accurate. The API is available. And the EBITDA does not change because the operating model — the workflow, the roles, the measurement architecture — was not redesigned to act on what the model produces.
Organisations that redesign both their technology architecture and their operating model achieve an average ROI of 1.7x from AI investment. Organisations that invest technically without the corresponding operating model redesign report results statistically indistinguishable from zero.
II. The Six Dimensions of AI Operating Model Design
An AI operating model has six dimensions that must be designed as a coherent system. Each dimension, designed in isolation, produces a partial solution. Together, they produce the conditions under which AI capability converts into compounding returns.
Dimension 1: Structure
Structure answers the question of how teams and functions are organised to deliver the AI-augmented workflow. The design error most commonly made in enterprise AI is to impose the new operating structure on top of the existing organisational chart — adding AI capability to an existing team without redesigning how that team is structured around the capability.
An AI operating model structure is derived from the capabilities required to deliver the strategy, not from the existing hierarchy. For a financial services firm deploying credit underwriting AI, the required capabilities include: decision model governance (who owns the model's performance and compliance), exception management (who reviews edge cases), outcome measurement (who tracks EBITDA attribution), and assurance operations (who monitors the system and escalates degradation). These are new capabilities that require explicit structural ownership — whether by redesigning existing roles, creating new ones, or reorganising teams around the AI-augmented workflow.
The most common structural omission is the Agent Manager role: the person responsible for supervising AI outputs, monitoring for drift, and escalating when the system operates outside its intended performance envelope. 84% of enterprises have not created this role or any functional equivalent. In its absence, the AI system runs unsupervised, its performance degrades gradually, and no one owns the remediation until the degradation becomes a P&L event.
Dimension 2: Processes
Process design answers the question of how work flows end-to-end through the AI-augmented system. The critical process design requirement for production AI is that the workflow is redesigned around what the AI system can do, rather than what human-only workflows could do.
In a pre-AI credit workflow, an analyst reviews every application in sequence. The process is designed around human throughput constraints: applications are batched, analysts have daily targets, quality control is a sampling function. When an AI model is added to this workflow without process redesign, it functions as a screening tool that routes all applications to human review anyway — the process constraint has not changed, so the throughput has not changed.
In an AI operating model, the credit process is redesigned around the model's output: applications above a confidence threshold are automatically decisioned, with the process designed around exception routing and quality assurance for the automated tier; applications in the ambiguous tier are routed to human review with model-generated evidence packs that compress the review time from twenty minutes to three; applications in the policy exception tier are routed to senior credit. The process is designed around what the model does well, not around what the pre-AI workflow did.
The Blueprint as the process specification. The operating model design work that precedes the build must produce a specific, workflow-level process design — not a high-level description of how AI will "augment" the underwriting team, but a decision tree that specifies the threshold conditions, routing rules, review workflows, and escalation paths for every decisioning category. This specification is what the build team implements. Without it, the build produces a model without a process architecture to run inside.
Dimension 3: Decision Rights
Decision rights define who decides what, under what conditions, with what escalation path. This is consistently the least-specified dimension in enterprise AI operating model design, and it is the dimension whose absence produces the most expensive failures.
The failure mode is specific: an AI system produces an output that a human reviewer disagrees with. Neither party has clear authority. The reviewer escalates to a manager who also has no clear guidance. The escalation takes days. The client experience degrades. The model's outputs are ignored because there is no process to act on them when they conflict with human judgment.
The solution is a decision-rights map that specifies, for each output category:
- Who has authority to act on the AI system's recommendation without additional review
- Who has authority to override the AI system's recommendation, and under what conditions an override is valid
- Who is accountable when an AI-influenced decision produces a bad outcome
- What documentation is required for each decision category
In regulated financial services, decision rights are not just an operating model efficiency tool — they are a compliance requirement. SR 11-7 model risk governance, EU AI Act human oversight obligations, and fair lending compliance frameworks all require that AI-influenced decisions have defined, auditable accountability structures. An operating model without explicit decision rights is a governance gap.
Dimension 4: People and Skills
The skills required to operate an AI-augmented workflow are different from the skills required to operate the pre-AI equivalent. The operating model design must specify those differences explicitly and address the transition.
In a credit underwriting team augmented by AI, the junior analyst role shifts from application review to exception management and model monitoring. The skills required — model output interpretation, edge case reasoning, governance documentation — are different from, and in some ways more demanding than, the prior application-review skills. The senior credit analyst role shifts from individual decisioning to threshold governance and model challenge. The skills required — statistical interpretation, model risk reasoning, calibration judgment — are new to most credit professionals.
The people and skills dimension of the operating model design specifies these skill requirements, identifies the gap between the current team's capabilities and the required capabilities, and specifies the training, hiring, or role redesign required to close the gap. This work must be scoped and started at the beginning of the build, not after production launch, because the operating model does not go live until the people dimension is ready.
The financial modelling capability gap. One non-obvious skill requirement in production AI operating model design is financial modelling. The Diagnostic Blueprint — the assessment that precedes the build — must produce a CFO-grade business case alongside the technical specification. This requires financial modelling skill in the diagnostic team: the ability to model EBITDA impact from operational drivers, construct sensitivity analyses, and present attribution methodology in terms that survive board and audit committee scrutiny. Most technical AI teams do not have this skill. Operating model design teams that do can produce a diagnostic output that closes the internal approval; those that do not produce a technical assessment that adds to the planning backlog.
Dimension 5: Technology and Data
The technology and data dimension specifies the infrastructure backbone that the operating model runs on. For production AI, this includes three distinct layers that are frequently conflated in enterprise architecture discussions.
The model layer. The AI models, orchestration framework, and inference infrastructure. The technology that generates the predictions, recommendations, or decisions. This is what most enterprise AI discussions focus on. It is not where the operating model differentiation lives.
The integration layer. The connectors between the AI system and the upstream data sources, downstream workflow systems, compliance reporting platforms, and business intelligence infrastructure. In most enterprise environments, the integration layer is the longest-lead-time component of the production build — not because it is technically complex, but because it requires engagement with legacy systems, access controls, and data governance frameworks that were built before AI was a deployment consideration. Integration must be scoped at the beginning of the build, not discovered at week eight.
The observability and assurance layer. The monitoring infrastructure that makes the AI system's production behaviour visible: drift detection dashboards that alert when model performance degrades below defined thresholds; SLA tracking that measures and reports on the operational commitments the engagement has committed to; governance reporting that produces the documentation required for regulatory examination and internal audit. This layer is where most production AI systems are under-invested, because it produces no visible output at go-live — it produces visible output only when something goes wrong.
The observability layer has a triple purpose that makes it one of the highest-ROI internal investments in the AI operating model: it is the mechanism for maintaining the EBITDA gains post-deployment (by detecting drift before it reaches the P&L); it is the proof-generation engine that produces the data for the next case study and the next client reference; and it is the benchmark data that makes the next Diagnostic Blueprint sharper and the next business case more accurate. An organisation that runs production AI without observability infrastructure is not just accepting operational risk — it is forgoing the institutional learning that makes subsequent AI investments cheaper and more predictable.
Dimension 6: Performance Metrics and Incentives
The performance metrics dimension answers the question: how does the organisation know if the AI operating model is working, and how are the people responsible for it held accountable?
The most common measurement failure in enterprise AI is measuring model performance rather than business outcome: accuracy scores, recall rates, inference latency, user adoption percentages. These are useful engineering metrics. They do not appear on the P&L. They do not tell a board whether the AI investment is compounding or dissipating.
An AI operating model measurement architecture connects operational metrics to EBITDA drivers with a defined attribution methodology. For credit underwriting AI: underwriting throughput (decisions per analyst per day), loss rate trend (credit losses as percentage of originations), and speed to decision (hours from application submission to decision). For fraud detection AI: detection rate, false positive rate, and investigation resolution time. These metrics connect directly to the three EBITDA drivers (throughput, loss rate, speed) with defined attribution that makes the business case closeable.
The incentive red line. The one incentive design that is structurally incompatible with an AI operating model is utilization targeting. If the people responsible for building, operating, and maintaining the AI system are measured on the hours they bill, their commercial incentive is to maximise hours, not to deliver efficiently against the outcome. This is the precise mechanism by which consulting firm economics create the accountability problem described in the prior section. It applies equally to internal teams: an internal AI team measured on project hours billed has no incentive to build reusable governance patterns, no incentive to deliver at 90 days rather than 180 days, and no incentive to make the next project cheaper.
The operating model incentive structure should tie the AI team's performance — and where appropriate, their compensation — to the outcome metrics: conversion rate, EBITDA attribution, NRR on the maintained client base. Not hours. Not headcount. The EBITDA.
III. The Alignment Check: Six Dimensions That Must Reinforce Each Other
Operating model design fails when the six dimensions contradict each other. The most common misalignments:
-
Structure defined by the current org chart, not by required capabilities. The structure dimension inherits the pre-AI hierarchy. The process dimension is designed around the AI-augmented workflow. The result: the processes require decisions that no role in the structure owns.
-
Decision rights that contradict performance incentives. Analysts have authority to override AI recommendations (decision rights) but are measured on throughput (performance metrics). The incentive is to override rarely and process fast, rather than to review carefully. The AI governance intent is contradicted by the incentive design.
-
Technology backbone that the people dimension cannot operate. Observability dashboards are deployed. The role responsible for monitoring them (the Agent Manager) does not exist. The dashboards run unread and the drift alerts accumulate unseen.
-
Utilization incentives in an outcome-committed operating model. This is the single most destructive misalignment. If any incentive tied to hours or headcount deployment exists in an operating model that has committed to a fixed outcome, the hours incentive will win. Design it out completely.
The alignment check is the step in operating model design where each dimension is tested against each other dimension for consistency. The result should be a single, coherent system where every dimension reinforces the same two metrics: conversion (did the Diagnostic Blueprint produce a build?) and NRR (is the maintained client base expanding?). If any dimension pulls against those two metrics, it is misaligned.
IV. A Scenario Walk-Through: The $2B Fintech CFO
The following walks a production engagement through the operating model design framework to illustrate what each dimension produces in a specific context.
The situation. A $2B-revenue financial services firm. The CFO has a board mandate to demonstrate AI-driven EBITDA improvement in the next four quarters. The Chief Risk Officer holds a compliance veto. The VP of Credit Operations has been running an AI pilot in underwriting for eight months with no production outcome.
Step 1 — Diagnostic Blueprint (3 weeks). The diagnostic maps the credit underwriting workflow at the sub-process level, identifies the three specific EBITDA levers (throughput, loss rate, speed to decision), models the directional EBITDA impact (~$10.5M/yr), scopes the integration requirements (connection to the core banking system, the credit bureau data feed, and the compliance reporting platform), designs the HITL architecture (three-tier decision classification, threshold calibration methodology, exception routing workflow), and produces a fixed-scope build specification and a CFO-grade business case.
The output is not a technology roadmap. It is a build-ready specification that the engineering team can implement without discovery work, and an internal approval document that the CFO can take to the board.
Step 2 — Commercial structure. The build is structured as a fixed-scope engagement: $1.9M, 90 days to production, SLA commitments on system availability and decision throughput, an outcome kicker (small share of verified, controllable EBITDA improvement, capped) that aligns the implementation team's return with the client's benefit, and E&O insurance that covers production failures within the scope of the engagement. The CRO receives the SOC 2 certification, the model risk methodology, and the procurement-ready vendor documentation in week one of the engagement, clearing procurement before the build begins.
Step 3 — Operating model design (parallel with the build). During the 90-day build, the operating model redesign runs in parallel: the tiered decision architecture is documented and trained, the Agent Manager role is defined and the current VP Ops analyst identified for the function, the performance measurement framework is instrumented (throughput baseline established in week 2, attribution methodology agreed), and the governance documentation is produced in compliance with SR 11-7 and the EU AI Act's high-risk system requirements.
The assurance team is embedded in the build from week one — writing the runbook, building the observability dashboards, calibrating the drift thresholds — so that the governance infrastructure is production-ready at go-live rather than an immediate post-launch task.
Step 4 — Go-live. At day 90, the production system goes live with: a running HITL architecture processing the three decisioning tiers, an observability dashboard monitoring throughput, drift, and SLA compliance, a named Agent Manager in the credit operations team, SR 11-7-compliant model documentation, and an attribution framework measuring EBITDA impact against the baseline established in week 2.
The VP of Credit Operations's eight-month pilot is retired. The analyst team's workflow has been redesigned. The CFO has a board-reportable EBITDA attribution from month 4.
Step 5 — Operating Model Assurance (ongoing from day 90). The implementation team transitions to an assurance retainer: monitoring, drift detection, threshold recalibration, SLA reporting, and governance documentation maintenance. The EBITDA attribution is measured and reported quarterly. The first case study is produced at month 12, when the annual loss-rate improvement and throughput gain are measurable.
At the 12-month mark, the next workflow — fraud detection — is ready for a new Diagnostic Blueprint. The infrastructure built in the first engagement reduces the second engagement's integration cost by approximately 40%.
V. Why the 90-Day Commitment Is the Strategy, Not the Promise
The 90-day production commitment is not primarily a marketing claim. It is a strategic constraint that disciplines the operating model design process.
A commitment to production in 90 days requires that the diagnostic phase produce a complete, implementation-ready specification. There is no room in 90 days to discover scope that was not scoped, to negotiate integration access that was not agreed, or to iterate on governance architecture that was not designed. The commitment creates a forcing function that produces the specification discipline that most enterprise AI engagements lack.
The commercial structure enforces the discipline: a fixed-scope, fixed-fee commitment with SLA credits creates a direct P&L incentive for the implementation team to produce a complete specification in the diagnostic phase rather than to discover scope during the build. The cost of incomplete scoping is borne by the implementation team, not the client.
This discipline is the most important differentiator between the operating model design approach and the traditional AI consulting approach. Strategy consulting does not commit to production. It cannot commit to production because the specification is not complete at the point of engagement. The roadmap is the product, not the system.
Operating model design commits to production because the specification — the workflow design, the governance architecture, the integration scope, the EBITDA model, the operating model redesign — is the work product of the diagnostic phase. The build phase implements a specification, not a hypothesis.
The 90-day commitment is not optimism about build speed. It is the consequence of a diagnostic phase that produces a complete specification before the build begins — a discipline that traditional AI consulting structurally cannot enforce.
VI. The Compounding Asset: What the First Operating Model Builds
The production AI operating model is not only the source of the first engagement's EBITDA. It is the foundation that makes every subsequent AI investment cheaper, faster, and more certain.
Reusable governance architecture. The governance patterns developed in the first production deployment — HITL escalation design, drift monitoring thresholds, SR 11-7 documentation templates, EBITDA attribution methodology — are reusable across subsequent workflows. The second deployment does not design governance from scratch. It extends a proven framework.
Institutional capability. The Agent Manager role, the operating model measurement practice, the decision-rights discipline — these capabilities exist in the organisation after the first production deployment in a way they did not before. The second deployment runs inside an organisation that knows how to operate an AI system, not one that is learning for the first time.
Proof and reference density. The first verified EBITDA case study enables the second, third, and fourth. The reference density — and the trust it enables in the procurement and risk management functions — compounds over time. The sixth deployment is substantially easier to approve than the first, because the first has made the governance architecture credible.
The flywheel. The observability platform that monitors the first production deployment accumulates operational data: throughput rates, loss rate trends, drift patterns, exception frequencies. That data sharpens the next Diagnostic Blueprint — the models for what a credit underwriting AI deployment produces, calibrated against real production outcomes rather than projections. The firm that has been running production AI for 36 months has a benchmark dataset that produces more accurate business cases than the firm making its first deployment. Each production deployment makes the next one better.
Conclusion: The Operating Model Is the Product
The AI strategy consulting industry has produced a generation of roadmaps. The enterprise AI market now has more roadmaps than it has production outcomes — a fact that the $300B annual investment figure and the 81% no-ROI statistic jointly confirm.
The operating model design discipline is the correction. It shifts the question from what should we do with AI? to how do we organise ourselves to make what AI does convert into returns? The answer to the first question is a roadmap. The answer to the second is a production AI operating model.
The six dimensions — structure, processes, decision rights, people and skills, technology and data, performance metrics and incentives — designed as a coherent system, tested for alignment, and committed to production in 90 days: that is the work that converts the $300 billion of AI investment into the 19% of enterprises that are actually compounding returns.
The operating model is the product. Not the strategy deck. Not the pilot results. Not the technology selection. The operating model — the system in which AI capability runs, is governed, and produces accountable returns.
Building it is an architectural decision. It is also the one investment with a guaranteed, measurable payoff.
From diagnostic to production in 90 days.
ExecuteML designs and builds production-grade AI operating models — from Diagnostic Blueprint through 90-day production build to ongoing Operating Model Assurance.
- Six-dimension operating model design, tested for alignment
- 90-day fixed-scope production build
- Ongoing Operating Model Assurance post-launch