The documentation was written at the end
What we do. Runbooks, decision records and access registers are written as the build proceeds and reviewed by the person who will use them, not assembled in the final week by whoever has time.
AISTORSServicesEnablement and handover
Service 10Your team, able to run it without us.
You should not need us in year two.
For teams who have inherited a system nobody internally fully understands. Handover is where most of the value in an engagement is either protected or quietly lost. We treat it as delivery with its own artefacts and its own test: your people run the system in front of us, using only what you already hold.
Book a 30-minute call
The handover test
Your team runs the system while we watch and say nothing. Anything they cannot do from the documentation is a defect in the documentation, not in your team.
01
Who this is for
If the left column is not you, say so on the call and we will tell you what would help instead.
This is for you if
- You have a system nobody internally owns fully. Built by us, by somebody else, or by a person who has since changed team or left the organisation.
- You intend to run it yourselves. Not as an aspiration for later, but as a plan with a date, which is what makes this work worth buying.
- Your team is capable and under-briefed. Good engineers who have not worked with evaluation sets, prompt practice or this particular platform before.
- Somebody must be accountable internally. A named person who will own accuracy, cost and drift once we are gone, and who needs to be genuinely ready for it.
- You want the practice, not just the artefacts. How to build an evaluation set, how to read a drift report, how to decide whether a model change is safe.
This is not for you yet if
- You want a certificate for the team. We are not a training provider and we do not award anything. If a formal qualification is the goal, we will point you at one.
- Nobody has been given time for it. Enablement with no protected time on your side becomes a set of documents nobody reads. We would rather wait until the time exists.
- The system should not survive. If the honest answer is that the thing was a mistake, transferring it is the wrong spend. We will say so.
- You want us to stay indefinitely. That is a managed operation engagement and it is a different page. This one is explicitly about ending the dependency.
- There is nothing written down and nobody to ask. Then the first job is reconstruction rather than handover, and we will scope that honestly instead.
02
What we fix, and how
Four things go wrong at handover. All four are predictable and all four are cheap to prevent.
Only one person understood it
What we do. Sessions are run with the whole team that will operate the system, and the runbook has to work for the person who was on holiday. If it only works for the person who attended, it has failed.
Nobody knows how to tell whether it still works
What we do. We teach the evaluation practice, not just the result: how to build and version a test set from real cases, how to read a drift report, and how to decide whether a model change is safe to accept.
Handover was a meeting rather than a test
What we do. The final step is your team operating the system in front of us, using only the documentation you hold, while we watch and say nothing. Every gap that surfaces gets fixed before we sign off.
03
What you get
Six deliverables, and the last one is the only real test of the other five.
What we build
- Runbooks for the work as it is actually done. Routine operation, the failure paths, the escalation path and the rollback, written for the person on shift rather than for the person who built it.
- Infrastructure as code handover. The environment in your repository, with the decision records explaining why it is shaped the way it is, so the next change is informed rather than archaeological.
- Evaluation and prompt practice for your team. How to build a test set from real cases, version it, score against it, and decide whether a change is safe. The practice, not just the current results.
- Internal AI usage policy, technical sections. What may be used, with what data, under what approval, and how exceptions are handled. Your legal and HR functions own the remainder and we will say which is which.
- Working sessions with the people who will own it. Held in your environment on your systems, not on a sample project, because the questions that matter only appear against real data.
- A witnessed handover. Your team runs the system while we observe. Anything they cannot do from the documentation is a defect in the documentation, and we fix it before sign-off.
What this is not
- Not a training course. No syllabus, no certificate, no attendance register. It is scoped as delivery and judged by whether your team can operate the system.
- Not slideware. Sessions are run against your systems and your data. A deck describing how the system works is not a runbook.
- Not a dependency in disguise. If anything can only be done by us at the end of this, it is an unfinished deliverable rather than an ongoing service opportunity.
- Not a substitute for capacity. If your team has no time to operate the system, enablement will not create it. That is a staffing decision and we will name it as one.
- Not a rebadged managed service. If you want us to keep running it, that is honest and it is a different engagement. We will not sell this as a route to that.
04
How it runs
The last phase is the only one that proves the others worked.
01
Establish who will own what
Named people against accuracy, cost, drift and escalation. Enablement without named owners is a reading exercise, and this is the step most often skipped.
02
Assess what is already documented
What exists, what is out of date, and what only lives in somebody's head. The gap list is the scope of the work rather than a preamble to it.
03
Write the runbooks with the operators
Drafted with the people who will use them and tested by the person who was not in the room, because that is the only honest test of a runbook.
04
Working sessions on your own systems
Evaluation sets, drift reports, model change decisions and the failure paths, worked through against your real data rather than a sample project.
05
Witnessed handover, then sign-off
Your team operates the system while we watch without intervening. Every gap that appears is fixed before sign-off, and sign-off is yours to give rather than ours to declare.
05
Platform native
Enablement is delivered on whatever you already run, because transferring practice on a different platform transfers very little.
Azure
Entra ID and RBAC for the access model, Bicep or Terraform in your repository, Monitor and Log Analytics for the reports your team will read, AI Foundry evaluation tooling.
AWS
IAM and Organizations for the access model, CDK or Terraform in your repository, CloudWatch and X-Ray for the operational view, Bedrock evaluation tooling.
Google Cloud
IAM and Organisation Policy, Terraform in your repository, Cloud Monitoring and Logging, Vertex AI evaluation and model registry.
DigitalOcean and self-hosted
Terraform or Pulumi in your repository, DOKS operational practice, and the evaluation harness run in your own estate where models are self-hosted.
Everything handed over runs on your accounts, in your repository, under your identity provider. If any part of the operational picture depends on an account of ours, the handover is incomplete and we will say so rather than close the engagement.
06
Questions we are actually asked
Is this a training course?
No, and that distinction matters commercially. Courses are scoped in days and measured in attendance. This is scoped as delivery and measured by whether your team can run the system without us, which is a different thing and usually cheaper than a course plus a dependency.
Why would you make yourselves unnecessary?
Because the alternative is a client who resents the dependency, and because handover is the part of the market most providers do badly. We would rather be re-hired for the next system than retained for the last one.
Can you embed with our team instead?
Yes. An embedded engineer works inside your team, your standups and your repository, under your priorities. It is the fastest way to transfer practice, because your people watch decisions being made rather than reading about them afterwards.
Our team is sceptical about AI. Is that a problem?
It is usually an advantage. Sceptical engineers ask the questions that keep a system honest, and the people who will be asked to trust the output are right to want to see the evaluation set. We would rather work with that than around it.
What if the people you train leave?
Then the documentation has to carry it, which is why the runbooks and decision records are the deliverable and the sessions are the accelerant. If knowledge only exists in the people who attended, we have not done the job.
Do you write our internal AI usage policy?
We draft the technical parts, covering what may be used, with what data, under what approval, and how exceptions are handled. Your legal and HR functions own the rest, and we will say which parts are which rather than presenting a complete policy we are not qualified to write.
07
Next step
Bring the system nobody wants to be responsible for.
Thirty minutes, no obligation. Tell us what is running, who is supposed to own it, and what they cannot currently do. We will tell you whether this is a documentation gap, a practice gap or a capacity gap, because the three have different answers and only two of them are ours.
- Starts with
- A short assessment of what is documented today and who is expected to own it. Read-only access is enough to begin.
- Investment
- Scoped on the introductory call. Where enablement follows a build we delivered, much of it is already included and we will say so.
- If the gap is capacity
- We will tell you plainly, because no amount of enablement fixes a team with no time. You keep the assessment.
Book a 30-minute call
Or write to [email protected].
08
Related work
Service 09
Managed AI and cloud operations
If you would rather not run it yourself yet, this is the honest alternative, with an exit designed in from the start.
Service 05Cloud architecture and migration
Where the environment is not yet in code, this is the work that makes a real handover possible.
Service 08AI governance and compliance
The policy, audit trail and incident playbook your team will be expected to maintain after handover.