Skip to content
be-human.ai
← Back to the journal

Human oversight

Data Processing Agreement for AI Vendors: What to Check

The clauses to look for in a data processing agreement with an AI vendor: training use, retention, subprocessors, incidents, plus questions for legal review.

Nested oak boxes of decreasing size sit on a travertine slab with their lids slightly open, next to a folded sheet of blank ivory paper, in warm sunlight.
Conceptual illustration created with AI · Be Human

A data processing agreement with an AI vendor should say which personal data the vendor may process, for which purposes only, where, through which subprocessors, and what happens to that data when the contract ends. The clauses that matter most for AI are the ones generic templates often skip: training use, retention of prompts and outputs, logs, memory and deletion. Read the agreement as an operating document that describes how your data moves, not as a formality to sign and file.

Key takeaways

  • Confirm roles first: your company should be the controller and the vendor the processor, with no hidden purposes of the vendor's own.
  • Ask for a written statement on training: your prompts, files and outputs should not improve models for other customers unless you opt in.
  • List every place data can rest: prompts, outputs, logs, embeddings, agent memory and backups, each with a retention rule and a deletion path.
  • Get the full subprocessor chain, including the model provider, with notice and objection rights when it changes.
  • Pair the agreement with evidence: security documentation, incident duties and an exit plan that returns or deletes your data.

Why does an AI vendor need more than a standard DPA?

In a conventional software tool, data enters a form and sits in a database. In an AI service, the same data may pass through an application layer, a model provider, a retrieval index, a log store and a memory store. Each layer can belong to a different company, and each keeps something: a copy, a derived representation or a trace.

Privacy laws such as GDPR and LGPD distinguish the party that decides why data is processed (the controller) from the party that processes it on its behalf (the processor, called operator under LGPD). A good agreement keeps the vendor in the processor role. The risk appears when a vendor reserves the right to use customer content for its own product improvement. For that purpose the vendor is acting for itself, and your company has agreed to something it may not have intended.

If you operate in Brazil, read this alongside LGPD and AI agents: what Brazilian companies should check, which covers the legal bases and the duties that sit with you as controller.

Which clauses should you look for?

Use this list as a first pass. Each item should be answered in the text, not in a marketing page that can change without notice.

  • Scope and instructions: the agreement names the categories of personal data, the categories of people, the purpose and the duration, and states that the vendor processes data only on your documented instructions.
  • Roles: it says plainly that the vendor is a processor for your content, and lists any purpose for which the vendor claims to act independently.
  • Training and improvement: it prohibits using your content to train, tune or evaluate models for other customers, or makes it an explicit opt-in.
  • Retention and deletion: it sets retention rules for prompts, outputs, files, embeddings, logs and memory, and requires deletion on request and at termination, with written confirmation.
  • Subprocessors: it lists them, including the model provider and hosting provider, requires notice before changes, and gives you a right to object.
  • Location and transfers: it states where data is stored and where model inference runs, and which transfer mechanism applies when data leaves your jurisdiction.
  • Security measures: it describes controls concretely, such as access control, encryption, customer separation and logging, instead of promising "industry standard" security.
  • Incident notification: it defines a notification window, the information you will receive and the vendor's duty to cooperate.
  • Assistance with requests: it commits the vendor to help you answer access, correction and deletion requests from individuals.
  • Audit and evidence: it allows you to review reports, answer questionnaires or audit in a reasonable way.
  • Return and exit: it describes how you can export your data and in what format before deletion.

What do training, retention and memory change?

These three topics are where AI differs most from ordinary software, so they deserve their own attention.

Training. Ask the question directly: will anything we send, or anything the agent produces, be used to train or improve a model that other customers use? The answer should be a clear no, or a clear opt-in that you control. Be careful with phrases such as "to improve our services", which can cover more than you expect.

Retention. Prompts often contain more personal data than anyone planned, because staff paste emails, contracts and notes into them. Outputs can contain personal data too. Model providers may keep inputs for a period for abuse monitoring, and some offer a mode with no retention. Ask what the default is, whether people can read retained content, and whether you can choose the stricter option in the agreement.

Memory. An agent that remembers clients, preferences and past decisions has a memory store, and that store is personal data in the same way a CRM is. Embeddings created from your documents are derived from them and should be treated as the same data. The deletion clause must reach memory, indexes and logs, not just the visible chat history. A practical way to reduce all three problems is to send less in the first place, as described in data minimization for AI agents.

A level brass balance scale holds a glass jar of seeds on one pan and folded ivory paper with a green marble block on the other, beside a coiled measuring tape.
Conceptual illustration created with AI · Be Human

How far does the subprocessor chain go?

Most AI services are assembled from parts. The vendor you sign with may run its application on a cloud provider, call a model from another company, send logs to a monitoring service and use a separate email or messaging provider. Your agreement binds the first company. It should also ensure the same obligations pass down the chain.

