Works council AI recruiting approval in Germany is not a final procurement checkbox. Involve the works council before selecting or piloting a tool whenever it can shape selection rules or monitor employees. A practical agreement should define purpose, data, human review, prohibited uses, audit rights, change control, and a route for approving updates.

When does a German works council have a say in AI recruiting?

The answer depends on what the system does, whose data it processes, and how its output affects work. “It uses AI” is not the legal test. A job-ad writing assistant, a CV ranker, an interview transcription tool, and a recruiter dashboard create different questions.

The central rule is Section 87(1)(6) of the German Works Constitution Act. It gives the works council co-determination rights over the introduction and use of technical devices intended to monitor employees’ conduct or performance. In recruiting, this can concern the people using the tool as well as the applicants being processed. A dashboard may reveal recruiter response times. Interview analytics may compare interviewers. Workflow logs may allow managers to assess individual output.

Candidate evaluation creates a second track. General assessment principles and selection guidelines can require works council involvement. Section 95 expressly extends its rules to cases where artificial intelligence is used to draw up selection guidelines. The employer must also involve the works council in individual hiring measures where Section 99 applies. These rights are distinct. Agreement on the software does not automatically settle every later hiring decision.

A useful first step is therefore a function map, not a vendor presentation. List each AI-enabled action and decide which governance track it enters.

This matrix is more useful than asking whether “the platform” is co-determined. One platform can contain low-impact writing support and high-impact ranking. Approval should follow the enabled function and actual configuration.

Why does Section 87(1)(6) become the gating issue?

Recruiting software creates logs by design. It records who reviewed a profile, changed a score, contacted a candidate, or moved someone through the pipeline. Those records help operate an ATS. They can also make conduct or performance visible. That dual use is why a technically impressive demo can trigger concern even when HR has no plan to monitor staff.

The productive response is not “we promise not to use the dashboard.” Put the boundary into the works agreement and the technical setup. Disable unnecessary analytics. Restrict roles. Define allowed reports. State whether data may be used in performance reviews or disciplinary action. Set deletion periods for user logs. A policy without a configuration check leaves the core concern unresolved.

Do not treat a pilot as legally or operationally invisible. A pilot using real applicants, real recruiters, and real workflow data already creates the relevant effects. A safer pilot has a defined duration, named users, a limited vacancy set, no automated rejection, a rollback route, and a written evaluation plan.

The works council also needs enough information to perform its task. Section 80 of the Works Constitution Act provides for timely and comprehensive information and access to necessary documents. It also states that an expert is considered necessary when the council must assess the introduction or application of AI. Budgeting time for that review is part of a realistic implementation plan.

What must an AI works council agreement in Germany regulate?

A good AI works council agreement in Germany is specific enough to govern the system but flexible enough to handle controlled updates. A one-page statement of principles is rarely sufficient for recruiting. A frozen technical specification is equally impractical because models, prompts, integrations, and vendor features change.

The strongest structure has two layers: a framework agreement for recurring rules and a system sheet for each tool or function. The framework defines the approval process. The system sheet records the concrete configuration. This makes a small, harmless update easier to approve without allowing material changes to slip through.

Scope and purpose

• Name the legal entity, sites, teams, user groups, applicant groups, and systems covered.
• Describe permitted purposes in operational terms, such as extracting CV fields or suggesting interview notes.
• List prohibited purposes, including emotion inference, personality inference from voice, and employee performance ranking.
• State which decisions always remain with a named human role.

Data and access

• Document input data, generated data, logs, integrations, storage locations, recipients, and access roles.
• Define retention and deletion by data category rather than using one blanket period.
• State whether customer data can train shared vendor models. If not, make the prohibition contractual and testable.
• Provide routes for correction, objection, and human reassessment.

Applicant data falls within the employment-data rules because Section 26 of the Federal Data Protection Act includes applicants in its definition of employees. A works agreement can provide a governance basis, but it does not make unnecessary processing necessary. Data minimization, purpose limitation, security, and transparent information still need separate operational work. For adjacent implementation details, see the guide to AI recruiting compliance before buying a tool.

Selection logic and human review

For screening, define the scorecard before evaluating the model. The agreement should identify the input fields, criteria, exclusions, weighting logic, minimum evidence, and treatment of missing information. It should say whether a score may prioritize review, recommend a shortlist, or trigger rejection. Those are three very different powers.

Section 95 of the Works Constitution Act requires works council approval for selection guidelines and expressly covers AI used in drawing them up. A defensible design keeps requirements tied to the role. It also records why a person received a result. Human review must be meaningful: reviewers need the authority, context, and time to change the recommendation.

Testing, audits, and changes

• Set acceptance tests for accuracy, repeatability, accessibility, and unequal error patterns.
• Define a representative test set without turning old hiring decisions into unquestioned ground truth.
• Record incidents, overrides, complaints, false positives, and false negatives.
• Agree who receives reports, how often, and what triggers remediation or suspension.
• Classify changes as notice-only, review-required, or approval-required.

Material changes usually include a new data source, new scoring criterion, new automated action, new individual-level dashboard, new model purpose, or materially different integration. A vendor’s label “minor release” should not decide the governance route.

