Five Contract Clauses That Decide Who Controls the AI Incident Record

Authored by Lukáš Smola, an independent hobby writer affiliated with The First File, writing on law, technology, and governance. His work explores contemporary legal and technological developments.

When an enterprise AI system fails, the most important evidence often sits outside the customer’s possession. The provider may hold prompts, output logs, and model-version history. A cloud host may hold infrastructure records. A specialist subprocessor may operate a safety filter. The customer may know who was affected but lack the technical evidence needed to explain why.

That division becomes a contract problem before it becomes a regulatory problem. A generic security addendum may cover unauthorized access while saying little about bias, unsafe output, model drift, or human-oversight failure. A broad promise to “cooperate” does not establish which records exist or whether they will survive ordinary deletion.

Five clause families determine whether the parties can build a coherent AI incident record. The drafting issues below are not universal model language. They are points for counsel to resolve against the use case, bargaining position, technical architecture, and applicable law.

This article explains how contract terms can turn fragmented technical records into usable incident evidence. Its purpose is to help counsel identify who must create, preserve, and disclose that evidence before an AI failure tests the parties’ legal and operational assumptions.

The discussion is comparative, not a statement that one legal regime governs every deployment. The EU AI Act and GDPR illustrate binding duties within their respective scopes; the U.S. authorities cited apply only to covered entities or proceedings. The remaining drafting points are contractual recommendations to be adapted to governing law, system risk, and the parties’ roles.

Control over AI incident evidence is, therefore, both a contractual and an evidentiary issue. In U.S. litigation, the agreement should also anticipate discovery scope and control over electronically stored information, issues outlined in this guide to Federal Rule of Civil Procedure 26.

1. Notice: define the event and the information flow

A traditional incident notice often begins with unauthorized access to customer data. AI failures do not fit neatly inside that trigger. A system may generate discriminatory rankings, fabricated professional advice or dangerous instructions without a security breach. A provider may discover a model defect affecting multiple customers before any customer identifies a concrete harm.

Counsel should separate at least four event types: a security incident involving compromise of data or systems; an AI safety incident involving harmful or unsafe behavior; a performance failure against documented accuracy, reliability, or service requirements; and a regulatory or compliance event such as a complaint, inquiry, or government contact tied to the service. The categories may overlap, but they need not share the same trigger, deadline or escalation level. A tiered structure can reserve immediate notice for material safety or security events and use a different cadence for lower-severity performance issues.

The trigger needs a knowledge standard. “Confirmed incident” may postpone notice until causation is settled; “suspected incident” can generate noise. Drafting can instead link notice to specified facts, reasonable belief, severity or activation of a formal response process. Decide whether subprocessor awareness counts as provider awareness.

Timing language should identify the clock, permitted initial uncertainty and follow-up cadence. Article 73 of the EU AI Act illustrates why this matters within its legal scope. For providers of covered high-risk AI systems placed on the Union market, it ties serious-incident reporting to awareness and causal assessment, sets a general 15-day outer period with shorter periods for specified incidents, and permits an incomplete initial report when necessary for timeliness. Those are statutory reporting duties, not a universal private-contract timetable. A customer that receives notice only after a vendor finishes root-cause analysis may nevertheless lose time needed for its own role-specific decisions.

Initial content should include the affected service and model version, detection time, scope, impacts, containment, evidence status, contact and next update. Avoid requiring a definitive cause. Require corrections when earlier information materially changes.

2. Logs and evidence access: specify the record, not merely an audit right

An audit clause does not guarantee useful incident evidence. It may provide only an annual report, exclude model internals, or operate too slowly for a live response. The agreement should identify evidence categories and a retrieval process.

Relevant categories may include input and output records, system prompts, model and configuration identifiers, retrieval sources, tool calls, safety-filter events, human overrides, access logs, deployment history, evaluation results, complaints, and incident tickets. The proper list depends on the system. A provider should not be required to create telemetry that would undermine privacy, security, or other customers’ confidentiality, but the customer should understand those limits before deployment.

AI Act logging rules provide a useful statutory reference point without becoming a universal contract checklist. Article 12 requires covered high-risk AI systems to support automatic event logging over their lifetime at a level appropriate to their intended purpose. Articles 19 and 26 assign retention duties for automatically generated logs under the control of providers and deployers, respectively. These are role- and scope-specific legal duties. Contract terms should separately allocate access, format, preservation, and cooperation according to the parties’ actual technical control.

Access drafting should address format, metadata, time zone, field definitions, secure transfer, response time, and follow-up questions. It should distinguish routine assurance from incident access. Can the customer connect a provider event to its transaction without exposing another customer’s information?

Trade-secret and confidentiality protections need calibrated procedures, not absolute vetoes. Options include limited-access review, independent experts, secure rooms, redacted extracts, or attestations for narrowly defined facts. The practical question is whether the arrangement lets the customer verify the incident while protecting legitimate provider and third-party interests.

3. Preservation and cooperation: convert aspiration into an operating protocol

“Reasonable cooperation” leaves the hardest questions unanswered. Who issues a preservation request? Which systems and custodians are covered? Can routine deletion continue? Who pays for forensic work? May the customer speak directly with a subprocessor or regulator?

The clause should define an activation mechanism and named contacts. Once activated, it can require each party to preserve relevant records under its control, identify material gaps, maintain an action log and avoid changes that would unnecessarily destroy evidence. The scope should be capable of narrowing as facts develop; an indefinite hold over every model interaction is neither proportionate nor operationally credible.

