Developers, Works Councils and Employment: Telemetry, Rights and Intellectual Property

A coding assistant arrives in an organisation as a licence, a plug-in or a vendor update, and it leaves behind something that no other tool of the developer's trade has left: a record of how each developer works. Acceptance rates, prompts, completions, agent runs and review comments are all data about people, and in most of Europe the law gives the people concerned a body that speaks for them before such a tool is introduced. This chapter sets out what must be informed, consulted or agreed before developer tooling and its telemetry are used, where the monitoring of developers ends, what employment terms the change touches, who owns what a developer produces with AI, and what a collective agreement on developer tooling contains. It concerns D3 Build, because the telemetry is generated by the act of writing and directing code, and D5 Steward, because stewardship needs named owners and records, which is exactly where it meets the limits on monitoring.

The chapter argues that the two requirements are compatible if they are kept apart by design. Stewardship needs a record that says which named person owns a change and can explain and revert it (the tests Name, Understand and Revert of Chapter 4). Employee representation and data protection forbid turning the by-products of that record into a score of the person. The same field can serve both only when purpose, grain and access are written down and agreed. The chapter describes obligations and good practice. It does not describe any way of avoiding or defeating the rights of representatives, and it is not legal advice.

From information to agreement on developer tooling: the steps of dialogue and the limits fixed in the agreement

Figure 22.1: From information to agreement on developer tooling: the steps of dialogue and the limits fixed in the agreement.

What the earlier volumes settle

Five conclusions of the earlier volumes carry this chapter, and each is summarised so that the chapter stands alone.

AI Boss settled that AI may direct work but may not, on its own, decide about people, and that Level 4 Autonomous is never used for the function that carries consequences for a named person (AI Boss, Chapters 4 and 33; F81) (167, Nordqvist, 2026). It settled that oversight of decisions about people must be measured and that contestability and transparency are designed in (AI Boss, Chapters 26 to 28; F84, F85). And it settled that monitoring and scoring of workers fall within co-determination and data-protection law, that German co-determination under BetrVG §87(1) no. 6 reaches almost every system that is objectively suitable for monitoring, that Swedish law obliges negotiation of important changes, and that agreements should govern classes of change and not software versions (AI Boss, Chapters 13 and 23; F86). AI Operations concluded that the charter recording response, rest, load and agent clauses is agreed first with employee representatives (AI Operations, Chapter 25; F151) (170, Nordqvist, 2026). AI Leader concluded that representatives' rights differ by country, that the leader's duty is mostly timing, and that an agreement is a better statement of limits than a policy, though the evidence that it improves outcomes is thin (AI Leader, Chapter 22; F175) (174, Nordqvist, 2026).

This chapter applies those conclusions to the people who build the software, and leaves the leaders' view of the dialogue to AI Leader, Chapter 22. Chapter 4 fixed the rule for this book: telemetry from coding tools is not a basis for rating or paying a named developer.

Information, consultation and co-determination

Europe has no single model of employee participation, but it has a common grammar of four degrees. Information means that the employer hands over what representatives need to examine a subject. Consultation means a dialogue before the employer decides. Negotiation means that the employer must seek agreement but may decide when none is reached. Co-determination means that the employer may not act without agreement or a substitute decision by a conciliation body or a court. The table states what the instruments grant for the two organisations of this book, not what an agreement may add.

Instrument Strongest right relevant to developer tooling Trigger in the text
Germany, Works Constitution Act (BetrVG) Co-determination; the conciliation committee decides if the parties do not agree (§87(1) no. 6 and §87(2)) Technical equipment intended to monitor behaviour or performance
Germany, BetrVG §90(1) no. 3 and §90(2) Information in good time and consultation on planned work procedures and workflows, "including the use of artificial intelligence" Planned use of AI in work procedures, not limited to high-risk systems
Sweden, Co-determination in the Workplace Act (MBL) Duty to negotiate before deciding (§11); negotiation at the union's request also in cases outside §11 (§12) Important change in the activity or in members' working or employment conditions
Netherlands, Works Councils Act (WOR) Consent of the works council (Article 27(1)(k) and (l)) Rules on personal data of employees; facilities for observing or checking attendance, conduct or performance
European Union, Directive 2002/14/EC Information and consultation "with a view to reaching an agreement" (Article 4(4)(e)) Decisions likely to lead to substantial changes in work organisation or in contractual relations
European Union, Directive 2009/38/EC Information and consultation of the European Works Council on transnational matters Matters concerning the whole group or at least two Member States
European Union, AI Act Article 26(7) Information of workers' representatives and affected workers before use A deployer that is an employer, before using a high-risk AI system at the workplace

