AI for Legal Teams: Privacy and DPA Checklist Before Buying

Checklist for legal and compliance teams: what to require from an AI vendor before signing — DPA, data retention, training opt-out, and certifications.

Why "reading the terms" does not solve this
The checklist: eight questions before you sign
Summary table for the evaluation meeting
Red flags: when the answer is already an answer
How this relates to what an employee should no longer paste
Frequently asked questions

Disclaimer: this article is a practical evaluation guide, not legal advice. AI vendors' policies change often; before you decide, verify the current version directly with the vendor and, for contractual and regulatory detail, with a lawyer specialized in data protection in your jurisdiction.

If your company has already decided that AI is entering the workflow, the legal or compliance team is not there to say "no". It is there to ask a different question than an end user asks: not "does this tool help me?", but "what happens to the data that goes in, who sees it, where is it stored, and what do we sign for that?".

This post complements the article on AI security and privacy in business, which covers what an employee should not paste into an AI chat. The angle here is different: it is the checklist legal and compliance should run before approving a tool, whichever it is. It does not evaluate any particular vendor — it evaluates the evaluation process.

Why "reading the terms" does not solve this

An AI vendor's terms of service change, sometimes several times a year, and they often have different layers depending on the product: the consumer chat, the API, the team plan, and third-party integrations can be governed by different documents under the same brand. Claiming today that "this vendor does not train on our data" as a fixed fact is the kind of sentence that ages poorly.

That is why the operational answer is not to memorize a specific policy, but to install a process: a checklist you run every time you evaluate a new tool, and run again when the terms of a vendor you already use change.

The checklist: eight questions before you sign

Each question must have a written answer from the vendor, not an impression from the sales call.

1. Is there a signable DPA (Data Processing Agreement)?

A DPA is the document that defines who is the controller and who is the processor, what the vendor can do with the data you send, and under which rules. If the vendor does not have a DPA available for your type of plan, or only offers it from a certain enterprise contract tier, that is information you need before deciding which plan to buy — not after.

Concrete question: "Can you send me the current DPA for the plan I am evaluating?" If the answer takes weeks or nobody knows whom to escalate it to, that is a signal about the real size of the vendor's compliance team.

2. Where are data processed and stored (data residency)?

Some vendors let you choose a processing region (for example, EU or US); others do not, or only offer it on higher plans. If your company operates under a regime that requires certain data not to leave a region — or that an international transfer be notified — this is not a technical detail: it is a compliance condition.

Check the current policy of the vendor you are evaluating, because it changes often and sometimes changes by billing country, not only by plan type.

3. What is the data retention window?

"We do not train on your data" is not the same as "we do not store your data". They are two different promises. Ask explicitly:

How long is conversation content or processed documents retained?
Is that period configurable by the customer?
What happens to the data if we cancel the contract?

4. Is there a real training opt-out ("do not train on my data")?

Many vendors offer some training opt-out mechanism, but the scope varies: it may apply only to chat and not the API, only to certain plans, or require each user to turn it on individually instead of being an account-level corporate policy. Ask them to confirm it in writing for the exact product you will use, not for "the brand" in general.

5. Is there a list of subprocessors?

A subprocessor is any third party the vendor uses to provide the service (cloud infrastructure, support tools, translation services, etc.). A serious vendor publishes or delivers on request a list of subprocessors, and notifies when it changes. If your contract with your own customers obliges you to tell them who processes their data, you need this list to fulfill your own chain of responsibility.

6. Are audit logs accessible to the account administrator?

For compliance, the question is not only "does the vendor keep logs?" but "can I, as administrator of my company's account, see who used the tool, when, and at what level of detail?". Without this, an internal investigation after an incident depends on asking the vendor for data, with the timelines that implies.

7. What certifications does it hold, and since when?

SOC 2 (Type I or Type II), ISO 27001, and sector-specific certifications (health, financial) are the standard way a vendor demonstrates controls verified by a third party, not self-declared. Ask for the report or the certificate, not just the logo on the pricing page. A logo without a date or defined scope is not evidence.

8. Whom inside the vendor can I write to with compliance questions?

A mature vendor has an identifiable channel (trust center, privacy email, security portal) distinct from general support. If the only path is a sales chat, that limits how fast you will be able to resolve a contractual question in the future, or react to a policy change.

Summary table for the evaluation meeting

Use this table as the minutes of the meeting with the vendor. If a row is left blank, that is the pending question before you approve.

Point to verify	Vendor response	Evidence (document / link)
DPA available for the plan under evaluation
Data residency / international transfer
Data retention window
Training opt-out (exact scope)
List of subprocessors
Audit logs for account admin
Current certifications (SOC 2, ISO 27001, others)
Compliance contact / trust center

Red flags: when the answer is already an answer

"We do not train on your data, trust us" with no document to back it up. A generic consumer-facing privacy policy is not a DPA.
The DPA only exists "from X seats" or "on the Enterprise plan", and nobody tells you until you have already advanced the evaluation on the cheapest plan.
Nobody can explain the difference between the chat product and the API on retention or training. They are, often, different products with different rules inside the same vendor.
The list of subprocessors does not exist or is not updated. If they do not know who else touches the data, they cannot guarantee you much about them either.
Certifications are mentioned but cannot be shown. Ask for the certificate or the report summary, not the list of logos.
The only compliance channel is the sales team. A contractual question answered by someone who earns commission for closing the deal is not the same guarantee as a dedicated compliance channel.

How this relates to what an employee should no longer paste

This checklist filters the vendor before you sign. But even with the best DPA signed, there is still a daily decision layer: what specific information goes into each conversation with the AI. That part — what not to share, the difference between a personal plan and a team plan, and how to write a one-page policy the team will follow — is covered in the article on AI security and privacy in business. The two checklists are complementary: one is for legal before buying, the other is for the whole team every day.

Frequently asked questions

Does a signed DPA eliminate the risk of using AI with customer data?

No. A DPA defines responsibilities and contractual commitments, but it does not replace operational judgment about what information is uploaded in the first place. It reduces contractual and compliance risk; it does not replace an internal use policy.

Do I need a different DPA for each AI tool the company uses?

In principle yes, one per vendor, because each one processes and retains data under its own terms. If your company uses several AI tools (chat, transcription, image generation, automations), the checklist in this article should be run for each one, not only for the main one.

How do I verify that a vendor's policy is still current after signing?

Add a periodic review — quarterly or twice a year — of the vendor's trust center or privacy page to your compliance calendar. Retention, training, and subprocessor policies change, and the signed DPA is not always updated automatically when the public policy changes.

Does this apply equally to AI features built into other software (for example, a CRM with built-in AI)?

Yes, and it is often overlooked. If your CRM, office suite, or helpdesk added an AI feature, that feature may have its own language-model subprocessor behind it, with its own retention policy. Ask that vendor directly which model it uses and under which terms, instead of assuming it inherits the guarantees of the original software contract.

No AI vendor is going to send you this checklist on their own initiative — it is for you to bring to the meeting. The question that separates a vendor ready for a regulated context from one that is not yet ready is not "is their AI good?". It is whether they can answer, document in hand, the eight questions above. If they cannot, that is enough information to decide, even before seeing a demo.