Quentin CasaresData and AI leadership for regulated growth

Reference patterns ยท not client work

Operating models

An operating model is a structure, not a plan. It answers what has to be true on the same day: which decisions the estate serves, who owns the data behind them, which controls prove it, and who is entitled to stop a thing. Every model below is a blank pattern. The structure is real, the organisation is not.

Contents
3 operating models, 2 instruments
Status
Illustrative

How this area differs

A model is a structure. A framework is a movement.

The two get used interchangeably in most decks, which is why so many transformation programmes buy one and need the other. A programme with only a framework never lands. A programme with only an operating model never starts. This site keeps them in separate places for that reason.

Operating models. Six layers ordered top to bottom by dependency, not by sequence. Read one downwards and each layer should justify the one below it. If a layer cannot name the one above it, that layer is being funded for its own sake.

Frameworks. Stages with a gate between each pair, ordered in time. Each stage should hand the next one an artefact. If a stage produces only a meeting, it is not a stage. See the frameworks

The models

Three target operating models

Each sets out six layers and the capabilities that sit in them, drawn as a stack so the dependency runs visibly downwards. The layer descriptions are written to be contested at an executive table, which is the only place a target operating model is ever really tested.

TOM 01

Decision-grade data

Purpose. Produce numbers that a board and a regulator can both rely on, without a reconciliation exercise standing between the two. The model is deliberately narrow. It governs the data that carries consequential decisions and leaves everything else managed at lower cost.

  1. Decision outcomes

    The decisions the estate exists to serve, named before anything is funded: board reporting, regulatory submission, pricing, credit, capital adequacy. A pipeline with no named decision behind it is a cost line, not an asset.

    • Board reporting
    • Regulatory submission
    • Pricing
    • Capital

  2. Critical data elements

    The small population of fields that actually carry those decisions, typically a couple of hundred rather than a couple of thousand. Each one has a business owner, a single agreed definition, and a stated quality tolerance. The discipline is in what gets left out.

    • CDE register
    • Business glossary
    • Quality tolerances
    • Named owners

  3. Lineage and controls

    Where each critical element originates, what transforms it on the way, and which control proves it was right. Evidence is captured at source rather than reconstructed at the end, because a lineage diagram drawn after the fact proves only that someone drew a diagram.

    • Lineage at source
    • Control library
    • Exception log
    • Automated testing

  4. Stewardship and organisation

    Data owners sit in the business, stewards sit in the process, and the central function sets standards rather than doing the work. The failure mode this layer exists to prevent is a central data office quietly becoming the owner of everyone else's numbers.

    • Business data owners
    • Embedded stewards
    • Standards function
    • Governance forum

  5. Platform and architecture

    The warehouse, the catalogue, the quality engine, and the access model. Chosen after the four layers above are settled, never before. Most estates that feel unfixable were architected at this layer first and are now reverse-engineering a purpose to fit it.

    • Warehouse
    • Catalogue
    • Quality engine
    • Access model

  6. Assurance and cadence

    The attestation cycle, the issue log, the handful of metrics that reach the board, and a clear line of sight for internal audit. This layer is what converts a programme into an operating state, and it is the one most often cut when the budget tightens.

    • Attestation cycle
    • Board metrics
    • Issue log
    • Audit line of sight

Read the evidenced writing on this

TOM 02

AI decision rights

Purpose. Give executives usable control over where AI touches a decision, without adding a policy layer nobody can operate. The test of this model is not whether a policy exists. It is whether a named person can stop a use case on a Tuesday afternoon and everyone agrees they were entitled to.

  1. Adoption intent

    A stated position on where AI is permitted to influence a decision and where it is not. Written as boundaries rather than aspirations, because an aspiration cannot be enforced and a boundary can.

    • Permitted domains
    • Explicit exclusions
    • Board mandate

  2. Intake and classification

    One route in, and every use case classified on the way through by who it affects and what it is able to change. Shadow adoption is not a discipline problem, it is usually evidence that the official route costs more than the workaround.

    • Single intake
    • Risk tiering
    • Use case register
    • Triage SLA

  3. Decision rights

    Who may approve, who must be consulted, and who holds the authority to stop. Named roles rather than committees, since a committee can absorb accountability indefinitely and a named role cannot.

    • Approver
    • Consulted
    • Stop authority
    • Escalation route

  4. Model and data controls

    Provenance of the training and prompt data, evaluation before release, and monitoring after it. This layer is where AI governance meets data governance, and where most AI programmes discover their foundations were never load-bearing.

    • Data provenance
    • Pre-release evaluation
    • Drift monitoring
    • Model inventory

  5. Human control points

    The specific moments at which a person must act, and what happens when the system is uncertain. Human oversight described as a principle is decoration. Human oversight described as a control point with a name and a deadline is a control.

    • Review gates
    • Override path
    • Uncertainty routing
    • Competence standard

  6. Evidence and reporting

    What is recorded, how long it is retained, and what can be shown to a regulator without a special project to assemble it. If producing the evidence requires a project, the evidence does not really exist.

    • Decision log
    • Retention standard
    • Regulator pack
    • Assurance reporting