The German provisions are those of the Act as opened for the series (9, Germany, n.d.), and the wider provisions on information and consultation are those of sections 58, 76, 77, 80, 90, 95 and 111 (148, Germany, n.d.); the Swedish ones are MBL sections 11 and 12 (10, Swedish Parliament (Sveriges riksdag), 1976); the Dutch ones are Article 27(1)(k) and (l) of the WOR (149, Kingdom of the Netherlands, n.d.). Directive 2002/14/EC sets the floor of information and consultation and allows Member States more favourable arrangements (13, European Union, 2002). For a Community-scale group the European Works Council has rights on transnational matters (147, European Union, 2009). AI Leader, Chapter 22, sets the instruments out in full for the leader's assistants, and the same reading applies here. The AI Act row needs a developer-specific comment.

Which rights a coding assistant reaches

A coding assistant that suggests the next line is, in the AI Act's terms, usually not a high-risk AI system. Annex III, point 4(b), lists among high-risk uses AI systems intended to make decisions affecting the terms of work-related relationships, promotion or termination, to allocate tasks on the basis of individual behaviour or personal traits, or to monitor and evaluate the performance and behaviour of persons in such relationships (1, European Union, 2024). A completion engine is not intended for that purpose. This is the book's reading and counsel confirms it for a given tool. The consequence is that the information duty of Article 26(7) does not attach to the assistant itself, and Regulation (EU) 2026/1744 postpones the deployer obligations for Annex III systems to 2 December 2027 in any case (5, European Union, 2026). The national rights are the operative ones now.

The position changes if the telemetry is turned to an evaluative use. A dashboard that ranks developers by acceptance rate and feeds an appraisal is a tool for monitoring and evaluating performance. It then falls within the national co-determination rights whatever the vendor calls it, and it moves towards Annex III, point 4(b). That is a second reason, beside the rule of Chapter 4, for fixing the exclusion in the agreement and in the tool's configuration: a configuration that cannot produce the ranking leaves no question about which regime applies.

In Germany the question is not whether the assistant was intended to monitor: the wording of §87(1) no. 6, read as objectively suitable to monitor, reaches a tool that logs prompts and acceptances per user (167, Nordqvist, 2026), and §90 adds a duty to inform and consult on planned AI in work procedures whatever the purpose (148, Germany, n.d.). In the Netherlands the consent right attaches to facilities suited to observe conduct or performance. In Sweden the question is whether the introduction is an important change in members' working conditions.

Trigger points in the life of a coding tool

The decisive practical point is when the duty arises. Developer tooling reaches an organisation in at least five ways, and each has its own trigger. The table gives the trigger, who holds the sequence and the point at which the information must have been handed over.

Trigger Typical form Who holds the sequence Information due
Licence or pilot A seat for 12 developers, a trial of an agent Head of development, with the CIO Before the first real use on real work
Vendor update An IDE update switches on completion by default Platform team, by configuration Before the update is accepted into the managed image; the default is set off until the decision is recorded
Telemetry switch-on A dashboard or an export of prompts and acceptances is enabled Platform engineer and data protection officer Before the first collection, with the description of fields, grain, retention and readers
Mandate change A coding agent gains a task class or a repository Tech lead as owner of the mandate By change class, as agreed
Evaluative use A figure from the tool is proposed for a team goal, an appraisal or a pay discussion Engineering manager and HR Never as a use of tool data on a named person (Chapter 4); a team goal needs the class to be agreed

A pilot is use. A pilot with real developers on real work is the introduction of the system for the purposes of the rights above, whatever the label. A short test that touches no employee data may fall outside them, but that is a conclusion to reach with the representatives or counsel and to record, not an assumption. A vendor update is not an exception: the ambient completion that the IDE vendor switched on in March 2030 at Nordvik Region arrived before any decision was recorded (AIDR-1102), and the retrospective record is the evidence that the sequence was wrong, not that the change was harmless. The control is technical and cheap. The managed IDE image takes updates through the platform team, and a new AI feature stays off until its decision is recorded and the representatives have the document set.

The document set

The information is a document set and not a presentation. For a coding tool the set contains: the purpose and the usage mode; the tool's identifier and provider, with the contract number and its clauses on training, processing location and notice of model changes; the delegation profile DLG-* with the ceilings per class of work; the mandate manifest MND-* where an agent is concerned; a telemetry description, which states each field collected, the grain at which it is stored and reported, retention and who may read it; the data flows, including what leaves the organisation in a prompt; the data protection impact assessment where there is one; and the way the tool changes over time. Representatives in Germany may call in an expert where they must assess AI, which the Act treats as necessary in that case (§80(3)) (148, Germany, n.d.). A schedule that has no room for the expert is a schedule for being late.

Practical guide: preparing a consultation file on a coding assistant with a telemetry description

