I overheard someone talking about how their company could not monitor what their own developers were doing inside their coding consoles. The reason, naturally, was GDPR.
The argument went something like this. Developers have privacy rights, even at work, so monitoring activity inside their development environment could create regulatory exposure. Therefore, the company should avoid collecting telemetry around what developers are doing, even when they are using company systems, company repositories, company credentials, and company-licensed AI tools.
I have spent enough time around risk, security, and regulation to recognize the difference between thoughtful compliance and overcorrecting out of fear of getting it wrong.
To be clear, GDPR gets a lot right. It has forced organizations to take data protection seriously. It established that access to personal data should be purposeful, limited, transparent, and accountable. Those principles matter even more as enterprises begin giving AI agents access to internal systems, sensitive data, and operational workflows. GDPR asks exactly the right foundational questions. What data is being accessed? Who is accessing it? For what purpose? Is the access proportionate? Is there a record of what happened? The specific problem is that GDPR does not map cleanly to agentic AI.
GDPR is just like us…still trying to get a grasp on agentic infrastructure
GDPR was written for a world where humans, organizations, and systems were relatively easy to distinguish. An AI agent may act on behalf of a user, use that user’s credentials, trigger workflows across multiple systems, retrieve sensitive data, and make decisions at machine speed. It may not be a person, but it can create consequences that look very human from a risk perspective. That creates a gray area, and in true enterprise fashion, some organizations are interpreting that gray area as a reason to do nothing while calling it prudence.
Some teams are now so cautious about employee monitoring that they hesitate to monitor agentic activity at all. The concern is that observing AI tools inside developer workflows might look like employee surveillance. The result is strange. Companies may feel more comfortable giving agents access to sensitive systems than watching what those agents do once they get there.
That cannot be the answer. Agents are not data subjects. They do not have dignity, employment rights, lunch breaks, work councils, or a reasonable expectation of privacy. They are software systems executing tasks. Full stop. Their prompts, tool calls, outputs, API requests, and system interactions are operational telemetry, not personal data deserving protection.
Nuance matters here. Monitoring an employee’s personal communications is one thing. Tracking a non-human system that can access production code, invoke tools, query databases, or move sensitive information is another thing entirely. Enterprises need visibility into what these systems are doing, especially when agents inherit user permissions or operate inside privileged workflows.
The regulatory tortoise meets the AI hare
This is where the current regulatory model starts to show its age. Things are moving too quickly for the traditional cycle of study, proposal, commentary, implementation, and enforcement. By the time detailed guidance arrives, the architecture it describes may already be outdated. New protocols, tools, and deployment models are appearing faster than regulators can reasonably absorb.
There is also a competitive issue. If a regulatory policy is built so narrowly that companies cannot safely monitor or govern agentic systems, it will not protect people. It will make responsible adoption harder. Organizations will either slow down to the point of irrelevance or move forward with less visibility than anyone should be comfortable with.
The more constructive path is for industry to lead while regulators catch up. Security, privacy, and risk leaders should define practical controls now. This looks like a defense-in-depth approach built around discovery of agentic systems, identity and access management for non-human actors, logging of agent actions, limits on what tools agents can invoke, human approval for high-impact actions and audit trails that show what happened after the fact.
Strong monitoring of agentic systems can demonstrate whether sensitive information was accessed appropriately, whether a system exceeded its intended purpose, and whether automated activity stayed within policy. That supports GDPR’s core principles rather than undermining them.
The bots are not going to audit themselves
The uncomfortable truth is that some companies are using privacy law as a polite way to avoid hard decisions. They would need to tell employees and developers that AI tools can be used, but not invisibly. They would need to define acceptable use, document monitoring practices, and explain why agent telemetry is necessary. That is not always fun, but neither is explaining to a regulator that the production database disappeared because nobody wanted to look too closely at the helpful robot.
Most enterprise AI telemetry is not as interesting as people think. Security teams are not trying to read someone’s private musings. They are trying to answer basic questions, like what agent acted? What data did it access? What tool did it invoke? Did it do something it was not supposed to do?
Those questions are not optional anymore. As agentic AI becomes part of enterprise infrastructure, the absence of monitoring will create more risk than the presence of it, producing data leaks, destructive actions, compliance failures, and eventually the fines and lawsuits organizations were hoping to avoid by being extra careful in all the wrong places.
Agentic AI is exposing the limits of applying old frameworks to new execution models. The next phase of guidance needs to recognize that non-human actors must be observable, governable, and accountable from the start.
Agents do not have rights. People do. And one of the best ways to protect people is to watch the software acting on their behalf.
