Betriebsrat-Friendly AI Architecture: Co-Determination Rollout (2026)

Q: Why is BetrVG §87(1) Nr. 6 the central architectural constraint rather than just a labour-law footnote?

Section 87(1) Nr. 6 of the Betriebsverfassungsgesetz grants the Betriebsrat mandatory co-determination over the introduction and use of technical equipment intended to monitor the behaviour or performance of employees. The Bundesarbeitsgericht has read this hook broadly in a long line of decisions — covering essentially any system that captures data which could be used to evaluate individual employees, regardless of whether the employer says it intends to use the data that way. Modern AI systems collecting per-user prompts, per-user responses, per-user adoption metrics, per-user satisfaction signals, or per-user override rates trigger the §87(1) Nr. 6 hook by the data they collect, not by the employer's stated purpose. Because the right is mandatory co-determination (not consultation), an unauthorised rollout is not a procedural defect to be fixed afterwards — it is a labour-court matter that produces personal exposure for the operations leadership and structural exposure for the platform. The architectural answer is to build the system so the per-user data does not exist at the grain that triggers the hook (telemetry boundary at the substrate, aggregation at collection time rather than at access time), so the negotiation focuses on the operational design of the AI rather than on a data-collection surface that the Betriebsrat will rightly refuse to authorise.

Q: How does the telemetry boundary actually look at the substrate level — what stack changes does it require?

The boundary is two parallel observability streams with different schemas, different storage, different access controls, and different audit. Stream one (system observability) is the standard SRE stack — typically OpenTelemetry traces, Prometheus metrics, structured logs flowing to Loki or CloudWatch — with the schema explicitly excluding any user identifier field. The trace context contains request id, route, latency, error code, model version, region, but no caller identity; the metrics are aggregated at scrape time without per-caller labels; the logs use a sanitised request representation. Stream two (employee-effect telemetry) is a separate pipeline feeding a separate warehouse — typically a small data warehouse running on the per-Betriebsvereinbarung-defined cohort threshold (minimum 10 employees per cohort, smaller cohorts suppressed), with per-task-category aggregations (adoption, override, opt-out, escalation, satisfaction) and explicit cohort-suppression at the query layer. The Betriebsrat dashboard reads this warehouse directly with role-graded credentials. Per-user data exists only on employee-initiated paths (individual review request, complaint, incident report) in a third store with separate retention and separate access controls. The substrate change is non-trivial — the OTel collectors need scrubbing pipelines, the Prometheus exporters need label sanitisation, the application code needs to stop emitting per-user spans for routine operations — but the engineering work is bounded and the Betriebsvereinbarung negotiation is materially easier when the boundary is structural rather than policy.

Q: What does the opt-out path look like in practice when the AI is deeply integrated into the daily workflow?

The opt-out is the pre-AI workflow maintained as a first-class engineering deliverable rather than a deprecated legacy. The architectural shape: the application gateway reads the employee's per-task-category opt-out preferences before routing the request; an opt-out request routes to the pre-AI workflow path which produces the same business outcome through the pre-AI sequence; the pre-AI path is exercised in the test suite at the same coverage as the AI path; the on-call rota covers both paths; the documentation describes both paths; the deployment pipeline ships both paths together. The opt-out is per-task-category granular rather than all-or-nothing — typical pattern: an employee in customer service may accept AI assist on internal documentation but elect the pre-AI path for customer-facing interactions, and may change preferences at any time without manager approval. The system audit log records that an opt-out path was taken for a category without recording who took it (the routing decision is logged, the caller is not); the employee-effect telemetry surfaces the aggregate opt-out rate per category. The performance review process explicitly acknowledges that AI-path-vs-opt-out-path is not a performance dimension — the Betriebsvereinbarung names this commitment and the line management training operationalises it. The architectural posture pays back operationally as well as politically: when the AI degrades (model regression, vendor outage, policy update breaking prompts), the pre-AI path becomes the production fallback for everyone, and the team that maintained it for the opt-out elective is the team that keeps the business running through the AI failure.

Q: How are the autonomy tiers (advisory, assist, act) enforced at the code level rather than as a runtime configuration?

