Public previewRAGSuite is open-source, self-hosted and EU-ready — and we build it in the open.See it live

Platform Platform overviewSee it in actionAI SearchAI AssistantAI Connectors & MCPIntegrationsQuality LoopAdministration & SecurityMobile app
Solutions IT & Platform teamsCompliance & Data ProtectionDevelopersAgencies & Partners
Sovereignty
References
Pricing
Resources Trust CenterEU AI ActSecurity & disclosureFree toolsOpen source & open coreDocumentation ↗API reference ↗GitHub ↗ReferencesBlogChangelog
Company AboutPartnersContact
Search See it live Book a demo
Compliance

AI you're actually allowed to use: a guide for regulated and works-council teams

Most enterprise AI projects in Germany don't fail on technology — they stall in a meeting with the works council. Five things to require of any vendor, and the parallel conversation with your data protection officer.

COMPLIANCE a boundary · and an open gate ragsuite.de
Jürgen Pietschmann
Jürgen Pietschmann AI Consultant
Published18 August 2026 Read6 min Compliance

Most enterprise AI projects in Germany don’t fail on technology. They stall in a meeting with the works council — and the way through isn’t persuasion, it’s five things you can show.

Two terms first, for readers outside the German context. A works council (Betriebsrat) is an elected body representing employees, with legally defined participation rights over certain management decisions. Co-determination is the principle that gives it a genuine say — not a consultation, a say — in specific areas, one of which is the introduction of technical systems capable of monitoring behaviour or performance.

That last phrase is what catches AI tools. The test is capability, not intention: a system nobody plans to use for monitoring can still fall within scope if it could be used that way. An assistant that records who asked what, and when, generally can be.

The reframe that makes the meeting shorter

Teams usually arrive at the works council meeting with a business case and leave with a list of concerns. The productive move is to invert the order.

The council is not going to be persuaded that the tool is valuable — that is not their question. Their question is what the system can do to the people they represent. So the useful preparation is not a better business case. It is evidence.

Which means the question to take into vendor selection is: what would we need to be able to show?

Five things to require of any vendor

Including us. These are procurement requirements, not a feature list — write them into the evaluation and let vendors answer them.

Take these to every vendor on the shortlist

  • Can it run on infrastructure we control? If not, there is a third party whose assurances everyone in the room has to accept on trust.
  • Can you show us what leaves the network? Ask for a packet capture from a running instance, not a paragraph in a datasheet.
  • Do logs stay in-house — and can we set the retention periods ourselves? Retention is a design decision; if nobody can name a number, the number is ‘indefinitely’.
  • Does every answer cite the document it came from? Without it, a decision made with the tool cannot be reconstructed afterwards.
  • Are roles and permissions separated, so the system can't become a performance-monitoring tool? And ask which edition that sits in — on most products, ours included, access control is a paid capability.

That fifth point deserves emphasis, because it is where evaluations go wrong quietly. Role separation is the control that most directly answers the council’s actual worry, and it is very often not in the free or entry tier. Discovering that after the works agreement has been drafted is an expensive kind of surprise.

What a works agreement usually covers

If the meeting goes well, the output is a negotiation about a works agreement rather than a debate about whether to proceed. Knowing the usual shape in advance makes that negotiation faster.

  • Permitted purposes — what the tool is for, stated positively, and what it explicitly is not for.
  • What is logged — which events, retained how long, and who can access them.
  • An explicit exclusion of performance monitoring, with the technical arrangement that backs it up rather than a bare undertaking.
  • Access and roles — who can see across projects, who cannot, and who administers the boundary.
  • A review interval — the agreement is revisited at a stated point rather than surviving unexamined for five years.

Our companion piece AI and the Betriebsrat goes into the technical detail behind each of these.

The parallel conversation

While the works council is asking about employees, your data protection officer is asking about data subjects, and the two conversations are easier run together than sequentially.

The central question there is whether the deployment needs a data protection impact assessment — a structured analysis required under GDPR Article 35 where processing is likely to result in a high risk to individuals’ rights and freedoms. For AI systems the usual triggers are the scale of data covered, the use of a new technology, and the combination of datasets that were previously kept apart.

That third one is the one teams miss. A search system that makes personnel folders, mailboxes and project archives searchable together creates a new processing situation, even when every individual source stays exactly as it was. Nothing moved; the reachability changed. Our DPIA decision guide works through the threshold, and DSGVO by design for RAG covers the Article 5, 25 and 32 mapping.

Start the assessment before you select the tool. Its findings routinely change the requirements list, and reversing that order means either redoing the assessment or living with a tool chosen against the wrong criteria.

For regulated sectors

Health, financial services, public-sector supply chains and anything with a professional confidentiality obligation add requirements rather than replacing these. The additions cluster around three things: record retention for defined periods, auditability of who accessed which record, and the ability to reconstruct a decision after the fact.

The convenient part is that these overlap heavily with what the works council asked for. Citations give you reconstruction. In-house logs with deliberate retention give you both retention control and auditability. One preparation, two committees.

The honest summary

None of this makes the meeting disappear, and it should not. A works council asking hard questions about a system that can see who asked what is doing exactly what it exists to do.

What preparation changes is the subject of the meeting. Walk in with five demonstrable properties and an offer to negotiate a works agreement, and you spend the hour on the shape of the agreement. Walk in with a business case and a vendor brochure, and you spend it on whether this should happen at all — and you will very likely be back in three months with the answers you could have brought the first time.

This article describes how the frameworks generally work; it is not legal advice about your deployment. Involve your works council and your counsel on the specifics.

Frequently asked questions

Why does a works council get a say in software at all?

German co-determination law gives works councils a genuine say over the introduction of technical systems that are suited to monitoring the behaviour or performance of employees. The test is capability, not intent — a system nobody plans to use for monitoring can still fall within scope if it could be used that way. An assistant that records who asked what, and when, typically can be. This is general information about how the framework works, not legal advice on your situation.

Does self-hosting make the works council question go away?

No, and any vendor who implies otherwise is overselling. It changes the character of several answers — data flows are demonstrable, logs stay in-house, retention is yours to set — which usually shortens the discussion. But the co-determination right attaches to the system's capabilities, not to where it runs.

What is a Betriebsvereinbarung and do we need one?

A works agreement — a written agreement between employer and works council covering how a system may and may not be used. For AI tools it typically covers permitted purposes, what is logged and for how long, who may access the logs, an explicit exclusion of performance monitoring, and a review interval. Whether one is required in your case is a question for your counsel, but offering to negotiate one is usually the fastest route through the meeting.

When do we need a data protection impact assessment?

A DPIA — data protection impact assessment — is required under GDPR Article 35 where processing is likely to result in a high risk to the rights and freedoms of individuals. For AI systems the factors that commonly trigger it are the scale of data covered, the use of a new technology, and the combination of datasets that were previously separate. That last one is the most overlooked. Our decision guide works through it.

Our sector is regulated. Does that change the list?

It adds to it rather than replacing it. Sector rules typically bring requirements on record retention, auditability and the ability to reconstruct a decision after the fact — which happen to be well served by the same properties the works council asks about. In practice one preparation covers a good deal of both conversations.

Sources & further reading

  1. GDPR — Article 35, Data protection impact assessment — when an assessment is required
  2. GDPR — Article 88, Processing in the context of employment — the basis for national employment-specific rules, including collective agreements

← All posts