Ethics, Professional Responsibility and the Developer's Judgement

Law tells a developer what the organisation must do and must show. It does not tell a senior developer whether to build the feature that product management has specified and counsel has cleared, what to write in a pull request when an assistant produced most of it, or what to do when a colleague's generated change reaches production without anyone having read it. Chapter 24 mapped the duties that the instruments place on named parties. This chapter starts where that map ends: at the decisions that nobody has regulated and that somebody still has to take. It concerns three of the five developer functions. D1 Frame is where a value first meets a requirement, because the problem a team chooses to solve and the people it chooses to count are fixed there. D2 Design is where a value becomes a constraint that every later change, generated or typed, must respect. D5 Steward is where the developer who owns the software answers for it, and where the authority to stop, to decline and to report is used or is not.

The chapter ends with an artefact that turns three of an organisation's values into engineering rules that a pipeline, an oracle or a reviewer can check, with evidence that expires.

Figure 25.1: From value to rule to evidence. Law and professional codes bound the rules, a named value is made checkable as a rule, a check outside the generator produces evidence that a forum reviews, and a case the rules do not cover goes to the developer's judgement, then to ask, record and escalate, then if necessary to a recorded refusal and a report outside the line.

What the series has already settled

Four conclusions of the earlier volumes carry this chapter. Architecture as Code (Chapter 20) concluded that some decisions stay with people whatever the agents propose, and that every decision is linked to a commit, a pull request and an accountable individual (F13) (161, Nordqvist, 2025). AI Governance, Chapter 17, concluded that in a public authority legality comes before capability, that the line between decision support and automated decision is drawn in the data model and the audit log, and that every case has a reasons log (F31) (162, Nordqvist, 2026). AI Boss concluded that contestability and transparency are designed in, and that the quiet harms of algorithmic management, to autonomy, dignity and the willingness to speak, deserve attention before the loud ones (F85 and F89, Chapters 11, 13, 14, 27 and 28) (167, Nordqvist, 2026). AI Leader, Chapter 25, concluded that law states a floor and a process, that four values recur in the decisions of a leader (fairness, dignity, honesty and care), that they conflict without a fixed solution, and that the delegation ladder gains a question: which value does a decision put at stake, and can the test run outside the system? Where it cannot, the ceiling is lowered (F178) (174, Nordqvist, 2026).

Chapter 4 turned the answerability principle into the stewardship principle: AI may draft, generate, refactor and, within a mandate, execute; it may not own. This chapter adds a conclusion of the book's own: the tests Name, Understand and Revert are necessary for an ethical change and not sufficient. An owner can be named, can explain the change and can revert it, and the change can still be unfair to the people it sorts, inaccessible to the people it is meant to serve, or dishonest about how it was made. The tests settle who answers. They do not settle what a good answer is.

Beyond compliance

The High-Level Expert Group on AI said in 2019 what the series has relied on since: many ethical principles are already reflected in legal requirements, but adherence to ethical principles goes beyond formal compliance with existing laws (105, AI HLEG, 2019). For a developer the gap shows in small decisions: a lawful requirement whose obvious implementation treats two groups of citizens differently, a compliant design that only people who can see a screen can use, a pull request accurate in every line and silent that an agent wrote it.

Three values recur in a developer's working day, and the chapter treats them as working categories. They are the book's own selection, not a list taken from a single source, and each is given below a rule and a check.

Fairness concerns who is counted, sorted or priced by what the software does: like cases are treated alike, and a person affected can contest the outcome and find a human who can change it. The first is built into code and tests, the second into the audit log and reasons log that AI Governance asked for.

Access concerns who can use what is built. It is the value most completely turned into law, and so the model for how a value becomes a rule.

Honesty concerns the developer's account of the work, to reviewers, colleagues, customers, upstream projects and the executive committee. Dignity and care, the other two values of AI Leader, Chapter 25, reach developers mostly through Chapters 13, 21 and 28.

Professional codes

Two professional bodies have long maintained codes that address developers by name or by implication. The Association for Computing Machinery adopted its current Code of Ethics and Professional Conduct on 22 June 2018 (260, Association for Computing Machinery, 2018). Its principle 1.2, on avoiding harm, defines harm as negative consequences, especially when those consequences are significant and unjust. It states that a computing professional has an additional obligation to report any signs of system risks that might result in harm, that if leaders do not act it may be necessary to "blow the whistle", and that capricious or misguided reporting can itself be harmful. Its principle 1.3 asks for transparency and full disclosure of pertinent system capabilities and limitations, and for honesty about one's own qualifications and the limits of one's competence (260, Association for Computing Machinery, 2018). The Institute of Electrical and Electronics Engineers revised its Code of Ethics in June 2020, adding high-level principles, a commitment to avoid harassment and a commitment to protect the privacy of others (262, Russell, 2020). The code commits members to hold paramount the safety, health and welfare of the public, to be honest and realistic in stating claims or estimates based on available data, to strive to ensure that the code is upheld by colleagues, and not to retaliate against individuals who report a violation (261, Institute of Electrical and Electronics Engineers, 2026).