Read the evidenced writing on this

TOM 03

Commercial data platform

Purpose. Run the data platform as operating infrastructure for commercial decisions rather than as a reporting service. The measure of success is decisions changed, not dashboards delivered, and the model is built so that distinction is visible in the numbers.

  1. Revenue decisions served

    The commercial decisions the platform exists for: pricing, retention, channel mix, campaign allocation. Each with an owner in the business who will be asked whether the platform changed what they did.

    • Pricing
    • Retention
    • Channel mix
    • Campaign spend

  2. Data products

    A deliberately small number of governed, versioned products with an owner and a published service level, rather than a lake of tables that everyone queries and nobody maintains. Fewer products, each genuinely supported.

    • Product owner
    • Versioning
    • Published SLA
    • Deprecation policy

  3. Self-service and access

    Who can query what without raising a ticket, and under which controls. Self-service fails when access is granted without a paved road, and it fails equally when the paved road requires an approval chain longer than the analysis.

    • Access tiers
    • Certified datasets
    • Query governance
    • Onboarding path

  4. Delivery model

    Product teams with embedded engineering, and a central platform function that maintains the paved road rather than building on it. The central team's success metric is how little of the work passes through it.

    • Embedded engineering
    • Paved road
    • Platform team
    • Contribution model

  5. Platform economics

    Cost per query, storage tiering, and an explicit expectation that something is retired every quarter. A platform that only ever accumulates will eventually be replaced wholesale, which is the most expensive outcome available.

    • Cost per query
    • Storage tiering
    • Quarterly retirement
    • Chargeback

  6. Value measurement

    Decisions changed, margin moved, and time from question to answer. Usage statistics are reported but are never the headline, because a heavily used dashboard that changed nothing is a cost that looks like a success.

    • Decisions changed
    • Margin impact
    • Question to answer time
    • Adoption

Read the evidenced writing on this

The instruments

What makes a model operable

Two instruments that sit inside the models above rather than alongside them. Neither is a sequence you pass through: one decides how much governance a thing earns, the other decides who is entitled to stop it. A model without both is a diagram.

INS 01

AI use case risk tiering

Purpose. Four tiers that set how much governance a use case earns, based on what it can change rather than which technology it uses. Governance effort rises with the tier so that low-stakes adoption is not taxed at the same rate as a control-affecting system.

  1. Advisory

    Assists an individual, changes nothing on its own. Drafting, summarising, internal search. A human reads everything it produces before it goes anywhere.

    Light governance

  2. Operational

    Feeds an internal process at volume: triage, classification, routing. Errors are absorbed internally but compound quietly, so sampling and monitoring are required.

    Standard governance

  3. Customer facing

    Reaches a customer directly or shapes what they are offered. Fair treatment, explainability, and a clear complaint route become part of the release test.

    Elevated governance

  4. Control affecting

    Touches a regulated decision, a control, or a reported number: credit, capital, surveillance, financial reporting. Board-level approval, full evidence trail, and a named stop authority.

    Full governance

INS 02

The decision rights grid

Purpose. The single page that turns a governance model into something operable. The column that matters is the last one: an organisation that cannot name who stops a thing has not distributed decision rights, it has distributed opinions.

Sample allocation of decision rights across common data and AI decisions
DecisionAccountableApprovesConsultedStop authority
Adopt a new AI use caseSponsoring executiveAI governance forumRisk, legal, data ownerChief risk officer
Change a critical data element definitionBusiness data ownerData governance forumDownstream consumers, financeBusiness data owner
Accept a data quality exceptionBusiness data ownerData governance forumInternal auditChief data officer
Retire a data productData product ownerPlatform leadershipRegistered consumersAny registered consumer
Publish a regulatory numberReporting leadFinance directorData owners, riskReporting lead

The gate

What turns a sample into a published model

Everything on this page is a pattern. None of it is a claim. A model only earns a place beside the evidenced work once it has been run on a real engagement, produced a result someone else can check, and been reviewed by the client whose numbers it moved. That gate is deliberate, and it is why this page says illustrative at the top rather than proven.

Used as intended, a sheet is a starting position for an argument: take the six layers, strike out the ones that do not apply, and find the layer nobody in the room can name an owner for. That layer is usually where the programme is going to fail. The wider argument for why an organisation needs this at all sits in data strategy.