How a fractional AI engagement should end: plan the exit on day one.

A good fractional AI engagement ends with your team able to run, change and stop every AI system without the fractional leader. To get this result, plan the exit on the first day. Write the handover items into the contract. Put an internal owner next to the leader from week one. Keep all code, prompts, evals and credentials in your accounts from the start.

Most sellers describe how a fractional engagement starts. Few describe how it ends. In one short interview, a fractional Chief AI Officer said that the goal is not to be the long-term CAIO. The goal is a succession plan. That is correct. This page describes what that plan contains.

I work as a fractional AI CTO. I use this list at the end of my own engagements.

Why does the exit matter so much?

A fractional leader makes many decisions in a short time. Many of these decisions live only in the leader’s head: why this model, why this limit, why this prompt, why not that vendor. When the leader leaves, the reasons leave too.

Then three problems occur:

• Nobody can change the system safely. The team does not know which change breaks what.
• Nobody can answer an auditor. The documents are missing or out of date.
• The company pays again. It hires a new consultant to learn what the old one knew.

A clean exit prevents all three problems.

What are the reasons that an engagement ends?

The handover items are the same for all four reasons. Only the time is different.

What must the company keep?

Use this list as the handover checklist. Each item must be in your accounts, not in the leader’s accounts.

Code and configuration

• All source code in your repositories.
• All prompts, with a history of changes.
• All configuration: model names, parameters, limits, feature flags.
• Infrastructure definitions, if the systems run in your cloud.

Evals and data

• The eval sets: the examples and the known good answers.
• The eval scripts and the latest results.
• A description of how each eval set was built, so that the team can add to it.

Operations

• A runbook for each system: how to start it, how to stop it, how to change the model, what to do in an incident.
• The monitoring dashboards and the alert rules.
• The cost dashboard and the budget limits.
• A list of known problems and open risks.

Decisions

• A decision log. Each important decision, with the date, the options, the choice and the reason.
• The vendor list. Each AI vendor, the contract, the data that goes to it and the renewal date.
• The model plan. Which models are in use, and what to do when a provider retires one.

Governance

• The AI usage policy and the approved tool list.
• The risk register with owners.
• Regulatory documents, for example records for the EU AI Act obligations that apply to you.

Access

• A list of all accounts and keys that the leader had.
• Confirmation that each account and key is removed or rotated.

What is a good exit timeline?

A clean exit takes about four weeks. Shorter exits lose knowledge. Longer exits cost money and delay the internal ownership.

In week 3, the change is a real test. If the owner can change a system safely with the evals and the runbook, the handover worked. If not, extend the handover by one or two weeks.

How do I prepare for the exit from day one?

Most of the exit work is cheap if you do it from the start. It is expensive if you do it at the end.

1. Write the exit into the contract. List the handover items and the notice period.
2. Name an internal owner on day one. The owner attends all design reviews and does part of the work.
3. Keep everything in your accounts. No code, prompts or documents in the leader’s private accounts.
4. Ask for a decision log from week one. One short entry for each important decision.
5. Ask for a monthly update of the runbooks. Not only at the end.
6. Use your own credentials. The leader uses accounts that you create and you can remove.

What does a bad exit look like?

Watch for these signs before and during the exit:

• The leader keeps the prompts. Prompts are part of the system. They must belong to you.
• The eval set is missing or small. Without evals, your team cannot change the system safely.
• The runbook says “contact the consultant.” A runbook must work without the consultant.
• The systems use the leader’s API keys. Your systems then stop when the leader’s account stops.
• The leader offers a support retainer as the only way to keep the systems running. Support can be useful. But it must be your choice, not a necessity.
• The decision log is empty. Your team will not know why the system works the way it works.

If you see these signs, stop and fix them before the last payment.

What about the transition to a full-time hire?

When a full-time AI leader replaces the fractional leader, use an overlap. Two to four weeks of overlap is usually sufficient.

During the overlap:

• The fractional leader explains each system and each decision.
• The new leader reads the decision log and asks questions.
• The new leader decides which decisions to keep and which to change.
• The fractional leader helps with the first change that the new leader makes.

Do not ask the fractional leader to defend old decisions. The new leader has the right to change them. The goal is that the new leader knows the reasons before any change.

A good fractional leader also helps with the selection of the full-time hire. The leader knows the systems and the team. The leader can write a realistic job description and do part of the technical interview.

What about a step down instead of a full exit?

Many engagements do not stop completely. They step down. For example, from two days each week to a two-hour review each month.

A step down works well when:

• The internal team runs the systems.
• The company wants a second opinion on new tools and vendors.
• The company wants a monthly check of cost, incidents and risks.

Even with a step down, do the full handover first. The monthly review must not be the only place where the knowledge lives.

What must the contract say?

Add these clauses to the contract for any fractional AI engagement:

• Ownership. All code, prompts, evals, data, documents and configuration belong to the company from creation.
• Location. All work is stored in company accounts.
• Handover items. The list in this page, or your own version of it.
• Notice period. Short, for example 30 days, and the handover happens in this time.
• Access. The leader uses company accounts. The company can remove all access in one step.
• Post-exit support. Optional, for a defined fee and time. Not required to run the systems.

What is different for each type of system?

The general checklist applies to all systems. Some types of system need extra items.

Retrieval systems (systems that search your documents and give the results to a model):

• The list of document sources and how often they update.
• The method that splits documents into parts, and the reason for it.
• The process to add a new source or remove an old one.

Agents (systems where the model calls tools and does actions):

• The list of tools that each agent can use.
• The actions that need human approval, and who approves them.
• The limits: number of steps, cost per run, time per run.
• The procedure to stop an agent quickly.

Configured third-party tools (AI features inside software that you buy):

• The configuration settings and the reason for each one.
• The data that the vendor gets, and the contract terms.
• The admin accounts. Make sure that a company person has admin access.

Internal assistants (chat tools for employees):

• The approved use cases and the forbidden ones.
• The training material for new employees.
• The usage reports and who reads them.

A hypothetical example

A company used a fractional AI leader for nine months. The leader built two systems: a document assistant for the legal team and an agent that prepared purchase orders from email.

At the exit, the company found three problems. The agent used an API key from the leader’s own account. The eval set for the document assistant had only 20 examples. The decision log stopped after month three.

The company and the leader fixed these problems in a four-week exit. The team created a company API key and rotated it into the agent. The legal team and the leader added 150 real examples to the eval set. The leader wrote the missing decisions from memory and from the weekly updates. One month after the exit, the internal owner changed the model of the document assistant. The eval suite caught a drop in quality before the change went live. The owner kept the old model and asked the vendor about the problem. That is a successful handover.

How do I check that the exit worked?

One month after the exit, ask your internal owner these questions:

1. Did you change any AI system this month? Did the evals run before the change?
2. Did any incident occur? Did the runbook help?
3. Do you know why the system uses its current model?
4. Do you know the monthly AI cost and the budget limit?
5. Did you need to call the old leader?

If the answers are mostly good, the exit worked. If the owner needed the old leader for basic tasks, some knowledge did not transfer. Fix the documents now, while the old leader is still easy to reach.

Next step

Add the handover checklist to your current contract, or to the next one. If you take over from an agency instead of an individual, use the AI agency handover checklist. To see how I structure my own engagements, read how my fractional AI CTO engagement works.