Three observations follow.

First, a code binds the members of the society that wrote it, by membership, and does not bind an employer. It is not law and does not override a contract of employment. A developer who is not a member is not bound by it, and the sources read for this book show no European instrument that makes membership of either body a condition of working as a developer. The codes are nevertheless the most widely cited statement of what the profession says about itself, and an organisation can adopt them by reference in its role charters, as Chapter 14 shows for the professional-judgement clause.

Second, the evidence that a code changes behaviour is thin and not encouraging. Andrew McNamara, Justin Smith and Emerson Murphy-Hill replicated a behavioural-ethics study with 11 vignettes answered by 63 software engineering students and 105 professional developers. Participants told to consider the ACM code did not decide differently from a control group that was told only that ethics matter (263, McNamara et al., 2018). The study measured decisions on vignettes in a single sitting, not conduct at work over time, and it cannot say that codes are useless. It supports a narrower conclusion that is the book's own: a code that is read once is not a control. A value has to be turned into something a person meets at the point of work, and the rest of the chapter is about that step.

Third, the codes were written for a world in which the professional wrote the code, and the texts read for this book do not address a developer who directs an agent. The book's reading is that the obligations attach to the person who ships, whatever produced the lines: a developer who merges a generated change owns it in the sense of the Name test, and the duties to avoid harm, to be honest about capabilities and to report risks apply to what was merged. AI Threat, Chapter 11, collected what happens when an organisation lets an unexplained system sort citizens; the codes do not by themselves prevent such a failure. Structure is the book's answer, and structure is the subject of the section on values and rules below.

Refusing to build harm

The question that a developer will actually ask is narrower than "what is ethical". It is: may I decline to build this, and what happens if I do?

A case from the record

In August 2017 a federal court in the Eastern District of Michigan sentenced James Liang, an engineer who had worked in Volkswagen's diesel development department, to 40 months in prison and two years of supervised release. He had pleaded guilty to conspiracy to defraud the United States, to commit wire fraud and to violate the Clean Air Act, in the case of software that recognised when a car was being tested for emissions (264, United States Department of Justice & Office of Public Affairs, 2017). The case is cited for one narrow reason: it shows that a developer who writes code that implements a deception is a person against whom the law can proceed. It does not show what any individual at Volkswagen intended or was told, and the chapter does not claim it does.

Dual use and the escalation route

Most requests are neither the Volkswagen case nor harmless. Software can be dual use in the ordinary sense: a face-matching module serves access control and surveillance, a scoring function serves triage and exclusion. The book's conclusion is that the developer's response should be a ladder and not a switch, written down by the organisation before anyone needs it.

1. Ask. The developer asks the requester what the software is for, whom it affects and what the person affected can do about it. Many concerns end here, because the specification (D1 Frame) was incomplete and not wrong.
2. Record. The developer writes the concern and the answer in the specification record or the Architecture Decision Record (ADR) where the decision was taken. A concern that is not recorded did not happen, as far as the next owner is concerned.
3. Escalate. The developer takes the concern to the tech lead, then to the owner of the delegation profile, then to the forum that the organisation has named for it. In both organisations that is the AI governance route of AI Governance, Chapter 13, extended to development.
4. Decline. If the concern stands, the developer may decline to build the part concerned and says so in writing. The organisation commits in advance that declining on these grounds, once recorded, is not a performance matter and is not recorded against the person. The commitment belongs in the role charter and is agreed with the representatives of staff (Chapter 22).
5. Report. If the concern is a breach of law or a danger to the public and the line has not acted, the developer uses the internal reporting channel and, where the law provides, an external one (see Whistle-blowing below).

Whether a developer may lawfully decline an instruction without sanction depends on the contract, the collective agreement and national employment law, which the book does not state; the reader asks counsel and the works council or union. What the employer controls is a prior commitment, a written route and a record.

What changes when an agent is in the loop

An agent does not decline on grounds of conscience: a model generates and executes within a mandate and does not weigh a request against a value. The burden of refusal moves to the person who directs the agent and, one level up, to the mandate. The Level 4 prohibitions of the book are the mandate's refusals, written in advance: no change to production without a gate that the change itself cannot alter, no code in a security-critical or safety-critical path without review by a named developer, no change to the agent's own mandate, permissions, credentials, oracles, review rules or gates, no irreversible action on production data, and no decision about a named person's employment, pay, performance rating or access to work. The developer's right to stop a run without penalty belongs in the same charter as the right to decline.