What does a typical approval process look like?

The fastest route is front-loaded. Teams lose time when procurement, privacy, security, HR, and the works council receive different documents at different stages. Build one evidence packet and let each function assess the same system.

1. Frame the use case. Start with the recruiting bottleneck and the exact decision being supported. Avoid a generic request to “introduce AI.”
2. Map functions and data. Show inputs, outputs, users, integrations, storage, logs, and human actions. Include features that will be switched off.
3. Define the decision boundary. State what the system may recommend and what it may never decide. Connect screening criteria to the role scorecard.
4. Prepare the evidence packet. Include security documents, data-processing terms, model documentation, retention settings, access controls, test results, and the change process.
5. Run a joint risk workshop. HR, recruiting, IT, privacy, information security, and the works council inspect the same workflow. Capture open questions and owners.
6. Negotiate the agreement and system sheet. Resolve purpose, prohibitions, reporting, audits, incidents, and updates before configuring the pilot.
7. Pilot within a closed boundary. Use named roles, a limited duration, manual final decisions, and predefined stop conditions.
8. Evaluate and release. Compare results with acceptance criteria. Document changes. Approve rollout, revise the configuration, or stop.

For a CV-screening example, the product conversation should show the difference between parsing and decision support. Sprad can be assessed as one option alongside ATS-native modules and specialist vendors. Its CV screening use case can serve as a concrete workflow for the system sheet. The same governance test should be applied to every provider.

Which arguments persuade a works council—and which ones fail?

The arguments that work reduce uncertainty and improve employee control. They do not ask the council to trust an AI label, a vendor brand, or an efficiency forecast.

Arguments that usually move the discussion forward

• “Here is the exact boundary.” Show enabled and disabled functions, not the full vendor roadmap.
• “The AI prepares; a qualified person decides.” Back this with interface rights, time for review, and override tracking.
• “Recruiter activity will not become performance data.” Put aggregation, access, purpose, and deletion controls into the agreement.
• “We will test errors before measuring speed.” Quality and equal treatment come before throughput.
• “A material update reopens review.” Change control prevents the approved tool from becoming a different system later.
• “The pilot can stop.” Named stop conditions turn a trial into a real test rather than an irreversible rollout.

Arguments that create resistance

• “The vendor says it is compliant.” Compliance is the employer’s operational responsibility, not a product badge.
• “It only gives recommendations.” Recommendations can still shape who is seen, interviewed, or ignored.
• “We need to move fast.” Speed does not answer questions about purpose, data, monitoring, or selection criteria.
• “The model is a black box.” That is a reason to narrow its power, not a reason to skip governance.
• “Other companies already use it.” Another employer’s configuration and agreement do not define yours.

The best business case is often workload quality, not headcount reduction. Show that the tool removes duplicate searches, formatting, or triage while recruiters retain judgment and candidate contact. If the goal is Active Sourcing, document how search criteria are approved and how recruiters validate suggested profiles. The guide to Active Sourcing and GDPR covers the adjacent data-protection questions.

How should multinational companies handle Germany?

A global AI policy is useful, but it does not replace German co-determination. The global document can set minimum controls. The German works agreement should then add local participation rights, system sheets, access restrictions, selection rules, and the release process.

Avoid presenting a finished US rollout as the only possible design. Bring the configurable decisions to the German process: data residency, retention, dashboards, automated actions, scoring criteria, integrations, and escalation. The earlier these choices remain open, the easier it is to negotiate without rebuilding the system.

Use one bilingual system dossier. Translate not only the policy but also field names, screenshots, score explanations, and admin settings. Define who can answer technical questions in Germany’s time zone. A council cannot assess a system from a sales deck that omits the actual configuration.

Finally, keep co-determination, privacy, and AI regulation in separate workstreams with one shared evidence base. They overlap, but approval in one does not close the others. For the regulatory layer, read the overview of EU AI Act obligations in recruiting.

Frequently asked questions

Does every AI recruiting tool require a works agreement?

Not simply because it uses AI. The enabled functions, employee-monitoring capability, selection rules, data, and operational effects matter. Run the function map before procurement and obtain case-specific labor-law advice where the boundary is uncertain.

Can HR start a pilot before the works council approves it?

Do not assume the word “pilot” removes participation rights. A trial with real users or applicants can create the same monitoring and selection effects as production. Agree the pilot scope, users, data, duration, manual controls, and stop conditions first.

Is human-in-the-loop enough?

No. Human review is only meaningful when the reviewer understands the recommendation, can access the underlying evidence, has time to challenge it, and can change the outcome without penalty. The agreement should make those conditions concrete.

Should the agreement name a model or a vendor?

Name the system and current configuration in a system sheet, but govern functions and material changes. A vendor name alone is too broad. A fixed model version alone becomes obsolete. The agreement needs a review trigger for consequential updates.

What is the fastest way to unblock approval?

Bring a complete system dossier to a joint workshop: purpose, function map, data flow, selection logic, disabled features, access roles, testing, human review, incident process, and change categories. Unanswered configuration questions delay approval more than a carefully bounded use case.