Can you monitor AI coding tool usage under GDPR?

This page describes how a system is built, written by the people who built it. It is not legal advice, we are not lawyers, and none of it is a compliance certification. Your DPO and your counsel decide what applies to your organisation.

Why consent is usually the wrong instrument

The instinct is to ask engineers to agree to it. Most DPOs will push back, and the reason is structural rather than pedantic: consent has to be freely given, and an employee asked by their employer is not in a position to refuse without cost. Build a rollout on consent and you inherit the problem that withdrawal must be as easy as granting, which for a fleet-wide agent it is not.

The basis organisations land on for this kind of processing is legitimate interest, documented with a three-part test: the purpose, why the processing is necessary for it, and a balance against the rights of the people being measured. That document is the thing your DPO will ask for, and it is the thing worth writing first, before anybody installs anything.

The four decisions that actually decide this

Whether monitoring is defensible in the EU comes down to design choices you make, not to which vendor you pick. Four of them carry the weight.

• What is collected. Metadata about tool usage sits very differently from the content of what an engineer typed. The second is a different category of processing and it changes every conversation that follows.
• Whether individuals are identifiable. Team-level data with no user attribution is a materially weaker intrusion than per-engineer records, and it is the single strongest thing you can offer a works council.
• Where it is stored, and who can reach it. EU hosting removes a transfer question. Self-hosting removes the processor relationship entirely.
• When you consulted. In Germany and Austria this is co-determination and it is a gate, not a courtesy. In France it is CSE consultation. Doing it after deployment is a much worse conversation than doing it before, and the software cannot help you with either.

What is collected, and what is not

The specific list matters more than any assurance about it, so here is the specific list.

Two details in that table do more work than the rest. Prompt storage is off by default and the default fails closed, so an absent, invalid or mistyped setting resolves to storing nothing rather than to storing everything. An organisation can turn it on for itself, and doing so is a decision that belongs in front of a DPO and a works council rather than in a settings page.

And secret detection is redaction rather than collection. The match is stripped from the event on the engineer's machine before the event is buffered, so the credential never crosses the network. What is stored is a label: this kind of finding, this severity, in this field.

Aggregate-only mode, and the part of it that is not built

There is an org setting that removes individual attribution at the point of ingest. With it on, the pipeline nulls the user id, the session id, the prompt hash and the git branch before anything is written, and event metadata is dropped. Team attribution is kept deliberately, because team-level cost and adoption are the reasons most EU organisations want this at all.

The consequence is worth stating positively: with that setting on, there is no per-engineer record to expose, to a manager, to an administrator, or to anybody with a database connection. Not hidden by a permission. Not stored.

The part that is not built, because you would find out eventually and it is better to hear it now: query-layer suppression of small aggregate cells (the k-anonymity threshold that stops a team of three being effectively identifiable in a team chart) is designed and not implemented. If your DPIA leans on cell suppression as a safeguard, raise it with us before you write it in.

The pause, and what software can honestly promise

Any engineer can pause collection on their own machine, for as long as they choose. There is no maximum duration, no administrator setting that overrides it, and no server-side mechanism to end one. An org-level setting that implied otherwise was removed from the product precisely because it implied a control that did not exist.

What a pause is not is covert. A paused machine reports itself as paused, so the organisation sees a paused agent rather than an ordinary working day that mysteriously produced nothing. That cuts both ways on purpose: nobody is silently monitored, and nobody is silently assumed to be idle.

Here is the line to be careful with in a works council meeting. The pause is a technical guarantee. "Pausing will never be held against you" is a policy commitment, and no software can enforce it. If you intend to make that promise, it belongs in your works agreement, in your words, and not in a vendor's feature list.

Where the data lives

Synopt Cloud runs on Hetzner in Germany, inside the EU. For a hosted deployment your organisation is the controller and we are the processor, with everything that follows from that.

Self-hosting is the other option, and it changes the relationship rather than merely the address. You run the containers, the data never reaches us, and there is no processor arrangement to paper because we never touch the data. That is the answer for organisations whose telemetry may not leave their own network, and it is a support-agreement conversation rather than a signup form.

What we do not have

A compliance page that lists only strengths is not a compliance page. Synopt has never been SOC 2 audited and has never been penetration tested. There is no SSO or SAML support. On the processor paperwork for the hosted service, a reviewed DPA and a published sub-processor list, ask us where that stands before you invest time in an evaluation, and you will get a straight answer rather than a roadmap.

If your procurement process requires an attestation to start, this is early-access software and that is a real blocker. Better to know on this page than three weeks into a security review.

What you can read before you talk to us

The security page on this site is the current statement of what the agent collects and what it cannot, how secrets are redacted on the device, where a hosted deployment stores data, and what we have not done. It is specific enough to be checked, which makes it the thing to take into a first conversation with your DPO.

There is no compliance pack to hand out. The DPIA, the legitimate-interest assessment and the works council brief are your organisation's documents to write, and the parts of them that depend on this product are questions rather than paperwork: what is collected, what is stored, what the aggregate-only setting removes, what is still designed and not built. Send those to support@synopt.dev and you will get an answer, including where the answer is that something does not exist yet.