Confidentiality Terms to Require From an AI Platform Vendor

A standard NDA assumes a human recipient who receives information, holds it in confidence and does not pass it on. An AI strategy platform does something structurally different: it ingests entire document sets, generates new material derived from them, retains the record of every interaction, and in some architectures learns from what it is fed. Five clauses address the gap: a no-training guarantee with an audit right; named sub-processors and data residency; deletion on termination with a certificate; model-version logging; and an incident notification scope that covers AI-specific failure modes.

Nothing in this article is legal wording or a substitute for legal counsel on any specific engagement.

A bilateral NDA is written for a human recipient. An AI strategy platform ingests entire document sets, generates new material derived from them, retains the record of every interaction, and in some architectures learns from what it is fed. Four categories of information a conventional NDA does not adequately cover:

• Inputs: board packs, financial models and diligence files uploaded to the platform – far larger and more sensitive than what a typical SaaS data processor touches.
• Generated outputs: new material the system produces, which may quote, summarise or recombine confidential content.
• Prompts: instructions the team types, which often contain client names, deal context and strategic intent.
• Model-interaction metadata: query frequency, session lengths, interaction times and user locations, which can map operational workflows, research timelines and competitive intelligence patterns.

Two further gaps deserve explicit attention. First: a model fine-tuned on customer material can memorise and reproduce fragments for a different customer – turning a confidentiality breach into an automated, repeatable event. Second: "we never share your data" is not the same as "we never train on it." A vendor can hold documents in strict confidence and still incorporate what it learned into a model that then serves competitors.

Ambiguity in defined terms cascades through every operative provision. The five defined terms that decide the most:

Three areas deserve particular attention in negotiation: Usage Data should be elevated to confidential information. Prompts should be treated as Customer Data in full. A prohibition on shadow data ingestion prevents quiet scope creep – where the vendor ingests content from customer sessions to improve its service without explicit permission.

A strategy firm evaluating an AI platform should insist on five clauses that standard vendor templates routinely omit or weaken:

1. A no-training guarantee with an audit right. The default should be that customer data, prompts, inputs and outputs are not used to train any model. Any exception requires express opt-in consent plus de-identification safeguards. An audit right – as the ICO expects under Article 28(3)(h) of the GDPR^[2] – turns the promise into something verifiable.
2. Data residency and a named sub-processor list. State the region where data is stored and processed. Name every sub-processor and require prior authorisation for changes, as Article 28(2) and (3)(d) of the GDPR require. The sub-processor list must include any third-party foundation model provider.
3. Deletion on termination, with a certificate. Require the vendor, at the customer's choice, to delete or return all data at the end of the contract and to provide written evidence that deletion has occurred. A vendor that cannot produce a deletion certificate from a prior client termination has never tested its own offboarding process.
4. Model-version logging. Every output should be traceable to the model version that produced it, so analysis can be audited months later and model behaviour change can be detected. This clause supports both the accountability record and the claim-to-source map for regulated work.
5. Incident notification with a properly defined breach scope. Notification obligations and cost allocation should be set out expressly. The definition of a security incident should cover model inversion and data extraction through outputs – AI-specific failure modes – not only network intrusion. Commit to notifying within a defined period.

The discipline is to ask each vendor for an artefact – a document or demonstration – rather than a verbal assurance. Assurances given in a sales meeting are not binding; written answers filed with the contract are.

• Deletion: request the evidence trail from a completed offboarding – the deletion log and certificate – not a description of the process. A vendor that cannot produce one has never tested it.
• Sub-processors: ask for the complete current sub-processor list, including any third-party foundation model provider and the data-centre locations for each.
• Anonymisation: probe the de-identification methodology and whether re-identification is technically feasible. A vendor that cannot answer should not be given access to client documents.
• Training controls: ask whether data is segregated between customers, whether training runs on shared or dedicated models, and whether a customer's data can ever influence outputs for a different customer.
• Certifications: treat SOC 2 and ISO 27001 as a baseline. Reliance on certifications alone, without the due-diligence questions above, is not adequate.^[3]

