AI deployment in Germany: the works council comes first
Teams deploying into Germany prepare for the AI Act and are then delayed by something else entirely. For an ordinary internal system, the European regulation usually imposes modest obligations, because most workplace automation does not fall into its high-risk categories. What does bite is employment law. Where a system is capable of monitoring employee performance or behaviour, a works council can have co-determination rights over its introduction, and the test is capability rather than intention. A tool that records which employee handled which case is capable of it, whatever anyone plans to do with the log. This single fact reorders a German deployment plan: the conversation that must happen first is not with the security team or the data protection officer, it is with the people who represent the employees whose work is about to change.
Germany, in short
Binding AI law| Instrument that binds | Regulation (EU) 2024/1689, the AI Act, alongside the GDPR |
|---|---|
| Population adoption | The AI Index does not publish a figure for this country. That is an absence of data, not a low number. |
| What differs here | The works council right of co-determination over systems capable of monitoring employee performance is the single most underestimated constraint on deployment timelines here. |
| Working language | German, with formal register expected in anything customer-facing |
Legal position checked 2026-09-24. This is a starting point for a question to a local lawyer, not an answer. No compensation figures: see methodology.
Why capability rather than intention changes the plan
Most teams hear co-determination and think of surveillance products. The scope is wider, and it catches ordinary systems.
Consider a straightforward document triage tool: it reads incoming requests, classifies them and routes them to the right queue. Nobody intends to measure anyone. But the system necessarily records that a request was routed to a person and when, and from that a performance picture can be assembled. That capability is what matters.
The practical consequence is that the question is not whether your project is a monitoring project. It is whether the logs it produces could support monitoring, and for most systems that touch individual work the honest answer is yes. Planning on that basis costs nothing if you turn out to be wrong and saves a quarter if you are right.
Sequencing: early consultation runs in parallel, late consultation does not
This is the entire practical lesson and it is about timing rather than compliance.
Started when the project is first described, consultation runs alongside the build. Questions arrive while there is still time to answer them by changing what is built, which is both cheaper and produces a better system: the objections raised are frequently the same ones a user would have raised in month four.
Started when the system is ready, consultation runs after the build. The delay attaches to a finished project, the team experiences it as an obstruction, and the only available responses are to wait or to rebuild. Teams in this position routinely describe the constraint as unreasonable, and the unreasonable part was the sequencing.
There is a second benefit that is easy to miss. A works council that has been engaged from the start becomes a route to the people whose work changes, which is exactly the population a deployment needs access to during stage four and usually struggles to reach.
What the AI Act actually adds here
Regulation (EU) 2024/1689 attaches obligations to the use a system is put to rather than to the technology, and its heaviest requirements fall on a defined set of high-risk uses. Employment-related uses are among the categories that warrant careful reading, particularly anything touching recruitment, task allocation or evaluation.
For a large share of internal automation, the practical effect is documentation: being able to say what the system does, on what data, with what human oversight, and having that written before someone asks. Organisations that already keep that record for their existing systems find this unremarkable; organisations that do not find that the AI Act is not really the problem.
The obligations that bite hardest for most projects remain the ones that predate it. The GDPR governs the personal data the system touches, and it is enforced. Working out the lawful basis before the build is ordinary practice and remains the more consequential piece of work.
Language is a quality requirement, not a nicety
A system whose output an employee has to act on has to be right in German, including register. Output that reads as translated gets treated as unreliable, and the resulting abandonment arrives upward as a quality complaint, which sends the team to fix the wrong thing.
This has a design consequence worth planning for: the evaluation set has to be in German, and labelled by German-speaking domain experts. An evaluation set built in English measures a system nobody is going to use.
What does not change
The method. Translating the problem, getting at the data, building, adoption, handing back what was learned: the five stages are the same in Germany as anywhere. What stretches is stage two, and what acquires a formal calendar is the early part of stage four.
The other constant is the best predictor of a timeline, which is how long it takes to issue a read credential on the main system involved. German organisations vary as widely on this as organisations anywhere, and the answer tells you more about your project than the national regime does.
