Transparency to the Managed: What Workers Are Told, When and by Whom

Chapters 25 to 27 gave every management decision a record, every overseer a measure of oversight quality and every worker a path to contest. None of that helps a person who does not know that a system takes part in managing them, what it reads about them, how far its output goes without a person and who answers for the result. This chapter designs transparency to the managed: what workers, their representatives, the public and supervisors are told, when and by whom. It reads the information duties of the GDPR, the AI Act, the Platform Work Directive, national transparency rules and co-determination law as organisational and architectural implications, not legal advice, and turns them into two versioned artefacts: the worker information notice and the transparency register. It concerns four management functions: M1 Direction, because workers must know when a system assigns and paces their work; M2 Evaluation, because they must know what is measured about them and who sees it; M3 Consequence, because a person facing a decision about pay, hiring or access to work must know whose decision it is; and M5 Care, because being told, in a language one understands and by a person one can ask, is part of the duty of care and the condition for voice.

Figure 28.1: Layers of transparency to the managed: what feeds the notice and the register, who receives what, and the triggers that renew the information.

Four audiences and five disclosures

Transparency has at least four audiences. The individual worker needs to know what the system does to them and what to do if it goes wrong. The workers' representatives need enough detail to inform, consult, negotiate or co-determine on behalf of everyone. Where the employer is a public authority, the public has a claim to know how it manages its staff. Supervisors and auditors need the full evidence, on request, under confidentiality.

Five objects of disclosure should be kept apart, because the law, the risk and the objections differ for each.

1. Existence. That a system takes part in managing the person, for which function and since when. Every regime requires it, and it is most often missed for Mode 0 Ambient AI features that arrive in an update.
2. Logic. What the system optimises, ranks or flags, and its main parameters and their weight. This is where trade secrets are claimed.
3. Inputs. Which data about the person enter the system, which are excluded and where they come from. Inputs are what a worker can check and correct.
4. Degree of delegation. Whether the system proposes (Level 0 Advisory, Level 1 Assisted), acts with per-decision approval (Level 2 Supervised) or acts within written bounds (Level 3 Bounded). Few legal texts ask for this, but it answers the worker's real question: is this a suggestion to my manager, or has it already happened?
5. The named decider. Who answers for each decision the system takes part in, and who receives a contest. Because Level 4 Autonomous is never used for M3 Consequence, every consequence decision has such a person.

The last two come from the delegation profile of Chapter 4 and the Management Decision Record of Chapter 25, and a worker can act on them most easily, because they say whom to ask.

Transparency to the individual worker

The GDPR sets the baseline for every employer in the Union. Information must be given "in a concise, transparent, intelligible and easily accessible form, using clear and plain language" (Article 12(1)), at collection or within the periods of Articles 13 and 14 (5, European Union, 2016). Articles 13(2)(f), 14(2)(g) and 15(1)(h) add "the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing". The duty to explain the logic is strict only for solely automated decisions with legal or similarly significant effects, which this book's rule on M3 Consequence excludes. For the larger set of systems that direct and evaluate work under human sign-off, the GDPR requires notice of the processing and its purposes and leaves the logic to good practice, the AI Act and national law.

Where meaningful information about the logic is owed, the Court of Justice has said what it means. In Dun & Bradstreet Austria it held that the person may require an explanation of "the procedure and principles actually applied in order to use, by automated means, the personal data concerning that person with a view to obtaining a specific result"; that neither "a complex mathematical formula, such as an algorithm" nor a description of every step suffices; and that it could be enough to say "the extent to which a variation in the personal data taken into account would have led to a different result" (65, CJEU, 2025). Chapter 27 builds the explanation on that holding. Here it settles the form of the notice: principles actually applied, written for the person, with a counterfactual where one helps, not a model card and not source code.

The AI Act adds two individual duties. Under Article 26(11), deployers of Annex III high-risk systems that "make decisions or assist in making decisions related to natural persons shall inform the natural persons that they are subject to the use of the high-risk AI system" (1, European Union, 2024); recital 93 says the information should include the intended purpose, the type of decisions and the right to an explanation under Article 86. The Digital Omnibus moved Article 26 for Annex III systems to 2 December 2027 (2, European Union, 2026), so the duty is expected on a decided date, while Article 86 applies on the text from 2 August 2026. Article 50(1), applicable from 2 August 2026, obliges providers to design systems "intended to interact directly with natural persons" so that people are told they are interacting with an AI system unless that is obvious. An employer that builds an agent which messages workers, to allocate a claim or ask for a status update, is its provider and should label those messages as coming from the agent.

