An AI integration can work on launch day and still be hard to own. If only its builders know how it works, you hold a system you can’t safely change, move or switch off. The handoff is where that gets fixed.
We build and hand over AI integrations through our AI integration service, so weigh that. Every fact below about the EU AI Act, the NIST AI RMF and the Claude API was checked against the official texts and Anthropic’s own documentation in October 2026.
Short answer: Get five documents before sign-off: an as-built data flow diagram, a credentials inventory, a model configuration record, the acceptance test results and a runbook with an off switch. On the Claude API, run production on a service account key in your own organisation, not a personal key. Under the amended EU AI Act, high-risk documentation rules apply from 2 December 2027 (Annex III) and 2 August 2028 (regulated products). Most automations aren’t high-risk, but every owner needs the same documents.
What the Rules and the Docs Say
As of October 2026, from the EU AI Act (consolidated text), NIST and Anthropic’s documentation:
| Source | What it says |
|---|---|
| AI Act, Art. 113 | High-risk rules from 2 Dec 2027 (Annex III), 2 Aug 2028 (Annex I) |
| AI Act, Art. 11 | Technical documentation before go-live, kept up to date |
| AI Act, Art. 18 | Providers keep it 10 years after market placement |
| AI Act, Art. 26 | Deployers keep automatic logs at least six months |
| NIST AI RMF 1.0 | Voluntary; covers inventory and decommissioning |
| Claude model IDs | Pinned snapshots; at least 60 days’ retirement notice |
| Claude API keys | Personal keys archived when the user is removed |
Sources: Art. 113, Art. 11, Art. 18, Art. 26, NIST AI RMF, Claude models, deprecations, authentication.
Why AI Handoff Documentation Fails in Practice
Many projects close with a login and a walkthrough video. That shows the system working. It doesn’t say how it works, which keys it holds or how to stop it.
The usual cause is timing. Documents get written at the end, when budget is spent, and nobody defined a complete set. Fix it at the start: name the documents as contract deliverables.
Why Handoff Documentation Gets Skipped
You can’t see a vendor’s motives, and you don’t need to. You can see dependency. If only the builders can explain the integration, every change goes through them, whatever anyone intended.
Treat that as a risk, not an accusation. NIST frames it from the buyer’s side: have policies for third-party AI risks and contingency processes for third-party failures (GOVERN 6.1 and 6.2) (source).
What “We’ll Handle It” Means at Renewal Time
Ongoing maintenance can be a good arrangement. The cost shows when it ends. Without documents, the next developer must reconstruct the system before improving it, and you pay for that time.
Keys are a concrete case. A Claude personal API key is archived when its user is removed from the organisation, and it isn’t restored (source). If a contractor’s personal key runs production, removing them stops it. Anthropic recommends a service account for shared or automated workloads (source).
The Core Document Set You Need Before Any AI Project Closes
Five documents cover most integrations:
| Document | What it proves |
|---|---|
| Data flow diagram | What connects, as built |
| Credentials inventory | You control every key |
| Configuration record | What runs in production |
| Test results | What “working” meant |
| Runbook | How to run and stop it |
Architecture and Data Flow Diagram
Every system the integration touches: CRM, database, APIs and the model endpoint. For each link, what data moves, what triggers it and where it’s stored. Ask for the as-built version, not the discovery plan. NIST’s MAP 1.1 asks that purpose, applicable laws and deployment settings be documented (source).
Secrets and Credentials Inventory
List every API key, token and webhook secret: what it’s for, where it lives, who rotates it and when it expires. Then move control to accounts your business owns.
Anthropic says to keep Claude API keys in a secrets manager, rotate them periodically and disable or delete any suspected leak (source). Expiring keys trigger an email to their creator, and an expired key can’t be reactivated (source). Record whose inbox gets those emails. The Console’s Usage export breaks usage down by key and model (source), so you can check the inventory against reality.
Model Card and Configuration Record
A model card is a short document that accompanies a trained model and reports its evaluation and intended use (source). For hosted models, the provider publishes it: Anthropic publishes system cards for Claude (source).
Your integration needs its own configuration record:
- The exact model ID and where the code sets it
- The system prompt, versioned
- Every request parameter set
- What happens on errors or failed validation
- The model’s retirement date and who watches for notices
Claude model IDs are pinned snapshots (source), but models retire. Anthropic gives at least 60 days’ notice, and requests to a retired model fail (source). Claude Sonnet 4.5, for example, retires on 30 November 2026. On Claude Opus 4.7 and later, a non-default temperature, top_p or top_k returns an error (source), so recorded settings matter when migrating.
Acceptance Criteria and Test Results Log
Write down the test inputs, expected outputs and results at sign-off, including awkward cases. This is your baseline. Anthropic recommends testing with newer models well before retirement (source), which needs the original tests. NIST’s MEASURE 2.9 asks that the model be validated and documented (source).
Operational Runbook (Including the Off Switch)
The runbook lets someone without the builder’s knowledge:
- Check it’s working and find the logs
- Fix common errors and restart it
- See who gets alerts
- Pause or switch it off without breaking connected systems
NIST asks for safe decommissioning (GOVERN 1.7) and assigned responsibility to deactivate a system acting outside its intended use (MANAGE 2.4) (source). On the Claude side, disabling a key is reversible and deleting it is permanent (source). Archiving a workspace archives its keys and can’t be undone (source). Say what the integration does when its key stops working.
Handoff to Client vs. Handoff to a New Developer, They’re Different
Two audiences need two documents.
What a Non-Technical Owner Needs
A plain summary: what it does, what it costs to run and where the bill goes, who to call and who can switch it off. Claude API workspaces support spend limits with alerts (source); say whether one is set.
Integrations built on custom WordPress development or WooCommerce need the same clarity about the platform underneath.
What a New Development Team Needs on Day One
The five documents, plus:
- Repository access with full history
- Setup steps and environment variable names
- The deployment process
- A changelog since launch
Claude API workspaces can separate development, staging and production, each with its own keys (source).
Compliance Obligations That Affect Your Documentation Requirements
For most automations this is good practice. For some, it’s law.
EU AI Act Dates and What They Mean for Documentation Retention
The high-risk rules were first set for 2 August 2026. The AI Omnibus amendment, in force since 27 July 2026 (source), moved them: they now apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I products (source). Annex III includes recruitment and credit scoring (source). 2 August 2026 remains the general date, bringing in transparency rules (source), such as telling people they’re interacting with AI (source).
For high-risk systems:
- Providers draw up technical documentation (source), keep it for 10 years after market placement for national authorities (source) and keep their logs at least six months (source).
- Deployers follow the instructions, assign human oversight, monitor use and keep logs at least six months (source).
A provider is anyone who develops a system, or has one developed, and puts it into service under its own name (source). So a business commissioning a high-risk system can be its provider. A deployer also becomes one by rebranding, substantially modifying or repurposing a high-risk system (source). Systems already in service are covered only after significant design changes (source). Get legal advice for your case.
NIST AI RMF Alignment, What the Framework Asks For
The NIST AI RMF 1.0, released in January 2023, is voluntary and is being revised (source). The Playbook says it isn’t a checklist (source), so nobody can promise what an auditor expects. It does give handoff language (source):
- AI system inventory: GOVERN 1.6
- Documented context: MAP 1.1
- Validation: MEASURE 2.9
- Deactivation: MANAGE 2.4
The Generative AI Profile adds incident response plans and vendor contract terms for third-party generative AI (source).
How to Verify Your Documentation Is Actually Complete
Two checks surface most gaps.
The New Developer Test
Give the package to a developer who wasn’t on the project. Ask them to answer from the documents alone:
- What does it do and connect to?
- What breaks if the main key is disabled?
- How do you restart it?
- How do you switch it off safely?
- Which model ID runs, and when does it retire?
If they need to call someone, the documents aren’t finished.
Gaps to Check in What Your Vendor Delivered
- Documents created in the week of the final invoice
- A diagram of the plan, not the build
- Credentials “stored in our systems” with no transfer step
- Production running on someone’s personal key
- A model ID or prompt missing from the documents
None of these proves bad intent. Each is a gap to close before sign-off.
Designodin’s approach to project ownership treats documentation as a deliverable, not a courtesy. See how we build this at designodin.com/ai.
Related Posts
- AI project handoff requirements: what full ownership covers
- How to document a custom AI tool: documentation for ownership transfer
- AI model updates and your integration: planning for model changes
- Ownership vs dependency in AI contracts: putting handoff terms in writing
Frequently Asked Questions
What documents should I receive when an AI integration project is finished?
An as-built data flow diagram, a credentials inventory under your control, a model configuration record, acceptance test results and a runbook with a shutdown procedure, plus a plain summary for the owner. Name them in the contract.
How long should AI integration documentation be retained?
For EU AI Act high-risk systems, providers keep technical documentation 10 years after market placement and deployers keep logs at least six months, from 2 December 2027 for Annex III. Otherwise, keep it while the system runs, plus what your contracts and data protection duties require.
What is a model card and why does my business need one?
A model card reports how a model was evaluated and what it’s for, an idea from Mitchell et al. in 2018. Anthropic publishes system cards for Claude. Your business also needs a configuration record of model ID, prompt, settings and fallback, because models retire.
What should be in an AI integration runbook?
How to check it, where the logs are, common fixes, restarts, who gets alerts and how to switch it off safely. Also what happens if its API key stops working.
How do I know if my vendor’s documentation is incomplete?
Usually you can’t, and you don’t need to. Judge the gaps, not the motive. Run the new developer test and ask for missing items in writing before final payment.
Who keeps AI Act documentation, the agency or the business?
The provider does. A business that has a high-risk system developed and puts it into service under its own name can be the provider, which puts the 10-year retention on that business. Deployers keep logs. Most automations aren’t high-risk; get legal advice.