Tools for Managing People with AI: Decision, Contestation and Care
This chapter serves the activity of governing AI that takes part in managing people: directing their work, evaluating it, rewarding or disciplining them, developing them and caring for them. It collects four kinds of tool. The artefacts are the records and files that give a decision a named human decider and give a person a route to challenge it: the Management Decision Record (MDR-*), the contestation record (CNT-*), the decision-rights file (DRF-*), the disparate-impact test record (DIT-*), the survey plan (SVY-*) and the works agreement annex. The methods are the practical guides that produce them with employee representatives. A few third-party standards frame them, namely JSON Schema for validation and ISO 45003 for psychosocial risk. The series has no own tool in this activity apart from its publishing scripts. The tools come mainly from AI Boss, whose thesis is that AI may direct work but may not, on its own, decide about people, and from AI Governance, Architecture as Code, AI Threat, AI Purple and AI Operations (7, Nordqvist, 2026) (2, Nordqvist, 2026) (1, Nordqvist, 2025) (5, Nordqvist, 2026) (9, Nordqvist, 2026) (10, Nordqvist, 2026).
AI Boss divides management into five functions, M1 Direction, M2 Evaluation, M3 Consequence, M4 Development and M5 Care, and sets degrees of delegation per function from Level 0 Advisory to Level 4 Autonomous. Two rules run through every tool in this chapter. Level 4 is never used for M3 Consequence, and a decision with an adverse consequence for a person is never delegated above Level 1 Assisted. Everything else follows from one design choice: each function that carries consequences for a person has a named human decider, who can be identified, contested and held to account. The tools here are the means by which an organisation can show that this holds, to the person, to the representatives and to a supervisor.
Figure 22.1: Decision, contestation and appeal. Delegation is agreed beforehand; the named decider is recorded; the contest goes to a reviewer outside the line; a correction reaches the decision, the data, the rule, the model and the register.
The law that surrounds these tools is stated here as architectural implication, not as legal advice. The decision-rights file cites Article 26(7) of the AI Act, which concerns informing workers and their representatives before a high-risk system is put into use at the workplace (195, European Union, 2024). The practical guide for the decision-rights file asks the data protection officer to check Article 22 of the GDPR on automated individual decision-making, and Article 88 of the GDPR allows Member States and collective agreements to lay down more specific rules for employees' data (196, European Union, 2016). The Region's contest deadline is kept within the two weeks of the Platform Work Directive, which it adopted as a benchmark (200, European Union, 2024).
Management decision records
The first question is which record shows who decided. The series answers it in three layers. The delegation profile says, per management function, what a system may do, at which degree, with which inputs and which reviews. The decision-rights file places the ceilings, the decision classes with their deciders, the stop rights and the representatives' fixed rights in one file that the management body adopts. The Management Decision Record records a single decision that a system made or shaped about a person. The profile and the file are written once and reopened by evidence; the record is written for every decision in the chosen classes.
Management Decision Record (MDR)
| Kind | Artefact |
| Origin | AI Boss, Chapter 25 (Chapter 9; Appendix B.4; Appendix A 25_CODE_MDRNR, 25_CODE_MDRHM) |
| Purpose | Records one management decision AI made or shaped about a person: function, system, recommendation, named human decider, basis, explanation and contestation route |
| Use when | For every M3 Consequence decision a system shaped, and for other decisions above the profile's threshold |
| Inputs | The system's proposal and log reference, the delegation profile, the decider's reasons, the information given to the person |
| Outputs | A YAML record validated against the MDR schema before it is stored |
| Identifier family | MDR-NR-* and MDR-HM-* (Nordvik Region MDR-NR-0001 onwards, Hansa Mutual MDR-HM-0001 onwards) |
| Full template | AI Boss, Appendix A, quoted below |
The record has a few fields that carry the design. decider holds a role and a name and may not be system or agent. delegation names the profile and the degree. affected refers to staff by pseudonymous reference only. information_given states to whom, when and through which channel the person was told, and contest states the route, the time to request and the time to answer. retention fixes when the record is deleted. The first Nordvik record concerns the approval of a four-week roster for the Strandvik home-care unit, the first by the unit manager under the profile DLG-NR-ROS-01 at Level 2 Supervised, and it records why the manager changed what the system drafted: to resolve a flagged rest breach, to give weight to a stated childcare preference, and to correct a draft that gave four premium-bearing shifts against a rotation of three. The first Hansa Mutual record, MDR-HM-0001, concerns the reassignment of claims that the claims-triage agent had allocated to a handler on an agreed reduced schedule; the lasting correction, a capacity field the team leader enters without reasons, became the first Class 2 change under the works agreement KBV-IT-2024 (7, Nordqvist, 2026). The text below is quoted from Appendix A without change.
# management/decisions/MDR-NR-0001.yaml (illustrative)
id: MDR-NR-0001
schema_version: "1.0.0"
status: decided
date: "2027-01-22"
decision_class: NR-M1-ROSTER-APPROVE
decision: approve four-week roster, Strandvik home care, 2027-02-08 to 2027-03-07
function: M1 Direction
related_functions: [M3 Consequence, M5 Care] # premium shifts and rest rules
trigger: profile_rule
adverse: false
affected:
person_refs: [NR-PSN-3A91C0, NR-PSN-7D20F4, NR-PSN-B1E655] # staff whose shifts changed
system:
name: ShiftWise
version: release in deployment log entry SW-DEP-2027-002
proposal: draft roster version 3
flags: [daily rest under 11 hours, evening route to morning route]
log_ref: ShiftWise roster run of 2027-01-21
delegation: {profile: DLG-NR-ROS-01 v1.0.0, record: AIDR-0602, level: Level 2 Supervised}
decider: {role: unit manager, name: Mikael Strand}
reasons:
- resolve flagged rest breach after an evening route ending 22:00
- stated childcare preference had been outweighed in the draft by travel cost
- draft gave four premium-bearing shifts against a unit rotation of three
information_given: {to: all rostered staff, date: "2027-01-22", channel: staff app with reasons, notice_days: 17}
contest:
route: unit manager, then HR business partner care
request_by: 30 days after the end of the roster period # four months under AIDR-0631 from 2027-03-15
answer_within: 10 working days, never later than 14 calendar days # AIDR-0631 from 2027-03-15
retention:
rule: Nordvik archive rule for roster records, AIDR-0629
delete_after: 2 years after the roster period; unit-level statistics kept
Management Decision Record schema
| Kind | Artefact (a schema) |
| Origin | AI Boss, Chapter 25 (Appendix A, 25_CODE_SCHEMA) |
| Purpose | A JSON Schema 2020-12, kept in YAML, that validates every MDR: a person as decider, a contestation route, a retention rule, no M3 Consequence at Level 4 and no adverse consequence above Level 1 |
| Use when | Before any MDR is stored, in the pipeline, so that a failed record holds the decision and not the pipeline |
| Inputs | The MDR |
| Outputs | A pass or a failure that blocks the decision |
| Identifier family | management/schemas/mdr.schema.yaml |
| Full template | AI Boss, Appendix A (25_CODE_SCHEMA); not reproduced here |
JSON Schema 2020-12 is an open specification for describing and validating JSON documents (118, Wright et al., 2022); the series uses it to turn two of its rules into checks. An if clause makes adverse mandatory for M3 Consequence and forbids Level 4 Autonomous there; a second clause confines an adverse consequence to Level 0 Advisory or Level 1 Assisted; a third requires superseded_by on a superseded record. The limit of the series' claim is the usual one for a schema: it checks the form of a record, not the quality of the decider's reasons. The quality is what the oversight records and the seeded-error results of AI Boss, Chapter 26, are for.
Introducing Management Decision Records for one system
| Kind | Method |
| Origin | AI Boss, Chapter 25 (practical guide) |
| Purpose | Makes one system produce validated MDRs as a by-product of operation, readable by four readers |
| Use when | A system takes part in a management function and no record yet exists |
The guide has eight steps: choose no more than five decision classes in the first scheme, map each field to its source, build the record into the decision screen so that approval cannot complete until the record validates, set the retention rule per class, agree access and purposes with the representatives before the first record is stored, validate in the pipeline, test the four views from twenty real records and record the scheme as an AI Decision Record with a review after six months. Its definition of done is that no record names a system as decider and that the two workers who reviewed it could read theirs (7, Nordqvist, 2026). The related method Introducing, pausing or retiring a screening model with a record (AI Boss, Chapter 7) keeps every hiring decision with a named person and a readable record as a screening model is introduced, paused or retired. Nordvik Region's recruitment screening is paused under AIDR-0601.
Decision-rights file (DRF-*) and how to write it
| Kind | Artefact, with the method Writing a decision-rights file with the representatives |
| Origin | AI Boss, Chapter 20 (Appendix A 20_CODE_DRFNR, 20_CODE_DRFHM; Appendix B.17) |
| Purpose | Gives every class of management decision a decider, a ceiling and a stop right, agreed with the representatives |
| Use when | Before the first delegation profile is adopted, and when an orchestrator or a mixed team is introduced |
| Inputs | The classes of decision a manager takes more than once a month and every M3 decision (the book expects 25 to 40 in a large organisation), the delegation register |
| Outputs | management/decision-rights.yaml adopted as an AI Decision Record |
| Identifier family | DRF-NR-01, DRF-HM-01 |
| Full template | AI Boss, Appendix A |
The file sets a ceiling per function. Nordvik Region's DRF-NR-01 (AIDR-0607, effective 2027-04-01) sets M1 Direction at Level 3 Bounded, M2 Evaluation at Level 2 Supervised for teams and Level 1 Assisted for individuals, M3 Consequence at Level 1 Assisted for any decision and for an adverse one (stricter than the book's default), M4 Development at Level 1 Assisted, and M5 Care at Level 1 Assisted for a flag and Level 3 Bounded for a protective block. It lists four stop rights: pause in the unit within fifteen minutes by the unit manager, a system-wide stop within an hour by the HR director, a technical stop by the platform on-call through the supplier contract's stop path with its last test dated, and the safety representative's right to require an investigation. It also lists fixed rights of the unions, the workers and the safety representatives. Hansa Mutual's file has more classes, because AI already reaches M3 there, and the throughput class lists the consequence decisions it may feed; the list is empty, and the review of 2027-04-30 confirmed it. The method asks for a test within three months on ten real decisions from the past year, including three M3 decisions and one stop (7, Nordqvist, 2026).
Negotiating a delegation profile with unions or works council
| Kind | Method |
| Origin | AI Boss, Chapter 9 (practical guide) |
| Purpose | Agrees before go-live what a rostering or allocation system may do per function, degree, inputs and reviews, and which changes reopen the agreement |
| Use when | Procuring or switching on a rostering, scheduling or allocation system |
| Outputs | A delegation profile (DLG-*), recorded as an AI Decision Record |
The defaults are Level 2 Supervised for rosters, Level 3 Bounded only for declinable actions such as open-shift offers, and Level 1 Assisted for working-time checks. The guide asks for a published input list with prohibited inputs (no ratings, acceptance rates or sickness absence unless the parties agree), the objective function in plain language, the collective agreement's working-time rules as constraints, and agreed change classes (7, Nordqvist, 2026). The delegation profile itself belongs to Chapter 18 of this book; it is named here because the profile is the document the representatives negotiate.
Issue templates for management decisions
| Kind | Artefact |
| Origin | Architecture as Code, Chapter 19 |
| Purpose | Custom GitHub issue templates that capture the expected data of a management topic (financial impact, staffing, compliance, risk, dependencies) and leave a searchable record of how a decision evolved |
| Full template | None; described without a template body |
The templates are the earliest tool of the family and the only one that concerns management in general, not the management of people by AI. Architecture as Code uses issues as transparent decision records: they give traceability, accountability by assigned owner and a place for collaborative resolution (1, Nordqvist, 2025). They are not a Management Decision Record: they hold no named decider for a person's consequence, no contest route and no retention rule.
Contestation and appeal
A decision about a person is only as accountable as the route by which the person can challenge it. AI Boss, Chapter 27, builds three tools for this, in the order the person meets them: the form, the record and the appeal path.
Contestation and appeal form
| Kind | Artefact |
| Origin | AI Boss, Chapter 27 (Appendix B.7) |
| Purpose | Lets a worker, or a representative on the worker's behalf, challenge a management decision in plain language, with the MDR identifier pre-filled |
| Use when | Offered with every explanation; a submission opens a contestation record |
| Full template | None; described in Appendix B |
Contestation record (CNT-*)
| Kind | Artefact |
| Origin | AI Boss, Chapter 27 (Appendix A 27_CODE_CNTNR, 27_CODE_CNTHM; Appendix B.8) |
| Purpose | Records a worker's challenge, the reviewer (never the original decider), the time limits, the outcome and the correction propagated to data or system |
| Use when | For every contest, from the first oral remark to the closed correction |
| Inputs | The contested record, the delegation profile, the grounds, the explanation given |
| Outputs | A record that links the decision's record and the profile and is retained for the life of the system plus two years |
| Identifier family | CNT-NR-*, CNT-HM-* |
| Full template | AI Boss, Appendix A, quoted below |
The Nordvik record is the book's most instructive case, and it is quoted in full because it shows why the record has a field for each kind of correction. An assistant nurse in the Strandvik unit noticed that the route planned zero minutes between two visits about a kilometre apart. The unit manager granted the contest in full on the first look, and the HR business partner for home care, the reviewer, found that both addresses had been geocoded to the same postcode centroid, that no transition time was planned on any route, and that no rest-rule flag had fired because no working-time rule was breached. The correction ran through the rule (a minimum travel time), the data (address-level coordinates for all Strandvik residents), the risk assessment (WRA-NR-HC-01, revision 2) and a test, and it closed when the test passed in production on 2027-03-25. The record says that the shortened visit was recorded as caused by the route, not by the worker, and that the contest is never an input to any M2 Evaluation of the worker. The first look rule appears in its first_look field: the decider may grant a contest in full, and may not reject it (7, Nordqvist, 2026).
# contestations/CNT-NR-0001.yaml (illustrative)
id: CNT-NR-0001
opened: 2027-01-26
channel: oral, to the unit manager; written down and read back
contested_record: ShiftWise daily route, Strandvik unit, 2027-01-26
delegation_profile: DLG-NR-ROS-01
contested_by: assistant nurse, Strandvik home-care unit
supported_by: safety representative
grounds: Route planned 0 minutes between two visits about 1 km apart; second visit shortened
explanation_given:
date: 2027-01-27
role_and_logic: ShiftWise orders assigned visits by time window and travel time; the unit manager approves
inputs_about_person: [shift times, competences, assigned visits] # no performance data
counterfactual: With travel time computed between the two addresses, 12 minutes would have been planned
human_decider: Mikael Strand, unit manager
first_look: granted in full; route for 2027-01-27 corrected
reviewer: HR business partner for home care
deadlines: {answer_due: 2027-02-09, answered: 2027-02-05}
findings:
- Both addresses geocoded to the same postcode centroid, so routed travel time was 0 minutes
- No transition time for parking, entering and leaving was planned on any route
- The rest-rule flag did not fire because no working-time rule was breached
outcome:
decision: shortened visit recorded as caused by the route, not the worker
data: address-level coordinates for all Strandvik residents
rule: travel time at least routed time plus 5 minutes, minimum 10 minutes (WRA-NR-HC-01 rev 2, C2)
model: none; the visit-duration forecast was examined and not implicated
register: DLG-NR-ROS-01 references constraint C2 and AIDR-0631
system_correction:
owner: Ingrid Halvorsen, HR director
reviewed_by: central work-environment committee
risk_assessment: {id: WRA-NR-HC-01, revision: 2, approved: 2027-03-11}
test: tests/test_travel_time.py
verified: 2027-03-25
no_use_in_evaluation: the contest is never an input to any M2 Evaluation of the worker
follow_up:
- {record: AIDR-0631, date: 2027-03-15, effect: review never by the decider; answer within 10 working days}
- {record: WIN-NR-SW-HC-01 v1.2, date: 2027-03-15, effect: travel-time rule told to every member of the unit}
closed: 2027-03-25
Hansa Mutual's CNT-HM-0001 shows the other path. A Dutch field-sales employee contested a quarterly performance score and the pay proposal based on it. The sales manager did not grant it, so it was referred to an HR business partner outside her line; the findings were that a complaint indicator penalised staff in markets with higher complaint rates, that two complaints had been attributed to her wrongly, and that the pay proposal matched the score band without a written assessment. The band was corrected and the indicator normalised per market. In the Dutch sales unit, 97 per cent of proposals matched the band and the median time to decide was 48 seconds, which is the observation that led to the classification of that unit as decisive in practice.
Building an appeal path
| Kind | Method |
| Origin | AI Boss, Chapter 27 (practical guide) |
| Purpose | Gives every affected worker a route from contest to correction that names who answers, by when and with what authority |
| Use when | Before a management system goes live; tested with a test contest |
| Inputs | The delegation profile's list of contestable decisions, the explanation template, the names of receivers and reviewers by role |
| Outputs | An appeal path recorded in a decision record and named in the worker information notice |
The guide has eight steps: map the contestable decisions; write an explanation template with four elements and test it with three workers; name receivers and reviewers by role, each with a deputy, where no reviewer may have approved the decisions they review; set the time limits; write the first-look rule; define correction for the decision, the data, the rule, the model and the register, each with an owner and a test; connect the contestation record; and agree reporting and triggers with the representatives. The defaults are acknowledgement within two working days and an answer within ten working days, never later than fourteen calendar days for a decision that takes effect within a month; pay inputs may take up to fifteen working days with the pay effect held or provisional.
Nordvik Region's own appeal path is the worked example, and it is recorded as AIDR-0631, which applies to DLG-NR-ROS-01, DLG-NR-HCD-01 and every future profile. A contest may be lodged with the unit manager, the HR business partner, a staff-app form or a union or safety representative within four months. Review is by the HR business partner for the sector, with another unit's manager as deputy, and the decider, the system and its supplier are excluded. The answer is due within ten working days and never later than fourteen calendar days, whichever is earlier. The Region found the rule after its first contest exposed two gaps: the contest went to the unit manager who had approved the route, and two different time limits were in circulation in two records (7, Nordqvist, 2026).
Impact tests with the representatives
Delegation and contestation deal with single decisions. Impact tests ask whether a system disadvantages a group, and co-determination tools make the answer a matter agreed with the people concerned. The two belong together in this chapter because the series insists on doing both with the representatives, not about them.
Disparate-impact test record
| Kind | Artefact |
| Origin | AI Boss, Chapter 12 (and Chapter 24) |
| Purpose | Records a test of whether an evaluating or allocating system disadvantages a group, agreed with the representatives |
| Use when | On every release of a system that evaluates people or allocates work, pay or opportunities, and at least every six months |
| Inputs | Groups of lawfully held characteristics and at least one intersection, a reporting floor of 20 people per cell |
| Outputs | A record with ratios and intervals, the cause, a decision whether it is objectively justified, a correction and a list of affected cases |
| Identifier family | DIT-HM-CTA-01, DIT-NR-ROS-* |
| Full template | AI Boss, Chapter 12, quoted below |
The record quoted here tests the allocation of claims by Hansa Mutual's claims-triage agent at Level 3 Bounded. The share of complex claims allocated to part-time handlers was 0.71 of the reference group (interval 0.64 to 0.78), a trigger; the cause was an allocation rule that offers complex claims only to handlers with two consecutive working days left in the week. The record does not say that anyone discriminated. It shows that a rule written for continuity put part-time handlers, most of them women in this population, at a disadvantage in access to the work that leads to promotion, without a justification that passes the test of appropriate and necessary means. It flags the promotion files for the years in question, because the disparity may already have shaped M3 Consequence decisions, which belong to the people who took them (7, Nordqvist, 2026).
disparate_impact_test:
id: DIT-HM-CTA-01
status: illustrative
system: claims-triage agent, allocation to claims handlers
delegation_profile: DLG-HM-CTA-01
decision_records: [AIDR-0651, AIDR-0653] # AIDR-0653: test on every release
period: 2026-Q3
population: claims handlers allocated by the agent in Germany
groups:
attributes: [handler_group, age_band, part_time_status]
intersections: [[part_time_status, sex]]
reference: full_time
min_cell_size: 20
results:
- {outcome: share_of_complex_claims, group: part_time, ratio: 0.71, interval_95: [0.64, 0.78], triggered: true}
- {outcome: share_of_complex_claims, group: [part_time, women], ratio: 0.69, interval_95: [0.60, 0.79], triggered: true}
- {outcome: claims_per_available_hour, group: part_time, ratio: 1.04, triggered: false}
cause: >
Allocation rule CTA-R-14 offers complex claims only to handlers with
two consecutive working days left in the week, which most part-time
handlers rarely have.
justification_found: false
correction:
rule_change: complex claims may span shifts with a recorded handover
retest: 2027-Q1
affected_cases: senior-handler promotion files 2025-2026 flagged for review
reported_to_works_council: 2026-12-08
Related impact-test tools
| Name | Kind | Origin | Purpose |
|---|---|---|---|
| Disparate-impact test with the representatives | Method | AI Boss, Chapter 12 | Seven steps: agree the question four weeks ahead, choose the groups (with special categories only under AI Act Article 4a and the data protection officer's written assessment), set a reporting floor of 20, measure with a 95 per cent bootstrap interval and treat a lower bound below 0.80 as a trigger for investigation and not as a finding, test the proxies, find the cause within 20 working days, correct, list affected cases and report within 30 days (7, Nordqvist, 2026) (195, European Union, 2024) (199, European Union, 2026) |
Disparate-impact test configuration (DIT-*) |
Artefact | AI Threat, Chapter 12 | A release-pipeline test configuration (DIT-NR-CR-01) that computes selection-rate ratios and a true-positive-rate gap for a benefits-triage ranker, with a bootstrap interval, a minimum cell size of 200, a proxy check and a block on promotion when a threshold is breached (5, Nordqvist, 2026) |
| Fairness evaluation configuration | Artefact | AI Governance, Chapter 10 | A fairness_evaluation block with protected attributes joined only in an isolated evaluation environment, metrics with thresholds and a rationale beside each, intersections and a minimum group size, read by the promotion gate and by weekly production monitoring (2, Nordqvist, 2026) |
| Fairness metrics (demographic parity, disparate-impact ratio, equal opportunity, equalised odds) | Method | AI Threat, Chapter 12 | Outcome comparisons, error comparisons and calibration; the book stresses that when base rates differ, an imperfect classifier cannot in general be both calibrated within groups and have equal error rates across them, so the choice of metric is a recorded decision |
The two test configurations are for systems that decide about the public or about applicants, and the test record of AI Boss is for systems that manage staff. The tests share the same arithmetic and differ in who must agree to them and who reads the result.
Consultation commitments
| Kind | Artefact |
| Origin | AI Governance, Chapter 15 |
| Purpose | Commitments made to employee representatives, tracked as data |
| Use when | Before a staff-facing system is introduced and consultation has produced commitments |
| Outputs | consultation/*-commitments.yaml, one entry per commitment with the control that enforces it and the test that proves it |
| Identifier family | consultation/*-commitments.yaml (NR-ALG-2026-007) |
| Full template | AI Governance, Chapter 15 |
Nordvik Region's staff assistant is not a high-risk AI system, but the Region ran the same information procedure it uses for high-risk systems. The file records five commitments: usage data is never used to assess individual performance, prompt and response logs are deleted after 90 days, adoption figures are reported only for groups of ten or more, use is voluntary for the first twelve months, and staff complete AI literacy training before access. Each names a control (a policy rule, a retention setting, a dashboard definition, an IAM group) and a test. The book's reasoning is that a commitment in a presentation is a promise, and one in a policy-as-code rule is a control (2, Nordqvist, 2026).
Co-determination checklist, clause set and change-class annex
| Kind | Artefacts (B.12 checklist, B.13 clause set, annex) and a method |
| Origin | AI Boss, Chapter 23 (Chapter 13; Appendix B.12 and B.13) |
| Purpose | The checklist lists per jurisdiction the information, consultation, negotiation or consent steps before a system that manages people is introduced or changed; the clause set offers draft clauses on purpose limitation, aggregation level, delegation limits, change notification, contestation and review; the annex classifies changes to a continuously changing system |
| Use when | At the start of every procurement, build or material change |
| Identifier family | Annex KBV-IT-2024 (Hansa Mutual) |
| Full template | The annex, AI Boss, Chapter 23, quoted below; the checklist and clause set are described in Appendix B without template text |
The checklist names, as examples, BetrVG §87(1) no. 6 and §§ 94 to 95 in Germany, MBL in Sweden and the WOR in the Netherlands; the clause set is a draft for negotiation, to be adapted to national law, and not legal advice. The annex answers a specific problem. A works agreement written for a system's first version does not say what happens when the rules change monthly. Hansa Mutual's revision (AIDR-0677, signed 2026-12-14) sorts changes into three classes: Class 1 renegotiation with the consent of the Konzernbetriebsrat for a higher degree of delegation, a behavioural input, a new individual metric or recipient, or any use of figures in M3 Consequence; Class 2 approval by a joint IT committee within ten working days, within stated bounds and after passing the allocation regression and DIT-HM tests; and Class 3 information. The works council may require a higher class but the employer may not lower one. A release manifest is required for every release. The first Class 2 change was the capacity field after MDR-HM-0001, and the throughput-based capacity factor withdrawn under AIDR-0651 is the example the annex was written to catch (7, Nordqvist, 2026).
# agreements/KBV-IT-2024/annex-change-classes.yaml (illustrative)
agreement: KBV-IT-2024
annex: change classes
parties: [Hansa Mutual group management, Konzernbetriebsrat]
legal_basis_de: [BetrVG 87(1) no. 6, BetrVG 94, BetrVG 95(2a), BetrVG 58(1)]
decision_record: AIDR-0677
signed: "2026-12-14"
applies_to:
- {system: claims-triage agent, profile: DLG-HM-CTA-01}
- {system: TalentLens, profile: DLG-HM-REC-01, from: "2027-04-01"}
release_manifest_required: [version, fields_changed, proposed_class, tests, notice_diff]
classes:
class_1_renegotiation:
procedure: consent of the Konzernbetriebsrat; new annex version
includes:
- higher degree of delegation or change of allocation objective
- behavioural input such as throughput or absence history
- new individual metric or new recipient of individual figures
- any use of figures in M3 Consequence
class_2_committee_approval:
procedure: joint IT committee decides within 10 working days
bounds:
daily_cap_per_handler: {min: 8, max: 20}
model_release: passes allocation regression and DIT-HM tests
class_3_information:
includes: [defect fix, security patch, input removed]
reclassification: works council may require a higher class; the employer may not lower one
disputes: standing conciliation committee under BetrVG 76(1)
review: {annual: "2027-12-01", triggers: [contestation pattern, failed stop test, new law]}
The method Drafting a works agreement for a continuously changing AI system (AI Boss, Chapter 23) has eight steps from the delegation profile to a test of the classification on the last ten releases, and it never goes below a statutory minimum notice.
Care and wellbeing
M4 Development and M5 Care are the functions that disappear when a system takes over the manager's attention, unless someone designs them back in. The tools below protect them and measure the effect of a change on the people it directs. Where studies are cited by the originating books, they are cited there; this chapter describes the tools and what they record.
Autonomy and fairness survey plan (SVY-*)
| Kind | Artefact, with the method Measuring autonomy and perceived fairness |
| Origin | AI Boss, Chapter 11 |
| Purpose | Plans a three-wave survey of autonomy, competence, relatedness and fairness before and after an AI system takes over part of M1 Direction |
| Use when | Before go-live of a system that directs work, once agreed with the representatives |
| Inputs | The change, the delegation profile, the agreed questions |
| Outputs | A survey plan in version control beside the delegation register, and unit-level results |
| Identifier family | SVY-NR-STV-01 |
| Full template | AI Boss, Chapter 11 |
The plan for Nordvik Region's Strandvik home-care unit sets three waves (four weeks before go-live, and three and nine months after), anonymous collection not linked to the HR information system, reporting only for groups of at least ten with the first audience a workplace meeting of the unit, prohibited uses (M2 Evaluation and M3 Consequence of individuals), 90 days' retention of raw responses and an action threshold of a fall of more than half a scale point on any dimension or a named loss. The method uses 12 to 16 statements and two open questions, and its definition of done includes a recorded decision to change nothing, where that is the decision (7, Nordqvist, 2026).
Writing health and rest constraints into an optimiser
| Kind | Method |
| Origin | AI Boss, Chapter 14 (practical guide) |
| Purpose | Makes health limits hard constraints that M1 Direction systems cannot trade for output, and proves by tests that they hold |
| Use when | Procuring or changing a scheduling or allocation optimiser |
The guide requires each constraint to have a source (law, collective agreement, risk assessment or agreed rule), classes everything with a legal or agreed source as hard, requires in the contract that hard constraints are feasibility conditions and not penalty terms, writes each constraint as a test that blocks approval of a failing plan, seeds known breaches on every change, reports strain monthly at team level, and keeps a manual fallback that the line manager or the safety representative can invoke and that is tested twice a year (7, Nordqvist, 2026). ISO 45003 gives guidelines for managing psychosocial risks at work (119, ISO/IEC, 2021) and AI Boss, Chapter 24, refers to it; the series does not claim that conforming to it is shown by these tests.
On-call charter for operators
| Kind | Method (the artefact ONC-* is treated in Chapter 21) |
| Origin | AI Operations, Chapter 25 |
| Purpose | Produces an on-call charter agreed with employee representatives before the rota or an AI operations tool changes |
| Use when | A rota or an operations agent's mandate is about to change |
The practical guide has a purpose, roles, steps, an interval and a definition of done, and its artefact, the charter, fixes working time, load ceilings, the attribution of agent actions and the rule that metrics are about the rota and the service and never a named person (10, Nordqvist, 2026).
Development without a score and the manager's weekly review
| Name | Kind | Origin | Purpose |
|---|---|---|---|
| Development conversation guide (development without a score) | Artefact | AI Boss, Chapter 19 (Appendix B.19) | Structures M4 Development conversations that do not start from a system's score, at least twice a year per worker and whenever work is reallocated to agents, and records what the worker can do and wants to learn without ratings |
| Manager's weekly review protocol | Artefact | AI Boss, Chapter 29 (Chapter 16; Appendix B.18) | A short weekly routine: review the week's MDRs and overrides, sample oversight records, read open contestations, check pace and rest flags, and hold one unassisted development conversation |
Neither has template text in the book. They are the human part of the chain: the record shows who decided, and the routine shows the manager reading it (7, Nordqvist, 2026).
Running the programme
Three plans and a checklist turn the records of a year into funded actions and give the management body a way to ask whether it governs the AI boss.
| Name | Kind | Origin | What it fixes |
|---|---|---|---|
| 24-month plan for governing the AI boss | Artefact | AI Boss, Chapter 32 (Appendix A 32_CODE_PLANNR, 32_CODE_PLANHM; Appendix B.22) |
A prioritised plan with owners, dates and AI Decision Records; Nordvik Region's PLAN-NR-MGT-2027 (AIDR-0640) has seven measures from procurement requirements through oversight before the third home-care wave to a reopening of recruitment screening only against stated conditions, and excludes Level 4 Autonomous anywhere and any M3 Consequence above Level 1 Assisted |
| First 90 days plan | Artefact | AI Boss, Chapter 33 (plans/ai-boss/first-90-days.yaml) |
A generic template in three phases (map, agree, record) that forbids raising any degree of delegation before day 90 and ends with a Management Decision Record read by a worker representative, not with a dashboard |
| Ten questions for governing the AI boss | Artefact (checklist) | AI Boss, Chapter 33 | An annual test: the management body asks, HR answers with evidence and the representatives review the answers before they reach the board; question 3, on Level 4 for M3 or an adverse consequence above Level 1, must be answered no |
| One-page board report on algorithmic management | Artefact | AI Boss, Chapter 32 (Appendix B.20) | A quarterly report to the management body on the delegation register, M3 decisions and contestation rates, oversight quality and co-determination, requesting one decision |
The plans are illustrative templates for the organisation that starts to govern. The first 90 days plan is explicitly a generic template and not a record of either organisation (7, Nordqvist, 2026).
Across the degrees of delegation
The tools of this chapter do not change with the degree; what changes is what they must hold. The table sets out, from AI Boss, where each degree is used in the two organisations' files and what the tools require there.
| Degree of delegation | Where the files use it | What the tools require |
|---|---|---|
| Level 0 Advisory | Recruitment classes at Nordvik Region with screening paused (NR-M3-HIRE); M3 Consequence on the sales score at Hansa Mutual (DLG-HM-SPS-01) |
An MDR with a named decider; the explanation and contest route given to the person |
| Level 1 Assisted | Nordvik's ceiling for M3 Consequence, for any and for adverse decisions; M2 for individuals; M4; M5 flags | The schema's rule that an adverse consequence is not above Level 1 |
| Level 2 Supervised | Approval of rosters (NR-M1-ROSTER-APPROVE) |
An MDR for each approved roster; oversight records with seeded errors; the decider is the unit manager |
| Level 3 Bounded | Open-shift offers at Nordvik (declinable actions); claims allocation at Hansa Mutual (DLG-HM-CTA-01) |
Change classes in the works agreement; a disparate-impact test on every release; stop rights with a tested time to effect |
| Level 4 Autonomous | Not used for M3 Consequence anywhere; Nordvik's plan excludes it altogether | The schema rejects it for M3 Consequence |
Nordvik Region and Hansa Mutual
Nordvik Region is a public employer that negotiates with two public-sector unions under the Swedish co-determination pattern (MBL §11) and deploys the rostering system ShiftWise in its home-care units at Level 2 Supervised (DLG-NR-ROS-01, AIDR-0602). Its toolbox is small and sequenced: a decision-rights file with ceilings stricter than the book's defaults, MDRs for approved rosters, an appeal path (AIDR-0631) that its first contest forced into existence, a survey plan for the first unit and a 24-month plan that starts with procurement and oversight and contains no agent directed by a manager. Its consultation commitments for the staff assistant show the same habit at the level of a smaller system.
Hansa Mutual is a group with a Konzernbetriebsrat, Polish employee representatives and AI that already reaches M3 Consequence in one unit. Its toolbox leans on the works agreement KBV-IT-2024 and its annex of change classes, on disparate-impact tests agreed with the council (DIT-HM-CTA-01), on a decision-rights file that names the executive board as accountable, and on a team-level reporting rule that excludes individual figures from M2 and M3. Its first MDR and its first Class 2 change are the same event: the allocation of claims to a handler on a reduced schedule. The difference between the two is the one the originating book draws: Nordvik's problem is oversight in a public employer with a small set of systems, and Hansa's is the sum of delegations across entities and legal regimes (7, Nordqvist, 2026).
How to choose among them
A practitioner can start from the question being asked. To show who decided, use the MDR with its schema, and begin with one system and no more than five classes. To bound what a system may do, negotiate the delegation profile and adopt the decision-rights file. To let a person challenge a decision, give them the form, open a contestation record and build the appeal path with a reviewer outside the line. To find out whether a system disadvantages a group, run the disparate-impact test with the representatives on every release. To keep the agreement alive as the system changes, add a change-class annex and require a release manifest. To protect care and development, write health limits as hard constraints, measure autonomy and fairness in three waves, and keep the weekly review. To run the whole, adopt the 24-month plan and ask the ten questions once a year.
The chapter treats 30 of the 33 inventory entries in entries of their own, in family tables or in combined entries; Appendix A lists all of them. Three entries are reassigned in the findings file: the chain record CHN-HM-CLM-01 (AI Boss, Chapter 17) belongs with the mandate and delegation tools of Chapter 18, and the consent and notice protocol CNP-* with its method (AI Purple, Chapter 22) belong with the tools for emulation across provider boundaries in Chapter 11. The method Introducing, pausing or retiring a screening model with a record is reassigned to this chapter from Chapter 21 and is treated above.
Summary
The management-of-people tools of the series divide one problem into parts that can be tested. The delegation profile and the decision-rights file fix in advance what a system may do per management function and who decides, and they are agreed with the representatives. The Management Decision Record shows afterwards who decided, with what basis and with which route for the person to contest. The contestation record, the form and the appeal path give the person a reviewer outside the line and a correction that reaches the decision, the data, the rule, the model and the register. Impact tests find what no single decision shows, and the change-class annex keeps the agreement true as the system changes. The care tools protect development and rest as constraints, not as intentions. The rules that survive across all of them are few: Level 4 is never used for M3 Consequence; an adverse consequence is never above Level 1 Assisted; a reviewer is never the decider; a contest is never an input to evaluation; and figures about people are reported at team level unless the person asks for their own.
The findings file records open points: the Region's time limit for an answer was held in two records before AIDR-0631 reconciled them; Appendix B of AI Boss lists B.1 to B.22 but only twelve have full code in Appendix A, so the form, checklist, clause set, weekly protocol, development guide and board report exist as descriptions only; and several identifiers of the book (DLG-HM-SPS-01, DIT-NR-ROS-*, RVT-NR-ROS-*) appear in text without a listing.
Sources
- Nordqvist, G. Architecture as Code. (1, Nordqvist, 2025)
- Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (2, Nordqvist, 2026)
- Nordqvist, G. AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (5, Nordqvist, 2026)
- Nordqvist, G. AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. (7, Nordqvist, 2026)
- Nordqvist, G. AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. (9, Nordqvist, 2026)
- Nordqvist, G. AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. (10, Nordqvist, 2026)
- Wright, A., Andrews, H., Hutton, B. JSON Schema: A Media Type for Describing JSON Documents. (118, Wright et al., 2022)
- International Organization for Standardization. ISO 45003:2021 Occupational health and safety management – Psychological health and safety at work – Guidelines for managing psychosocial risks. (119, ISO/IEC, 2021)
- European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (195, European Union, 2024)
- European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). (196, European Union, 2016)
- European Parliament and Council of the European Union. Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). (199, European Union, 2026)
- European Parliament and Council of the European Union. Directive (EU) 2024/2831 of 23 October 2024 on improving working conditions in platform work. (200, European Union, 2024)