GDPR and AI Agents: What to Know Before You Ship

The AI feature ships before the paperwork exists. A support ticket summarizer, a sales email drafter, a document extraction pipeline, it doesn't matter which, the pattern repeats: someone wires a call to a hosted model, customer data starts flowing into prompts, and the feature goes live to EU users while the actual GDPR obligations sit undone. Nobody signed a data processing agreement with the model vendor. Nobody documented the lawful basis under Article 6 for the new processing purpose. Nobody can answer where the prompts and completions are stored, or for how long, or which sub-processor actually holds them. It is not that engineering teams don't care about compliance. It is that GDPR compliance for an AI feature requires three specific outputs that a code editor and a general-purpose chatbot both fail to produce: a mapped inventory of what personal data actually enters the prompt, a signed processing agreement with whoever is running the model, and a written record of the lawful basis, filed before a regulator or a customer's procurement team asks for it after the fact. Most teams discover the gap the same way, an enterprise prospect's security questionnaire asks for the DPA on file, and there isn't one.

Why ChatGPT can't draft your DPA and Cursor won't ask about data residency

Ask ChatGPT or Claude.ai to "write a GDPR compliant privacy policy for an AI feature" and you get a competent-looking template: categories of personal data, purposes of processing, a boilerplate line about appropriate technical and organizational measures. What you don't get is a policy grounded in your feature's actual data flow, because the chatbot has no access to what your prompt payload contains, no visibility into which sub-processor is receiving it, and no memory of what your existing privacy policy already says about email addresses versus order history. It will produce the same output for a resume-screening AI, a health chatbot, and a support ticket summarizer, because it is optimizing for plausible legal-sounding prose, not for a document your DPO can defend to a supervisory authority. The gap shows up the first time a customer's legal team asks a specific question the generic template can't answer, like which sub-processors receive the prompt data or how long completions are retained.

Cursor and Copilot are worse in a different way. They're not compliance tools and never claim to be, but that's exactly the problem, because they're the tool actually wiring the AI feature into production. An engineer asks Copilot to call the model API to summarize a ticket, and Copilot writes a clean integration in ninety seconds. It doesn't ask whether the ticket contains health data. It doesn't flag that the default API call sends data to US-based infrastructure with no data residency guarantee. It doesn't know a DPA needs to exist before that first API call goes to production, because autocomplete tools have zero model of legal obligation. They complete code, and the code they complete works, which is exactly why the compliance gap stays invisible until someone outside engineering asks about it.

The stakes here are not abstract. GDPR fines under Article 83(5) run up to twenty million euros or four percent of global annual turnover, whichever is greater, and several EU supervisory authorities have already issued enforcement actions specifically against AI processing that lacked a documented lawful basis or shipped an unaddressed international transfer to a US-based provider. This isn't a hypothetical future AI regulation, it's the same GDPR that has applied to every other processing activity since 2018, applied to a new processing purpose that nobody assessed before launch. The AI feature doesn't get a grace period because it's new.

Terms drafts the paperwork, Shield maps the exposure, Warden locks the pipeline

This is the gap Terms, Shield, and Warden are built to close, and they close it before launch, not after a complaint. Terms is the privacy and ToS drafter: given a description of what the AI feature does and what personal data it touches, it runs terms-recon to inventory the actual data flow, what enters the prompt, what leaves as a completion, where it gets stored, before drafting anything. Nothing gets written until the inventory exists, because a DPA or privacy clause drafted against an assumed data flow is worthless the moment the real flow turns out to include a field nobody accounted for.

Tonone's Terms agent runs terms-recon to inventory a feature's actual data flow before drafting a single clause of a DPA or privacy policy update.

Once the inventory exists, Terms drafts the two documents a GDPR-facing AI launch actually needs. terms-privacy produces the data processing agreement addendum naming the model vendor as processor, the categories of data covered, and the retention terms, plus the privacy policy update disclosing the new processing purpose to end users, and the corresponding entry for the Article 30 record of processing activities that the DPO has to keep current anyway. terms-tos updates the Terms of Service clause covering the AI feature itself, what it does, what data it touches, and any opt-out mechanism the feature requires. Both outputs are scoped to the specific sub-processor and retention window terms-recon surfaced, not a generic template pulled from a legal library, which is the difference between a document that survives a customer's legal review and one that gets bounced back with three follow-up questions.

Shield: the exposure assessment that decides what the paperwork needs to say

Shield is the regulatory risk advisor, and its job on this workflow runs one step ahead of Terms. shield-recon maps where the GDPR exposure actually sits: is this large-scale, systematic processing that triggers Article 35, does the feature touch special category data even occasionally, does the model vendor process outside the EEA. shield-assess then turns that map into a judgment call, a lawful basis recommendation under Article 6, a yes-or-no on whether a Data Protection Impact Assessment is required, and a flag on whether the international transfer needs Standard Contractual Clauses because the model host processes in the US with no EU-region option. Where Terms produces the documents, Shield produces the decisions those documents encode.

Tonone's Shield agent screens for DPIA triggers under Article 35 and flags whether international transfers require Standard Contractual Clauses, before an AI feature ships, not after a supervisory authority asks.

Warden: is the pipeline actually locked down the way the DPA says it is

