AI coding agents in a German company: the layer everyone forgets

TL;DR. Bringing AI coding agents into a German operation is not only a technical decision. The moment they meet real systems and real teams, they also meet three things that international AI content almost never mentions: a data processing agreement, the works council, and the question of who owns the generated code. None of this is a footnote. It decides whether your AI project reaches production or stalls in legal review. Here is the layer most vendors forget, and the fast order to clear it.

Why this layer is invisible from outside Germany

Most content about AI coding agents comes from a world where a developer tries a tool and starts shipping. In a German company with a works council, GDPR, and a legal department reading along, the path to production looks different. Not harder, but with stops that nobody skips without regretting it later.

This is not a brake. It is the actual difference between an impressive demo and something your company is allowed to run. And it is exactly the layer that reveals whether a vendor has ever delivered in Germany or is only demonstrating a tool.

The three stops

1. The data processing agreement: who is processing whose data?

As soon as personal data is processed on your behalf, Article 28 GDPR requires a data processing agreement with the processor (in German, an Auftragsverarbeitungsvertrag, or AVV). With AI coding agents the decisive question is not "are we using AI" but what does the agent actually touch. Does it run over a codebase that contains customer data? Does it send fragments to a third-party model provider? Who in that chain is the controller, and who is the processor?

This is answerable, and it belongs settled before the first access, not after. A clean setup often limits, at the technical level, what data an agent can even see, which makes the data-protection question smaller and the answer simpler.

2. The works council: codetermination over systems that can monitor

This is the stop most often missed from outside Germany, because many countries have nothing like it. A works council (Betriebsrat) is an elected employee body, and under the Works Constitution Act it has a real codetermination right over introducing technical systems that are capable of monitoring employee behavior or performance. The key word is "capable": what matters is not whether you intend to monitor, but whether the system could.

An agentic development system that logs who triggered which task, and when, can fall into this category. The instinct to hide or skip past that is the most expensive mistake here: a works council that was bypassed can bring a finished project to a halt. The fast path is the open one. Involve the works council early, and be able to tell them precisely what the system records and what it does not.

This is where it helps to look at the Oversight Ladder, our model of the five autonomy levels of AI coding agents. Where a system sits on that ladder is closely tied to what data about people's work it generates at all. A team that can name its own level clearly can give the works council a clear answer instead of floundering. Clarity about the level is clarity in the codetermination conversation.

3. Intellectual property: who owns the code?

When an AI generates code, ownership is not answered automatically, and it belongs in the contract. The rule is simple and should be stated explicitly: everything built for you, including AI-generated code, is your property and yours to use without restriction. A vendor who dodges this question, or wants to keep rights to "their" AI output, has just told you the most important thing about the partnership. Settle it up front, and it is never an issue.

The fast order

The whole layer only feels like a brake when you leave it to the end. Put up front, it is done in a few days and never in the way again. A simple order, before the first agent touches anything:

1. Define data access. What may the agent reach, and what not? That answers half the data-protection question before it is asked.
2. Settle the data processing agreement. Who processes what, and is the agreement in place? With your data protection people, not after the fact.
3. Involve the works council. Early, openly, with a clear description of what the system records. Do not ask permission at the end.
4. Fix IP in the contract. All deliverables are yours. One sentence that saves a lot of trouble later.
5. Then build. At a deliberately chosen level of the Oversight Ladder, with guardrails that match that level.

This is not bureaucracy for its own sake. It is the order in which an AI project actually reaches production in Germany, instead of dissolving into a loop of follow-up questions.

The question that exposes a vendor

If someone offers to build software for you with AI, ask them a German question: how do you handle the data processing agreement, the works council, and the IP question? A good answer is concrete and sounds like experience: data access is scoped, an agreement is in place or will be provided, the works council is involved early, and all deliverables are yours. A bad answer is a blank look or a "we will sort that out later." The first is a partner who has delivered in Germany. The second is a tool with an invoice.

(Note: this article informs, it does not replace legal advice. Whether an AVV is required, when codetermination applies, and how to draft the contract all depend on the specific case. Confirm your actual situation with your data protection officer, your works council, and your legal counsel.)

We build production AI software, including inside German companies with a works council and GDPR. This layer is part of the craft for us, not a surprise at the end. If you want to know how it applies to a specific project, that is what a first conversation is for.