To secure contractual drafting involving AI, systematically require a Data Processing Agreement compliant with Article 28 GDPR, a contractual prohibition on training without a legal basis, an effective audit right covering logs and technical reports, plus verifiable security measures such as encryption and pseudonymization. These four requirements form the minimum foundation for any negotiation in 2026.
In brief:
- It is essential to require a data processing agreement compliant with Article 28 GDPR, including a precise list of subprocessors and a detailed technical annex.
- The training prohibition clause must explicitly cover the processing of embeddings and derived data to prevent any risk of leakage via these means.
- Technical measures such as encryption, multi-factor authentication, and logging must be codified in the contract and verifiable through audit.
- The right to audit must include concrete access to technical logs and provide for the possibility of regular third-party audits to guarantee ongoing compliance.
- Real-time pseudonymization of data constitutes a secure practice that enables compliance with the training prohibition and facilitates regulatory compliance.
Table of contents
- 2026 regulatory framework: AI Act, GDPR, and contractual consequences
- Essential contractual clauses for AI use
- Which technical measures to require in the contract?
- How to formalize a truly enforceable audit right?
- Who validates AI outputs before use?
- What do these clauses look like in practice?
- Contractual checklist: what to do within 72 hours?
- Real-time pseudonymization as a contractual safeguard
- Outlook: what 2026 will change in contractual negotiation
- Reduce contractual risk with an operational pseudonymization layer
- Sources
2026 regulatory framework: AI Act, GDPR, and contractual consequences
The legal landscape for enterprise AI now rests on two overlapping and mutually reinforcing instruments: the GDPR and the AI Act. Article 50 of the AI Act imposes a transparency obligation-namely, informing users that they are interacting with an AI and marking AI-generated content. This requirement, purely regulatory on paper, translates concretely into clauses that must be negotiated with every service provider.
On the GDPR side, two articles structure the entire contractual relationship. Article 28 governs subprocessing whenever an AI tool processes personal data on behalf of a client, while Article 32 imposes security measures proportionate to the risk. The EDPB clarified in its Opinion 28/2024 the conditions for lawful training on personal data, which closes the door on many vague practices by generative AI vendors.
Three developments now structure every contractual negotiation:
- The AI Act requires marking of generated content and prior user notification.
- The GDPR makes any AI processing conditional on a robust DPA and verifiable security guarantees.
- The European Directive on liability for defective products (2024/2853) potentially expands the liability of publishers of defective AI software.
Essential contractual clauses for AI use
Three families of clauses concentrate most of the legal risk when a contract involves a generative AI tool. Neglecting them amounts to signing an agreement without real visibility into what happens to the data you transmit.
1. The DPA (Data Processing Agreement). Whenever an AI processes personal data on behalf of a client, the vendor generally acts as a processor within the meaning of Article 28. The DPA must precisely list subsequent subprocessors (hosting providers, third-party model suppliers), frame transfers outside the European Union, and detail the security measures applied. A generic three-page DPA no longer suffices: you need a technical annex naming the actual data flows.
2. The training prohibition. The standard clause should stipulate that transmitted data is never used to train or fine-tune a model, except for limited exceptions to explicitly validated tools and on previously anonymized data. This distinction between raw data and derived data-such as embeddings or fine-tuned models-remains the most often overlooked point in negotiations, even though a leak via an embedding is just as damaging as a leak of the raw document.
3. Transparency and ownership of outputs. The clause must cover the marking of generated content in accordance with Article 50 of the AI Act, but also the ownership of the results produced: who holds the rights to a contract, report, or code generated by the AI, and under what conditions the supplier may reuse them.
Pro tip: Contractually segment data flows (input, metadata, derived data) rather than treating "the data" as a single block. This is the only way to obtain retention periods and usage rights truly adapted to each category.
Which technical measures to require in the contract?
Legal clauses are worthless without their technical translation. Article 32 GDPR requires measures proportionate to the risk, and the contract must make them verifiable rather than declarative.
Four technical requirements deserve precise formalization:
- Encryption of data in transit and at rest, with mention of the algorithm and key management practices.
- Multi-factor authentication for all administrator access to processing environments.
- Fine-grained authorization management, limiting access only to data necessary for the task.
- Complete logging of access and processing, with a log retention period sufficient to allow retroactive audit.
The CNIL explicitly recommends pseudonymization and anonymization as major protection levers, particularly for processing via API and cloud environments. Stateless processing, where no identifying data is ever stored by the service provider, mechanically reduces the contractual risk surface: there is simply no database to protect against a leak or unauthorized access.
Operationally, it is better to require that the service provider specify in the contract which type of pseudonymization it applies (masking, tokenization, substitution) rather than accepting a vague formula such as "appropriate security measures will be implemented."
How to formalize a truly enforceable audit right?
An audit right that merely states a principle serves no purpose in litigation. It must specify concrete access to technical logs, not just to the service provider's declarative processes.
Specialized lawyers recommend systematically extending this right beyond organizational processes, to include technical logs and test reports addressing non-discrimination in generated outputs. Concretely, the clause must cover:
- Direct or on-demand access to access and processing logs.
- The ability to request an independent third-party audit, at shared expense or at the client's expense depending on frequency.
- Transmission of existing certification reports (SOC 2, ISO 27001) without waiting for a formal request.
- Reasonable notice, typically 30 days, except in the event of a triggering security incident.
An effective GDPR audit is conducted annually, supplemented by triggered audits in the event of a significant change to the service, new AI tool, or incident. This cadence is not arbitrary: treating the audit as a continuous activity, rather than as a one-off formality, measurably improves accountability to supervisory authorities like the CNIL.
Pro tip: Systematically request a screenshot or dated export of SOC 2 or ISO reports as an annex to the contract, not just a mention in the general terms. A promised but never delivered report protects no one.
Who validates AI outputs before use?
Human oversight is not limited to an ethical principle stated in the contract preamble. It must translate into a concrete verification procedure, with responsible parties identified and deadlines set.
1. Establish a clear obligation of means. The contract must specify that any output generated by AI undergoes human review before critical use (legal, financial decision, or affecting third parties), otherwise the oversight clause remains decorative.
2. Define who validates, with what skills. Naming a function (senior lawyer, DPO, business lead) rather than a vague "the client" avoids gray areas in the event of error.
3. Set a correction deadline. In the event of an error detected after use, the contract must provide for a notification and correction deadline, as well as compensation arrangements if applicable.
4. Articulate with insurance caps. The oversight clause must explicitly reference the service provider's liability caps and insurance coverage; otherwise, an undetected AI error may remain without effective remedy.
This articulation between human oversight and insured liability becomes all the more strategic as Directive 2024/2853 on defective products extends the scope of possible recourse.
What do these clauses look like in practice?
Excerpt 1, training prohibition: "The service provider undertakes not to use data transmitted by the client, or derived data (embeddings, vector representations), to train, fine-tune, or improve a model intended for third parties, except by prior written agreement limited to the tools listed in Annex A."
Excerpt 2, minimal DPA: "The processor provides in an annex the exhaustive list of subprocessors involved in the processing, specifies the location of servers, and undertakes to notify any change to this list at least 15 business days before its implementation."
Excerpt 3, AI Act transparency: "All content generated by an AI system within the meaning of the European Regulation on Artificial Intelligence is marked in a legible manner, and the end user is informed of the AI-generated nature of the content before any decision based on it."
| Clause | Legal objective | Point of vigilance |
|---|---|---|
| Training prohibition | Prevent data reuse for fine-tuning | Also cover embeddings, not just raw documents |
| DPA and subprocessing | Compliance with Article 28 GDPR | Require the updated list of subprocessors |
| AI Act transparency | Compliance with Article 50 | Provide for automatic marking, not a mere contractual mention |
These three clauses work together: confidentiality poorly articulated with AI use often leaves blind spots precisely between these three regimes.
Contractual checklist: what to do within 72 hours?
When faced with a new contract involving AI, the first 72 hours often condition the entire subsequent negotiation.
1. Block unauthorized training. Insert a prohibition clause, even provisionally, before any signature or automatic renewal.
2. Require a DPA, even temporarily. An incomplete but signed DPA is better than a verbal promise from the salesperson.
3. Request access to logs. Formalize the request for access to technical logs in writing, even if the full audit follows later.
4. Mobilize the right internal parties. DPO, CISO, procurement, and legal counsel must coordinate at this stage, not after signature.
5. Plan three-month follow-up. Schedule an initial reporting meeting and a review of mitigation measures before the end of the quarter.
Pro tip: Never leave the audit clause "to be negotiated later": this is precisely the clause that vendors defer indefinitely once the contract is signed.
Real-time pseudonymization as a contractual safeguard
A layer of pseudonymization applied before sending data to a public AI changes the very nature of contractual risk. If no identifying data ever leaves the enterprise, the training prohibition becomes technically verifiable, and no longer just a promise on paper.
Stateless processing, without storing the documents processed, allows you to use public AIs like ChatGPT or Claude without transmitting real identifiers, while producing an exportable mapping to restore the original data on the client side. For the auditor or the DPO, this translates into concrete evidence to attach to the compliance file: processing reports, export of the anonymization mapping, and timestamped logs. These elements align directly with the pseudonymization requirements within the meaning of Article 4(5) GDPR.
Outlook: what 2026 will change in contractual negotiation
The AI Act and the Defective Products Directive will gradually transform clauses currently negotiated on a case-by-case basis into market standards. I expect rapid standardization of technical annexes, much as cloud security clauses became quasi-uniform after a decade of disparate negotiations.
What will really unfold is the rise of independent audits as contractual currency. A supplier unable to produce a recent SOC 2 report or ISO certification will lose a negotiating point, not just a compliance point. My advice: modularize your clauses now rather than waiting for a definitive implementing text. Contractual governance conceived as a continuous process resists regulatory change far better than a static contract renegotiated in haste every two years.
- Jacques
Reduce contractual risk with an operational pseudonymization layer
Certain solutions process documents in real time, without durably storing them, which directly addresses one of the most difficult clauses to enforce in an AI contract: the prohibition on training with real data.
Certain platforms automatically detect many types of personal and confidential data in a document before it goes to a generative AI, then provide an exportable mapping to restore the original data once the response is obtained. This type of technical safeguard can transform a theoretical training prohibition clause into verifiable practice, and provide concrete elements-such as processing logs-to present during an audit. Those who want to formalize these commitments in their own contracts can consult Safe-Doc's DPA, GDPR, and AI Act page, or request a demonstration to assess how the solution integrates with an existing document workflow.
Sources
To deepen technical and legal implementation, several official resources remain essential:
- Guide to personal data security | CNIL
- SaaS and AI: contractual clauses for buyers
- AI terms and conditions: 2026 clauses to add (Atias Avocats)
This article provides general information and is not a substitute for advice from a qualified attorney. Consult a qualified legal professional regarding your individual case before acting on this content.