When a custom AI project closes, the developer has already been paid. Everything they know about the tool, the prompt logic, the model configuration, the dependencies they hold the accounts for, leaves with them unless you contracted for documentation before anyone wrote a line of code. Most clients don’t. Most handovers are a GitHub link and a Loom walkthrough. That is access, not ownership.
Proper documentation for an AI tool is different from standard software documentation. It must cover not just what the code does, but what models it calls, which prompts drive its behaviour, where the training data came from, and who legally owns each component. Miss any of those layers and you own a black box, not a business asset.
Why Standard Software Handover Falls Short for AI Tools
A website or SaaS app can be handed over with source code, a deployment guide, and admin credentials. That covers the asset.
A custom AI tool has additional layers that don’t exist in conventional software. The logic lives partly in prompts, partly in model configuration, and partly in fine-tuning data or retrieval corpora. None of that shows up in source code alone. A developer can hand you every file in the repository and you can still be unable to run, modify, or replicate the tool, because the prompts are undocumented, the model vendor contract is theirs, or the data pipeline requires credentials only they hold.
The Three Layers of AI Tool Ownership
Every custom AI tool operates across three layers, and documentation must cover all three:
Technical layer: The code, APIs, infrastructure, and deployment configuration. This is what most handovers cover.
Logic layer: The prompts, model selection decisions, context windows, temperature settings, output parsing rules, and orchestration flow. This is where most documentation stops short.
Legal layer: IP assignment, training data licensing, third-party API terms, and any fine-tuned model weights. This is what most developers never produce unprompted.
A complete ownership transfer requires documentation of all three.
The Six Documents You Need Before Closing Any AI Project
1. System Architecture Diagram
This is not a README. It is a visual map of every component, how data flows between them, and which services are external versus internal.
For an AI tool, the diagram must show where each API call goes, what triggers it, and what data passes through. If your tool calls GPT-4o for one task and Claude for another, both must be labelled, along with which account holds each API key, what the fallback behaviour is, and what happens if either service is unavailable.
Minimum requirements: input/output flows, all external API calls, database or storage connections, authentication points, and a legend explaining each component type. A one-page Mermaid diagram or Lucidchart export is sufficient, the format matters less than the completeness.
2. API and Dependency Register
This is a structured list of every third-party service the tool depends on, with four fields per dependency: service name, purpose, account owner, and what breaks if it goes down or changes its pricing.
An AI tool commissioned in 2026 typically calls three to seven external APIs beyond the primary LLM. Common examples: a vector database for retrieval (Pinecone, Weaviate), an embedding model, a document parser, a data extraction service. Each is a dependency your developer controls until you take over the accounts.
The register should flag any dependency with a proprietary data lock-in risk, services where the data you’ve sent cannot be exported, or where switching requires a rebuild rather than a redirect. That’s the information that tells you whether a dependency is routine or structural.
3. Prompt Architecture and Model Configuration Records
This document is the most frequently missing and the most critical. It records every prompt template, system message, and model configuration parameter used in the tool.
For each prompt, document: the full text of the system and user message templates, the model it targets, the temperature and top-p settings, the maximum context length, any output format instructions, and the reasoning behind key design decisions. That last item, the reasoning, is what allows a different developer to modify the tool without accidentally breaking it.
If your tool uses a chain of prompts (common in document processing, data extraction, or multi-step reasoning workflows), the document must show the sequence, how the output of each step becomes the input for the next, and what validation happens between steps.
A note on prompt IP: in most jurisdictions, prompts are copyrightable as written works. An IP assignment clause in your contract should explicitly include prompt templates. If it doesn’t, you may have the prompts in a file but not the legal right to use them without the developer.
4. Training Data Provenance Record
If your tool involves fine-tuning, retrieval-augmented generation (RAG), or any custom data corpus, this document records where every piece of that data came from and under what terms it was used.
The questions it must answer: Was the training or retrieval data scraped, licensed, or client-owned? If scraped, was it scraped from sources that permit AI training use? If licensed, does the licence transfer to the client at project end or expire with the developer’s subscription? If client-owned, internal documents, customer records, product data, was it handled according to the applicable data agreements and privacy regulations?
For US and EU SMBs, this matters for two reasons. First, if the data provenance is unclear, you inherit legal exposure, particularly under GDPR if EU customer data was used without clear basis. Second, if the developer holds the licensed data source and your contract doesn’t address it, they can revoke your tool’s data foundation with a cancelled subscription.
5. Operational Runbook
The operational runbook is the document that determines whether you can actually run the tool without the developer. It covers four topics: routine operations, monitoring, incident response, and update procedures.
Routine operations: how to deploy, how to roll back a deployment, how to adjust model parameters without a code change, and how to add or remove users or permissions.
Monitoring: what normal output looks like, which metrics signal degraded performance, and where to look when something behaves unexpectedly. For AI tools this includes specific guidance on detecting hallucination or output quality drift, something no standard software runbook covers.
Incident response: the step-by-step process for diagnosing a failure, the escalation path if internal resolution fails, and the data needed to file a support request with any third-party service involved.
Update procedures: how to update model versions (critical, since the underlying LLM changes on the provider’s schedule), how to modify prompt templates safely, and how to test changes before they affect production.
A runbook that takes two hours to write is not a runbook. A useful runbook is tested by giving it to a competent person who did not build the tool and asking them to perform each procedure.
6. IP Assignment and Handover Agreement
This is the legal document, and it must be signed before final payment, not after.
The document must explicitly assign the following to the client: all source code and build artifacts, all prompt templates and system messages, all fine-tuned model weights (if applicable), all custom data pipelines and schema definitions, and all derivative works created during the project.
The assignment must be a transfer, not a licence. A licence says you can use the IP under certain conditions. An assignment says you own it. The difference is whether your developer can revoke access or change terms later. Make sure the word “assign” appears in the agreement, not “licence,” “grant,” or “rights to use.”
The agreement should also include a warranty that the developer did not use third-party proprietary tools or assets in the build that would encumber your ownership, and an indemnity against IP claims arising from how the tool was built.
How to Verify the Documentation Is Complete
Receiving documents and receiving complete documents are different things. Three checks distinguish them.
The independence test: Give the documentation to a developer who was not involved in the build and ask them to deploy and modify the tool using only those materials. If they can’t do it without calling the original developer, the documentation has gaps.
The prompt audit: Ask a developer to extract and run every prompt template from the documentation against the live tool. The outputs should match. If they don’t, the documented prompts are not the production prompts, a common shortcut when developers document prompts from memory rather than extracting them from the codebase.
The dependency verification: Go through the API and dependency register line by line and confirm you hold the account or have been transferred the account for each one. “You have access to the account” is not the same as “you own the account.” Account ownership means billing, credentials, and the ability to transfer or close without contacting the original developer.
How to Contract for Documentation From the Start
Demanding documentation after a project closes is negotiating from weakness. The developer has already invoiced, the relationship has momentum toward closure, and “write proper documentation” is a scope increase they did not price.
The correct approach: specify every documentation deliverable in the Statement of Work, and tie each to a payment milestone.
A workable structure: link 20% of the total project fee to delivery of the complete documentation set, signed IP assignment, architecture diagram, dependency register, prompt records, training data provenance, and operational runbook. Define each document by its minimum required contents in the SOW. That prevents a two-page skeleton being passed off as complete.
Include an acceptance criteria clause: documentation is accepted when an independent developer can deploy the tool using only the delivered materials. That creates an objective standard the developer cannot argue with and you cannot be argued out of.
If you’re evaluating a vendor now, before a contract is signed, ask them to show you documentation from a previous project. Vendors who document properly as a matter of practice can do that. Vendors who are planning to under-document for yours will have difficulty finding an example to show.
If you want to talk through what defined documentation deliverables look like before you sign anything, start a conversation.
Frequently Asked Questions
Does receiving the source code mean I own the AI tool?
Not necessarily. Source code ownership is part of IP transfer, but without a signed assignment agreement, the original developer may retain copyright, especially if there’s no work-for-hire clause. Code delivery and legal ownership are separate questions.
What happens to my custom AI tool if the original developer’s company closes?
If you have a complete IP assignment, documented dependencies under your own accounts, and a full operational runbook, you can continue operating. If not, you face the same situation Builder.ai clients did in 2024, assets that exist but can’t be operated, rebuilt, or transferred without the original team’s knowledge.
Do I need to document the AI model itself, or just how I use it?
You need to document how you use it: model name and version, parameter settings, prompt templates, and the vendor API terms under which you use it. You don’t own the underlying model, that belongs to the provider, but you need records of your configuration so a different team can replicate your setup.
What if my developer says detailed documentation isn’t standard practice?
That’s a flag. Detailed documentation is standard practice for any project where full ownership transfer is the goal. Developers who build proprietary tooling and depend on ongoing maintenance revenue have an incentive to under-document. Ask specifically which documentation deliverables are included in the scope and get the answer in writing before you sign.
How often does AI tool documentation need to be updated?
Documentation should be updated whenever a significant change is made, model version updates, prompt revisions, new dependencies, infrastructure changes. At minimum, schedule a documentation review quarterly for any tool in active use. AI tool behaviour changes as underlying models update, and documentation that was accurate at launch can become misleading within six months without maintenance.
Can I demand documentation of prompts if my developer says they’re proprietary?
The prompts were written to build your tool, using your requirements and your data. If the contract includes a work-for-hire clause or IP assignment, they are yours, not proprietary to the developer. If the contract is silent on this, get legal advice immediately. A developer claiming your tool’s prompts are their IP is claiming partial ownership of the tool you paid for.
Get This Right Before the Project Starts
Documentation written after a project closes is documentation written against the developer’s interest. They’ve been paid. Re-opening scope to produce complete records is work they didn’t price. The only reliable path is contractual: define every deliverable in the SOW, tie payment to delivery, and specify acceptance criteria before anyone writes a line of code.
Tell us what you’re building. We’ll be direct about whether we can help.