Elish's moral crumple zone is the warning: in a system whose parts have owners and whose whole has none, responsibility tends to land on the person nearest the system (49, Elish, 2019). The developer who merges the agent's change is that person. The remedy from AI Leader, Chapter 12, is an accountability map that also names the owner of the review design, the grant of the level and the stop right, and not only the person who pressed merge.

Accessibility and inclusion as engineering rules

Accessibility is the clearest case of a value that has already become a rule, and it shows what a value needs in order to become enforceable.

For a public sector body, Directive (EU) 2016/2102 requires that websites and mobile applications be made accessible by making them perceivable, operable, understandable and robust (Article 4). Content that meets a harmonised standard is presumed to conform (Article 6), the body must publish an accessibility statement with a feedback mechanism through which any person can notify it of non-compliance (Article 7), and the requirements apply only so far as they do not impose a disproportionate burden, a derogation the body must explain in its statement (Article 5) (14, European Union, 2016). For services offered to consumers after 28 June 2025, Directive (EU) 2019/882, the European Accessibility Act, requires that economic operators provide only services that comply with its accessibility requirements, and exempts microenterprises providing services (Article 4(1) and (5)); its scope lists electronic communications, consumer banking, e-books and e-commerce, among others (Article 2) (17, European Union, 2019). Whether an insurer's customer portal or app falls within that list is a question for counsel (Chapter 24).

The evidence on the state of practice is sobering and is not specific to generated code. The WebAIM Million of February 2026 analysed 1,000,000 home pages with automated tools and found detectable failures against the Web Content Accessibility Guidelines (WCAG) 2 on 95.9 per cent of them, an average of 56.1 detected errors per page, and low-contrast text, missing alternative text and missing form labels as the most frequent failures (274, WebAIM, 2026). The study measured what automated detection sees on home pages. No study that the writer could verify compared the accessibility of AI-generated front-end code with hand-written code, and the chapter claims no direction. That automated checks find only part of what a person would find is the book's own point, not a finding of the report.

From these instruments three engineering rules follow, and each is checkable.

• The gate rule. The golden path (Chapter 16) runs automated accessibility checks on every change to a citizen-facing or customer-facing front end, and a failing check blocks the merge. The gate is configured by the platform team, outside the change.
• The person rule. A change that adds or alters an interaction pattern is tested by a person with a keyboard and a screen reader before release, because the automated checks cannot establish that a flow is understandable. The tester or accessibility specialist is independent of the author, which is the oracle corollary of the stewardship principle applied to a value.
• The prototype rule. A prototype built by a non-developer with a generative tool (Chapter 17 and Chapter 19) is not released to the public until it has passed the gate and the person check. A prototype that never leaves the room needs neither.

Inclusion has a side in D1 Frame: the people who write acceptance criteria decide whose use is imagined. The rule is to name, in every specification record that touches the public, the users whose circumstances differ most from the author's, and to say who checked.

Honesty about provenance

Honesty about AI provenance is a different obligation from disclosure to a regulator. It concerns the ordinary truth-telling of a working relationship: who wrote this, who read it, what was tested and by whom.

To whom, and in what form

The reviewer needs to know that a change was generated so that review begins from the right place (Chapter 9). The next owner needs to know so that the Understand test is applied to the person who holds the understanding. A customer, a commissioning authority or an upstream project needs to know where a contract, a tender or its contribution rules ask. The executive committee needs the truth about what has been measured.

The Linux kernel's documentation on AI coding assistants is a useful public example of how a large project puts the principle into a rule. It states that AI agents must not add Signed-off-by tags, because only humans can certify the Developer Certificate of Origin, and that the human submitter is responsible for reviewing all AI-generated code, ensuring licence compliance and taking full accountability for the contribution (214, The Linux kernel community, 2026). The page is the documentation of one project and has changed between kernel versions; it measures nothing. It is cited because it ties provenance to the same structure as the stewardship principle: a tool may produce text, a named human certifies and answers.

Provenance inside the organisation

The provenance record (PRV-*) of Chapter 10 holds the origin of generated code and dependencies. Two entries matter here: whether an assistant or agent took part in the change, and under which tool, mode and mandate (MND-*). The pull request template asks the author to state this in one line, and a change that reaches production without the line is blocked by the pipeline, not by a reviewer's memory. The line is not a confession. It is the input to the review design of Chapter 9 and the run records (RUN-*) of Chapter 8, and it must not be used to rank developers by how much they generate (Chapter 22); the Level 4 prohibition on decisions about a named person's performance rating applies.

Disclosure is not a cure