Purpose. Hand the representatives, before first use, a file from which they can study the tool, its telemetry and its limits, and which becomes the basis of the agreement.

Roles. The head of development (owner of the use); the tech lead of the pilot team; a platform engineer who can read the gateway and the logs; the HR director or chief HR officer, who holds the dialogue; the union IT representative or the chair of the works council, and their expert; the data protection officer; counsel on the national law.

Inputs. The delegation profile; the contract; the provider's documentation; the gateway configuration; a sample of the logs the tool produces, with personal fields masked; the list of people whose work the tool reaches, with the employer of each (employees, consultants, supplier staff).

Steps.

  1. List who is affected and which body holds which right, including the European Works Council where the tool is group-wide. Separate employees from consultants and supplier staff, whose terms follow from contracts (see the section on employment terms below).
  2. Write the telemetry description field by field. For each field state why it is collected, the grain (event, person, team), where it is stored, retention and the roles that can read it. Mark each field as needed for operation, needed for stewardship or needed for an adoption claim. A field with no purpose is not collected.
  3. Fix the grain of every report before the first collection: by team, with a minimum group size of 5, never by named developer. Say where the technical enforcement sits, preferably in the gateway or the export and not in a policy.
  4. Say what the data may not be used for: rating, pay, promotion, discipline, access to work and the ranking of named developers. State that raising a ceiling of delegation or adding a field is a change that needs the representatives' agreement.
  5. Describe the stop path: who can switch the tool or the telemetry off, how fast, and that the mechanism sits outside the tool.
  6. Send the file before anything is switched on, with an offer to fund the expert and a proposed date for the first meeting. Record the date of dispatch.
  7. Record the result as an AI Decision Record, and file the telemetry description and the agreement in version control next to the mandate manifest and the delegation profile.

Result. A dated consultation file, a telemetry description in version control and an AI Decision Record.

A telemetry description is short and mechanical. The sample below is illustrative.

# governance/telemetry/NR-DEV-001.yaml (illustrative)
tool: NR-DEV-001
owner: Gunilla Roos            # accountable for use
collected_by: ai-gateway       # not by the IDE plug-in
fields:
  - {name: timestamp,      purpose: operation,   grain: event,  retention_days: 180}
  - {name: team,           purpose: operation,   grain: team,   retention_days: 180}
  - {name: repository,     purpose: stewardship, grain: event,  retention_days: 180}
  - {name: tool_id_model,  purpose: operation,   grain: event,  retention_days: 180}
  - {name: token_count,    purpose: operation,   grain: team,   retention_days: 180}
  - {name: suggestion_accepted, purpose: adoption_claim, grain: team, retention_days: 90}
not_collected: [prompt_content, completion_content, keystrokes, user_id_in_reports]
reports:
  to: [head of development, platform team, union IT representative]
  grain: team
  minimum_group_size: 5
  named_developer: never
prompts: not retained until MBA-NR-2030-03 is concluded
readers: [platform team on-call, data protection officer]
stop: "platform team switches the gateway route off; effect Level 0 at once"

Telemetry and monitoring of developers

Developer tooling produces four kinds of record, and they differ in what they say about people. A usage record says that a tool was called: time, team, repository, model and token count. A suggestion record says what was proposed and what was accepted. A content record keeps the prompts and completions. A run record (RUN-*, Chapter 8) says what an agent did on a task within a mandate. A fifth record, the review record (RVW-*, Chapter 9), names who read a change and what they found. The first and fourth are about the system. The second is about the system and, if stored per user, about the person. The third is about the person's thinking, in the sense that a prompt shows what the developer did not know or tried first, and it may contain colleagues' personal data and secrets. The fifth must name people, because accountability for a change is accountability of someone.

What the law bounds

The law does not forbid collecting these records. It bounds the purpose, the grain and the process. The GDPR's principles apply to any personal data in them, and Article 88 allows Member States, by law or collective agreement, to lay down more specific rules for the processing of employees' personal data in the employment context, with suitable and specific measures for transparency and for monitoring systems at the workplace (4, European Union, 2016). The Court of Justice held in Case C-34/21 that a national rule cannot count as a more specific rule under Article 88(1) if it does not meet the conditions of Article 88(2), and that a provision that does not must in principle be disregarded; the rule must have normative content specific to the employment context and cannot merely repeat the general rules (151, CJEU, 2023). The practical lesson for an agreement is that it should say something specific about developers' data and not restate the Regulation. A collective agreement is a lawful place to put the data rules, and it is the place where a statement such as "no prompt content is retained" can be tested.

The measurement problem is also a monitoring problem

Monitoring of developers has a persistent temptation: the tool produces numbers, and numbers look like performance. Two observations from the series' own material and from the research argue against it, and both belong in a consultation.

