Contract for AI Services

Direct answer

What should an AI contract contain? An AI contract should preserve the controls relied on during procurement by defining permitted use, data rights, model and provider change notification, security and incidents, testing, audit evidence, human responsibilities, intellectual property, regulatory change, termination and exit. Material changes should trigger review or re-evaluation where appropriate.

AI contracts need to deal with change, data and dependency risk more explicitly than many conventional SaaS agreements. The contract should preserve the evidence and controls relied on during procurement.

1. Define the service and permitted use

Describe the product, deployment model, permitted use cases, material integrations and any prohibited uses. Avoid a contract that allows the delivered service to drift materially away from the evaluated service.

2. Data rights and restrictions

Set out:

• customer-data ownership and permitted processing;
• whether prompts, files, outputs or feedback may be used for training or service improvement;
• retention and deletion periods;
• data location and international transfers;
• subprocessor controls;
• confidentiality and access restrictions;
• post-termination deletion and evidence of deletion where appropriate.

3. Model and dependency changes

Require notification of material changes to models, model providers, hosting, safety controls, subprocessors or data practices. For higher-risk uses, reserve approval or termination rights where the change materially affects the evaluated risk profile.

4. Performance and testing

Tie contractual service commitments to the measures that matter in the intended use. Where quality cannot sensibly be represented by a single SLA, define test methods, acceptance criteria, escalation thresholds and remediation processes.

5. Security and incidents

Include security obligations appropriate to the service, notification timescales for material incidents, investigation cooperation, evidence preservation, vulnerability handling and responsibilities across supplier dependencies.

The NCSC secure AI guidance highlights secure deployment, incident management and continuous operation as lifecycle responsibilities.

6. Audit and evidence rights

Specify what evidence the buyer can request to verify continuing compliance. This may include independent audit reports, control attestations, incident summaries, subprocessor information, testing results, change records or relevant logs.

Audit rights should be proportionate and protect other customers' confidential information.

7. Human oversight and operational responsibility

Document which controls are provided by the supplier and which remain the buyer's responsibility. Avoid ambiguity about who is expected to monitor outputs, configure safeguards, review incidents or approve consequential decisions.

8. Intellectual property

Address rights in inputs, outputs, prompts, fine-tuned assets, retrieval content, generated code and any supplier-created artefacts. Where third-party model terms may affect these rights, require the supplier to identify the relevant dependency.

9. Regulatory and policy change

AI regulation and guidance can change during the contract term. Include a mechanism for assessing material legal, regulatory or policy changes and agreeing necessary remediation.

10. Exit and continuity

Define termination assistance, export formats, removal of access, deletion, transition support and treatment of model-specific assets. For critical services, consider contingency plans where a model provider or key dependency becomes unavailable.

Contract schedule approach

A practical approach is to maintain an AI schedule that records: 1. approved use cases; 2. data categories; 3. model/provider dependencies; 4. material controls; 5. change-notification triggers; 6. incident obligations; 7. monitoring information; 8. buyer and supplier responsibilities; 9. exit requirements.

The schedule can then be updated under controlled change rather than relying on generic SaaS wording.

Frequently asked questions

What AI-specific terms should a supplier contract include?

In addition to ordinary software terms, identify the approved AI service and uses, data-use restrictions, model and subprocessor change notifications, incident handling, audit or evidence access, human responsibilities and exit arrangements. See the supplier due-diligence checklist to link clauses back to assessed evidence.

Can an AI supplier use our prompts or documents to train models?

That depends on the agreed service and contract. Record the permitted purposes for customer content, retention, subprocessors, access and any training or improvement use explicitly. Do not assume a supplier's generic privacy policy answers what happens in your deployment. See ICO procurement data protection guidance.

Should a buyer approve changes to AI models or providers?

Define which changes are material to security, accuracy, privacy, resilience or permitted uses and require appropriate notice, evidence and reassessment. The contract should also identify urgent security changes and practical escalation routes. See model and provider dependencies.

What exit protections matter in an AI contract?

Specify access and data export, deletion confirmation, transition support, critical model or API dependencies and any restrictions on using buyer-supplied prompts, configurations or fine-tuned assets after termination. Test whether the service can be replaced without unacceptable interruption or data loss.

Next: Deploy purchased AI safely.