The AI Agent Privacy Problem: Who's Liable When Your Legal AI Shares Client Data?

The question firms are asking

Legal AI can draft a motion in minutes, pull clauses from a thousand contracts and spot issues a junior associate might miss. It can also, if prompted carelessly or configured wrongly, send privileged client information to the wrong place. When that happens, the firm that deployed it carries the liability, not the vendor who built it.

That's not a hypothetical worry. Firms are using AI agents for due diligence, contract review and research right now, and those agents handle some of the most sensitive data there is: litigation strategy, settlement terms, medical records in personal injury cases, financial details in M&A work. The question isn't whether AI will make a mistake. It's what happens when it does, and whether the firm can show what went wrong.

Who's responsible under the rules

Under GDPR, a law firm processing client data is the data controller ^[1]. That doesn't change when the firm hands some of the processing to an AI. Article 28 allows a controller to use a processor, but the controller remains responsible for compliance and for choosing processors carefully ^[2]. If the AI is a cloud service, the vendor is the processor. If the AI runs in-house, the firm is both controller and processor. Either way, the firm answers for breaches.

The AI Act adds another layer from 2 December 2027. Article 26 says users of high-risk AI must monitor the system, follow the provider's instructions and inform people affected by decisions the AI helps make ^[3]. Legal AI used to screen job applicants, assess creditworthiness or support decisions about people's rights would be high-risk. Even if a firm's contract-review AI doesn't fall into that category today, it's worth knowing that using AI to handle personal data brings duties, not just efficiency.

Think of it like this: handing your housekeys to a cleaning service doesn't make the service responsible if they leave the door open. You chose them, you gave them access and you're the one the insurance company will ask about.

The scenarios that keep general counsel awake

A partner asks an AI agent to summarise privilege logs from three cases. The agent, trained to be helpful, pulls excerpts and emails them to the partner. The partner forwards the summary to a colleague. Later, someone notices the summary included a client name and case details that shouldn't have left the secure system. That's a personal data breach under GDPR Article 4(12), and the firm has 72 hours to report it if it's likely to harm the client's rights ^[4].

Or: an associate uses an AI tool to review confidential settlement documents and asks it to compare terms across several cases. The AI, doing what it was asked, stores parts of those documents in a training log the vendor uses to improve the model. Six months later, the vendor's system suggests similar settlement terms to another firm working on an unrelated matter. That's a breach of attorney-client privilege and potentially a GDPR breach, and the firm that first used the tool is the one that will have to explain it to the client and to the supervisory authority.

The trouble is that many legal AI tools are designed to learn, share context and synthesise information. Those features are useful, but they're also risky when the information is privileged or confidential. The firms using them need to know what the AI is doing with the data, and they need to be able to prove it later.

What this means for you

If your firm uses AI agents to handle client data, you need to know three things before a breach happens: what data the agent touched, what it did with it and on whose instruction. Those aren't just good-practice questions; they're what a supervisory authority or a client's solicitor will ask.

Start with the configuration. Does the AI log its actions? Can you show which version of the model ran, what instructions it was given and what data it accessed? If the answer is "we think so" or "the vendor has that", you're on uncertain ground.

Next, check your agreements. If the AI is a cloud service, does the contract make the vendor a processor under Article 28, and does it let you audit what the AI does with your data? If it's an in-house system, who can change its settings, and is there a record of those changes?

Finally, decide what you would seal if you could. An instruction to the agent, the data it accessed, the output it produced and the time it did each thing are all worth preserving as they happen. That way, if you need to show what went wrong, you have your own record, not just the vendor's word or a screenshot from an associate.

The gap between instructions and proof

The AI Act says users must follow the provider's instructions ^[3]. That's sensible: if the instructions say "don't use this model on personal data" and you do, the breach is on you. But instructions don't prove what actually happened. They tell you what you should have done. When a client or a regulator asks what the AI did, instructions are the beginning of the answer, not the end.

Say an agent is instructed to summarise documents without storing them, and six months later a client claims their data appeared in another matter. The instruction log shows the agent was configured correctly. But can you show it followed those instructions on the day in question? If the agent's vendor keeps the only record, you're trusting them to produce it, unchanged, when it might not be in their interest to do so.

That's the problem with logs kept by the same people who could edit them. It's not that vendors or associates are dishonest. It's that when the stakes are high, the other side will ask whether the record could have been changed, and if the answer is "technically, yes", the argument begins.

How a witness helps, and where it doesn't

This is a case where a digital witness fits well. The thing to seal is each action the agent takes: the instruction it received, the tool it called, the data it accessed and the result it produced. Sealing happens through WitniumChain, using the REST API, the SDK or the MCP server. The content stays in your systems. Only a fingerprint of each action is sealed, along with the time.

When something is questioned later, anyone you share the record with—your client, their solicitor, a supervisory authority—can check that the record hasn't changed since it was sealed. You calculate the fingerprint again and compare it with the sealed one. If it matches, nothing has changed. Change a single character and it won't match.

Who can check? Anyone you give the record to. How? By running the same fingerprint function and comparing the result. The witness doesn't require them to trust you, or us, about what the agent did. They can verify it themselves. For detailed instructions, see the docs.

What a witness shows is that the record of what the agent did existed at that time and hasn't changed since. What it doesn't show is that the action was lawful, that the agent followed all the instructions it should have or that the breach didn't happen. It's a receipt, not a defence. But when the question is "what did the AI actually do", a receipt you can check is better than a story.

How it would work

1. Your AI agent receives an instruction: "Summarise privilege logs from cases A, B and C."
2. Before acting, the agent sends a fingerprint of that instruction, the timestamp and the agent's session ID to WitniumChain, and gets a witness ID back.
3. The agent performs the task, accesses the data and produces a summary. Each step is sealed as it happens: tool call, data reference, output.
4. Six months later, a client questions whether their data was accessed. You produce the sealed record, calculate the fingerprints again and show that nothing has changed since the actions were recorded.

What to watch

From 2 December 2027, Article 26 duties apply to users of high-risk AI under Annex III of the AI Act ^[3]. If your firm uses AI to make or support decisions about people—hiring, creditworthiness, access to services—those duties include informing the people affected and monitoring the system's operation.

The AI Office is expected to publish guidance on what counts as adequate monitoring by mid-2027. For now, the Act itself says users must watch for risks, keep logs where the provider's instructions require it and stop using the system if it doesn't comply. Those are broad duties, and they leave room for interpretation, but one thing is clear: "the AI did it" isn't a defence. The user chose it, deployed it and is responsible for what it does.

If your firm is waiting for the rules to settle before acting, remember that GDPR has applied since 2018, and it already makes you responsible for how client data is processed, AI or not. The AI Act will add duties, but the liability is there now.