The Platform Work Directive binds only digital labour platforms, but it is the best template for any employer (47, European Union, 2024). Article 9(1) requires information on automated monitoring and decision-making systems, including the categories of decision, "the categories of data and the main parameters that such systems take into account and the relative importance of those main parameters", including how the person's data or behaviour influence decisions, and the grounds for restricting, suspending or terminating an account. Article 9(2) requires a written document in "clear and plain language". Article 9(3) sets the timing this chapter adopts for every employer: a concise version "at the latest on the first working day", "prior to the introduction of changes affecting working conditions, the organisation of work or monitoring work performance" and "at any time upon their request", with the comprehensive version on request; Article 9(5) extends the duty to candidates before recruitment starts. Transposition is due by 2 December 2026 (Article 29(1)).

Two further instruments fill in timing for ordinary employment. Directive (EU) 2019/1152 requires a change in the essential aspects of employment to be given in a document "at the earliest opportunity and at the latest on the day on which it takes effect" (Article 6(1)) (53, European Union, 2019). Italy went further. Article 1-bis of Legislative Decree 152/1997, inserted by Legislative Decree 104/2022 and in force in its amended form since 5 May 2023, obliges employers to inform workers of "fully automated" decision or monitoring systems relevant to hiring, management, termination, task assignment, surveillance and evaluation (78, Repubblica Italiana, 2022). The information covers, among other items, "the logic and functioning", the main parameters and the accuracy metrics. Workers must be told in writing "at least 24 hours" before a change, must be answered in writing within thirty days of a request, and receive the information in a machine-readable format, as does the company union representation. The 2023 narrowing to fully automated systems shows how contested the reach of such duties remains.

Transparency to workers' representatives

Representatives judge a system on behalf of everyone and negotiate its terms, so their information must be fuller, earlier and continuous. Article 26(7) of the AI Act obliges employers, before using a high-risk system at the workplace, to inform "workers' representatives and the affected workers that they will be subject to the use of the high-risk AI system" (1, European Union, 2024); Chapter 21 showed that this is information, not consultation, owed to both groups, prior, and undefined in content. The Platform Work Directive gives representatives the comprehensive version of Article 9 before use, before changes and on request (Article 9(4)), extends information and consultation under Directive 2002/14/EC to decisions likely to introduce or substantially change automated systems, and gives them an expert of their choice (Article 13(2) and (3)) (47, European Union, 2024).

