Build a GDPR Data-Request Agent

What is a GDPR data-request agent?

A GDPR data-request agent is a single privacy inbox that receives data-subject requests, classifies each one, acknowledges it, and routes it to your data protection officer with the legal deadline attached. It handles intake and tracking — the parts that are slow and easy to drop — while a human makes every decision about what data to release or delete.

The deadline is what makes intake worth automating. The GDPR (Article 12) requires responding to a request within one month. A message that sits unread in a shared inbox for three weeks is most of that clock gone, and a missed deadline is a compliance failure — the agent timestamps every request the moment it arrives so the clock starts on time.

Why run request intake on an agent account?

Privacy requests should land in their own inbox, not a marketing or support queue where they get lost. On an agent account, privacy@yourcompany.nylas.email is the single front door for every request, and each one carries a clean timestamp and audit trail — exactly the evidence an auditor asks for. You can run up to 5 such accounts on the free tier, one per brand or region.

A dedicated inbox also contains the data exposure. The agent reads only privacy requests, so a person's wider mailbox is never in scope and a crafted message has nowhere to pivot. That isolation matters more here than anywhere, because the whole topic is handling personal data carefully.

How does the agent classify the request type?

The agent reads each request and a model sorts it into a request type: access, deletion, rectification, or portability. An access request invokes the right of access (Article 15); a deletion request invokes the right to erasure (Article 17). Classification takes 1 to 2 seconds and decides which DPO workflow the request enters.

# Pull new requests for the agent to classify and route
nylas email list --unread --json

Keep the classification advisory, not final. The model's label routes the request to the right queue and starts the right checklist, but the DPO confirms the type before anyone acts. A misread “please update my address” that gets handled as a deletion is the kind of error a human catches in seconds and an unsupervised agent would not.

How does the agent verify the requester?

The agent never fulfills a request on its own, because releasing or deleting data for an impostor is itself a breach. It flags the request for identity verification and routes it to a human, who confirms the requester is who they claim before any data moves. The agent's job ends at routing — it has no tool that reads or deletes a customer's records.

This boundary is deliberate. An agent that could fulfill a deletion could be talked into deleting the wrong person's data by a crafted email — prompt injection ranks #1 (LLM01) in the OWASP LLM Top 10 for 2025 — so that capability simply does not exist in its tool set. Acknowledge, classify, verify-then-route: every step that touches real personal data stays with a human reviewer.

How does the agent track the one-month deadline?

On intake, the agent timestamps the request, sends an acknowledgement, and sets a deadline one month out. The nylas email send command delivers the acknowledgement from the privacy inbox the moment the request lands, which both reassures the requester and records the start of the clock. Complex requests can extend the window by two further months under Article 12, but only with notice.

# Acknowledge receipt and start the one-month clock
nylas email send \
  --to requester@example.com \
  --subject "We've received your data request" \
  --body "Your request is logged. We'll respond within one month."

Escalate as the deadline nears. The agent re-checks open requests on a schedule and nudges the DPO when a request crosses the three-week mark, so nothing reaches day 30 unhandled. The timer lives in your tracking store, not the agent's memory, so a restart never loses a clock.

Next steps

• Revoke an AI Agent's Email Access — the grant-revocation step that backs a right-to-erasure request
• Getting Started with Agent Accounts — the workspace model and grant lifecycle behind the privacy inbox
• Build an AI Customer-Support Inbox — the same intake-classify-route loop for support tickets
• Stop Your AI Agent From Going Rogue — why the agent has no tool that reads or deletes real customer data
• Build a KYC Document-Collection Agent — the intake side: collecting the identity data a request later concerns
• Full command reference — every nylas email and nylas agent subcommand