Ask for these items in writing:

  • The current subprocessor list, with the service each one performs and the country where it operates.
  • The commitment that each subprocessor is bound by terms no weaker than yours.
  • The notice period before a new subprocessor is added, and what you can do if you object.
  • The model provider's terms on retention, human review and training, as they apply to your data.
  • Whether you can choose a region or a no-retention option for inference.

A vendor that cannot describe its chain in a simple diagram usually has not mapped it. For a broader review of the vendor itself, how to run a security review of an AI agent provider gives a structured set of questions that complements the contract.

What should security, incident and audit clauses say?

Security language in agreements is often generic. Look for specifics you can later verify: how access to your data is limited inside the vendor, how customers are separated, how credentials are stored, and who can see your content during support. Ask how the vendor addresses risks specific to language model applications, such as prompt injection and excessive agent permissions. The [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) is a useful reference for that conversation, and the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) helps you frame the vendor's answers as part of your wider risk work.

For incidents, the agreement should define what counts as one, how fast you will be told, what the notice contains and who does what next. An agent that sends the wrong document to the wrong person is a different kind of event from a database breach, so check that misdirected output and unauthorized agent actions are covered by the notification duty, not only data theft.

For exit, require a way to take your data and configuration with you, and a deletion confirmation afterward. This is also the best protection against dependency on one provider, a topic covered in how to avoid AI vendor lock-in with business agents.

What does this look like in practice? An illustrative scenario

Illustrative scenario: a small accounting firm wants an AI assistant to draft replies to client emails. The vendor's standard agreement allows use of customer content "for service improvement" and names the hosting provider but not the model provider.

The firm's legal reviewer asks three questions. Does service improvement include model training? Which company runs the model, and how long does it keep inputs? Does deletion at termination cover the assistant's memory of client details? The vendor answers that training is excluded for business accounts, names the model provider and offers a no-retention setting, and agrees to add memory and logs to the deletion clause. The firm adds a short internal rule that client tax identifiers are never pasted into prompts. None of this required a new tool. It required reading the agreement against the actual data flow.

Questions to bring to legal review

Give your lawyer or privacy officer this list along with a one-page description of the workflow: what the agent does, which data it sees and who approves its actions.

  • Are we the controller and the vendor the processor for every purpose, and where does the text say otherwise?
  • Does any clause let the vendor or its providers use our content for training, evaluation or product analytics?
  • Which data types are retained, for how long, and can we shorten or disable retention?
  • Does the deletion obligation reach logs, embeddings, backups and agent memory, and how is it confirmed?
  • Is the model provider listed as a subprocessor, and are its terms flowed down?
  • Where is data stored and where is it processed, and which transfer mechanism applies?
  • How are we told about incidents, including wrong outputs and unauthorized actions by the agent?
  • What happens to our data and configuration if we terminate, and in which format can we export it?
  • How does the liability section treat a breach caused by a subprocessor?
  • Does the regulation that applies to our sector, or to our use case, add duties the template does not cover? For the European angle, see whether the EU AI Act applies to your company's AI agents.

How does a managed approach handle this?

Be Human treats the agreement as one input to the design, not a separate legal step. At the start of an engagement, the role, the data categories the agent will touch, the tools it connects to and the approval boundaries are written down, which gives your legal reviewer a concrete description of the processing. During managed operations, permission reviews and integration maintenance include checking that what the agent can reach still matches what was agreed, and subprocessor or provider changes are brought to your attention for review. The legal assessment itself stays with your counsel.

Frequently asked questions

Do we need a data processing agreement if we only send a little personal data? Yes, if the vendor processes personal data on your behalf at all, the amount does not remove the need. Small volumes still carry obligations, and an agreement is also what lets you hold the vendor to retention and training limits. Reducing what you send is a good complement, not a substitute.

Can we accept the vendor's standard agreement as it is? Often you can, if it answers the clauses above in clear text. Read it first and negotiate only the gaps that matter, usually training use, retention, the subprocessor chain and deletion scope. A vendor unwilling to clarify any of them has told you something useful.

Who is responsible if the vendor's model provider has a breach? Your contract is with the vendor, so the agreement should make the vendor responsible for its subprocessors and require them to notify you. As controller, you may still have your own duties toward regulators and affected people. Ask your counsel how liability and notification fit together before you sign.

How often should we review the agreement after signing? Review it when the workflow changes, when the vendor announces a new subprocessor or provider, and on a regular schedule such as an annual check. Record the review in your AI risk register so changes to data, tools or permissions trigger a fresh look at the contract.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.

Less busywork. More room for you.

Bring us the work you wish you had time for.

Try a personalized AI agent free for 7 days on WhatsApp ↗