How to hand over AI leadership to an internal owner

An outside AI lead sets up governance or ships a first system. Sooner or later the role has to sit with someone on the payroll. Four questions run through a handover: what moves, who takes the role, who signs what, and how the company knows it worked.

Is there a standard way to hand over AI leadership?

None turned up. In October 2026, searches of standards bodies, regulators and journals found no standard, law or study on this exact move.

What exists sits next door. Interim and fractional executives have exit practices. Engineering teams have ways to transfer ownership of a service. A UK financial regulator has rules for handing over a senior role. The NIST AI RMF and the EU AI Act texts checked in October 2026 never mention a change of person.

The evidence is thin. One academic model of interim assignments says the evidence base on interim effectiveness lacks empirical studies. A company linked to two of its authors funded its literature search. Most checklists come from firms that sell interim or fractional staff. Read what follows as practice that others found sensible, plus some points that have no outside source. None of it is proven.

What has to move in a handover?

Documents alone can fall short. Esya, a UK studio that builds AI inside client companies, writes that a folder of documents can be complete while the handover is not. It says the receiving team also needs the route to deploy and controlled access to systems. It needs monitoring data, the evals and the runbook. It needs authority over incidents and practised knowledge. Esya sells related work, so read that as a peer’s view.

The table shows what each source asks for, and how much weight it can bear. Six rows come from sources about handovers, exits or onboarding. The three NIST rows are marked. The NIST text checked in October 2026 never mentions a change of person, so applying it to a handover is this page’s reading.

Nine rows are a lot to move on one day. Google’s book describes a progressive transfer of responsibilities and ownership, including parts of operations, the change management process and access rights. This page reads that as support for moving a handover in steps.

My access list has six categories: the AI register, the LLM gateway, CI/CD, the cloud consoles, the vendor panels and the SSO admin. The client’s internal owner or IT lead revokes each one. Revocation is confirmed in writing the same day. A revoke-all line sits on the last-day checklist.

Who should take the role?

The company side needs one named person with the authority to pause the system. The pilot article says the same. It adds that the person should have written at least one eval case and watched a rollback rehearsal. Someone who was not part of the build inherits a document, not an understanding.

The usual successor is the tech lead or the head of data. A COO takes the role when AI sits deep in company processes. One person holds the role.

This site’s own pages point to two jobs inside the role. One is answering for risk, including the authority to stop a launch. The other is keeping the system working, including the eval case and the rollback rehearsal. One person holds both jobs.

NIST’s playbook suggests managing development apart from testing, so that someone can correct a system independently of its builders. That is about testing, not owners, but it shows why a company might split the jobs.

A US federal memo from April 2025 makes a different choice. The memo from the Office of Management and Budget lets an agency head name an existing officer as chief AI officer. The chief information officer is one example, if that person has significant expertise in AI.

The memo binds US federal agencies only, so for a private company it is an analogy. It also requires agencies to tell the Office of Management and Budget within thirty days when the officer changes or the post is vacant. Later revisions were not checked.

Sometimes nobody inside can take the role yet. The academic paper cited earlier notes that recruiting a senior executive can take six months or more. That figure is not specific to AI roles. No competence framework for a chief AI officer or head of AI from a standards body or regulator turned up in the search. The test the new owner must pass has to be written locally.

How do you know the handover worked?

Test behaviour, not paperwork. Google’s SRE book says a production readiness review is considered a prerequisite for a site reliability team to accept responsibility for the production side of a service. So the receiving side sets a bar before it takes ownership. That is a reading of the text.

A specialist team can refuse a service that fails the review. A single internal owner may lack that power, so agree the check with the outside lead in advance.

Esya’s test is short: the receiving team has practised the response and can make the next change without waiting for the builders to return.

Some checks already appear on this site. The pilot article says the new owner should have written at least one eval case and watched a rollback rehearsal. The approach page lists a related measure under engineering capability. It tests whether your engineers can already roll back a bad model without waiting on the outside lead.

Three checks close my handover, and I judge each one. The new owner writes an eval case. The new owner runs a rollback rehearsal. The new owner handles one incident without me in the room.

Write the full list of checks with the outside lead before the handover starts. For each check, name who judges it and what counts as a pass.

CE Interim, which supplies interim managers, lists three causes of failed handovers. The first is making changes without enough involvement of the internal team. The second is treating knowledge transfer as a final step. The third is relying too heavily on the interim as the central decision maker.

It adds that a handover is a confirmation, not a critical moment, when the organisation already runs on its own before the interim leaves. Read it as a provider’s marketing page.