Honesty about the source of advice does not remove the advice's influence. The series has relied on this since AI Leader, Chapter 25: in a preregistered experiment with 767 analysed participants, a chatbot's inconsistent moral advice moved users' moral judgements, and the users underestimated how far (107, Krügel et al., 2023). The participants were US residents answering a moral dilemma, not developers, and the study says nothing about code review. The caution is the book's own: a pull request that says "an assistant drafted this" tells the reader where the text came from and does not remove the pull of its framing. Honesty about provenance is a precondition for independent review and not a substitute for it.

Honesty about numbers

A common breach of honesty in a development organisation is a number. The IEEE code asks members to be honest and realistic in stating claims or estimates based on available data (261, Institute of Electrical and Electronics Engineers, 2026), and both organisations here have a claim stated more strongly than its basis (see below). The rule is to state scope, method, date and result, and to say "not measured" where it has not been; Chapter 20 puts it into the adoption and value record (AVR-*).

Bias in what is built

The developer's hardest ethical task is often a technical one: noticing that the thing being built will treat people differently in a way nobody intended.

Two pieces of evidence show where the risk sits. Ziad Obermeyer and colleagues examined a widely used commercial algorithm for identifying patients who need extra care. At the same risk score, Black patients were sicker than White patients, because the algorithm predicted future health-care cost and not illness, and less is spent on Black patients' care. The authors estimated that correcting the target would raise the share of Black patients receiving extra help from 17.7 per cent to 46.5 per cent (273, Obermeyer et al., 2019). The lesson for the developer is that bias often enters through a design choice made early (the target variable, the proxy) and not through a defect found late. That is D2 Design.

Dong Huang and colleagues tested five models for social bias in the code they generate. They reported gender-biased behaviour in 13.47 to 49.10 per cent of the generated code, found direct prompt strategies of limited use for mitigation, and found that feeding the results of test execution back to GPT-4 reduced the share of biased code from 59.88 per cent to 4.79 per cent (213, Huang et al., 2023). The study used a purpose-built framework, models of 2023 and tasks the authors designed; its figures do not transfer to another model or codebase without a new measurement. Two points stand. A model can generate code that treats people differently without being asked to, and the check that worked was a test whose result the generator saw. A test that the generator wrote for its own output can encode the same bias, which is why the oracle must be independent.

The European setting adds three facts. In Test-Achats the Court of Justice held that the exemption in Article 5(2) of Directive 2004/113/EC, which had allowed sex to be used as a factor in insurance premiums and benefits, was invalid with effect from 21 December 2012 (173, CJEU, 2011). For a developer at an insurer the practical reading is that sex is not a rating factor in the code, and neither is a field that the code uses as its substitute without a recorded justification; the rule below says so. The Dutch data protection authority's report on the processing of applicants' nationality in the childcare benefit system (158, Autoriteit Persoonsgegevens, 2020) and the Hague District Court's judgment on SyRI (102, Rechtbank Den Haag, 2020) show what the public sector looks like when a selection is not explained; AI Threat, Chapters 11 and 12, treat them in full. The GDPR sets fairness as a principle of processing (Article 5(1)(a)) (4, European Union, 2016).

Three engineering rules follow from this evidence.

• The proxy rule. The specification record states, for every function that sorts, ranks, prices or routes people, which attributes are protected and which fields are known or suspected to stand in for them. The design review (D2) approves the fields; a later change that adds one returns to review.
• The counterfactual rule. The verification plan (VER-*) includes tests that change one protected or proxy attribute and require the outcome to be equal, or the difference to be explained in the reasons log. The tests are written by someone other than the author of the change and the generator of the code, and they are held outside the change so that the change cannot alter them.
• The reasons rule. For a function that bears on a person, the code produces a reason in words that the person can contest. This is the design counterpart of the contestation records of AI Boss.

Whistle-blowing

A developer who has asked, recorded, escalated and declined, and who still holds a concern about a breach of law or a danger to people, needs a route that does not run through the line manager and a guarantee against retaliation. The law has built both, within limits.

Directive (EU) 2019/1937 lays down common minimum standards for the protection of persons reporting breaches of Union law in listed areas (Article 2(1)). A reporting person is a natural person who reports or publicly discloses information on breaches acquired in the context of work-related activities (Article 5(7)). Protection depends on reasonable grounds to believe that the information was true at the time of reporting and within scope, and on reporting through the internal, external or public route the Directive provides (Article 6(1)). Private-sector entities with 50 or more workers must establish internal reporting channels (Article 8). Member States must prohibit any form of retaliation, including dismissal, harm to reputation and blacklisting (Article 19), and a reporting person who meets the conditions is not considered to have breached restrictions on disclosure (Article 21) (172, European Union, 2019).