The enforcement is at the dispatch layer — the AI invocation gateway looks up the task category in a manifest, reads the authorised autonomy tier for that category, and routes the request to the corresponding handler. Advisory handler: invokes the model, returns the suggestion to the human, logs the suggestion in the working artefacts but explicitly excludes it from the decision record so the AI suggestion does not become the audit-trail justification for the human's decision. Assist handler: invokes the model, returns the draft action to the human for review, the human's approval is the recorded decision, the AI draft is held as a working artefact. Act handler: invokes the model, executes the action without per-instance human review, but only for task categories whose Betriebsvereinbarung clause has explicitly authorised the act tier. The manifest is a declarative file that lives in the codebase; changing a category from advisory to assist or from assist to act requires a code change that hits the release pipeline; the change-classification stage of the pipeline detects the manifest change and computes the Betriebsvereinbarung-impact tier (typically Tier C consultation for assist elevation, Tier D amendment for act elevation); the release is gated until the corresponding Betriebsrat process completes. Personnel-decision categories live in their own category space with their own autonomy bounds — the default tier for any personnel-decision category is advisory and the act tier is structurally unavailable in the Betriebsvereinbarung-friendly default. An attempt to dispatch an act call against an advisory category fails fast at the gateway with a structured error that surfaces in monitoring; chronic patterns of attempted elevation surface in the change-classification audit and prompt a Betriebsrat conversation about whether the operational reality is asking for a Betriebsvereinbarung amendment.

Q: How is the Betriebsvereinbarung-impact change-classification pipeline structured, and what does each tier require?

The pipeline is a stage in CI that runs on every release candidate. The classifier reads the diff against the manifest of Betriebsvereinbarung-relevant surfaces — autonomy-tier configuration module, telemetry-schema module, opt-out-workflow module, personnel-decision category register, artefact pack contents, model version manifest, vendor relationship manifest — and computes the maximum-impact tier across all surfaces touched. Tier A (no impact, ships on engineering cadence): bug fixes, performance improvements, infrastructure migrations that preserve the data flows and the autonomy tiers; the diff does not touch any Betriebsvereinbarung-relevant surface. Tier B (notification, ships after 10 business days notice): changes that surface in the artefact pack but do not modify the autonomy tiers, the telemetry boundaries, the opt-out paths, or the personnel-decision category bounds; typical example is a model-version update from a vendor without changes to the data flows. Tier C (consultation, ships after a Betriebsrat consultation that produces an updated artefact pack and the Betriebsrat's acknowledgement): changes that affect the artefact pack materially, expand into a new task category not previously covered, or modify an evaluation methodology; typical engagement window is 4-8 weeks. Tier D (amendment, ships after the formal Betriebsvereinbarung amendment): changes that modify an autonomy tier upward, expand into a personnel-decision category, change the telemetry boundary, or modify the opt-out availability; typical engagement window is 3-6 months including formal vote. The pipeline emits a tier classification with the rationale, the operations leadership and the Betriebsrat receive the classification, the release is gated on the corresponding process. Tier-misclassification disputes escalate to a joint review between engineering and Betriebsrat; chronic misclassification escalates to the Einigungsstelle, which the architectural posture is designed to avoid.

Q: How does the architecture handle the case where an employee files a complaint that the AI is treating them unfairly?

The complaint triggers an individual-review path that exists specifically for this purpose and is the only path on which per-user data is collected and reviewed. The shape: the employee files the complaint through a designated channel (typical pattern: a form that the Betriebsrat has co-designed, accessible from the AI tool itself and from a separate intranet location); the complaint is logged in the individual-review store with the employee's identifier, the complaint description, the time window concerned, and the categories affected; the review is conducted by a panel that includes a Betriebsrat representative under §80, an HR representative, and an engineering representative; the panel has authority to query the system audit log and the model invocation history for the employee's sessions in the time window concerned (with the queries themselves logged); the panel produces findings within a Betriebsvereinbarung-defined SLA (typical 30 calendar days); the findings drive either a remediation (model recalibration, category boundary adjustment, individual remediation for the employee) or a documented closure with the rationale shared with the employee. The individual-review path is deliberately separate from the routine telemetry — the per-user data exists only because the employee initiated a request that requires it, and the data has its own retention schedule (typical: duration of the matter plus a defined post-matter window, after which the personally identifying data is purged and the aggregate findings are retained for trend analysis). The complaint volume and findings are reported in aggregate to the Betriebsrat in the quarterly engagement; chronic complaint patterns in a category prompt a Tier C consultation about the category's autonomy tier or the model behaviour.

Satyam Kumar

Retour au blog

ai-architecture

Betriebsrat and AI Deployment: Co-Determination-Friendly Rollout Architecture (2026)

By Satyam KumarMay 12, 202619 min read

betriebsrat betriebsvereinbarung co-determination betrvg german mittelstand works council ai deployment governance employee data protection eu ai act workplace ai autonomy tiers telemetry boundary opt out architecture einigungsstelle ai architecture european works council

Betriebsrat and AI Deployment: Co-Determination-Friendly Rollout Architecture (2026)

Frequently Asked Questions

Partager l'article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

Architecte AI & Cloud. J'aide les équipes à construire des systèmes qui scalent pour des millions.

LinkedIn GitHub

Betriebsrat and AI Deployment: Co-Determination-Friendly Rollout Architecture (2026)

Frequently Asked Questions

Partager l'article

Comments

Leave a comment