Run the questions in writing and keep the answers. The written record is also evidence that the firm conducted appropriate due diligence if the relationship later becomes a source of a confidentiality incident.

Confidentiality is quietly won or lost at the end of an engagement. Three exit-term provisions prevent lock-in and data exposure at termination:

• Export format: specify the format in which client data and analysis outputs are returned, and whether prompts are retrievable alongside them. If the vendor cannot produce a data export in a usable format, the practical ability to leave is limited regardless of the contractual right.
• Ownership of outputs: the contract should confirm at minimum that the customer holds a broad licence to use outputs for any lawful business purpose without restriction. Any fine-tuned model built on the customer's data should receive separate, explicit treatment of ownership and the customer's ability to take it away on termination.
• Log retention: state how long the vendor retains usage logs and interaction records after termination and on what deletion cycle they are purged.

The GDPR floor: Article 28(3)(g) requires that at the end of a contract, the processor must delete or return all personal data and delete existing copies, unless law requires storage.^[2] Delayed deletion from backups is acceptable only where the data is put immediately beyond use and deleted on the processor's next deletion cycle.

Most vendor questionnaires miss the service-improvement clause. Most technology agreements allow the vendor to use customer data to improve its offerings, and vendors increasingly seek rights to extend this to training AI models. Such language has significantly broader implications than a conventional service-improvement clause.

The core problem: data ownership does not equal data control. Even if a company retains ownership of its raw data, broad rights over aggregated or anonymised derivatives may let a vendor build models incorporating learnings from that data indefinitely – and those models will continue to serve the vendor's other customers after the contract ends.

Four things to address explicitly in the contract:

1. Define derived-value use explicitly: benchmarks, analytics products, new features and model training should each be named – not left to an open-ended "improve our services" clause.
2. Prohibit the derived uses you will not accept: name them individually rather than relying on a general confidentiality provision.
3. Restrict any permitted use to your own instance – not aggregate training across the customer base.
4. Tie any permitted use to the contract term – not an indefinite licence that survives termination.

This example is illustrative, not a real engagement, and not legal advice. A mid-sized strategy firm evaluating an AI platform ran its pre-contract review in three passes.

1. Pass one, definitions: confirmed that Inputs, Outputs, Customer Data, Usage Data and Training Data were all defined, that prompts sat inside Customer Data, and that the service-improvement clause was limited to the customer's own instance.
2. Pass two, the five clauses: requested a no-training commitment in writing, the published sub-processor list, evidence of a prior deletion certificate, the model-version logging specification, and incident notification terms that covered AI-specific extraction attacks.
3. Pass three, exit terms: fixed the export format, confirmed a broad licence over outputs, and capped post-termination log retention at 90 days for non-personal logs.

One question exposed the gap that mattered most: the vendor could not document its de-identification methodology or rule out re-identification of firm or client data, even after two follow-up requests. The contract was amended before signature: a defined de-identification standard, a prohibition on re-identification, and an explicit end to derived-value use when the contract ended.

Decisity states plainly that customer data is never used to train AI models and pairs that commitment with full source traceability and European data residency. The security overview covers the technical and contractual commitments in detail.

Related reading:

• Confidential Documents and AI Strategy Tools: What to Verify
• AI-Assisted Deal Analysis: Meeting the IC and LP Evidence Bar
• AI Model Version Disclosure: What Your Board Needs to Know
• How Decisity works

• Ward and Smith: Contract architecture – core AI clauses for vendor agreements
• ICO: Contracts and liabilities between controllers and processors – what needs to be included
• Ward and Smith: Pre-contract due diligence and operational safeguards for AI vendor engagements
• Morgan Lewis: Key considerations when allowing a vendor to train AI models on customer data (June 2026)