National law usually gives more, and Article 2(11) of the AI Act protects it. In Germany the works council must be informed "rechtzeitig und umfassend", in good time and comprehensively, with the documents it needs on request (BetrVG §80(2)); an expert is deemed necessary where it must assess AI (§80(3)); and the employer must inform it in good time about planned work procedures "einschließlich des Einsatzes von Künstlicher Intelligenz", including the use of AI, and consult it early enough for its concerns to shape the planning (§90(1) no. 3 and §90(2)) (9, Germany, 2001). In Sweden the employer keeps the unions continuously informed of its activity and of "riktlinjerna för personalpolitiken", the guidelines of its personnel policy, with access to documents (MBL §19) (205, Sveriges riksdag, 1976), before the duty to negotiate under §11. In Spain the Rider law gave works councils the right to be informed of "los parámetros, reglas e instrucciones" on which algorithms affecting working conditions and employment are based (Workers' Statute, Article 64.4(d)) (77, Jefatura del Estado, 2021).

Representatives therefore need five things the worker's notice only summarises: the delegation profile with its inputs and prohibited inputs; the AI Act classification record; the change log, seen before each change takes effect; the pattern reports, such as Nordvik's monthly allocation review or Hansa's team-level metric OQM-HM-CLM-01; and the contest statistics of Chapter 27. A representative who receives only the notice has been informed in the AI Act's narrow sense but not equipped for the job national law gives them.

Transparency to the public, supervisors and auditors

Public authorities owe a third layer. Under Article 49(3) of the AI Act, public-authority deployers must, before using an Annex III high-risk system, register themselves, select the system and register its use in the EU database (1, European Union, 2024). Annex VIII, Section C requires, among other items, "a summary of the findings of the fundamental rights impact assessment" and, where applicable, of the data protection impact assessment, and Article 71(4) makes the information publicly available and machine-readable outside law enforcement, migration and border control. A regional authority that rosters its nurses with a high-risk system will publish, in summary, what it found when it assessed the system's effect on its own staff; for Annex III management systems this is expected from 2 December 2027.

The EU database is a floor. AI Governance, Chapter 17 concluded that a public authority's algorithm register is generated from version-controlled entries, with the line between decision support and automated decision drawn in the data model and audit log (41, Nordqvist, 2026); this chapter builds on that conclusion (F31). The register that tells residents how benefit applications are ranked can tell them, and the staff, how care workers are rostered. For a private employer there is no such duty; the transparency register below is this book's proposal, by analogy.

Supervisors and auditors form the fourth layer. The Platform Work Directive gives competent authorities the comprehensive information on request (Article 9(4)), the AI Act requires deployers to cooperate with competent authorities (Article 26(12)), and data protection authorities, internal audit, the works council's expert and courts need the same material. The evidence behind every notice must therefore be retrievable without assembly: the profile version in force on a date, the notice version the worker received, the change log and the decision records. AI Platform and Security, Chapter 5 concluded that the repository, not the document, is the single source from which documentation is generated (42, Nordqvist, 2026); notice and register are generated the same way.

The trade secret objection

The commonest objection to disclosing logic is that it is the supplier's trade secret. The objection has a legal basis and a limited reach. Directive (EU) 2016/943 protects undisclosed know-how and business information, but its Article 3(1)(c) treats acquisition through the "exercise of the right of workers or workers' representatives to information and consultation" as lawful, and Article 5(c) excludes remedies for "disclosure by workers to their representatives as part of the legitimate exercise by those representatives of their functions" (247, European Union, 2016). It protects the supplier against competitors, not against the information rights of the workforce. Article 78 of the AI Act binds authorities and others applying the Regulation to protect trade secrets, "including source code", with an exception for the cases in Article 5 of that Directive (1, European Union, 2024); it governs what authorities disclose, not what an employer tells its staff.

Recital 63 of the GDPR says access should not adversely affect trade secrets, but that "the result of those considerations should not be a refusal to provide all information to the data subject" (5, European Union, 2016). In Dun & Bradstreet the Court held that a controller claiming trade secrets must give the allegedly protected information to the supervisory authority or court, which balances the interests (65, CJEU, 2025); the controller does not decide alone. The Platform Work Directive lets courts order disclosure of confidential evidence with protective measures (Article 21(2)). Co-determination law has its own confidentiality machinery: works council members must keep secrets the employer has expressly designated (BetrVG §79) (9, Germany, 2001), and under MBL §21 a party may negotiate a duty of confidentiality and ask a court to order one (205, Sveriges riksdag, 1976).

The trade secret objection therefore limits the form of disclosure, not its fact. The worker's notice needs principles, main parameters, inputs, degrees and deciders, none of which is source code, and the representatives' detail can be given under confidentiality. An employer that buys a system should not accept a contract that prevents it from meeting its own duties: beyond the instructions for use of Article 13, the tender should require the content of a worker information notice for each management function, a change notice with every release that alters behaviour, and permission to disclose that content to workers, representatives and authorities.

A second objection is gaming. Bernstein's transparency paradox, discussed in Chapter 10, concerned the visibility of workers to supervisors, which led workers to hide their improvements (122, Bernstein, 2012); transparency of the system to the worker runs the other way. A system that people can game by knowing its inputs measures the wrong thing, and secrecy hides the defect rather than curing it. The notice should state the direction of each input, and the employer should treat a pattern of gaming as evidence about the metric.

Transparency that nobody reads

A notice can comply with every article and inform nobody. McDonald and Cranor estimated that reading the privacy policies of the websites an American internet user visits would take about 201 hours a year (248, McDonald & Cranor, 2008). The study concerned consumers and websites, not employees, and its point is the scale of the burden, not a measured reading rate at work; it warns against the notice written for an auditor.

The evidence from work points the same way. Eurofound's literature review reports a survey of trade union members across Europe in which 32 per cent of workers were unaware of the use of algorithmic technology in their workplace, a British retail union survey showing a general lack of awareness of how personal data were used, and Nordic case studies whose informants said that taking part in the research was the first time they had reflected on these issues (150, Riso et al., 2025). The review notes that workers often do not know how or why an algorithm made a decision, and that employers who buy off-the-shelf systems are themselves limited in what they can explain. These are surveys and case studies of awareness, not experiments on notices; they show that the gap exists, not that better notices would close it.

Three design responses follow. Layering: Kaminski and Malgieri argued that the GDPR's impact assessment should produce "multi-layered explanations", combining a systemic account with what an individual needs to invoke their rights (174, Kaminski & Malgieri, 2021); the notice applies the idea to the worker, one page first and detail behind it. Timing at the moment of relevance: information on the roster or allocation the person is looking at is read, information given once at hiring is not. And a person: the line manager explains, because conversation is how people at work actually learn how they are managed.

The worker information notice

The worker information notice is a versioned artefact, written for the people a system manages, that states for one system and one group of workers what the system does, which management functions it performs at which degree of delegation, what data it reads and must not read, who decides and how to contest. It is generated from the delegation profile and the transparency register, reviewed by the representatives, tested with the people it is for and explained by their line manager.

Its fields follow the five disclosures: the system, functions, units, start date and version; what the system optimises or ranks, the main parameters in order of weight and one counterfactual example; the data read, the data never read and their sources; the degree for each function, stated in words with the level in brackets; and the role and name of the person who answers for each kind of decision. Then come the person's rights (access, explanation, contest with the answer time, representation), who sees outputs about the person and what they may not be used for, and a one-line history per version. The notice has three layers: one page in plain language, readable in five minutes; the full notice of two to four pages; and the detail on request, which for representatives and supervisors includes the profile, the classification record and the change log.

It has three timings. Before deployment, it is issued with the representatives' information and explained at a workplace meeting before the system first affects anyone. At each change class, it is reissued before the change takes effect. At each decision about a person, a decision notice, an extract of the Management Decision Record of Chapter 25, shows the system's part, the named decider and the contest path. The change classes are agreed with the representatives in advance:

Change class	Examples	Notice	Representatives	Default lead time
Class 1	New system, new management function, higher degree of delegation, new unit or entity	New notice version, workplace meeting	Informed, and consulted or negotiated where law requires, before the decision	15 working days before use
Class 2	New or removed input, changed objective, threshold or bound, new recipient of individual outputs	Updated notice and one-line summary to each person affected	Informed before the change, with the diff	5 working days, never less than any statutory minimum
Class 3	Model retrained within tested bounds, defect fix, no change to any notice field	No new notice; change log entry visible on request	Change log available continuously	None

The defaults must be adapted to the collective agreement or works agreement; Italy's 24 hours is a statutory floor, not a target.

The feature register FTR-* of Chapter 10, in management/office-feature-register.yaml, is the source of what must be disclosed when a vendor release changes behaviour. When a release note announces a change, the product owner updates the entry; if the change alters any field the notice or register publishes, the diff is a Class 1 or Class 2 change, and the new behaviour is not enabled until the notice has been reissued. The rule closes the route by which Mode 0 Ambient AI features become managers without anyone being told, the blind spot that AI Red Team, Chapters 8 and 28, found for vendor AI in security tooling (43, Nordqvist, 2026); this chapter builds on that conclusion (F57).

Practical guide: Writing a worker information notice and testing it with the people it is for

Purpose. Produce a notice that the workers a system manages can read, understand and act on, that meets the employer's information duties and that stays true as the system changes.

Roles. The system owner drafts from the delegation profile; HR owns the notice; the data protection officer checks it against GDPR Articles 13 to 15; the workers' representatives review it and agree the change classes; a small group of the workers affected tests it; the line manager explains it; the worker affected can ask for the detail and contest.

Steps.

1. Generate the fields from the delegation profile and the register entry, not from the vendor's brochure. Every statement must trace to a field in a versioned artefact.
2. Write the first page for the least experienced reader in the group: short sentences, the workers' own words for their work, no abbreviations. Default: at most 400 words, readable on a phone.
3. State each degree in words a worker would use: "the system suggests and your manager decides", "you can decline the offer without consequence".
4. Add one counterfactual example showing how a change in the person's own data would change the output.
5. Translate into the languages the group works in and check each translation with a reader from the group.
6. Test the draft with five to eight workers, in working time. Ask each to say, without the notice, what the system does, who decides and how they would object. Revise until most can answer all three.
7. Agree the change classes and lead times with the representatives and record the agreement in the notice.
8. Brief the line manager with the notice, the detail layer and the test group's questions, and hold the workplace meeting before first use.
9. Publish the notice where workers already look (the roster app, the unit's intranet page, the staff room) and link every decision notice to it.
10. Review it at every Class 1 or Class 2 change and at least annually, and record each version in the register.

Definition of done. The notice traces field by field to the profile; the test group could state what the system does, who decides and how to object; the representatives have reviewed it and agreed the change classes; the manager has explained it in person before first use; every version is in the register; and the detail layer can be produced on request within five working days.

Worked example: the ShiftWise worker information notice for Strandvik home care

Illustrative. Nordvik Region's ShiftWise drafts visit schedules and routes for home care and offers open shifts, under the delegation profile DLG-NR-ROS-01. Before the first roster for the Strandvik unit, Ingrid Halvorsen's team drafted the notice from the profile, and Mikael Strand tested it in December 2026 with six assistant nurses and care assistants from his unit. None of the six could say what the first draft, "optimising route efficiency under working-time constraints", meant for their day; the second draft answered what they asked: how much time a visit gets, whether declining an extra shift counts against them, and whom to call when a route does not work. Version 1.0 was issued on 2027-01-11 and explained by Mikael Strand at a workplace meeting the next day, before the first roster was published on 2027-01-22. The source is below; the rendered notice is two pages, the first being the plain-language summary.

# management/notices/WIN-NR-SW-HC-01.yaml (illustrative)
id: WIN-NR-SW-HC-01
version: "1.2"
system: ShiftWise
applies_to: home-care staff, Strandvik unit; further units by rollout wave
delegation_profile: DLG-NR-ROS-01
register_entry: TRG-NR-SW-HC
decision_record: AIDR-0634
languages: [national language, English, Arabic, Tigrinya]
summary_plain_language: >
  ShiftWise is a computer program. It suggests your four-week roster and
  your daily visit route. Your unit manager checks and approves every roster
  and can change any shift. ShiftWise also sends offers of extra shifts to
  everyone who has opted in, in a published rotating order. You can say no,
  and saying no is never held against you. If a route does not leave enough
  time, tell your unit manager or contest it. You get an answer within
  10 working days, and never later than 14 calendar days.
functions:
  M1_Direction:
    rosters_and_routes: the system suggests, your unit manager approves every roster
    open_shift_offers: sent automatically to all who opted in, rotating order, decline without effect
  M2_Evaluation: none; dashboard figures do not enter ShiftWise
  M3_Consequence: none; rosters set hours, so pay effects are checked monthly
  M5_Care: the system flags breaches of rest rules; your unit manager resolves them
inputs_used: [care plan visit times, travel time by road, your competences,
  your contract hours, your stated preferences, working-time and rest rules]
inputs_never_used: [whether you accepted or declined earlier offers,
  sickness absence, time-per-visit dashboard figures, union membership]
acceptance_of_open_shifts: recorded for pay and the roster only
counterfactual_example: >
  If you mark Tuesdays as unavailable before the roster deadline, ShiftWise
  will not suggest Tuesday shifts for you unless no one else with your
  competences is available, and then your manager must ask you first.
named_deciders:
  rosters_and_routes: Mikael Strand, unit manager
  contest_receiver: Mikael Strand or the HR business partner for home care; review by the HR business partner, never by the person who made the decision (AIDR-0631)
your_rights: [see the data ShiftWise holds about you, explanation of a roster or route,
  contest within four months (30 days before AIDR-0631), answer within 10 working days and never later than 14 calendar days, help from your union]
outputs_seen_by: [you, your unit manager, central rostering support]
change_classes_agreed_with: [union for municipal and care workers, union for nurses and midwives]
history:
  - {version: "1.0", date: "2027-01-11", change: first issue before go-live}
  - {version: "1.1", date: "2027-01-21", change: open-shift rotating order added, DLG-NR-ROS-01 v1.0.0}
  - {version: "1.2", date: "2027-03-15", change: minimum travel time between visits, after CNT-NR-0001; appeal path of AIDR-0631}

Version 1.2 shows the change classes at work. The contestation CNT-NR-0001 led to a new routing constraint, routed time plus five minutes and never under ten, which changes the time a worker has between visits. That is a Class 2 change: the notice was reissued and each member of the unit received a one-line summary in the roster app before the constraint took effect.

The transparency register

The transparency register lists every system that performs a management function in the organisation, per entity: what it does, its usage mode, its degree of delegation per function, the delegation profile and notice in force, the person to contact, the representatives' agreement and its date, whether the AI Act applies as law or as group policy, and the history of changes. It is to the workforce what the algorithm register of AI Governance, Chapter 17 is to residents, and it is generated in the same way, from version-controlled entries (41, Nordqvist, 2026). It reads the delegation register of Chapter 25 and the feature register of Chapter 10, so that a feature switched off in the feature register does not appear as enabled in the transparency register, and a change in either produces a diff that the representatives see.

The register does three things separate notices cannot. It makes absence visible: a system not in the register is a gap. It shows degrees across systems, so drift towards higher levels is visible in one place. And it carries the agreements: which body agreed which system, on which date, and where agreement is pending.

# management/transparency-register.yaml (illustrative excerpt, Hansa Mutual, Germany)
register: transparency-register
organisation: hansa-mutual
version: "2027.1"
generated_from: [management/delegation-register.yaml, management/office-feature-register.yaml]
entries:
  - id: TRG-HM-CTA-DE
    system: claims-triage agent, allocation of claims to handlers
    usage_mode: Mode 5 Autonomous production agents
    functions: {M1_Direction: Level 3 Bounded, M2_Evaluation: Level 1 Assisted}
    M3_Consequence: not delegated; figures no input to pay, discipline or dismissal
    delegation_profile: DLG-HM-CTA-01
    notice: WIN-HM-CTA-DE v1.1
    contact: claims team leader of each team; group head of claims operations
    agreement: {body: Konzernbetriebsrat, instrument: KBV-IT-2024, date: "2026-12-14"}
    ai_act: law
  - id: TRG-HM-TL-DE
    system: TalentLens screening and structured interview scoring
    usage_mode: Mode 4 Built AI applications
    functions: {M2_Evaluation: Level 1 Assisted, M3_Consequence: Level 1 Assisted}
    delegation_profile: DLG-HM-REC-01
    notice: WIN-HM-TL v1.0 and candidate notice in the application form
    contact: named recruiter per vacancy; group HR recruitment
    agreement: {body: Konzernbetriebsrat, instrument: KBV-IT-2024 annex, date: "2026-05-20",
      pending: selection criteria HR-REC-CRIT-2026-01 under BetrVG section 95}
    ai_act: law
  - id: TRG-HM-SPS-DE
    system: sales-performance score
    usage_mode: Mode 4 Built AI applications
    functions: {M2_Evaluation: Level 1 Assisted, M3_Consequence: Level 0 Advisory}
    delegation_profile: DLG-HM-SPS-01
    contact: sales manager of each team; entity HR lead
    agreement: {body: Konzernbetriebsrat, status: under review}
    ai_act: law
  - id: TRG-HM-OSA-DE
    system: wellbeing and collaboration analytics, office suite
    usage_mode: Mode 0 Ambient AI
    status: switched off, feature register entry FTR-HM-CA-01
    agreement: {body: Konzernbetriebsrat, status: pending}

The manager explains

A notice forwarded by email has been delivered, not explained. The person who can explain how a system manages a team is the person who manages the team with it, because only they can say how they use its output, when they depart from it and what they want to hear about. That is why the line manager stands in the path of every Class 1 notice and receives the detail layer before the team receives the first page. Chapter 29 turns this into the transformed manager's role; here it is a design requirement of transparency.

The manager should be able to answer five questions without looking anything up. What does the system do to my work? What does it read about me, and what does it never read? Who decides, and when do you change what it suggests? What do you see about me that I do not see? What do I do if I think it got something wrong? A manager who cannot answer these lacks the competence, training and authority that Article 26(2) of the AI Act requires of the people assigned to oversight (1, European Union, 2024), and the oversight record of Chapter 26 should show it. The questions a team asks at the workplace meeting are, in turn, evidence about the notice and the system, and recurring questions are a signal for the representatives.

Worked example: Hansa's Article 26(7) notices for TalentLens and the claims-triage agent

Illustrative. Hansa Mutual issued its notice for TalentLens on 2026-06-01, ahead of the date from which Article 26(7) applies to Annex III systems, because the group decided to run the information step as soon as the system was classified high-risk under point 4(a). The notice went to the Konzernbetriebsrat and the recruiters in Germany, and in Poland to the company trade union organisation and the employee council; candidates receive their own notice in the application form before the procedure starts, as Article 26(11) requires and as Article 9(5) of the Platform Work Directive models. When AIDR-0651 reclassified the claims-triage agent's work-allocation function as high-risk under point 4(b) on 2026-12-14, the group needed a second notice, for claims handlers, covering both the allocation and the throughput figures that team leaders see under KBV-IT-2024. Thomas Brandt asked that the notice state plainly that throughput figures stopped being an allocation input with release 7.0 and are no input to any M3 Consequence decision, and that the transparency register show the Konzernbetriebsrat's agreement and its date for every system. The group accepted both, and AIDR-0682 records the decisions.

# decisions/AIDR-0682.yaml (illustrative)
id: AIDR-0682
title: Worker information notices and transparency register for management systems
date: "2026-12-21"
status: accepted
proposed_by: chief HR officer
decided_by: group AI governance board
consulted: [Konzernbetriebsrat, european-works-council, group data protection officer]
related: [AIDR-0650, AIDR-0651, DLG-HM-CTA-01, DLG-HM-REC-01, DLG-HM-SPS-01, KBV-IT-2024]
decisions:
  - notice: WIN-HM-TL
    system: TalentLens
    basis: AI Act Article 26(7) and 26(11), applied ahead of application
    issued: "2026-06-01"
    recipients: [Konzernbetriebsrat, recruiters DE, trade union organisation PL,
      employee council PL, candidates via application form]
  - notice: WIN-HM-CTA-DE
    system: claims-triage agent, allocation and throughput figures
    basis: [AI Act Article 26(7), BetrVG section 90(1) no. 3, KBV-IT-2024]
    issued: "2027-01-08"
    states:
      - throughput figures are not an allocation input from release 7.0
      - throughput figures are visible to the team leader only
      - throughput figures are no input to pay, discipline or dismissal
      - the team leader can reassign any claim and switch the team to manual allocation
      - agent messages to handlers are labelled as sent by the agent, Article 50(1)
    explained_by: claims team leader at a team meeting before issue
  - register: management/transparency-register.yaml
    scope: EU entities as law; NO, UK and CH as group policy, adapted per entity
    publishes_agreement_and_date: true      # Konzernbetriebsrat request, accepted
    change_classes: [class 1: 15 working days, class 2: 5 working days, class 3: change log]
    vendor_release_rule: no behaviour change enabled before the FTR diff is classed
rejected_options:
  - option: one group notice for all systems
    reason: workers could not find what applies to them; one notice per system and group
  - option: publish the register only to managers
    reason: absence of a system is visible only to the people it would manage
review: on any class 1 change; at least annually; first review "2027-06-30"

The first Class 2 change came within weeks. After MDR-HM-0001 on 2027-01-12, the group added a capacity field that the team leader enters without reasons. Because it is a new allocation input, WIN-HM-CTA-DE was reissued as version 1.1, the change was notified to the works council under KBV-IT-2024 before release, and the register entry TRG-HM-CTA-DE now points to the new version.

Across the usage modes

Transparency is hardest at the two ends of the mode scale: for Mode 0 Ambient AI features that nobody registered, and for Mode 5 Autonomous production agents whose behaviour changes with every update of rules or models. The register records mode and degree, and a change of either is a Class 1 change.

Usage mode	Typical management use	What must be disclosed first	Main transparency risk	Trigger for a new notice
Mode 0 Ambient AI	Analytics and default-on features in licensed suites	Existence, and that the feature is on or off	Enabled by an update before anyone is told	Any FTR diff that changes a published field
Mode 1 Conversational assistants	A manager asks an assistant to rank or summarise people	That such use is forbidden or permitted, and by whom	Unrecorded use; no system to name	Change in the policy on general assistants
Mode 2 Embedded workplace assistants	Meeting summaries with owners, status reports	Who assigns, and whether outputs are filed per person	Proposals read as instructions	Change in distribution default or retention
Mode 3 Agentic work tools	A team lead's agent triages tickets	Whose identity the agent uses and who answers	Allocation hidden inside a person's account	New tool or new action class
Mode 4 Built AI applications	Rostering, screening, scoring	Logic, inputs, degree and decider per function	Vendor declines to explain	Class 1 or 2 change per the agreed table
Mode 5 Autonomous production agents	Agent allocating work to people	Degree, bounds, reassignment right and stop path	Frequent rule changes outrun the notice	Every new input, bound or degree

The outlook follows the labels of AI Governance, Chapter 22 (41, Nordqvist, 2026). The information duties of the GDPR, Italy's Article 1-bis, Spain's Article 64.4(d) and national co-determination law are observable law. Worker information notices for algorithmic management are observable in platform work and expected elsewhere, as Article 26(7) and 26(11) apply to Annex III systems from 2 December 2027 and as transposition of the Platform Work Directive sets a visible standard. Registration of public employers' management systems in the EU database is expected from the same date. Transparency registers kept by private employers are this book's proposal and remain speculation as a practice until they are observed.

Nordvik Region and Hansa Mutual

At Nordvik Region transparency is a public-law habit applied to its own staff. AIDR-0634, dated 2026-12-18, adopts this chapter's notice standard for every management system, makes the change classes part of the agreement with the unions behind DLG-NR-ROS-01, and adds a section for management systems to the Region's public algorithm register, generated from the same repository as the transparency register. ShiftWise appears there with the summary of FRIA-2026-007, and the Region will register its use in the EU database under Article 49(3) when the Annex III obligations apply, expected from 2 December 2027, as Chapter 21 records. Each rollout wave in home care repeats the notice test with the next unit. The home-care dashboards appear as a precautionary high-risk system whose individual figures go to the unit manager only and are barred from pay reviews and disciplinary matters under DLG-NR-HCD-01, and the paused recruitment-screening pilot appears with its status and AIDR-0601, so that the care staff whose union asked how it ranked can see that it is not in use. Nordvik's difficulty is the supplier: the notice depends on what the provider under tender NR-2025-089 will disclose, so the Region's next tender annex requires notice content and change notices from the provider.

At Hansa Mutual transparency is a question of plurality. The transparency register on the group intranet covers the EU entities as law and the Norwegian, UK and Swiss entities as group policy, each adapted to its own data protection law and its own body, from the ondernemingsraad in the Netherlands to the employee committee in Switzerland. Under AIDR-0682 the register shows each body's agreement and its date, and an entry whose agreement is pending in an entity is marked as not enabled there. Jana Petersen explained the claims-triage notice to her team before it was issued. Hansa's difficulty is volume: allocation rules change monthly and vendor releases reach every entity, so the change classes, not the notices, carry most of the work.

Nordvik publishes to residents as a public authority and must tell a supplier what to disclose; Hansa publishes to its workforce, builds most of its systems and must keep seven sets of representatives informed of the same changes. Both rest transparency on the same artefacts: the delegation profile as the source, the notice for the person, the register for everyone and the manager in between.

Summary

Transparency to the managed has four audiences, the worker, the representatives, the public and supervisors, and five objects: existence, logic, inputs, the degree of delegation and the named decider. The GDPR and the Dun & Bradstreet judgment set the baseline and the form of an explanation; the AI Act adds Articles 26(11), 26(7), 50(1) and, for public employers, 49(3); Article 9 of the Platform Work Directive is the best template for content and timing; and Italian, Spanish, German and Swedish law add detail and representative rights.

The trade secret objection limits the form of disclosure, not its fact, because Union and national law treat information to workers and their representatives as lawful and send disputed secrets to an authority or court. The harder limit is that notices go unread, which the awareness surveys reported by Eurofound suggest; the answer is layering, timing at the moment of relevance and a manager who explains.

The worker information notice, generated from the delegation profile, tested with the people it is for and explained by their manager, is issued before deployment, at each change class and, as a decision notice, at each decision. The transparency register lists every system that performs a management function, per entity, with its mode, degrees, contact, notice and the representatives' agreement and date, and reads the feature register of Chapter 10 so that a vendor release cannot change behaviour before workers are told. The chapter concerns M1 Direction, M2 Evaluation, M3 Consequence and M5 Care: workers must know what directs and measures them, who decides consequences and whom to ask.

Chapter 29 turns to the person at the centre of every layer: the line manager, whose role is transformed from supervisor of tasks to accountable leader of people and conductor of agents.

Sources

1. European Parliament and Council of the European Union (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union. (5, European Union, 2016)
2. Court of Justice of the European Union (2025). Judgment of 27 February 2025, CK v Dun & Bradstreet Austria GmbH and Magistrat der Stadt Wien, Case C-203/22, ECLI:EU:C:2025:117. (65, CJEU, 2025)
3. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union. (1, European Union, 2024)
4. European Parliament and Council of the European Union (2026). Regulation (EU) 2026/1744 (Digital Omnibus on AI). Official Journal of the European Union. (2, European Union, 2026)
5. European Parliament and Council of the European Union (2024). Directive (EU) 2024/2831 of 23 October 2024 on improving working conditions in platform work. Official Journal of the European Union. (47, European Union, 2024)
6. European Parliament and Council of the European Union (2019). Directive (EU) 2019/1152 of 20 June 2019 on transparent and predictable working conditions in the European Union. Official Journal of the European Union. (53, European Union, 2019)
7. Repubblica Italiana (2022). Decreto legislativo 27 giugno 2022, n. 104. Normattiva. (78, Repubblica Italiana, 2022)
8. Federal Republic of Germany (2001). Betriebsverfassungsgesetz (BetrVG). Gesetze im Internet. (9, Germany, 2001)
9. Sveriges riksdag (1976). Lag (1976:580) om medbestämmande i arbetslivet. (205, Sveriges riksdag, 1976)
10. Jefatura del Estado (2021). Ley 12/2021, de 28 de septiembre (the Rider law). Boletín Oficial del Estado. (77, Jefatura del Estado, 2021)
11. European Parliament and Council of the European Union (2016). Directive (EU) 2016/943 on the protection of undisclosed know-how and business information (trade secrets). Official Journal of the European Union. (247, European Union, 2016)
12. Bernstein, E. S. (2012). The Transparency Paradox: A Role for Privacy in Organizational Learning and Operational Control. Administrative Science Quarterly, 57(2). (122, Bernstein, 2012)
13. McDonald, A. M. & Cranor, L. F. (2008). The Cost of Reading Privacy Policies. I/S: A Journal of Law and Policy for the Information Society. (248, McDonald & Cranor, 2008)
14. Riso, S., Adăscăliţei, D. & Oosterwijk, G. R. (2025). Implications of algorithmic management for work, employment and social dialogue: Literature review. Eurofound. (150, Riso et al., 2025)
15. Kaminski, M. E. & Malgieri, G. (2021). Algorithmic impact assessments under the GDPR: producing multi-layered explanations. International Data Privacy Law, 11(2). (174, Kaminski & Malgieri, 2021)
16. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 2. (41, Nordqvist, 2026)
17. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. The Architecture as Code Series, Book 3. (42, Nordqvist, 2026)
18. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 4. (43, Nordqvist, 2026)