National law implements and sometimes widens the Directive. Sweden's Lag (2021:890), as summarised from the Riksdag's text, applies to reports of wrongdoing in a work-related context where there is a public interest in the information coming out, requires employers with 50 or more employees to have internal reporting channels, and prohibits obstructing reporting and retaliation (152, Sveriges riksdag, 2021). Germany's Hinweisgeberschutzgesetz requires an internal reporting office for employers with 50 or more employees, from 2 July 2023 for those with 250 or more and from 17 December 2023 for those with 50 to 249; that rests on chamber-of-commerce and law-firm guidance because the statute page could not be opened (153, Bundesrepublik Deutschland, 2023).

Three limits matter for a developer and are the book's own reading, not legal advice.

1. Scope. The Directive protects reports of breaches of Union law in listed areas. A concern that the organisation is misleading its board about productivity, or that an agent's mandate was widened without a decision, may not be a breach of any listed instrument. National law may reach further, as the Swedish summary suggests, and a developer who is unsure asks the representative body or counsel before reporting. The professional codes cover what the statutes do not, though without a legal guarantee.
2. Evidence. A report is credible when it is specific. The records of this book (OWN-*, RVW-*, RUN-*, PRV-*, the AIDR) are the ordinary evidence, and a developer who points to a record is pointing to the organisation's own account, not copying material the developer was not entitled to see. Nothing in this chapter is a method for gathering information covertly, and none is offered.
3. Practice. The chapter found no study of how often developers use internal reporting channels, what happens to them afterwards, or whether the presence of a channel changes outcomes in software teams. The design is therefore a hypothesis the organisation tests, by publishing aggregate figures on the use of the channel and on the time to a response, never by identifying reporters.

The organisation's part is to make the route usable before it is needed: a named channel outside the development line, a person competent to understand a technical report, a statement in the role charter that reporting through it is protected, and an annual test, without a real report, that the channel answers in the stated time. The representatives of staff are involved in all four (Chapter 22), and contracts with suppliers say whose channel a supplier's developer uses.

Values to rules

Each of the sections above ended in a rule. This section shows how to produce such rules for an organisation's own values, and why the rules are written as records.

Practical guide: turning a value into an engineering rule and a check

Purpose. To give one value of the organisation a rule that a developer meets at the point of work, a check that is independent of the generator, and evidence that expires.

Roles. The developer who owns the software; the tech lead; the quality engineer who owns the oracle; the platform engineer who owns the gate; the product owner; legal counsel or the data protection officer for the legal floor; a staff representative where the rule touches monitoring.

Inputs. The organisation's published values; the legal floor from Chapter 24; the delegation profile (DLG-*); the team's specification and verification records; the last incident or near miss that touched the value.

Steps.

1. Name the value in the organisation's own words and cite its source (a statute, a code of conduct, a board paper). A value without a source is a slogan.
2. Name the point in the development loop where it is at stake: a specification, a design choice, a generated change, a test, a release or a claim.
3. Write the rule as one sentence that a stranger can apply and a tool can test. If it needs "appropriate" or "reasonable", rewrite it.
4. Name the work classes it constrains and whether it lowers the delegation ceiling. If the check cannot run outside the system that produced the change, lower the ceiling (the question added by AI Leader, Chapter 25).
5. Name the check and an owner independent of the author and the generator.
6. Name the evidence, its record, its expiry and the person who looks at it.
7. Name the case the rule does not cover and who is asked (Refusing to build harm).
8. Record the mapping as an AI Decision Record in version control beside the delegation profile, and review it when the profile is reviewed.

Result. A values-to-rule record that fits on a page, sits beside the delegation profile and gives a new developer a place to start.

Worked example: Nordvik Region's public-service values

Illustrative. On 10 February 2031 the CIO of Nordvik Region, Henrik Dahl, recorded AIDR-1125, which maps three values of the Region's development work to rules, with Gunilla Roos accountable for use. Maria Åkesson, the Region's legal counsel, reviewed the legal floor, and the union branch's IT representative, Tomas Ekblad, was consulted because the third rule touches how work is reported. The mapping applies to Applications and Integration and, for the first rule, to the consultants working in its repositories.