The first is that the numbers do not measure what they are taken to measure. The SPACE framework starts from the point that developer productivity cannot be measured by a single metric or dimension and needs several (62, Forsgren et al., 2021). An acceptance rate is an activity metric about a suggestion; it says nothing about whether the code stayed, passed review or was understood. In the randomised trial of Becker and colleagues, 16 experienced open-source developers completed 246 tasks, each randomly assigned to allow or disallow early-2025 AI tools; allowing AI increased completion time by 19 per cent. The developers had predicted a reduction of 24 per cent beforehand and estimated a reduction of 20 per cent afterwards (63, Becker et al., 2025). The study is small, concerns experienced developers on mature projects they knew and early-2025 tools, and says nothing certain about other settings. Its relevance here is narrower and secure: developers' own impressions of a tool's effect, and by extension a tool's own counters, can point in a different direction from a measured outcome. A rating built on such counters rests on a figure that the series' evidence says may mislead.

The second is that the series already holds two examples. Nordvik's "a third faster" rested on an acceptance rate of 31 per cent for 12 developers and a survey answered by nine (AVR-NR-2030-01). Hansa's "42 per cent AI-assisted" counted accepted suggestions as a share of committed lines, against 27 per cent in a sample of 40 merged pull requests (AVR-HM-2030-01). Chapter 20 treats such claims. For this chapter the point is the use of the figure: both numbers came from telemetry, and a figure of that kind that moves from a dashboard to a team goal, and from a team goal to an appraisal conversation, becomes a decision about a person on evidence that was never designed for it.

Naming for stewardship, not for scoring

The stewardship principle needs names. The code-ownership record (OWN-*) names a team and a lead, the review record names the reviewer, and the agent run record carries the task reference and the owner of the mandate. None of that is a score. The distinction is of purpose and grain, and the agreement can state it in four rules.

  1. A record names a person for a change, not for a rate. The review record says that Joakim Wester read this pull request and explained it. No report says that he explained 4.1 pull requests a week.
  2. Reports to managers and to the organisation are by team. The minimum group size is 5, following the practice that the SOC annex of AI Blue and the operations annex of AI Operations already use (168, Nordqvist, 2026) (170, Nordqvist, 2026).
  3. Person-level data is read only for the purpose it was collected for. A review record is read to trace a defect, an incident review reads the run record, and the data protection officer reads logs on a complaint. Access is logged and the log is reported in aggregate to the representatives.
  4. Prompts are not retained unless the agreement says so. If retention is needed, for incident analysis for example, the agreement sets the class of prompts, the period and the readers, and the developer is told.

Where monitoring ends

The exclusions are plain and belong in the agreement as a list. Telemetry from coding tools is not used to rate, pay, promote, discipline or select a named developer; not to rank developers or teams against one another; not to infer working hours, attention or mood; not to profile a developer's skill from their prompts; and not as the first source in a performance conversation. Where an incident review needs to establish what a person did with a tool, it does so by a defined route with the representatives informed, and not by browsing the logs. The book does not describe, and the series excludes, covert monitoring of staff and any approach that works around the representatives' rights. If a manager wants a figure from the tool for a team goal, the route is Chapter 20: a claim with scope, method, date and result, agreed at team level and reviewed when its evidence expires.

Employment terms

The introduction of AI into development changes working conditions in ways that do not all show up in telemetry. This section lists the terms an agreement or a consultation should address. Whether each is a matter of information, consultation or negotiation depends on the national instrument and the facts, and the chapter states them as questions to put to representatives and counsel.

Roles and grading. The role charters of the book (ROLE-NR-DEV-01 for a senior developer and ROLE-NR-DEV-02 for a junior, and the Hansa equivalents) change content: more specification, review and stewardship, less first-draft writing (Chapters 13 and 14). A role description that changes materially is a change in the conditions of the people who hold the role. In Sweden it is a candidate for negotiation under MBL §11 as an important change in members' working conditions (10, Swedish Parliament (Sveriges riksdag), 1976). In Germany a changed work organisation falls within the information and consultation duty of §90 (148, Germany, n.d.). The charter should be drafted with the representatives and say what the role does not become, for example that review is not added to a developer's tasks without time for it.

An obligation to use the tool, and a right not to. A requirement to use an assistant for a share of the work, or an adoption target set for a team, is a statement about how work is done. This is the book's reading: such a requirement is a change in work organisation that belongs in the consultation, and a target expressed as a share of AI-assisted lines is exactly the kind of figure that Chapter 20 warns against. The agreement should say whether use is expected, encouraged or optional, and what happens to a developer who has a professional reason, such as the security class of the code or a legacy estate where the tool performs poorly, to work without it. The ownership of that reason is the developer's and the tech lead's, written in the specification record, not a performance matter.

