Most AI contracts start life as a SaaS agreement with a data processing addendum attached. That covers uptime, security, and personal data. It says little about what actually changes with AI.
Model versions get retired. Outputs shift after an update nobody announced. Agents take actions on your behalf. The evaluation results that would tell you whether a model fits your use sit with the provider.
Your governance program can decide who owns each of these risks. But that decision only binds anyone once it’s written into the contract. Here’s what that contract needs to say.
Why a DPA isn’t enough
A DPA works as a template because GDPR Article 28 fixes what it must contain. Nothing does that for AI yet, and AI deals vary too much for one fixed form.
Calling a proprietary model through an API, fine-tuning a model on your data, running agents on a platform, and buying a SaaS product with AI features built in carry very different risks. A single template either overreaches on the simple deals or misses what matters in the complex ones.
The better pattern is modular, closer to the EU’s Standard Contractual Clauses than to a DPA: a set of core terms that apply to every AI deal, plus modules you add based on how the AI is used.
Seven terms every AI contract needs
These apply whether you’re calling a model API or buying an AI-enabled application.
- Who does what. A schedule that assigns each AI control to the provider or the customer, including what you must do on your side. Gaps become visible before signing, not after an incident.
- Components. Which models, hosting providers, and third-party tools sit underneath the service, with notice before any of them change.
- Use of your data. Whether prompts, outputs, and files are used for training, how long they’re retained, whether humans review them, and where they’re processed.
- Change notice. Advance notice before a model version is changed or retired, and before updates that affect behavior. Name the period; vague “reasonable notice” language won’t hold up when a version disappears mid-quarter.
- Logs. What’s logged, how long it’s kept, and how you get access when you need to reconstruct what happened.
- Incidents. A definition of AI incident that goes beyond a data breach, such as harmful outputs, safeguard failures, or misuse, with a notification deadline.
- Assurance. What evidence the provider will share, in what form, and how often.
Terms that depend on the use
Add these on top of the core terms when the deal calls for them. The use case, not the model, decides which ones apply.
| Module | Add it when | What to ask for |
|---|---|---|
| Model assurance | You rely on a provider’s model | Evaluation scope and results, model documentation, a stable model identifier, security testing |
| Fine-tuning | The provider tunes a model on your data | Limits on tuning data use, who owns the tuned model, deletion on request and at exit |
| Agents and platforms | AI can call tools or take actions | Scoped agent permissions, approved tool lists, logs of every action taken |
| AI features in applications | You buy software with AI built in | How outputs are classified, performance data, transparency and human oversight features you can switch on |
| Continuity and exit | You’d be hurt if the service stopped | Fallback options, suspension rules, transition help, deletion of your data and tuned models |
| High-risk use | Outputs affect people’s rights, safety, or access to services | Validation for your context, bias testing, ongoing monitoring, support for explaining decisions |
When the provider won’t negotiate
Many AI providers sell on standard terms, and many customers don’t have the leverage to change them. The same terms still help. Turn them into questions, send them as a disclosure questionnaire, and record the answers. Where the answers leave gaps, you know which controls you’ll have to cover yourself, or whether the use case should proceed at all.
Most of these terms ask the provider to tell you things: notices, disclosures, access to logs. Providers accept those far more readily than warranties about how a model will perform, which makes them a realistic place to start.
A clause is only as good as its evidence
A signed commitment is a promise, not proof. For each term, ask what evidence will show it’s being kept: a change notice log, evaluation reports, exported logs, an incident record.
Some commitments you can verify yourself, because you can see which model answered a request or what an agent actually did. Others you can only take on the provider’s word. Prefer terms that produce artifacts you can check, and know which of your commitments fall in the second group.
As always, adapt any of this to your governing law and each party’s legal role.
How Airia helps
A good AI contract tells you what to expect. Airia helps you confirm you’re getting it.
- Know what’s in the stack. Discovery and a use case registry show which models, providers, and tools each use case depends on, so your components schedule matches reality and unannounced changes stand out.
- Match terms to the use case. Use-case-level risk assessment shows which deals need agent, fine-tuning, or high-risk terms, and which don’t.
- See it, don’t just take their word. Because Airia sits in the path of AI traffic, model identity, logs, and agent actions are observed directly, which turns several contract commitments from attested to verified.
- Hold up your end. Guardrails and policy enforcement put your side of the contract into practice, from data controls to human oversight.
- Keep the evidence together. Assessments, approvals, provider responses, and runtime evidence stay tied to each use case, ready for audits, renewals, and incident reviews.
Contracts set the commitments. Governance proves they’re kept.
See how Airia helps enterprises govern AI from intake to runtime: airia.com/request-demo
Put these ideas to work.
Schedule a 30-minute walkthrough with our team.