Handing over a GenAI system: preparing operations with internal teams
A GenAI handover is ready when the internal team can operate, restrict, evolve and explain the system without relying on an informal exchange with the build team.
Handing over a GenAI system to internal teams is not just about delivering a repository, a prompt and a demo. It is ready when the team that will operate it can answer four questions without ambiguity: which scope is authorised, who decides on a change, how to restrict the system when something deviates and which evidence explains an execution. Prepare this handover before the end of the build, then test it as an operational capability.
In short
- A successful handover makes the internal team autonomous in operations, not just a recipient of documentation.
- Distinguish four responsibilities: operate, decide, evolve, and investigate or restrict.
- Run a takeover exercise before delivery: controlled change, simulated incident, access removal and return to a reference version.
- Keep a handover file linked to versions, tests, decisions and procedures. It must not contain secrets.
NIST's AI RMF organises AI risk management around governance, context, measurement and management functions. Its generative AI profile points out that governance must accompany the system's life cycle, not only step in at go-live.[1][2]
Why should the handover start before the end of the build?
A GenAI system often changes beyond the application code. A model, a prompt, a corpus, an authorisation rule, a connector or an evaluation configuration can alter its behaviour. If the team operating the system discovers these dependencies at delivery, it receives a responsibility without the real capacity to carry it.
The handover is therefore a production decision. It must show that the people in charge can understand the scope, observe deviations, take a change decision and scale the system back if needed. This logic aligns with the GenAIOps practices described by Microsoft, which link integration, deployment, evaluation and monitoring across the life cycle.[3]
Do not aim for an exhaustive file. Aim for evidence usable by the people who will have to act when data, a tool, a model or a rule changes.
Which responsibilities must become autonomous?
Handing over code is not enough if it does not specify who can operate, decide and intervene. The following grid is a working summary for a GenAI handover. It is not a universal standard.
| Responsibility | Question to settle before the handover | Useful evidence |
|---|---|---|
| Operate | Who monitors the system and applies routine procedures? | Short procedure, useful alerts and access to operations tools |
| Decide | Who accepts a scope extension or an open risk? | Decision criteria, named owner and review date |
| Evolve | Who can change the model, prompt, corpus or a connector? | Change rule, reference version and tests to rerun |
| Investigate or restrict | Who handles a deviation and who can reduce, stop or disable a capability? | Usable trace, escalation procedure and tested restriction action |
Microsoft stresses the importance of clarifying roles and responsibilities in the teams that transform and operate platforms. For a GenAI system, this clarification must cover decisions specific to data, models, tools and access rules.[4]
Which handover file should you prepare?
The handover file must link the real system to possible actions. It can be short if its items point to the right technical artefacts.
| Part of the file | What it must make possible | Content to include |
|---|---|---|
| System scope | Know what is authorised and what is excluded | Use case, users, data, tools, forbidden actions and refusal conditions |
| Reference version | Compare a change with the accepted state | Model, prompts, rules, index, corpus, connectors and associated evaluation results |
| Operations | Respond to routine signals without improvising | Useful indicators, alerts, recovery procedures and degraded mode |
| Access and revocation | Know who holds which capability and how to remove it | Identity owners, authorisation rules, revocation procedures and service accounts concerned |
| Decisions and risks | Find out why a limit was accepted or postponed | Open risks, go/no-go criteria, approvals and review triggers |
| Build team support | Avoid an implicit dependency after delivery | Agreed support scope, escalation paths and items handed to the internal team |
Do not put secrets, API keys or passwords in this file. Instead, document the controlled location, the owner, the access procedure and how to revoke or replace each technical identity.
For the reference version and change evidence, the guide on documenting a GenAI system for a technical team details the elements that must remain tied to a decision.
How do you test the handover before delivery?
A team does not become autonomous because it attended a demo. Run a short exercise with the people who will actually take over operations. The goal is not to cause an incident. The goal is to check that the information and rights make it possible to act.
- Replay a normal execution. The team finds the active version, the sources or tools used and the expected result for a representative scenario.
- Handle a controlled deviation. A test case triggers a refusal, a non-compliant output or an unavailable dependency. The team applies the procedure and records the decision.
- Remove a capability. The team restricts a source, a role, a connector or an impactful action without silently changing the rest of the scope.
- Prepare a change. It proposes a change of model, prompt, corpus or tool, identifies the tests to rerun and requests the expected approval.
- Revert to a reference. It knows which approved state to restore if the candidate version does not meet the set criteria. The guide on conditions for suspension, rollback and escalation helps distinguish immediately blocking a capability, restoring a reference and authorising resumption.
These exercises turn knowledge transfer into operational evidence. They also reveal hidden dependencies, for example a procedure known to only one person, an access that was not transferred or a change decision without an owner.
The go/no-go grid between an LLM prototype and production can be used to structure the criteria and evidence before opening. The handover adds one question: can the team taking over the system apply these criteria without relying on an oral interpretation?
How should change decisions be distributed?
Not every change has the same reach. Replacing an interface label, opening a new corpus, changing a system prompt and connecting a tool that can write to an information system should not follow the same path.
Prepare a simple matrix that answers four points for each type of change:
- who can propose the change;
- which tests or controls must be rerun;
- who accepts the new scope or the residual risk;
- who can revert to the previous state if a deviation is observed.
For a RAG, a change of corpus or access rule must in particular be linked to the people concerned, the retrieval rights and the refusal cases. For an agent connected to business tools, clearly distinguish changing a routing rule from opening a new impactful action. Our guides on human approvals for an agent and AI agent traceability help separate proposal, control, authorisation and execution.
Which signals show that a handover is not finished?
The handover remains incomplete when the internal team cannot answer an operational question without contacting the build team again. The most useful signals are concrete:
- nobody knows where to find the active version or the reference tests;
- a change of model, corpus or connector has no defined approval path;
- access rights are known informally or cannot be revoked by the right owner;
- traces cannot link an execution to a configuration, a decision or a recovery procedure;
- the only way to scale the system back is an undocumented intervention by the team that built it;
- the support expected after delivery is not defined.
These signals do not prove that the system is faulty. They show that its operation still depends on knowledge that has not been transferred. In that case, reduce the scope, complete the takeover exercise or postpone a change until the team can take on its consequences.
Which evidence should you keep at the end of the handover?
Keep an operational acceptance record. It is neither a compliance certificate nor a performance guarantee. It is a trace that links:
- the scope handed over and its exclusions;
- the people taking over operations and their responsibilities;
- the reference version and the associated test results;
- the takeover exercise carried out and any gaps;
- the risks or decisions postponed, with their owner and review date;
- the support and escalation plan remaining after delivery.
This evidence distinguishes a documentation hand-off from an operable handover. It also makes the next change review easier, because the team knows which version, decisions and limits must be compared.
FAQ
Should the GenAI system be handed over as soon as the prototype ends?
Not necessarily. A prototype can be useful to decide on a use case, but operations should only be handed over for the scope actually opened. If access, tests, procedures and owners are not ready, keep a reduced scope or postpone the opening.
Who should be present during the handover exercise?
Involve at least the people who will operate the system, those who decide on scope changes, and the owners of the data, tools or access concerned. The exact composition depends on the use case and the organisation.
Should the handover file contain prompts and API keys?
Prompt versions, their rules and their tests can be part of the reference file. However, do not put keys, passwords or secrets in the documentation. Reference the secrets management system, the owner and the revocation procedure.
When should the exercise be repeated after delivery?
Repeat it when a change can alter the scope, the accessible data, the possible actions, the controls, the responsibilities or the ability to revert to an approved version. Define these triggers in your change process.
Methodology and sources
- [1] NIST, AI Risk Management Framework, consulted on 23 September 2026.
- [2] NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1), July 2024, consulted on 23 September 2026.
- [3] Microsoft Learn, Azure Well-Architected Framework, MLOps and GenAIOps for AI workloads, consulted on 23 September 2026.
- [4] Microsoft Learn, Cloud Adoption Framework, Prepare your organization for the cloud, consulted on 23 September 2026.
This page offers an operational handover method for enterprise GenAI systems. It contains no client data, no mission statistics and no promise of security, compliance, timelines or results. Roles, controls and procedures must be adapted to each organisation's use case, data, tools and rules.
Are you preparing for your internal teams to take over a GenAI system? Describe your scope to IgnitionAI. A first conversation can help structure the handover file, the takeover exercises and the responsibilities to clarify before opening.