Time, training and the effect of time saved. The AI Act's Article 4 requires providers and deployers to take measures to support the AI literacy of their staff, in the form replaced by Regulation (EU) 2026/1744, and does not require a specific level for any individual (5, European Union, 2026). The employment question is how much paid time a developer gets to learn, to practise without the tool and to review generated code with care. Chapter 27 treats competence. The agreement should record the hours, the rule that training time is working time and, where the organisation expects a saving, what is done with it. The series has no verified evidence that a time saving reaches a team as capacity, and the agreement should not assume it.

Consultants and supplier staff. Nordvik Region has about 22 consultant developers inside its teams under framework agreement NR-2025-102, and Hansa Mutual about 190 external developers, mostly from the nearshore partner Wiślana Software. Their employer is the supplier, and the organisation's works council has no right over them as employees of the supplier. The telemetry of their tool use is, however, collected by the organisation's gateway, and their data is personal data. This is the book's reading: the framework agreement needs a clause on AI tools and on telemetry, matched to the agreement with the organisation's own employees, and the supplier's own representatives are informed by the supplier. The incident of March 2030 at Nordvik (INC-NR-2030-0071), where a consultant pasted a connection string into an unapproved public chat assistant, happened under a framework agreement that had no clause on AI tools. The gap was contractual before it was technical.

Ownership of output

The question "who owns what a developer produces with AI" splits into three, and only the first belongs to employment law in the narrow sense.

The employer's right in the program. Directive 2009/24/EC on the legal protection of computer programs provides in Article 2(3) that where a computer program is created by an employee in the execution of duties or following the employer's instructions, the employer exclusively is entitled to exercise all economic rights in the program so created, unless the contract provides otherwise (20, European Union, 2009). Member States have implemented the rule in their own copyright law, and the terms of implementation differ; counsel confirms the national text for a given employee. The consequence for developers is that code written in the course of their work, with or without a coding assistant, is the employer's to exploit, and that an assistant does not move the line between work for the employer and the developer's own time. The line that matters is the one the contract draws: code written on the employer's time and systems, for the employer's task, with the employer's licensed tool.

What AI contributes. Whether a generated passage is protected by copyright, who the author is, and whether a suggestion reproduces licensed code are questions for Chapter 26. The employment point is only that the employer's right in the program covers what the employee created. The employment contract, the developer's work instructions and the policy should say that the employer's right follows the program as committed, including the generated parts, and that the developer is not expected to warrant what the tool produced beyond the duties the stewardship principle gives them: to name an owner, to understand the change and to be able to revert it. The consequence for a licence problem found later is a matter of process, not of blame, and Chapter 23 treats it.

What stays with the developer. The developer's skills, general know-how and professional reputation are not the employer's property, and a prompt history is not a work product to be mined for them. Three practical questions follow and belong in the agreement or the policy: whether a developer may use a personal account of an AI service for work (the answer for the series is no for code and data of the organisation, which the gateway enforces); whether prompts and conversations are the employer's records, with the retention rules above; and whether a developer's contribution to open source, in work time or private time, with or without an assistant, needs the employer's consent, which is a contract term that exists already and that AI use makes more frequent.

An agreement can also state, because representatives often ask, what the organisation does not do: it does not use developers' prompts or code to fine-tune a model without a decision recorded as an AI Decision Record and information to the representatives, and its contract with the provider must exclude training on the organisation's code. Hansa's contract with CodeMeridian (HM-PROC-AIDEV-2029-01) has that clause and a notice period of 30 days for model changes; the model change notice is itself a trigger for the change-class process below.

Collective agreements

An agreement on developer tooling should be shorter than a policy and harder to ignore. The experience of the series is that two design decisions decide whether it works.

It follows the mandate and the delegation profile, not the product. Coding tools change monthly: a new model, a new feature, a new default. An agreement written about a product version is out of date at the next release. An agreement written about classes of change is not. As in AI Leader, Chapter 22, and AI Boss, Chapter 23, the agreement defines classes by what changes for the people affected: changes that need the representatives' consent or negotiation (a higher level of delegation, a new field of telemetry, a person-level report, any use in a people decision); changes approved within agreed bounds by a joint committee with a notice period (a new model version that has passed the agreed tests, a new task class within a mandate); and changes of which the representatives are only informed (a defect fix, a security patch, a field removed). Doubt moves a change up a class, and the representatives may reclassify upwards. The agreement is tested against the last releases of the tool before signing: if one of them cannot be placed in a class, the classes are wrong.

