Who owns an AI system after the pilot ends

What loses its owner when a pilot ends

During a pilot, a small team holds everything in their heads: why a prompt says what it says, which cases were excluded and which model version was tested. Google's Rules of Machine Learning make the same point about data features: know who maintains each one, and when that person leaves, make sure someone else has the information. AI systems add parts that change from outside. Anthropic, for example, retires older models on a published schedule and promises at least 60 days' notice for publicly released models. Someone has to read that notice, test the replacement on your cases and ship the change before the date.

An ownership map for one AI process

The roles below are an example for a hypothetical invoice-checking agent. The names will differ in your organisation, but every line needs one.

• The system as a whole: the head of accounts payable, accountable for results, cost per case and scope. The AWS Generative AI Lens suggests a single-threaded owner for ongoing performance evaluation.
• Prompts, tools and orchestration code: the engineering team that runs the service.
• Model choice and versions: the same team, with each model recorded in a model catalogue together with its provider's deprecation dates.
• Data sources: the owner of each source system, who approves use and is told about schema changes.
• Test set: the process owner and the engineering team together, with an expert adding new failures as they appear.
• Review queue and corrections: a team lead in accounts payable.
• Authority to switch it off: named people on both sides. NIST's framework asks that responsibilities to supersede, disengage or deactivate an AI system be assigned and understood.

Who approves which change

• Prompt wording within the current scope: the engineering team, provided the regression suite passes.
• A new model version or provider: engineering proposes, and the process owner approves after seeing regression results and the cost per case.
• Thresholds that change how many cases reach a person: the process owner, because they change both reviewer hours and risk.
• New case types or new write actions: the process owner together with security and the affected data owners, and with your data protection officer where personal data is involved.
• Retiring the system: the process owner, with a decommissioning plan. NIST lists processes for phasing out AI systems safely as part of governance.

A written policy for when quality slips

Google's example error budget policy states in advance what happens when a service misses its objective: changes other than urgent fixes stop until it recovers, an incident that uses more than a fifth of the budget gets a postmortem, and disagreements go to the CTO. An AI system benefits from the same kind of agreement. A hypothetical version might read as follows, with critical events handled separately from gradual drift.

1. 1

   Critical events

   An unauthorised action, exposed data or an error the policy classes as critical needs no waiting period. The affected action or the whole system is switched off at once, the cases go to full human review and the incident process starts.

2. 2

   Trigger

   For non-critical drift: the sampled error rate for any case type stays above the agreed level for two consecutive weeks.

3. 3

   Immediate action

   That case type returns to full human review, and changes other than fixes pause.

4. 4

   Decision

   The process owner chooses between a fix, a narrower scope and switching the case type off, based on the failure analysis.

5. 5

   Escalation

   If engineering and the process owner disagree, a named executive decides within an agreed time.

Where the decisions are recorded

The AWS lens describes an AI policy document as the central authority for operational questions about AI workloads and asks that it be kept current. For a single system, one page in the repository next to the code is enough: owners, change approvals, the quality policy, who can switch it off and how it would be retired. NIST's framework asks for roles and lines of communication to be documented and clear. Review the page whenever an owner changes, and check it when you onboard a new provider.

Warning signs that the page is not being used: a model on a provider's deprecation list still serving traffic, a test set unchanged while the process has changed, a review backlog nobody escalates, and nobody able to say who may switch the system off. When we hand over a system, the code, test set, runbooks and monitoring go with this page.

From pilot to productionPlanning how to leave an AI vendor