In 2025, the European Commission's Public Buyers Community published a set of model clauses for the public procurement of AI systems — the MCC-AI, with a full version for high-risk systems and a lighter version for the rest, both aligned to the obligations of the EU AI Act. The initiative did not come from bureaucracy for its own sake: it came because no public buyer wanted to keep signing an AI contract that rested on a vendor's word alone.
The reason shows up in third-party risk research. According to Ncontracts, in a 2026 survey of U.S. financial institutions, 72% of them know only partially which of their vendors use AI, and 16% have never assessed this at all. Not a single organization said it felt "extremely confident" managing that risk.
That matters to whoever signs the contract, not only to whoever runs the system afterward. A vague clause today is an obligation nobody can enforce tomorrow — in an audit, in an incident investigation, or when the contract comes up for renewal.
What most AI contracts are missing
Law firms specializing in technology contracts document a similar pattern among AI buyers: a vendor's security clause tends to repeat the same generic language — "state-of-the-art security," "full compliance" — without naming a control that can later be verified. A clause guide for AI vendor contracts from Gouchev Law lists points that often go missing: a clear definition of data use for training, ownership of the generated output, human review required based on risk, and indemnity that covers claims over the data used in training — not just over the software itself.
The most frequently missing point is the very definition of customer data. A well-drafted contract, according to an analysis from Tish Law on AI vendor clauses, needs to treat as confidential not just the uploaded document, but also the typed prompt, the generated output, and any usage log — restricting the vendor's use to delivering the contracted service unless written permission says otherwise.
The U.S. National Institute of Standards and Technology, NIST, addresses the same problem from the governance-structure side. Its AI risk management framework asks that a company keep a formal policy for risk coming from vendors and third-party data, assess that risk at contracting time and at defined intervals, and preserve the right to audit the vendor's AI practices — not just take its word for it.
The international AI management-system standard, ISO/IEC 42001, arrives at a similar conclusion by another route: it requires the company to evaluate each vendor's ability to meet responsible-AI requirements, ask for evidence — not a promise — and be notified when the vendor changes the model, the dataset, or the hosting setup, because that change can alter the risk the company had already accepted.
Why the marketing clause protects no one
The most common fallback is still the wrong one: accepting the vendor's security page as if it were proof. A public claim of "enterprise-grade security" is not a clause — it is a sales argument, and a sales argument is not enforceable once something goes wrong.
The same goes for the standalone certificate. Asking for a compliance seal in the proposal is a first filter, but it does not replace the contractual obligation. The practice recommended by vendor-risk reviewers is different: turn every certification the vendor displays into a clause that backs it up — the vendor states the certified scope, commits to notifying any scope change, and agrees to provide evidence on request, not just the seal.
Another common mistake is treating the subcontracting clause as a formality. An AI vendor rarely operates alone: it uses a third party's model, a third party's hosting, sometimes even outsourced human review. Without a clause requiring the vendor to list those subcontractors and notify any change, the contracting company discovers the real chain only once something has already gone wrong.
And there is the point that comes up most in recent legal analyses: indemnity usually covers the software, but not the training data or the AI-generated output. If the model was trained on data that infringes copyright or violates a third party's privacy, liability can fall on whoever contracted the service — not only on whoever trained it. Negotiating that coverage before signing is cheaper than negotiating it after a breach notice.
What has to be in place
An auditable AI contract rests on verifiable mechanisms, not on an adjective. These are what a well-written clause needs to require of the vendor — and what a mature company already demands of itself before signing.
Entry through corporate identity, not a standalone account. The clause should require that access to the AI system come from the company's own identity directory: whoever leaves the company loses access at the same time, without depending on someone remembering to cancel a side account.
Access matched to each person's role, not the whole tool. The contract needs to allow configuring what each function can see and do inside the system — and the vendor has to prove that separation exists, not just describe it on a sales page.
Human approval on sensitive actions, with a clear rule for when it applies. The clause needs to name the situations where an action stops and asks a person to confirm before proceeding — not leave that decision to the vendor's discretion after the contract is already signed.
A detailed audit trail accessible to the buyer. The right to audit, championed by NIST, only holds up in practice if the contract also guarantees access to the logs — who did what, when, and under what permission — not just the theoretical right to request an audit someday.
A written data retention and deletion rule. The contract needs to state how long data is retained after the service ends and how deletion is proven. Without that, "data will be handled securely" is not a verifiable obligation — it is just a sentence.
This is how Skyller was designed: identity coming from the company's directory, permission by role, and human approval as the system's default — not as a clause the company has to negotiate separately.
The payoff of a contract you can actually audit
When the contract names the controls instead of promising security, legal and security teams stop working in parallel and start negotiating from the same list. Internal audit gets an objective question for every clause: does the control exist, and is there evidence of it?
It also speeds up the next purchase. Whoever reviews an AI vendor without a prior list of controls to require redoes the same work at every renewal. With specific clauses, the next negotiation reuses the same playbook — and the procurement team argues position, not vocabulary from scratch.
There is a less obvious gain: a well-written contract also protects against the vendor's own evolution. AI systems change model, hosting provider, and data policy more often than other corporate systems do. A material-change notification clause — the kind ISO 42001 recommends — gives the company a chance to reassess the risk before the change is already live, not after.
Questions to bring to the next contract negotiation
Before signing — or renewing — an AI vendor contract, it's worth bringing these questions to the table:
- Can the vendor use our data to train its model, and under what condition does that change? If the answer lives only in a public policy and not in a clause, it can change without notice.
- Who on our side has the right to audit the vendor's AI practices, and within what response time? An audit right with no deadline is a right that, in practice, no one exercises.
- Does the indemnity cover claims over training data and generated output, or only over the software? It's the gap most often cited by lawyers who specialize in AI contracts.
- Is the vendor required to notify a change of model, subcontractor, or hosting? Without this clause, the company finds out about the change only after it has already affected some operation.
- Is there a contractual deadline for deleting data after the contract ends, and how is it proven? "Data handled securely," with no written deadline, is not an obligation — it's just an intention.