It has a review with an evidence date and triggers. Agreements that are not reviewed outlive the tool they were written for. In Germany, an expired works agreement continues to apply, in matters where a conciliation award could replace agreement, until another arrangement replaces it (§77(6) BetrVG) (148, Germany, n.d.), which is a reason to write a review date and to treat it as a date. The review should be tied to events: a failed stop test, a change of provider, a new law (the Annex III obligations on 2 December 2027), or a result of the stewardship checks that shows the Understand test failing.

How agreements nest

Both organisations already have agreements. Nordvik has MBL-NR-IT-2027-01 on operations tooling, which says a tool that logs engineers' queries or commands is negotiated before it is switched on, and MBA-NR-2029-02, which does not cover coding tools. Hansa has the group agreement KBV-IT-2024 with operations annexes -OPS-01 to -03 and SOC annexes -SOC-04 and -SOC-05. The task is to attach a developer annex to the existing structure, not to start a new one. At Hansa the group works council is competent for matters that concern the group or several group companies (§58(1) BetrVG), the local Betriebsrat in Hamburg gave the interim agreement under which the assistant was introduced, and the Polish and Dutch representatives have asked for the same terms. The Dutch works council has its own consent right (WOR Article 27), and the European Works Council is informed of transnational matters. The annex therefore states its scope by group company and puts the common terms in one place, so that the Polish and Dutch bodies can adopt them by their own procedure and not by a decision made for them.

The evidence that agreements help

The series states plainly what it does not know. AI Leader looked for independent studies that measure the effect of employee representation on the outcome of AI adoption and found none that could be opened and verified (AI Leader, Chapter 22) (174, Nordqvist, 2026). This chapter has not found one for developer tooling either. The case for an agreement is an argument from mechanism and is this book's own conclusion: an agreement forces the organisation to write down what it intends and what it will not do, a requirement that exists can be tested, and the representatives' knowledge of where the work really goes wrong reaches the owner earlier. The European social partners' 2020 framework agreement on digitalisation asks for control of humans over machines and for a joint process of exploration, mapping, strategy and assessment (150, BusinessEurope et al., 2020); it is not law and not evidence of effect.

An agreement outline

The outline below is for the developer annex at Hansa Mutual. It is illustrative and is not the signed text. It keeps the telemetry rules of Chapter 8 (by team, minimum group size 5, never by named developer) and the people rule of Chapter 4.

# agreements/KBV-IT-2024-DEV-01.yaml (illustrative outline, not the signed text)
agreement: KBV-IT-2024-DEV-01
title: Developer-tooling annex to the group works agreement on IT systems
parent: KBV-IT-2024
parties: [Hansa Mutual group management, Konzernbetriebsrat]
status: negotiating            # opened 2030-10-14
decision_record: AIDR-1172
legal_basis_de: [BetrVG 87(1) no. 6, BetrVG 90(1) no. 3, BetrVG 90(2), BetrVG 58(1)]
informed: [local_betriebsrat_hamburg, polish_representatives, ondernemingsraad_nl, ewc]
scope:
  tools: [HM-DEV-001, HM-DEV-002, HM-DEV-003]
  mandates: [MND-HM-DEV-01, MND-HM-DEV-02]
  profile: DLG-HM-DEV-01
  new_versions_in_scope: true          # follows the mandate, not the release
  external_developers: framework HM-PROC-DEV-2026-02 amended to match
excluded_uses:
  - rating, pay, promotion, discipline or selection of a named person
  - ranking of developers or teams by acceptance rate or agent usage
  - inference of working hours, attention or mood
telemetry:
  grain: team
  minimum_group_size: 5
  named_developer: never
  prompts_retained: false              # exception only by class 3 consent
  person_level_access: [incident review route, data protection officer on complaint]
  access_log_reported_to: Konzernbetriebsrat, aggregate, quarterly
change_classes:
  class_1_consent: [higher level of delegation, new telemetry field, person-level report, use in a people decision]
  class_2_joint_committee: {notice_working_days: 10, includes: [model version passing agreed tests, new task class within a mandate]}
  class_3_information: [defect fix, security patch, field removed]
reclassification: representatives may raise a class; employer may not lower one
use_of_tool: optional by default; reasons to work without it recorded in the SPC-* record, not in appraisal
training: {paid_working_time: true, practice_without_tool: true}
ownership: employer holds the rights in programs created in duty (national law applies); personal AI accounts excluded
expert: {basis: BetrVG 80(3)}
stop: {who: [owner, reviewer, Konzernbetriebsrat chair], path: Hansa Forge gateway, effect: Level 0 at once}
review: {due: 2031-09-30, triggers: [failed stop test, provider change, Annex III obligations 2027-12-02]}
disputes: standing conciliation committee under BetrVG 76(1)

Across the degrees of delegation

The agreement is the place where the delegation profile meets the people concerned. For each class of work the table says what the representatives should see and what stays outside the tool.

