The handover record we recommend for a private AI service

NIST's AI Risk Management Framework addresses trustworthiness across the design, development, use and evaluation of AI systems.[1] The operating period deserves its own evidence. For a private AI pilot moving into routine use, we recommend a handover record that allows the receiving team to identify the installation, understand its limits and respond when something stops working.

This is our proposed handover format, not a report of an audited customer deployment. It complements the technical and data-boundary information in the Software Tailor trust centre. Each organisation should assign the responsibilities to its own operating model.

Name the receiving owner and the permitted work

Start with a named role that accepts responsibility for the service. Record its contact route and the alternate arrangement when the usual owner is unavailable. A supplier's support address is useful, but the organisation also needs someone who can decide whether the service should continue running during an incident.

Describe the tasks approved for routine use and the tasks still confined to the pilot. Include the groups allowed to use the service and the expected operating hours. An unresolved pilot finding should remain visible with an owner and a planned decision date; it should not disappear because the installation has changed status.

Carry over the capacity and deadline assumptions used in the purchase decision. That gives the receiving team a reason to investigate when the workload changes.

Preserve the configuration that was actually checked

Record the application and server builds, the runtime and the exact model reference. Retain the installation source and the relevant configuration through the organisation's normal controlled-document process. Store credentials through its credential-management process, with references in the handover rather than copied secret values.

Hugging Face model cards provide documentation for model uses, limitations and evaluation.[2] Link the relevant card and revision, then add the local findings from the pilot. The publisher's description and the organisation's test results answer different questions; the receiving team should be able to locate both.

Where the system has optional external providers, record which routes are enabled. Describe the intended data boundary for each route and who may approve a change. Avoid a broad label such as “local” when the operating configuration needs a more precise explanation.

Assign responsibility for actions and permissions

For an agent integration, attach the agreed tool list and the identity used by each connection. OWASP recommends limiting agent capabilities and permissions, and enforcing authorisation in downstream systems.[3] Our handover proposal turns that guidance into an ownership question: who can review or revoke each grant?

Include the outcome of the tool-call integration checks, with any remaining restrictions. Distinguish permission to propose an operation from permission to execute it. If a person must approve an action, identify where that approval happens and how a failed or abandoned approval is handled.

The receiving owner should also know which diagnostic records exist, who can access them and how long they are retained. Use the configured policy and a verified example. Do not infer that prompts are absent from every connected component simply because one component has a content-free audit design.

Rehearse one interruption before handover

Choose an agreed, non-destructive interruption in a test environment. Have the receiving team follow the recovery instructions while the original implementer observes. Record the missing information they encounter and update the instructions before sign-off.

The exercise should establish how to recognise the problem, who may stop the affected work and how to check the recovered service. If rollback is part of the plan, identify the retained version and the point at which rollback is appropriate. Keep untested recovery assumptions labelled as untested.

For a Software Tailor service discussion, a redacted configuration record and a clear account of the failed step are more useful than an unsupported claim that the whole system is broken. The handover should explain how to collect that information through the organisation's approved support route.

Make sign-off a usable record

Finish with the receiving owner's acceptance, the date and the unresolved items. Name the changes that should trigger a review, such as a different model, a new connector or a broader permitted task. This is a proposed operating discipline rather than a certification scheme.

The record is ready when the receiving team can use it to make a decision without reconstructing the pilot from memory.

References

[1] NIST. AI Risk Management Framework. Framework 1.0 released 2023; background guidance. Accessed 2026-09-26.

[2] Hugging Face. Model Cards. Standing model-documentation guidance. Accessed 2026-09-26.

[3] OWASP Gen AI Security Project. LLM06:2025 Excessive Agency. 2025 edition. Accessed 2026-09-26.

Related articles

• Connecting an agent to AI Server
• Buying private AI capacity around a business deadline
• A private AI upgrade needs an acceptance record