The governance chapter says which controls apply. This chapter says who runs them after launch: who decides, which workflow carries each decision, where the evidence lives, and who pays for shared assets. Counts and durations on this page are illustrative.
An operating model is the answer to one question asked many times: when this happens, who decides, by when, and where is the proof? If the answer is "it depends", the team waits.
1. Decision rights
Decision rights say who holds each decision. The table uses RACI (responsible, accountable, consulted, informed): R does the work, A owns the decision and there is exactly one, C gives input before, I is told after. AI (artificial intelligence) use cases add decisions; they do not reassign the ones the organization already has.
| Decision | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Register a use case (intake) | Product | Business owner | Engineering, architecture | AI governance function |
| Set the risk tier (triage) | AI governance function | AI / model risk | Data and privacy, security, legal and compliance | Business owner, AI governance reporting |
| Approve a tool or provider | Procurement and third-party risk | Procurement and third-party risk | Security, data and privacy, legal, architecture | Engineering, AI governance function |
| Approve the data use | Product | Data and privacy | Security, records, legal | Business owner |
| Decide which prompts and outputs are records | Records | Records | Legal, data and privacy | Engineering |
| Approve the design | Engineering | Architecture | Security, data and privacy | Product |
| Validate a high-tier use case | AI / model risk | AI / model risk | QA (quality assurance), engineering | Business owner, AI governance reporting |
| Approve a change for release | Engineering | The existing change approver | Security, product | Business owner |
| Accept residual risk | Product | Business owner | AI / model risk, security, legal and compliance | AI governance reporting |
| Grant an exception | Product | Business owner | The 2nd-line owner of the control being excepted (approves the deviation from the control standard) | AI governance reporting |
| Invoke the kill switch | Engineering on call | Business owner (or on-call delegate) | Security | All partners |
| Retire the use case | Engineering | Business owner | Records, data and privacy, procurement | AI governance function |
| Test control effectiveness | Internal audit | Internal audit | All of the above | Audit committee, leadership |
Every row has exactly one Accountable role. AI governance reporting is the central risk reporting that rolls these decisions up. Internal audit is not informed of each routine decision: it sets its own audit coverage, follows its own findings, and is told directly only when an event meets the audit-committee or material-incident threshold.
The same roles, read the other way:
| Role | Holds | Never does |
|---|---|---|
| Business owner | The use case, its value and its residual risk | Approves its own exception alone |
| Product | Intake, the backlog, acceptance of the outcome | Sets the risk tier |
| Engineering | Build, operation, the kill switch on call | Approves its own change |
| Architecture | Design approval; shared patterns and the asset catalog | Owns a team's delivery |
| Data and privacy | Data use, privacy impact assessment, residency | Builds the masking itself |
| Security | Threat model, access, secrets, tool permissions | Accepts business risk |
| Legal and compliance | Licence, output rights, applicable regulation | Writes the evaluation set |
| AI / model risk | Risk tier standard; independent validation | Runs the use case |
| Records | Records classification, retention, legal hold reach | Chooses a tool's log setting |
| Procurement and third-party risk | Provider terms, sub-processors, exit plan | Approves the use case |
| Internal audit | Independent testing of all of the above | Designs a control it will test |
2. Central or federated
Most regulated organizations end up with hub and spoke. A small central hub sets standards and runs shared assets. Spokes, the delivery teams, own their use cases and their risk.
| Capability | Hub (central) | Spoke (team) | Why it sits there |
|---|---|---|---|
| AI inventory | Keeps the register and its schema | Registers and updates its own use cases | One register, many contributors |
| Risk tier standard | Writes and versions it with the 2nd line | Applies it at intake | Consistency across teams |
| Approved tools and configurations | Negotiates terms; publishes the list | Picks from the list | Vendor terms are checked once |
| Guardrails as code | Shared CI (continuous integration) checks, secrets block, policy rules | Team-specific rules on top | The floor is common; the ceiling is local |
| Asset catalog | Runs the platform; curates entries | Contributes and reuses assets | Reuse needs one place to look |
| Evaluation | Shared harness, shared risk slices | Task-specific evaluation sets | Teams know their tasks; the hub knows the method |
| Enablement | Learning paths, labs, champions network | Practice in the team's real work | Skills stick only in real work |
| Use-case delivery | Not here | Builds, operates, monitors | The 1st line owns the risk |
A fully central model becomes a queue. A fully federated model repeats the ten date implementations (illustrative) in governance form: every team its own tier, its own evidence and its own gaps.
3. The use-case lifecycle
Every use case follows one path, from intake to retirement. Each step has an owner and leaves an artifact.
| Workflow | Trigger | Owner | Inputs | Output | Target time (illustrative) |
|---|---|---|---|---|---|
| Intake | Someone proposes an AI use | Product, for the business owner | Intake card: problem, users, data, actions, tool | Inventory entry with status "proposed" | Same day |
| Triage | A new intake card, or a material change | AI governance function | Intake card, data classification, tier standard | Risk tier, required controls, required reviewers | 5 business days |
| Approval | Triage complete | The accountable approvers named at triage | Tier, control plan, PIA (privacy impact assessment) and threat model where required | Approve, approve with conditions, or decline, with reasons | 10 business days for medium; longer for high |
| Exception | A control cannot be met yet | Business owner; the 2nd-line control owner approves the deviation | Control gap, reason, compensating control, expiry date | Exception record in the inventory | 5 business days |
| Incident | A monitor alert, a user report or a near miss | Business owner; engineering on call | Signal, affected scope, logs | Containment, notification, fix, post-incident review | Containment within the hour |
| Material change | New model or provider version, new data, new tools, wider use | Technical owner | Change description, new evaluation run | Back to triage; possible step down | Before the change ships |
| Periodic review | The tier's review date | Business owner | Monitoring, incidents, exceptions, evaluation trend | Continue, change, step down, or retire | Yearly for medium, twice a year for high |
| Retirement | Purpose ended, or review says retire | Business owner | Inventory entry, access list, records list | Access revoked, records archived, catalog entry deprecated | 30 days |
The target times are examples, not standards. What matters is that each workflow has one, that it is measured, and that a slow approval is visible instead of silent.
Exceptions are the workflow most likely to rot. Every exception names an owner, a reason, a compensating control (the control that covers the gap meanwhile) and an expiry date. An expired exception stops the use case or is renewed by the same approvers; it never continues by default.
4. Incidents
An AI incident is any event where the use case caused, or nearly caused, harm, a control breach or a wrong output that reached someone who relied on it. Near misses count; reporting them is how the organization learns before harm.
| Step | Who acts | What they do |
|---|---|---|
| Detect | Monitoring, users, reviewers | Raise the signal: a quality alert, a complaint, a rejected output that should not have been possible |
| Contain | Engineering on call | Use the kill switch or a feature flag; switch to the manual fallback; keep the logs |
| Assess | Business owner, security, AI / model risk | Severity, scope, affected customers or records; whether a legal hold applies |
| Notify | Business owner, legal and compliance | Internal partners first; external notice where applicable regulation requires it |
| Recover | Engineering | Fix, re-run the evaluation, roll back, or move to a fallback provider |
| Learn | Business owner, with all partners | Post-incident review; new test cases in the evaluation set; the team steps down if needed |
A provider outage is an incident too. The manual fallback and the provider outage runbook are written before Stage 3, not during the outage.
5. The evidence system of record
Evidence is only useful if it is findable. Each kind of evidence has one system of record, the place that holds the authoritative copy. Other places may link to it; they never hold a second version.
| Evidence | System of record | Owner | Retention |
|---|---|---|---|
| Use case, owner, tier, status | The AI inventory | AI governance function | Life of the use case, then the records schedule |
| Intake card, triage decision, approvals | The inventory, linked to the governance workflow tool | Business owner | Records schedule |
| Exceptions | The inventory, with expiry dates | Business owner | Records schedule |
| PIA and data-flow diagram | The privacy office's register | Data and privacy | Privacy office schedule |
| Threat model and red-team findings | The security register | Security | Security schedule |
| Evaluation sets and results | The evaluation store, versioned | Technical owner | Life of the use case, plus the records schedule |
| Code, reviews, reuse decision records | The source repository and pull requests | Engineering | Repository retention |
| Change and release records | The change management system | Release manager | Change records schedule |
| Traces, prompts and outputs that are records | The log store the records decision named | Records, with engineering | The records schedule; reachable by legal hold |
| Audit findings | Internal audit's system | Internal audit | Audit schedule |
The inventory is the index. From one inventory entry, an auditor reaches every other row.
6. Shared assets: ownership, funding, support, deprecation
Reuse fails when a shared asset has no owner, no budget and no support. The reuse-first chapter covers the catalog; this table covers who keeps it alive.
| Question | Answer in the operating model |
|---|---|
| Who owns an asset? | A named team, recorded in the catalog entry. No owner, no catalog entry |
| Who funds it? | The hub funds the platform and the core assets; consuming teams fund extensions they need. Funding is reviewed with the periodic review |
| What support does it promise? | An assurance level in the catalog: supported, best effort, or deprecated, with a response target per level |
| How do consumers ask for a change? | A change request to the owner; the owner accepts, declines with a reason, or invites an inner-source contribution |
| How is it deprecated? | The owner announces a date and a replacement; the catalog marks it deprecated; CI warns on new use; consumers migrate before the date |
| Who decides it is retired? | Architecture, with the owner, after consumers have moved |
7. The due-date ask, through the operating model
The ask: show the contractual payment due date the same way on every channel, and the payment cutoff time in the customer's own time zone. The AI use is the team's coding assistant on proprietary source.
| Step | What happens | Artifact |
|---|---|---|
| Intake | The developer's team registers the coding assistant use for this repository | Inventory entry, medium tier proposed |
| Triage | The AI governance function confirms medium: proprietary source, no customer data in prompts | Tier decision with controls: data classification check, evaluation, traces, reviewer |
| Approval | Architecture approves the design: reuse the shared temporal-domain contract | Design approval; reuse decision record |
| Build | The coding agent drafts the change as a pull request; the reuse check passes | Pull request with tests and the decision record |
| Release | The existing change approver approves; the developer who prompted the agent does not | Change record |
| Monitor | Channel consistency checks run daily after release | Monitor results in the evidence index |
| Review | At the yearly review, the use case continues | Review record |
At the top of the ladder, this delivery shape is what ask-to-release describes: front-loaded artifacts, agents doing bounded work, and humans holding the decisions they are accountable for.
These are patterns, not legal or regulatory advice. The roles, workflows and targets follow the organization's own policy and jurisdiction.