Level Typical class in the two profiles What the representatives receive What is fixed in the agreement
Level 0 Advisory Design, review, operate, migrate in both profiles; deploy by the pipeline Description of the tool and its data flows No telemetry beyond usage by team; an AI comment never counts as the human review
Level 1 Assisted Generate and refactor at Nordvik; test drafts at both Telemetry description, ceilings, stop path Suggestions accepted by the developer; no per-person acceptance report
Level 2 Supervised Generate and refactor outside the security-critical and payment paths at Hansa; documentation at both Mandate manifest, run record fields, review rules Pull requests read by a named developer; run record about the agent, not the engineer
Level 3 Bounded One class at Hansa: patch-level dependency updates (MND-HM-DEV-01) Class approval, pipeline checks, rollback Change to the class is class 1 consent; the class is dropped one level if evidence lapses
Level 4 Autonomous Not used Statement of the prohibitions Never for production change without an unalterable gate, security-critical code without a named reviewer, the agent's own mandate, gates or oracles, irreversible production data, or a decision about a named person's employment, pay, performance rating or access to work

The people class is not delegated at either organisation, and the last row of the table is the one a representative can check most easily: the tool's configuration either has no report that a manager could use that way, or it has.

Nordvik Region and Hansa Mutual

Nordvik Region must inform and negotiate with the unions before an important change (MBL §11) and the union branch for IT staff has an IT representative, Tomas Ekblad, who asked in June 2030 to negotiate before the pilot of NR-DEV-001 was extended. MBL-NR-IT-2027-01 already covers operations tooling and says that a tool that logs engineers' queries is negotiated before it is switched on. The negotiation record MBA-NR-2030-03 on developer tooling and telemetry was opened in September 2030. Pending its conclusion the gateway records metadata only, and no prompt content (AIDR-1116, Chapter 16). In this chapter the CIO records, in AIDR-1122 (dated 2030-12-09), that the extension of the pilot beyond 2030-12-31 will follow an interim protocol with the union (signed on 2030-12-12), and that the next step, from 12 developers to the further developers of Applications and Integration, waits for the review of the record. The ceilings of DLG-NR-DEV-01 are annexed. The instrument is negotiation, not co-determination, and the lever is timing.

# negotiation/MBA-NR-2030-03.yaml (illustrative)
record: MBA-NR-2030-03
subject: Developer tooling and telemetry
opened: 2030-09-15
parties: [Nordvik Region, union branch for IT staff]
representatives: [Tomas Ekblad, Birgitta Almqvist]
basis: MBL 11 and 12
interim_protocol: {date: 2030-12-12, covers: NR-DEV-001, valid_until: 2031-06-30}
decision_record: AIDR-1122
agreed_so_far:
  telemetry: [metadata only via the AI gateway, by team, minimum group size 5]
  prompts_retained: false
  excluded_uses: [rating, pay, discipline, ranking of named developers]
open: [retention of prompts for incident analysis, consultants under NR-2025-102, use-of-tool statement]
next_meeting: 2031-01-22

The open items show what the Region's profile lacks. The framework agreement NR-2025-102 has no clause on AI tools, and about 22 consultant developers work in the teams. The inventory of repositories finds 31 per cent with a departed owner (OWN-NR-2030-00), so the names that stewardship needs are not yet in place for every repository; the negotiation should not wait for them, and the agreement says by what date the records exist.

Hansa Mutual co-determines under BetrVG §87(1) no. 6. The IDE assistant HM-DEV-001 was rolled out in January 2030 under an interim agreement of the local Betriebsrat in Hamburg, and the Polish representatives and the Dutch ondernemingsraad were informed later and have asked for the same terms. The sequence was therefore the wrong way round for two of three bodies, and the Dutch consent right under WOR Article 27 makes the remedy a matter of obtaining consent for something already in use. The annex KBV-IT-2024-DEV-01 has been drafted since autumn 2030. In AIDR-1172 (dated 2031-01-27) the group CIO, Rainer Lehmann, records that the terms of the interim agreement (no report by named developer, no use of acceptance rates in appraisal or pay) apply in all group companies from that date pending signature, that the licences for HM-DEV-001 are not extended beyond 340 and the agent pilot (MND-HM-DEV-02) is not widened before the annex is signed, and that the chief HR officer, Marlene Voss, holds the dialogue with the Konzernbetriebsrat chair, Thomas Brandt. The decision is not a substitute for the agreement. It narrows the gap between practice and the rights while the agreement is negotiated.

Summary