Once the documents exist and the exposure is assessed, the remaining question is whether the infrastructure storing those prompts and completions matches what the paperwork promises. warden-iam audits who has read access to the logged prompts, whether the support team's access to raw ticket content is broader than the documented purpose requires, and whether the retention window written into the DPA matches what the logging infrastructure actually enforces. A DPA that promises thirty-day retention is worthless if the logs sit in a storage bucket with no lifecycle policy and nine engineers holding standing read access nobody ever scoped down.

Tonone's Warden agent audits who has read access to logged prompts and completions against the retention and access terms a DPA actually promises.

Worked example: shipping an AI ticket summarizer to 40,000 EU tickets a month

Northlane, a project management SaaS, wants to ship an AI feature that summarizes incoming support tickets for the triage queue, using a hosted model API. Volume: roughly 40,000 tickets a month across customers in 12 EU countries. Ticket content includes customer name, email, order or account ID, and free-text complaints, a small subset of which come from wellness-industry tenants and occasionally mention health context ("my prescription reminder app crashed again"). Before this ships, Terms and Shield run the review together, and Warden checks the pipeline that will store the output.

Terms + Shield, AI Ticket Summarizer Launch Review
Recon: 40k EU tickets/mo, 12 countries, US-hosted model API, no DPA on file.

───────────────────────────────────────────────────────────
Data flow
  In:  ticket text (name, email, order ID, free-text complaint)
  Out: model completion (summary, stored alongside ticket)
  Sub-processor: model vendor, processes in US, no EU region on
  this plan tier.

Lawful basis (Article 6)
  Recommendation: legitimate interest, not consent. Support triage
  is necessary to fulfill the existing service contract. Consent
  would be revocable mid-ticket and break the triage queue.
  Action: Terms drafts the legitimate interest assessment and adds
  the processing purpose to the privacy policy.

DPIA screening (Article 35)
  Systematic, large-scale processing: yes (40k/mo, ongoing).
  Special category data present: occasional, wellness-industry
  tickets mention health context.
  Call: DPIA required. Shield drafts the screening record; full
  DPIA needed before wellness-industry tenants are enabled.

International transfer (Chapter V)
  Model vendor processes in US, no EU region on current tier.
  Action: Standard Contractual Clauses required in the DPA
  addendum. Upgrading to the EU-region tier removes this
  requirement entirely, flagged as the cheaper long-term fix.

Retention and access
  DPA to specify: 30-day completion retention, encryption at rest,
  named sub-processor list.
  Warden check: current logging bucket has no lifecycle policy,
  9 engineers hold raw read access. Fix before launch.
───────────────────────────────────────────────────────────
Recommendation: ship to non-wellness tenants now with the LIA and
SCCs in place. Hold wellness-industry tenants until the DPIA
completes.
Next: Terms finalizes the DPA addendum, Warden fixes the bucket
lifecycle policy and access scope, re-review before the wellness
cohort goes live.

This is what GDPR-ready actually means for an AI feature, not a policy statement, but a specific, defensible answer to five questions: what data flows in, what lawful basis covers it, whether a DPIA is triggered, whether the international transfer needs Standard Contractual Clauses, and whether the infrastructure retention matches what's written down. Northlane shipped to eleven of twelve markets on day one, held the wellness cohort two weeks for the DPIA, and had the DPA addendum and updated privacy policy live before the first ticket was summarized, not after a customer's procurement team noticed and asked. That two-week hold is the difference between a documented decision and a fire drill six months later when an enterprise customer runs a vendor security review and asks for the DPIA record by name.

GDPR compliance for an AI feature isn't a one-time signature

The DPA, the privacy policy update, and the DPIA screening are only accurate as of the data flow they were assessed against. Model vendors change pricing tiers and quietly change default retention. Feature scope expands, the ticket summarizer that started as internal triage gets exposed to customers as a self-serve summary. A new EU market comes online with its own supervisory authority guidance on automated processing. Any of these is a material change that invalidates the original assessment, and the failure mode isn't that the documents become wrong overnight, it's that nobody re-runs terms-recon or shield-assess when the underlying facts shift, so the paperwork quietly drifts out of sync with what the system actually does.

• Model vendor changes, or a fallback provider gets added to the pipeline

• Default logging or debug tooling starts capturing raw prompts it didn't before

• The feature expands to a customer segment with more sensitive data (health, financial, minors)

• A new EU market goes live with distinct national supervisory authority guidance

• An enterprise customer's security review requests updated DPIA or DPA documentation

Any one of these should trigger a re-run of the same recon-assess-draft-audit loop Northlane ran before launch, not a full restart, but a targeted pass that checks whether the lawful basis, DPIA status, and transfer mechanism still hold given the new facts. Treating the GDPR review as a quarterly discipline rather than a one-time launch gate is what keeps the documentation defensible a year in, instead of accurate only on the day it was signed.

Terms and Shield vs the alternatives

Neither Terms nor Shield are trying to replace outside counsel for a genuinely novel legal question, and they say so when a question exceeds what a documented pattern can answer. What they do replace is the current default, a generic chatbot template or an engineer's best guess wired straight into production with no one asking the compliance question at all. The comparison below is specific to the capabilities that matter when an AI feature is heading toward EU users, not general legal drafting capability.

Install and try

Tonone is free and MIT-licensed. Install it once and Terms, Shield, Warden, and every other agent in the roster are available in your Claude Code session. You pay only for the Claude Code token usage during the work itself.