record: AIDR-1125
organisation: Nordvik Region
date: 2031-02-10
profile: DLG-NR-DEV-01
owner: Henrik Dahl
accountable_for_use: Gunilla Roos
reviewed_by: [Maria Åkesson]
consulted: [Tomas Ekblad]
review_due: 2031-08-10
values:
  - value: equal treatment and impartiality
    source: Instrument of Government, Chapter 1, Article 9
    rule: >
      No code that sorts, ranks or routes cases uses a protected
      attribute or a field that stands in for one, unless an exception
      is recorded in the specification record and approved at design review.
    work_classes: [generate, refactor, test, migrate]
    ceiling_effect: generate stays at Level 1; test never writes the oracle for its own change
    check: counterfactual tests in the verification plan, written by the quality function
    check_owner: Saga Edvardsson
    evidence: VER-NR entry, run on every change to eligibility and triage modules
    evidence_expiry_days: 90
    uncovered_case_goes_to: Gunilla Roos, then the AI governance forum
  - value: access for every citizen
    source: Directive (EU) 2016/2102, Articles 4 to 7
    rule: >
      A citizen-facing change is released only after the golden-path
      accessibility gate has passed and a person has tested the changed flow
      with a keyboard and a screen reader.
    work_classes: [generate, refactor, document, deploy]
    ceiling_effect: prototypes built by non-developers never reach citizens unreviewed
    check: platform gate plus manual test by an accessibility specialist
    check_owner: Maja Lindqvist
    evidence: RVW-NR entry with the tester named
    evidence_expiry_days: 180
  - value: honesty about how the work was made
    source: IEEE Code of Ethics, item 1
    rule: >
      A pull request states in one line whether and how a tool took part;
      a claim about speed or value carries scope, method, date and result.
    work_classes: [generate, review, document]
    ceiling_effect: none
    check: pipeline refuses a production merge without the line
    check_owner: Anders Falk
    evidence: AVR-NR entry with evidence age shown
    evidence_expiry_days: 90
    use_limit: not used in appraisal, pay or ranking of named developers

The record shows one consequence the Region had not planned. The first rule has no adequate check for the nine inherited sector systems, because test coverage there is low and a regression pack exists only for the portal and the benefits workflow, so the rule is declared in force for new and changed code only, and the Region records that for the inherited code the value is asserted and not shown. That is an honest entry, and it is what a rule with a check and an expiry makes visible.

Worked example: Hansa Mutual's customer-fairness values

Illustrative. On 24 February 2031 the group CIO, Rainer Lehmann, recorded AIDR-1175 for Group Application Development, with Dr. Annette Krämer, chief risk officer, as reviewer and the Konzernbetriebsrat consulted through its chair, Thomas Brandt. Dr. Philipp Reinhardt is accountable for use. The value of fair treatment of policyholders and claimants is mapped as follows.

record: AIDR-1175
organisation: Hansa Mutual
date: 2031-02-24
profile: DLG-HM-DEV-01
owner: Rainer Lehmann
accountable_for_use: Philipp Reinhardt
reviewer: Annette Krämer
consulted: [Thomas Brandt]
review_due: 2031-08-24
values:
  - value: fair treatment of policyholders and claimants
    source: Judgment C-236/09 Test-Achats; GDPR Article 5(1)(a)
    rule: >
      Sex is not an input to premium or benefit calculation. A field that
      correlates with a protected attribute may be used only if the
      specification record states why and the chief risk officer's
      delegate has approved it.
    work_classes: [specify, generate, refactor, test]
    ceiling_effect: generate inside rating and settlement code stays at Level 1
    check: counterfactual tests on rating and settlement services
    check_owner: Ewelina Maj
    evidence: VER-HM entry
    evidence_expiry_days: 90
  - value: accessibility of customer channels
    source: Directive (EU) 2019/882 where counsel confirms scope
    rule: >
      Customer-facing changes pass the Hansa Forge accessibility gate;
      scope under the Directive is decided by legal counsel and recorded.
    work_classes: [generate, deploy, document]
    check: gate in Hansa Forge plus manual test
    check_owner: Lukas Frey
    evidence_expiry_days: 180
  - value: honesty about how the work was made
    source: ACM Code of Ethics 1.3; IEEE Code of Ethics item 1
    rule: >
      Reports to senior bodies on AI-assisted share state the counting rule
      and the sample; an AI review comment never counts as a human approval.
    work_classes: [review, document]
    check: second approver reads the counting rule
    check_owner: Stefan Brückner
    evidence: AVR-HM entry with evidence age
    evidence_expiry_days: 90

The record notes a case it did not cover. Stefan Brückner's team received a request to rank broker-plug-in enquiries by a derived "likelihood of claim" built partly on postcode. The developer who took it neither refused nor built it: they asked what it was for, recorded the answer in the specification record, and the proxy rule routed it to review. Whether postcode was a permissible input became a decision for the chief risk officer's delegate, not for the developer or the agent. The rule did not forbid the field; it made the decision visible, owned and datable.

Across the usage modes