Esya also lists promises that are not enough on their own, such as “contact the builder”, “documentation has been shared” and “support remains available”.

One more check comes later. Fractionus suggests asking the successor at the thirty-day mark what they wish they had known on day one. It is one vendor’s suggestion.

Who signs what after the handover date?

Every decision that carries a signature needs a name on the handover date. Examples are risk acceptances, policy exceptions, vendor approvals, changes to eval thresholds, rollback calls and answers to customer security questionnaires. Write the old signer and the new signer next to each one, with the date the change takes effect. Customer paperwork that names the outside lead needs a new name, and someone has to tell the customer.

None of the sources in the table above lists who may sign what, so this part is the page’s own advice.

Until the handover date, I sign risk acceptances and the customer security questionnaires that carry my name. From that date, the internal owner signs. The client tells its own customers, and I provide the letter template.

The FAQ on how AI risk is recorded and signed off explains how AI risk is recorded and how the Retainer signs each entry while it is running.

Accountability stays with the company. The NIST AI RMF says executive leadership takes responsibility for decisions about AI risk. The EU AI Act puts the duties of a deployer on the body that uses an AI system under its authority.

On that reading, an adviser’s departure moves no deployer duty, because the duty never sat with the adviser. It is a reading of the text and not legal advice, so ask counsel before relying on it.

Do the AI rules say who must take over?

None of the AI rules checked names a successor. The Commission was asked whether an AI officer is necessary. For the AI literacy duty, its guidance says no specific governance structure is mandated and no certificate is needed. That guidance is not binding law.

Article 26 covers high-risk systems. It asks deployers to give human oversight to people who have the competence, training and authority for it, and the support they need. None of the articles checked asks for an AI officer.

The duties in Article 26 start on 2 December 2027 for systems that are high-risk under Annex III and on 2 August 2028 for those under Annex I. Regulation (EU) 2026/1744 set those dates in July 2026.

Most high-risk systems already on the market before those dates come under the duties only if their design changes significantly. Those intended for use by public authorities must comply by 2 August 2030 in any case. Whether a system counts as high-risk is a question for counsel.

The NIST AI RMF is voluntary. Its Govern function asks for clear, documented roles and for training for the people in them. It also says executive leadership takes responsibility for risk decisions. NIST says it is revising the framework, so check the current text.

The contents of ISO/IEC 42001 list roles, responsibilities and authorities, and competence. Its full text is paid, so nothing from it is quoted here.

None of the NIST or EU texts checked says what to do when the person changes, and the ISO text was not read in full. A handover is where role clauses like these get tested. That is a reading, not a rule.

How long does a handover take?

The sources that say how long a handover takes disagree, and none is about AI. Lengths run from a few weeks to a few quarters, depending on the setting. CompassPoint’s guide for nonprofits describes a short overlap, then a few weeks of drop-in help. Fractionus suggests starting weeks before the last day. Google describes quarters for engineering teams taking over a service.

My handover takes three months, in three phases. In months one and two, the new owner and I work side by side. In month three, the new owner leads and I review. At the end of month three come the final test and the signatures. The end date is fixed in the month-one plan, not the contract.

A fixed date and a ready receiver can pull against each other. Write down both, and agree who may move the date. The Institute of Interim Management code of conduct asks members to agree formal termination terms with the client. These include a handover period and a period of notice.

Sources agree that some reachable help after the last day is useful, and differ on how much. Google’s book says the development team must stay available to advise the receiving team while it settles. CompassPoint’s guide suggests drop-in days, then availability by phone as needed. Fractionus suggests optional advisory time after the exit, though its own page gives two different windows. Whatever is agreed, write down the length, the scope and who may call.

For thirty days after the last day, I answer questions by email within one working day. I hold one review call on day 30. Anything beyond that is a separate agreement.

What this does not solve

The sources are neighbouring fields, vendor advice and voluntary frameworks. No outcome study of AI-leadership handovers turned up, so nothing here shows that a practice leads to better results later.

No engagement has yet ended in a full handover by this method.

It is not legal advice. The readings of the EU AI Act here are plain-language summaries and need counsel before anyone relies on them.

It does not cover the case where nobody inside can take the role. That calls for a hiring or reassignment decision, and no handover method replaces it.

The Fractional CAIO Retainer is built to end with a named internal owner and written decisions. The FAQ on how the Retainer ends and the approach page say more. The Handover Playbook turns these questions into six tables to fill in.