Works Councils and Automation: When Codetermination Applies

The works council codetermines the introduction and use of technical devices designed to monitor the behaviour or performance of employees. This applies where no statutory or collective agreement rule already covers the matter.

The word designed is broader than it sounds. According to the case law of the Federal Labour Court, technical devices are designed to monitor if they are objectively suitable for collecting or recording information about an employee's behaviour or performance. The employer's subjective intention to monitor is irrelevant. The court confirmed that standard again in 2024.

For an HR workflow that means: a process that assigns tasks, tracks deadlines, routes incoming documents or records processing status will as a rule produce data that can be attributed to a person. The threshold is met regardless of whether anyone ever intends to analyse that data.

There is one constellation in which a labour court denied codetermination, and it marks the boundary well. In January 2024 the Hamburg Labour Court ruled on the use of ChatGPT that a company had permitted through accounts employees created themselves. The court denied a codetermination right because the application did not run on company systems and the employer had no access to the data created there.

For automation projects that case is a counterexample rather than a template. A self-hosted n8n server is the exact opposite: your own infrastructure, your own accounts, your own logs. The more cleanly the solution sits inside your organisation, the clearer codetermination becomes.

German law draws a second line at selection decisions. Selection guidelines remain subject to codetermination even where artificial intelligence is used in drawing them up. So a workflow that pre-sorts applications lands in that area as well.

The codetermination question can only be answered if you know which data accumulates. n8n stores the history of every execution: which workflow ran, when, with what result, and which data passed through the individual nodes.

That execution data is pruned by default. EXECUTIONS_DATA_PRUNE enables deletion, EXECUTIONS_DATA_MAX_AGE is set to 336 hours, which is 14 days, and EXECUTIONS_DATA_PRUNE_MAX_COUNT caps the store at 10,000 entries. Whether executions are saved on success, on error or with intermediate progress can be configured separately.

On top of that, the enterprise tier offers log streaming, which forwards workflow, node and audit events to a syslog target, a webhook or Sentry. These settings belong in the documentation you hand to the works council, because they answer the question of how long it stays traceable who triggered what.

In practice that means: before the first meeting, be clear about which retention periods are configured, who has access to the executions view, and whether personal data ends up in the logs or only case identifiers.

Codetermination is preceded by information. The employer must inform the works council in good time about plans concerning technical installations as well as work procedures and workflows, and must consult on the planned measures early enough for suggestions and concerns to still feed into the planning.

For assessing artificial intelligence, German law strengthens the works council further: if it has to assess the introduction or use of artificial intelligence in order to perform its duties, calling in an expert is deemed necessary. For plain automation without AI nodes that does not apply automatically, but as soon as a language model sits in the flow, plan for it rather than contest it.

The usual outcome is a works agreement. It is useful in data protection terms too, because processing employee data is permitted on the basis of collective agreements, with the negotiating parties required to observe Article 88(2) of the General Data Protection Regulation.

An agreement that holds describes the purpose of the workflow, the data categories processed, retention periods for the logs, access rights, an explicit exclusion of performance and behaviour monitoring, and a procedure for changes. The last point is the one most often forgotten and the most important, because workflows change constantly.

If no agreement is reached on a matter subject to codetermination, the conciliation committee decides, and its award replaces the agreement between employer and works council. That is not an edge case, it is the route the law provides.

The committee consists of an equal number of assessors appointed by each side and an impartial chair both sides have to agree on. If they cannot, the labour court appoints the chair. The committee must act without delay and takes its decisions by majority after oral deliberation.

In practice this route is slow and expensive, and it rarely ends with a result that fully satisfies either side. Developing a workflow jointly is therefore almost always the faster procedure, even though it costs more meetings at the start.

One further aspect in larger programmes: in companies with more than twenty employees entitled to vote, fundamental changes to the organisation of the business or the introduction of fundamentally new working methods can amount to an operational change. A single automation normally stays below that threshold, a programme that rebuilds entire processes may not.

The first meeting sets the pace of the whole project, and it rarely fails because of opposition. It fails because of missing information. A works council that cannot get an answer about log data cannot approve, even if it wants to.

What works is a document that fits on a few pages: the purpose of the workflow in one sentence, triggers and steps as a sketch, the data categories processed at each step, recipients outside your own systems, the configured retention periods for execution data, and the list of people with access to the executions view.

It also needs an honest statement about what the system could technically do but is not meant to do. A process that measures handling times could be turned into a performance statistic. Naming that openly and writing the exclusion into the agreement gets you further than staying silent and being confronted with it later.

And it helps to show a small use case first. A reminder for expiring deadlines or the routing of incoming applications is manageable, touches few data categories and works well as a shared first step. A small working process builds trust for the bigger one, while a large draft usually produces a long review.

A works council is the exception in Germany, not the rule. According to figures from the Institute for Employment Research, 9 percent of establishments have one, covering 45 percent of employees in western Germany and 41 percent in the east.

Without a works council, codetermination falls away but data protection law does not. The legal basis for processing then has to come from statute rather than from a collective agreement, and the necessity of each data category has to be justified individually.

Either way one limit remains, and many automation projects brush against it: nobody may be subject to a decision based solely on automated processing which produces legal effects concerning them or similarly significantly affects them. Where such decisions are exceptionally permitted, there is at least the right to obtain human intervention, to express one's point of view and to contest the decision.

For practice that means a workflow may prepare, route, remind and summarise. Decisions about a person are made by a person, and that should be visible in the flow itself, not just in its description.