Process assurance and surveillance, clearly separated

Wanted

  • Batch quality
  • Error prevention at the plant
  • Traceability of materials and equipment

Separated technically and organisationally

  • Roles and permissions
  • Logging of access
  • Agreement on the purpose of the data

Excluded

  • Evaluating the performance of individuals
  • Evaluating the behaviour of individuals

Schematic illustration, not to scale.

“Treat the works council as an opponent and you lose months. Involve it as a partner for occupational safety and you clear the way.”

That sentence sounds like an attitude. It is a sober observation from projects in which digital systems were introduced in production.

Informed late, blocked early

The most common pattern: engineering and purchasing choose a system, the roll-out is planned, and shortly before the start the works council is informed. From its point of view, that is not participation but a done deal. It responds with questions nobody can answer and, in the worst case, with a procedure that delays the start by months.

The delay is self-inflicted. It does not arise because the works council rejects innovation, but because it could not examine in time what the system does.

The real concern

Behind scepticism towards modern software, and AI in particular, there is usually a concrete fear: that it will be used to monitor performance and behaviour. A system that records work steps, measures times or recognises patterns can monitor employees, even if that was never the intention.

The concern is justified, and it can be taken seriously without stopping a project.

Process assurance is not surveillance

The most important step is a clear, written separation:

  • Wanted: technical process assurance, batch quality, error prevention, traceability of materials and equipment.
  • Excluded: evaluating data on the performance or behaviour of individual people, technically and organisationally.

“Technically and organisationally” means in concrete terms: roles and permissions that do not allow personal evaluations in the first place, logging that shows who accessed what, and an agreement that sets the purpose of the data and prohibits everything else.

Such a separation does not reassure the works council through promises but through verifiability. And it helps management, because it clearly defines what the system may be used for.

AI needs particular attention

If AI is used for shift planning, task allocation or assessing employees, several sets of rules apply at once: co-determination in the company and the classification under the EU AI Act. The classification therefore belongs at the beginning, and the works council should know it. Individual legal questions belong with your legal counsel.

A different approach: safety and relief

Involving the works council from the start changes its role. Instead of inspecting a finished project, it helps to shape it. The topics where interests meet are concrete:

  • Which tasks become easier, which routes shorter?
  • Where does the system increase safety at the plant?
  • Which documentation disappears, which double entry goes away?

On this basis, works agreements emerge that enable innovation, because both sides know what has been settled.

What follows

  1. Involve the works council before the selection, not after the decision.
  2. Set out the purpose and limits of the data in writing, separating process assurance from surveillance.
  3. Describe the effect at the workstation together: relief, safety, ergonomics.
  4. Classify AI applications early and share the results.

It takes time at the start and saves it at the end.

How is it in your case?

In 30 minutes you will know where you stand.

Book an initial call