GDPR, LGPD and AI agents: what your security team will ask

To let AI agents read customer data under the GDPR and the LGPD, a company has to prove six things: who is the controller and who is the processor, how the data is encrypted and where the keys live, what each agent may read, who read what, what reaches the AI model, and how data subjects exercise their rights. When agents from several vendors read the same customer memory, every answer has to hold for all of them at once. The security team at a bank, an insurer or a healthcare operator will ask for each standard by name, with evidence.

Who is the controller, who is the processor, and what must the DPA say?

The company serving the customer is the controller: it decides why the data is processed. Anyone who processes the data on its behalf is a processor (GDPR, Art. 4(7) and (8)). The LGPD uses the same two roles, under the names controlador and operador (Art. 5, VI and VII, official text in Portuguese).

With agents from three vendors, the company has several processors touching the same customer. The memory layer that sits above them is a processor too. A processor acts on the controller's instructions (LGPD, Art. 39), and the data processing agreement (DPA) is where those instructions are written down. Article 28 of the GDPR sets out what that contract covers:

• processing only on documented instructions;
• named subprocessors, and no new one without written authorization;
• security measures, and help with data subject requests;
• breach notice to the controller without undue delay, so it can meet its own notification duties (GDPR, Art. 33; LGPD, Art. 48);
• deletion or return of the data when the contract ends;
• access to the audits that demonstrate compliance.

How is the data encrypted, and who holds the keys?

Article 32 of the GDPR names encryption among the security measures. Article 46 of the LGPD requires protection against unauthorized access from the design stage onward. The standards, by name:

• At rest: AES-256-GCM. GCM authenticates the data, so any tampering makes decryption fail.
• In transit: TLS 1.3.
• Field level: personal data gets a second cipher, which protects it inside the database itself.
• One key per company: if a bug mixes records from two companies, decryption fails instead of leaking.

The strength of encryption depends on who controls the keys. Master keys belong in HSMs validated to FIPS 140-3, which anyone can check through the NIST Cryptographic Module Validation Program. The standard defines four increasing security levels, and each validation states the level of the module. Three answers matter: the master key never leaves the HSM, whoever uses a key never administers it, and rotation is automatic.

Who can read what, and how do you prove who read it?

Access starts denied. Each agent has its own credential, and its permissions follow its purpose. That rule applies purpose limitation and data minimisation under the GDPR (Art. 5(1)(b) and (c)) and the purpose and necessity principles of the LGPD (Art. 6, I and III). Health data is a special category (GDPR, Art. 9; LGPD, Art. 5, II). The collections agent should never see it.

The rule covers the context an agent receives before it replies and every search it runs through the history. The company's team needs to simulate what each agent sees before granting access, and to cut off a vendor on the spot.

Every read leaves a record: which agent read, what, why and when. Records are chained by SHA-256 hash, so any alteration breaks the chain. A copy streams to the company's SIEM in real time. That record is how the controller demonstrates compliance (GDPR, Art. 5(2); LGPD, Art. 6, X). An excerpt from a read log:

• 2:07 pm, voice agent from vendor B: got the voice context.
• 2:05 pm, in-app agent: got the full context.
• 2:02 pm, WhatsApp agent from vendor A: got the chat context.
• 9:31 am, collections agent from vendor C: denied, because collections cannot see technical open items.

The denied line is the proof that the purpose rule works.

What reaches the AI model, and where does the data live?

The contract has to guarantee three things about the AI model:

• Masking: tax IDs, card numbers and other sensitive data are masked before they reach any model.
• No training: the data never trains models, the vendor's or anyone else's.
• No sale: the data is never sold or shared.

Training a model on support conversations would be a new purpose. Both laws bar further processing that is incompatible with the original purpose (GDPR, Art. 5(1)(b); LGPD, Art. 6, I).

The company chooses the region where the data lives, and nothing leaves it without written authorization. International transfers have their own rules under both laws (GDPR, Art. 44; LGPD, Art. 33). Certifications have owners too. ISO 27001, SOC 2 and PCI DSS can belong to the vendor or to the cloud it runs on. The security team should ask who holds each one.

How do data subjects exercise their rights?

Data subjects have the right to access, rectification, portability and erasure (GDPR, Arts. 15 to 20; LGPD, Art. 18). The processor helps the controller answer each request (GDPR, Art. 28(3)(e)). That is why these rights need to exist as an API.

In a customer memory, erasure is the hardest right to honor. Each conversation produces facts, open items, context and a search index. A serious answer walks through everything derived from the data and issues a receipt of what was erased. From then on, no agent receives that data in its context or finds it in a search.

The company sets a retention period for each type of data (GDPR, Art. 5(1)(e); LGPD, Art. 16). When the period ends, the data is erased for real, and backups expire within a documented window.

What goes into the security review?

Every answer should arrive with its evidence.

How Niadra handles it

Niadra is the shared memory for a company's AI agents, across every channel and vendor. It acts as the processor, with a signed DPA. Its six security layers cover AES-256-GCM and TLS 1.3, keys in FIPS 140-3 Level 3 HSMs, purpose-based access, a read log chained by SHA-256, GDPR and LGPD by design, and cloud infrastructure certified to ISO 27001, SOC 2 and PCI DSS. The data never trains models, and sensitive data is masked before it reaches any model.

In the Console, the company's team cuts off a vendor's access on the spot, simulates what each agent sees and erases data with a receipt. Niadra runs all the infrastructure, and the company's team connects the SDK. On the Regulated plan, the company gets a dedicated environment with its own servers, database and keys, an availability SLA in the contract and a security review with its team.

This article is for information only and is not legal advice.

Frequently asked questions

Does the GDPR allow AI agents to read customer data?

The GDPR allows it, as long as the processing has a lawful basis (Art. 6), a defined purpose and appropriate security measures (Art. 32). In practice, compliance teams require a contract with each processor, purpose-based access and a record of every read.

Is encryption enough to comply with the GDPR and the LGPD?

Encryption alone is not enough. Article 32 of the GDPR pairs it with ongoing confidentiality, the ability to restore access and regular testing of the measures. Both laws also require a defined purpose, minimal access and support for data subject rights.

How do you erase a customer's data from every AI agent?

The controller receives the request and passes the erasure on to each recipient of the data (GDPR, Art. 19; LGPD, Art. 18, §6). In a shared memory, erasure reaches the original conversation and everything derived from it, with a receipt. Copies that each vendor keeps on its own fall under that vendor's contract.

Who is liable if an agent vendor leaks data?

Under the GDPR, a processor is liable when it breaches the obligations aimed at processors or acts outside the controller's lawful instructions (Art. 82). The LGPD makes the processor jointly liable in similar situations (Art. 42).