The highest degree of delegation each usage mode has been allowed in practice at the start of the year, with the value most exposed. The ceilings are those of DLG-NR-DEV-01 (AIDR-1101, with AIDR-1116 for the platform team's Mode 3 drafts) and DLG-HM-DEV-01 (AIDR-1153), and the table adds the value at stake, which is the question that AI Leader added to the ladder.

Usage mode	Value most exposed	Nordvik Region, highest degree	Hansa Mutual, highest degree
Mode 0 Ambient AI	Honesty: nobody records that it took part	Ambient completion, recorded retrospectively (AIDR-1102)	Ambient completion in IDEs and in the managed service provider's mainframe tooling
Mode 1 Conversational assistants	Honesty and fairness: drafting of requirements and tests	Level 1 Assisted for generate and refactor	Level 1 Assisted inside rating, settlement and payment paths
Mode 2 Embedded workplace assistants	Fairness: generated code that sorts people; access: front-end code	Level 1 Assisted; document Level 2 Supervised	Level 2 Supervised outside security-critical and payment paths
Mode 3 Agentic work tools	Honesty and revert: many files, one named owner	Platform team only, Level 2 Supervised under AIDR-1116, drafts never applied	Level 2 Supervised; one Level 3 Bounded class (patch-level dependency updates)
Mode 4 Built AI applications	Fairness: a test drafter that writes its own oracle	None	Test drafting at Level 1 Assisted; legacy explainer Level 0 Advisory (planned)
Mode 5 Autonomous production agents	Care and revert: acts without a person present	None; the Region has no autonomous production agents	Operations agent only, under AI Operations; no coding agent merges or deploys alone

The Level 4 prohibitions apply in every row. The value-specific ones follow from them: no mode writes the oracle for a fairness or accessibility rule against its own output, and no mode decides about a named person's employment, pay, performance rating or access to work.

Nordvik Region and Hansa Mutual

Nordvik Region builds under public-law accountability. Its software supports decisions that citizens may contest and its published components carry the Region's name. The values it can cite are in law: equality before the law, objectivity and impartiality in the Instrument of Government, Chapter 1, Article 9 (106, Sveriges riksdag, 1974), and the accessibility duties of Directive 2016/2102. About 25 people write code as their main work, and the 22 consultant developers working in its repositories are bound by the framework agreement NR-2025-102, which had no clause on AI tools in March 2030 and which the Region should also read for the question of whose reporting channel a consultant uses. The note of April 2030 that called a pilot of twelve "a third faster" is, in this chapter's vocabulary, a failure of honesty about what had been measured, and AIDR-1125 puts a rule and an expiry on it.

Hansa Mutual builds under financial-sector supervision. Its values are customer-facing and written in the language of fair treatment, and its legal floor includes Test-Achats for pricing, the GDPR and, where counsel confirms the scope, the European Accessibility Act. The "42 per cent AI-assisted" figure that reached the executive board in February 2030, against 27 per cent in a sample of 40 merged pull requests in August, is the same kind of failure: a count taken for an outcome. The group's scale, about 290 developers and about 190 external developers, makes the unowned case more likely, not less, and the right to decline sole approval in security-critical or payment paths, written into ROLE-HM-DEV-01 in Chapter 14, is the mechanism by which a developer such as Ralf Hauser says no without a conflict. The Konzernbetriebsrat co-determines under BetrVG section 87(1), no. 6 on tools suited to monitor behaviour or performance, which is why the use limit on the provenance line is agreed with it first. As an employer of 50 or more people, Hansa has internal reporting duties under the German act.

Nordvik leans on public law and a small team that knows each other, Hansa on process and a supervisor. Neither can lean on the codes alone, and both found that the hardest line to write was the one that said what the rule did not cover and who would be asked.

Observable, expected, speculation

The outlook for the ethics of development, labelled as the series does (162, Nordqvist, 2026).

• Observable. The codes exist (ACM 2018, IEEE 2020). The accessibility instruments and the whistle-blower directive are in force, and the directive has national acts in Sweden and Germany. The Linux kernel ties AI-assisted contributions to a named human certifier. A code read once did not change decisions in the one replication found. Accessibility failures were detected on about 96 per cent of a million home pages in 2026.
• Expected, with weak support. Contribution rules and contract clauses that require disclosure of AI involvement will become more common; the one stated trend is the kernel rule, and the sources read show no decided European instrument that requires such disclosure for code. Pipeline gates that check provenance lines and accessibility are expected to replace review by memory where an organisation adopts the rules of this chapter.
• Speculation. Licensing of software developers, on the pattern of other professions, has no decided instrument behind it in the sources read here. Whether a profession-wide duty to decline harmful work will be written into European law is likewise unevidenced.

Summary

This chapter concerned D1 Frame, D2 Design and D5 Steward: the points at which a value enters a requirement, becomes a constraint and is answered for in production. Law is a floor. The professional codes say what the profession says of itself, and the one replication found suggests that a code read once does not change decisions, so the codes have to become rules that a person meets at the point of work.

The Name, Understand and Revert tests are necessary and not sufficient. The developer's judgement remains for the cases no rule covers, and the organisation's part is a route for it: ask, record, escalate, decline without penalty, and report outside the line where a breach or a danger remains. Accessibility is the model of a value that has become law and that a gate and a person can check. Honesty about provenance is a precondition for independent review and not a substitute for it. Bias enters through design choices, and the check that worked in the evidence was a test whose result the generator saw, which is why the oracle must be independent. The whistle-blowing instruments protect reports of breaches of listed law and not every ethical concern, and the book found no study of how software teams use them.

The artefact is the values-to-rule mapping, recorded as an AI Decision Record beside the delegation profile: a rule, a work class, a ceiling effect, a check owner independent of the generator, evidence with an expiry and a route for the case it does not cover. Nordvik Region's AIDR-1125 and Hansa Mutual's AIDR-1175 are illustrative. Chapter 26 turns to the questions between ethics and law in the toolchain: who owns what is generated, what the licences of its sources allow, and on whom the organisation depends.

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. (4, European Union, 2016)
2. Rechtbank Den Haag (2020). Judgment of 5 February 2020, NJCM c.s. v the State of the Netherlands (SyRI). (102, Rechtbank Den Haag, 2020)
3. High-Level Expert Group on Artificial Intelligence (2019). Ethics Guidelines for Trustworthy AI. European Commission. (105, AI HLEG, 2019)
4. Sveriges riksdag (1974). Regeringsform (1974:152), 1 kap. 9 §. (106, Sveriges riksdag, 1974)
5. Krügel, S., Ostermaier, A. & Uhl, M. (2023). ChatGPT's inconsistent moral advice influences users' judgment. Scientific Reports 13, 4569. (107, Krügel et al., 2023)
6. Autoriteit Persoonsgegevens (2020). Belastingdienst/Toeslagen: De verwerking van de nationaliteit van aanvragers van kinderopvangtoeslag. (158, Autoriteit Persoonsgegevens, 2020)
7. Nordqvist, G. (2025). Architecture as Code. (161, Nordqvist, 2025)
8. Nordqvist, G. (2026). AI Governance. (162, Nordqvist, 2026)
9. Nordqvist, G. (2026). AI Boss. (167, Nordqvist, 2026)
10. Nordqvist, G. (2026). AI Leader. (174, Nordqvist, 2026)
11. Elish, M. C. (2019). Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction. (49, Elish, 2019)
12. Association for Computing Machinery (2018). ACM Code of Ethics and Professional Conduct. (260, Association for Computing Machinery, 2018)
13. European Parliament and Council (2019). Directive (EU) 2019/1937 on the protection of persons who report breaches of Union law. (172, European Union, 2019)
14. European Parliament and Council (2016). Directive (EU) 2016/2102 on the accessibility of websites and mobile applications of public sector bodies. (14, European Union, 2016)
15. European Parliament and Council (2019). Directive (EU) 2019/882 (European Accessibility Act). (17, European Union, 2019)
16. Court of Justice of the European Union (2011). Case C-236/09, Test-Achats. (173, CJEU, 2011)
17. Sveriges riksdag. Lag (2021:890) om skydd för personer som rapporterar om missförhållanden. (152, Sveriges riksdag, 2021)
18. Bundesrepublik Deutschland. Hinweisgeberschutzgesetz, section 12. (153, Bundesrepublik Deutschland, 2023)
19. Institute of Electrical and Electronics Engineers. IEEE Code of Ethics. (261, Institute of Electrical and Electronics Engineers, 2026)
20. Russell, K. (2020). Board of Directors Approves Revisions to the IEEE Code of Ethics. IEEE Spectrum. (262, Russell, 2020)
21. McNamara, A., Smith, J. & Murphy-Hill, E. (2018). Does ACM's Code of Ethics Change Ethical Decision Making in Software Development? ESEC/FSE 2018. (263, McNamara et al., 2018)
22. US Department of Justice (2017). Volkswagen Engineer Sentenced for His Role in Conspiracy to Cheat U.S. Emissions Tests. (264, United States Department of Justice & Office of Public Affairs, 2017)
23. Huang, D. et al. (2023). Bias Testing and Mitigation in LLM-based Code Generation. arXiv:2309.14345. (213, Huang et al., 2023)
24. The Linux kernel community. AI Coding Assistants. (214, The Linux kernel community, 2026)
25. Obermeyer, Z. et al. (2019). Dissecting racial bias in an algorithm used to manage the health of populations. Science 366(6464). (273, Obermeyer et al., 2019)
26. WebAIM (2026). The WebAIM Million. (274, WebAIM, 2026)