Legal AI Data Processing Agreement Checklist

A legal AI data processing agreement should match the system that will actually receive legal work. Standard clauses may miss model providers, embeddings, prompt logs, human support review, retrieval indexes, and product-improvement uses. The review begins with architecture and ends with a tested exit, not with a familiar contract label.

Use current authoritative sources from MeitY and India Code when qualified counsel determines applicable Indian requirements. The NIST Privacy Framework can help organize privacy risk, while CERT-In publishes cyber directions and advisories. These sources do not replace advice on roles, obligations, enforceability, or incident facts.

Does the agreement describe the real processing scope?

Attach or incorporate a processing schedule that names the service, features, deployment, purposes, duration, data categories, affected people, locations, subprocessors, and customer instructions. Include prompts, files, OCR, embeddings, generated output, feedback, telemetry, support records, backups, and exported data where relevant.

Compare the schedule with the data-flow diagram and order form. Look for gaps between “customer content” in one document and narrower “personal data” elsewhere. Confirm which terms prevail if the DPA, privacy notice, product terms, model-provider terms, and configuration screen conflict.

Review workflow:

1. Freeze the proposed architecture and configuration.
2. Map every data type and recipient.
3. Assign legal and operational roles with counsel.
4. Mark each purpose, instruction, location, and retention period.
5. Compare contract promises with technical controls.
6. Record exceptions, owners, and approval conditions.
7. Recheck the signed documents against production settings.

The legal AI DPIA guide can capture risks that a contract schedule alone will not show.

Are instructions and purpose limits specific enough?

The agreement should identify permitted processing and how the customer issues, changes, and records instructions. Ask what the supplier does if it believes an instruction conflicts with law or creates a security risk. Limit secondary use rather than relying on ambiguous claims that data is “not sold.”

Clarify model training, fine-tuning, evaluation, abuse monitoring, human review, product improvement, and benchmarking separately. Determine whether restrictions cover raw content, derived data, metadata, feedback, and de-identified or aggregated forms. If a setting controls use, require the promised default and prohibit unilateral changes where appropriate.

Ask whether the provider can suspend processing, and under what notice and preservation rules. An urgent suspension may protect data, but an unexplained lockout can disrupt a deadline. Align the term with a documented continuity plan.

How should subprocessors and data locations be controlled?

Require a current subprocessor list that identifies function and location, not only company names. Include model APIs, cloud hosting, observability, support, content scanning, communications, and backup providers. Define notice, objection, replacement, and termination processes for material changes.

Check whether equivalent obligations flow down and whether the primary provider remains accountable under the negotiated arrangement. Ask for a data-residency description that includes processing, support, telemetry, backups, and disaster recovery. “Hosted in India” may not describe every route.

Maintain a change register:

A notice inbox without an assigned reviewer is not an effective control.

Which security commitments should be contractual?

The security schedule should be specific enough to measure and flexible enough to keep pace with risk. Cover identity and privileged access, tenant isolation, encryption, keys, secure development, vulnerability management, logging, personnel controls, incident response, resilience, deletion, and customer configuration responsibilities.

Request evidence rights that are proportionate and usable. Certifications, independent reports, penetration-test summaries, remediation status, architecture reviews, and targeted questionnaires may form a sensible evidence ladder. Define a route for additional evidence after an incident or material change.

Link contract language with the legal AI security questionnaire. If the questionnaire promises a control, ensure the final agreement does not disclaim it. If the customer must enable single sign-on or set retention, name that responsibility in implementation records.

What should incident terms accomplish in practice?

Define the event that triggers notice, the notice route, required information, update cadence, cooperation, evidence preservation, containment coordination, and post-incident findings. Avoid treating the first notification as a complete forensic report. Early facts change.

An operational notice should cover known timing, affected service, data and people, likely consequences, containment, evidence status, and a reliable contact. Require updates as material facts become available. Address regulator and affected-person communications, while preserving lawful decision rights and privilege.

CERT-In applicability and timing require current, fact-specific advice. Contractual notice should leave enough time for the customer to assess its own obligations. Run a tabletop exercise before launch so contact failures and evidence gaps appear while they are fixable.

Can people’s requests and data corrections be supported?

Determine how the provider assists with access, correction, erasure, grievance, nomination, or other applicable processes identified by counsel. The workflow must locate data across primary stores, indexes, logs, support systems, and backups without exposing another person’s material.

Ask whether correcting source data updates embeddings or generated records. Document when an output is a historical work product rather than a live profile, and who decides the treatment. Set response routes, identity verification, search scope, exceptions, and completion evidence.

Test one request with synthetic data. Measure handoffs and verify deletion or correction in each relevant layer. A contractual promise to “assist” is weak if no operator knows how to find the record.

Are retention, deletion, and legal holds workable?

List retention by data type and purpose. Avoid one indefinite period for prompts, files, telemetry, support, and backups. Define the customer’s configuration controls, default values, termination timeline, backup aging, and deletion evidence.

Address legal holds and conflicting instructions through an authorised process. Determine what happens to derived data and whether de-identification is irreversible enough for the intended claim. Ask who can restore deleted information from backup and under what controls.

Deletion test checklist:

• remove a file and confirm search no longer retrieves it;
• verify related embeddings and cached previews are handled;
• inspect administrative and support visibility;
• export a deletion event record;
• confirm backup treatment and restoration safeguards; and
• repeat after account termination.

Do not promise instant deletion if the technical design cannot deliver it. Negotiate accurate, bounded language and risk controls.

What happens at termination or vendor failure?

Specify export formats, metadata, audit records, time window, assistance, charges, access continuity, and secure deletion. Test the export before dependence grows. PDFs alone may not preserve structured fields, sources, permissions, or review history needed for continuing work.

Address insolvency, prolonged outage, disputed invoices, security suspension, and acquisition. Identify which records must remain available for professional, client, investigation, or matter obligations, while avoiding unnecessary retention by the supplier.

Use a scorecard across scope accuracy, purpose limits, subprocessors, security, incidents, rights support, retention, and exit. Rate each zero for absent, one for vague, two for workable language, three for verified implementation. Apply hard gates to uncontrolled training, unknown recipients, unworkable incident notice, and inability to recover or delete critical records.

Pair the review with the legal AI RFP template, accuracy evaluation guide, and self-hosted versus SaaS analysis. Teams may review Gotham’s privacy information, security approach, workflows, or contact Gotham. The signed document is one control. Its value depends on architecture, configuration, ownership, and testing matching the words.