This chapter concerned D3 Build and D5 Steward. Developer tooling brings telemetry with it, and telemetry is data about people. The rights of representatives attach early: in Germany to technical equipment that is objectively suitable for monitoring (BetrVG §87(1) no. 6) and to planned AI in work procedures (§90); in Sweden to important changes in members' working conditions (MBL §11); in the Netherlands to facilities for observing conduct or performance (WOR Article 27(1)(l)); in the European Union to information and consultation (Directive 2002/14/EC) and, for transnational matters, to the European Works Council. A coding assistant is normally not a high-risk AI system under Annex III, so the national rights are the operative ones, but the same telemetry turned into an appraisal tool would be.

The leader's duty is timing. A pilot is use, a vendor update is a trigger, and the telemetry switch-on is its own trigger. The consultation file contains the tool, the delegation profile, the mandate and a field-by-field telemetry description. Stewardship needs names for changes, not scores for people: reports are by team with a minimum group size of 5, person-level data is read only for the purpose it was collected for, prompts are not retained unless an agreement says so, and tool data is not used to rate, pay, promote or select a named developer. The research supports the caution: productivity is not measured by a single metric, and in one randomised trial developers' predictions and estimates of a tool's effect pointed in the opposite direction from the measured result.

Employment terms need attention beyond telemetry: role charters, expectations of use, paid time for training and practice without the tool, and the position of consultants and supplier staff. The employer holds the economic rights in programs created by employees in the execution of their duties unless the contract provides otherwise (Directive 2009/24/EC, Article 2(3)), subject to national implementation; questions about copyright in generated code are for Chapter 26. A collective agreement follows the mandate and the delegation profile, classifies changes by their effect on people, has a review with triggers and a stop path outside the tool, and fixes the Level 4 prohibitions. The evidence that such agreements improve outcomes is thin, and the argument for them is the book's own conclusion from mechanism: they force the intent to be written down, make it testable and bring the representatives' knowledge in earlier. Chapter 23 turns to what happens when AI-involved changes break.

Sources

  1. 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, 12 July 2024. (1, European Union, 2024)
  2. European Parliament and Council of the European Union. (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (4, European Union, 2016)
  3. European Parliament and Council of the European Union. (2026). Regulation (EU) 2026/1744 (Digital Omnibus on AI). Official Journal of the European Union, 24 July 2026. (5, European Union, 2026)
  4. Federal Republic of Germany. Betriebsverfassungsgesetz (BetrVG), section 87. gesetze-im-internet.de. (9, Germany, n.d.)
  5. Swedish Parliament. Lag (1976:580) om medbestämmande i arbetslivet, sections 10 to 12. (10, Swedish Parliament (Sveriges riksdag), 1976)
  6. European Parliament and Council of the European Union. (2002). Directive 2002/14/EC establishing a general framework for informing and consulting employees. (13, European Union, 2002)
  7. Forsgren, N. et al. (2021). The SPACE of Developer Productivity: There's more to it than you think. ACM Queue 19(1). (62, Forsgren et al., 2021)
  8. Becker, J., Rush, N., Barnes, E. & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089. (63, Becker et al., 2025)
  9. European Parliament and Council of the European Union. (2009). Directive 2009/38/EC on the establishment of a European Works Council (recast). (147, European Union, 2009)
  10. Federal Republic of Germany. Betriebsverfassungsgesetz (BetrVG), sections 5, 58, 76, 77, 80, 90, 95 and 111. (148, Germany, n.d.)
  11. Kingdom of the Netherlands. Wet op de ondernemingsraden (WOR), Articles 25 and 27. (149, Kingdom of the Netherlands, n.d.)
  12. BusinessEurope, SMEunited, CEEP and ETUC. (2020). European Social Partners Autonomous Framework Agreement on Digitalisation. (150, BusinessEurope et al., 2020)
  13. Nordqvist, G. (2026). AI Boss. The Architecture as Code Series, Book 7. (167, Nordqvist, 2026)
  14. Nordqvist, G. (2026). AI Operations. The Architecture as Code Series, Book 10. (170, Nordqvist, 2026)
  15. Nordqvist, G. (2026). AI Leader. The Architecture as Code Series, Book 11. (174, Nordqvist, 2026)
  16. European Parliament and Council of the European Union. (2009). Directive 2009/24/EC on the legal protection of computer programs (codified version). Official Journal L 111, 5 May 2009. (20, European Union, 2009)
  17. Court of Justice of the European Union. (2023). Case C-34/21, Hauptpersonalrat der Lehrerinnen und Lehrer beim Hessischen Kultusministerium v Minister des Hessischen Kultusministeriums, judgment of 30 March 2023. ECLI:EU:C:2023:270. (151, CJEU, 2023)
  18. Nordqvist, G. (2026). AI Blue: How Artificial Intelligence Transforms the Blue Team. The Architecture as Code Series, Book 8. (168, Nordqvist, 2026)