Cooperation can cover technical interviews, reproducibility testing, regulator questions and a joint chronology. Privilege and work-product issues require jurisdiction-specific handling. The contract should not promise that every cross-party investigation communication will be privileged.

Preservation must coexist with containment and safety. A provider may need to disable a system or overwrite a harmful configuration immediately. Drafting should permit urgent protective action while requiring feasible snapshots, decision records and prompt explanation. It should also address legal holds, statutory retention and instructions from authorities that may override normal deletion or disclosure restrictions.

4. Subprocessors: make the evidence chain survive delegation

AI supply chains are unusually layered. A customer contracts with an application provider that relies on a foundation-model API, hosting provider, vector database, moderation service, and evaluation vendor. The primary vendor cannot provide evidence that it has neither required nor retained downstream.

Subprocessor terms should address advance information or notice, permitted functions, locations, material changes, and flow-down of incident obligations. The lead provider should remain the operational point of accountability to the customer even when a subprocessor supplies the facts. Direct customer contact with subprocessors may be useful in a major incident, but it should be coordinated so that requests do not conflict or bypass security controls.

Within its scope, Article 28 of the GDPR supplies a binding model for personal-data processing: a controller may use only processors providing sufficient guarantees; the contract must specify required processing details and assistance; subprocessors must receive the same data-protection obligations; and processors must make information available to demonstrate compliance and allow audits. Those duties do not automatically require disclosure of every AI artifact. Any broader evidence-access requirement remains a matter for tailored drafting and other applicable law.

The FTC Safeguards Rule likewise requires covered financial institutions to take reasonable steps in selecting and retaining capable service providers and to require safeguards by contract, with periodic assessment based on risk and continued adequacy. NIST’s voluntary AI Risk Management Framework adds AI-specific governance context by recommending documentation, monitoring, and contingency processes for third-party AI resources.

For an Indian comparison, section 8 of the Digital Personal Data Protection Act, 2023, places responsibility on the Data Fiduciary for processing carried out on its behalf, permits engagement of a Data Processor only under a valid contract, and addresses safeguards and breach notification. India’s commencement framework is staged, so counsel should confirm which provisions and 2025 Rules are in force for the relevant date. The framework reinforces the same drafting lesson without converting a data-protection duty into a general right to every AI record.

Drafting should also allocate the consequences of a downstream refusal. The lead provider can be required to use enforceable flow-down rights, pursue the subprocessor promptly, provide equivalent evidence or a reasoned attestation where direct production is lawfully unavailable, and keep the customer informed. For a material or continuing failure, defined remedies may include service credits, indemnity for specified response costs, suspension or replacement of the component, termination rights, and transition assistance. Any remedy should remain subject to proportionality, confidentiality, privilege, data-protection law, and restrictions protecting other customers. A right to receive notice has limited value if the contract does not respond when the evidence chain breaks.

5. Deletion and exit: preserve what is needed without creating a shadow archive

Termination clauses often require return or deletion of customer data, while incident clauses require preservation. Both can be correct. The agreement needs an order of operations.

Define the export package before exit: customer content, relevant outputs, configuration, model/version identifiers, audit history, open incident records and documentation needed for continuity. Specify formats, delivery timing and whether transition assistance includes an explanation of proprietary fields. As a broader discussion of privacy, security, and contract issues in cloud services notes, cloud contracts commonly allocate responsibilities for access, permitted use, return and destruction rather than eliminating them. See The First File’s cloud-contract guide.

Deletion should identify active systems, caches, replicas, test environments and backups, while acknowledging technical differences. Require a completion record or certification suited to the risk. Identify exceptions for law, unresolved disputes, and preservation duties, and limit retained data to the relevant purpose with continued safeguards and a final deletion trigger.

The European Commission’s controller-processor standard contractual clauses illustrate this structure for covered personal data: following termination, the processor generally deletes and certifies deletion or returns the data and deletes existing copies, unless applicable law requires storage. That is not a ready-made AI exit provision, but it highlights the choices a bespoke clause must resolve.

Exit drafting should also anticipate provider failure, not just orderly termination. Address access if the provider discontinues a model, loses a key subprocessor or becomes insolvent. Determine which documentation remains available and which rights survive long enough to close an incident.

Contract architecture determines incident truth

These five clause families work as a system. Notice without log access produces an alert without proof. Access without preservation retrieves whatever survived. Preservation without subprocessor flow-down stops at the first vendor boundary. Cooperation without exit rights can leave the customer dependent on a service it no longer trusts.

Counsel should test the package with a tabletop built around the actual architecture. Ask who detects the event, who possesses each artifact, which clock starts, how a hold reaches subprocessors and what the customer receives if the service is terminated during the investigation. The gaps found in that exercise are drafting issues, technical requirements or both.

An AI contract cannot guarantee a clean incident. It can determine whether the parties share a verifiable record—or negotiate about missing evidence while a regulator waits.

Sources

• Regulation (EU) 2024/1689 — Artificial Intelligence Act

• Regulation (EU) 2016/679 — General Data Protection Regulation

• European Commission Implementing Decision (EU) 2021/915 — Controller-processor standard contractual clauses

• 16 C.F.R. § 314.4 — FTC Safeguards Rule elements

• NIST — AI Risk Management Framework Core

• NIST — AI Risk Management Framework Playbook: Manage

• The First File — A cloud computing business in 2026 can face privacy, security, and contract law issues

• The First File — Federal Rule of Civil Procedure 26

• Digital Personal Data Protection Act, 2023 — section 8

• Digital Personal Data Protection Rules, 2025