A customer-support assistant begins returning incorrect advice after a supplier changes its model. The application team can switch off the feature, customer operations can change staff guidance, and procurement can contact the supplier. Nobody is sure who should decide whether the service remains available while the problem is investigated.
The organisation may have an AI policy, a risk committee, and a named project sponsor. The missing element is an operating arrangement that connects those roles to the decisions now required. During an incident, responsibility needs to be specific enough for people to act without negotiating the structure again.
An AI governance operating model describes how people, authority, processes, information, and resources work together to govern AI. It assigns decisions and handoffs throughout the service lifecycle. The governance framework establishes the required activities; the operating model makes them executable within the organisation.
Strategy identifies where AI should create value. The operating model turns responsible-AI principles and applicable regulatory requirements into recurring business decisions, review workflows, and technical controls. Its test is whether people know who can approve a use, what evidence is needed, and how safeguards continue to operate after launch.
Connect Three Layers of Governance
The following layers separate direction, coordination, and execution without requiring three new departments. Smaller organisations may combine roles; the responsibilities and decision limits still need to be explicit.
| Layer | Participants | Decisions and responsibilities | Handoff to the other layers |
|---|---|---|---|
| Strategic oversight | Board or delegated board committee and relevant executives, such as the CEO, CIO, CISO, Chief Data Officer, and General Counsel. | Set enterprise risk appetite, allocate resources, approve defined higher-risk uses, and hold leaders accountable. | A mandate, delegated limits, funding, and requests for assurance on material risks. |
| Operational management | A cross-functional AI governance committee, centre of excellence, and risk, legal, privacy, and security representatives. | Coordinate intake, risk tiering, review routes, inventory maintenance, exceptions, and escalations. | Clear release conditions and reusable patterns for teams, with unresolved decisions escalated to authorised leaders. |
| Technical and domain execution | Data scientists, engineers, MLOps or platform teams, service operators, business-unit specialists, and product owners. | Build and operate controls, test for bias and data leakage, evaluate performance, implement releases, and report incidents. | Versioned evidence, monitoring findings, and requests for decisions beyond delegated scope. |
The operating model should connect these layers through tools as well as meetings: a maintained inventory, linked assessment and approval records, deployment controls, and alerts with named recipients. For the support assistant, a supplier-change alert should reach its technical owner, trigger the agreed evaluation, and escalate any decision about continued customer use within a defined time.
Higher-risk approval does not need to mean that the board approves every release. Define which matters are reserved for senior authority and which can be decided under delegation. Equally, a central committee should not become the default owner of every application simply because it coordinates reviews.
Begin With Decisions People Actually Need to Make
List the recurring decisions around a representative application. Who sponsors the use? Who classifies its risk? Who can approve access to a data source? Who authorises release, accepts a residual risk, approves a material change, or suspends the service?
These decisions do not all need the same owner. A data owner may approve access while the business owner decides whether the proposed use is worth pursuing. Security and privacy specialists provide assessments within their areas, and an authorised release owner confirms that required conditions have been met.
Distinguish advice, approval, and operation. A security reviewer can identify a weakness without having authority to fund its correction. An engineer can disable a service without being responsible for deciding how customers will be supported afterwards. The model should connect those responsibilities explicitly.
Record delegated limits. A team might release routine changes within an approved use while needing further review to connect a new data source or enable external actions. Defined limits let work proceed while making changes in authority visible.
Use existing management authority where possible. Creating an AI committee does not automatically give it the power to change budgets, business processes, or supplier contracts. If a new body is needed, its mandate should identify the decisions it can make and the decisions it must escalate.
Separate Business Ownership From Technical Operation
The business owner should understand the intended outcome, affected people, and consequences of error. For a support assistant, that may be the leader responsible for the customer-service process. Their role continues after the initial project funding ends.
The technical service owner is responsible for operating the application and its dependencies. That includes monitoring, release management, access arrangements, failure investigation, and coordination with platform or supplier teams. The owner needs enough information to maintain the deployed configuration, including prompts and retrieval settings where relevant.
Data ownership requires its own attention. Someone must establish which policies and records are authoritative, who can access them, and how updates reach the application. A technical team can maintain an index without being qualified to decide whether a refund policy is current.
One person can hold more than one role in a small organisation. The distinctions still help reveal conflicts and gaps. If the developer is also the business sponsor and release approver, a consequential change may need additional challenge from someone able to examine the assumptions independently.
The allocation should survive staff changes. Record roles in a maintained service record, name deputies where necessary, and include handover in role transitions. A project’s old presentation is unlikely to provide a reliable escalation route several years later.
Design Specialist Review as a Service
Privacy, security, legal, procurement, and risk teams often support several business functions. Their involvement needs a clear entry point and sufficient capacity. Requiring specialist approval without defining what reviewers receive can create avoidable queues and repeated requests for information.
An intake record should explain the purpose, users, data flow, supplier, expected consequences, and proposed controls. Reviewers can then identify relevant issues and request additional evidence. Teams should know which questions can be resolved through established patterns and which require a more detailed assessment.
The review’s outcome should be actionable. A finding might prohibit a data source, require a configuration change, or permit deployment subject to a documented condition. Record the owner of each action and who confirms completion. A comment such as consider privacy gives the delivery team little basis for proceeding.
Disagreement needs a route too. If the business wants to proceed despite an identified risk, specify who has authority to decide and which restrictions cannot be waived internally. Internal risk acceptance cannot remove a legal obligation. The compliance article explains how legal applicability differs from voluntary governance practice.
The voluntary NIST AI RMF can inform the risk-management work, while ISO/IEC 42001 addresses an organisational management system. Neither supplies the specific staffing, authority, or review capacity the business must establish.
Translate relevant principles and obligations into assigned work. A requirement for oversight becomes a reviewer role, access to evidence, override authority, and an escalation route. A monitoring requirement becomes a signal, threshold, recipient, and response. Where the EU AI Act or another law applies, legal specialists identify the duty and relevant organisational role; the operating model allocates delivery and evidence ownership. The framework article covers the control structure, leaving this model focused on who performs and authorises the work.
Make Handoffs Carry Decisions and Evidence
A use case moves between people as it progresses from proposal to procurement, development, release, and operation. Each handoff should transfer the information needed for the next decision, including restrictions and unresolved questions.
For the support assistant, procurement needs the permitted data and use to evaluate the supplier arrangement. Developers need the approved access boundaries and required review behaviour. Operations needs the configuration, monitoring, fallback, and supplier escalation details. The business owner needs evidence about quality and the work users must perform.
Use a shared record where practical, linking to authoritative evidence rather than copying it into several disconnected forms. If a restriction changes, there should be a reliable way to identify the affected application, contract, evaluation, and staff guidance.
Make acceptance explicit at the receiving end. If operations finds that monitoring cannot detect a known failure, the handoff should return that gap to an owner for resolution. Recording that the deployment documents were sent does not establish that the receiving team has what it needs to support the service.
Handover into production deserves a concrete readiness check. Confirm that someone accepts operational ownership, the necessary access exists, alerts reach the right people, support is funded, and the fallback has been exercised. A project can pass its functional tests while leaving these service responsibilities unresolved.
Retirement creates another handoff. The service owner needs to remove integrations and access, while business teams communicate the replacement process and information owners determine data handling. Assign those tasks before the application becomes an unsupported dependency.
Give Escalation Enough Authority to Resolve the Problem
When the assistant returns incorrect advice, the first decision may be whether to restrict use immediately. Authorise an appropriate operational role to contain the issue, with conditions for notifying the business owner and specialists. Waiting for a scheduled committee meeting may be incompatible with the consequences of continued use.
Containment and restoration can require different decisions. Engineers may confirm that a technical defect has been corrected, while the business owner needs evidence that staff can use the service appropriately again. Privacy or legal teams may need to assess affected records and any external obligations.
Define what happens outside normal hours and when key people are absent. Identify deputies, emergency access arrangements, and the manual process. An escalation diagram that depends on one unavailable sponsor has limited operational value.
Practise with a scenario that crosses organisational boundaries. For example, a supplier update changes output quality, a misleading answer reaches a customer, and logs may contain sensitive information. Follow the decisions from detection through containment, investigation, communication, and restoration. Record where authority or information was missing.
The exercise should also examine suppliers. The organisation needs to know who can raise an incident, what evidence can be shared, and what happens while the supplier investigates. Outsourced infrastructure does not eliminate the need for an internal decision about continued use.
Fund the Work and Check Whether the Model Functions
Governance creates continuing work: maintaining inventories, reviewing changes, evaluating behaviour, investigating incidents, and updating controls. Allocate that work explicitly. Adding it to job descriptions without time or funding can leave formal ownership disconnected from actual capacity.
Shared capabilities need an owner and a funding arrangement. If a central team operates identity, model access, or evaluation tooling, departments should understand its service boundaries and their own responsibilities. The centre-of-excellence and federated-model comparison considers alternative allocations of those capabilities.
Measure the operating model through decisions and outcomes. Examine unresolved actions, review waiting time, repeated handoff failures, exceptions, and incident response. A large number of committee meetings does not establish that the important decisions were timely or well supported.
Check a sample of live services periodically. Can the owner explain the approved use? Can the technical team identify the current configuration? Can staff report a problem and reach someone able to respond? These checks connect the documented model with the way the organisation actually works.
Revise the arrangement when repeated friction reveals a structural problem. A common review might become a reusable service pattern. A department with stronger capability might take on more delegated decisions. A consequential service without reliable support may need a different owner or a narrower scope.
For the support assistant, a working operating model means the supplier change reaches an accountable person, containment happens within known authority, and restoration follows agreed evidence. The same allocation should help during routine releases, when clear ownership gives teams a dependable route from proposal to a service they can sustain.
