LGPD and GDPR for AI agents: what to log, what to stop, what to keep out

Oct 21, 2026 · 4 min read

This is an engineering view, not legal advice. Talk to your DPO or counsel about your specific obligations.

Brazil's LGPD and the EU's GDPR were written before anyone wired a language model to a CRM. They still apply, and agents make some of their principles harder to meet: the agent decides at runtime what to read, what to send and where. Your privacy notice said "we share data with these processors". Your agent just emailed a spreadsheet to an address nobody has seen before.

Here's how we'd approach it as engineers.

1. Find where personal data moves

Personal data in an agent system moves through actions:

reading records (support history, contacts, invoices)
writing or updating them
exporting them
sending them by email or to an external API

Both laws care most about the last two: data leaving the controlled environment, to whom, and on what basis. Start by listing which agents have tools that export or send, and which resources those tools touch. In most systems that's a short list.

2. Minimise what the control layer itself keeps

A common mistake is fixing a privacy problem by logging everything the agent did, including the records. Now you have a second copy of the personal data in your logs.

Log the action, not the payload. Vulnify records action metadata (agent, action, resource, destination, record count, timestamps, risk result, review decision and notes), not a copy of the records the agent read or exported. If you choose to send outgoing text for scanning, it's scanned in memory and not stored; only the finding types and their categories may be kept.

3. Stop unplanned transfers before they happen

The cheapest incident is the one that never ran. Put a check in front of the actions that move personal data out:

EXPORT_DATA or SEND_EMAIL to an external destination → a person reviews it
external exports above a record count → blocked
anything touching a resource marked sensitive → a stricter rule

The decision happens before the tool runs, so a blocked transfer never leaves. A review holds it until an approver (not the requester) decides in the app or in Slack. If nobody decides within the review window, it expires and counts as blocked.

4. Know what's in the outgoing content

When you're allowed to inspect the text an agent is about to send, scanning it catches the obvious cases. Vulnify's detectors return findings with LGPD categories:

Category	Examples of findings
IDENTIFICATION	CPF, RG, CNH
CONTACT	Email, Brazilian phone
LOCATION	CEP
FINANCIAL	Credit card, PIX key
HEALTH	Health data (ICD-10 / CID-10 code); marked sensitive
COMPANY	CNPJ
CREDENTIALS	API keys, private keys

Detection is specific rather than fuzzy: a CPF needs valid check digits and a card number must pass a Luhn check, which keeps false positives down. The current list is public at GET /public/dlp-types. It's a safety net for clear-cut identifiers, not a classifier for every kind of personal data, so it doesn't replace knowing your data.

Health data deserves its own note: LGPD treats it as sensitive personal data, and GDPR as a special category. If an agent can reach it, put a review on every external transfer, not only the large ones.

5. Keep evidence you can hand over

When a regulator, a customer or your own DPO asks "what did the agent do with this data?", you need an answer that doesn't depend on the agent's own log.

Every decision and human review goes into an append-only audit log with a per-organization SHA-256 hash chain. Verification recomputes the chain and reports the first entry that doesn't match.
Compliance exports download as JSON or CSV with a SHA-256 checksum, so you can show the file you hand over is the file you exported.
Owners and admins can download recent security events for a SIEM as JSON or CEF lines.

6. Retain only as long as you need

Retention is a GDPR and LGPD principle, and it applies to control-layer data too. In Vulnify, decision events are deleted automatically after the plan's retention window (see /pricing and the docs). Set the window to what your audit needs actually are, not "forever by default".

A one-week starting plan

Day 1: list agents, their export and send tools, and the resources those touch. Mark the sensitive ones.
Day 2: add a check in front of those tools, in monitor mode.
Days 3–6: read what would have been reviewed or blocked. Adjust the rules.
Day 7: enforce reviews for external transfers, and blocks for bulk ones. Write down who approves.

None of this makes a system "compliant" by itself. It gives you two things both laws keep asking for: control over where personal data goes, and a record of it.

Vulnify decides every sensitive agent action before it runs: ALLOW, REVIEW or BLOCK, with the reasons.

Try it free