AI Developer · Whitepaper

Chapter 24 · Regulation, Ethics and Responsibility

Regulation as Constraint

AI Act, Cyber Resilience Act, Product Liability, NIS 2, DORA, GDPR

Author Conceived and directed by Gunnar Nordqvist; text written by AI agents under his direction.
Published 11 November 2026
Build number 2026.11
software-development stewardship ai-governance architecture-as-code ai-agents
Figure 24.1: From instruments to roles, duties and the evidence kept with the change.
Figure 24.1: From instruments to roles, duties and the evidence kept with the change.

This chapter reads the instruments that reach software and says what each asks of the people who write, review, release and keep it. It concerns all five developer functions. D1 Frame: the intended purpose of a system and the data it may touch are written in the specification, and several instruments attach their duties to that text. D2 Design: security, logging and data protection by design are decisions with a named owner. D3 Build: code produced with an assistant or an agent is the code of the manufacturer, the provider or the entity, and a dependency a tool proposes becomes a third-party component once integrated. D4 Prove: the instruments ask for source code review, tests and independent approval, the evidence of Chapters 9 and 10. D5 Steward: support periods, reporting clocks, retained documentation and a path to withdraw a change belong to the owner who can pass Name, Understand and Revert.

The argument has one thread. In the provisions on software development read for this chapter, none distinguishes code written by a person from code written with an assistant; the one that may, the marking duty of Article 50(2) of the AI Act, is discussed below. Each attaches to a product, a system, a processing operation or an entity, and asks who answers and what evidence exists. The developer's contribution is to make the answers true in the repository: to know which role the organisation holds under each instrument, to keep the records that prove it, and to gate the changes that alter the role. Everything below is an organisational and architectural implication and not legal advice. Each article was read in the Official Journal text on EUR-Lex, or the Swedish Riksdag's publication, on 11 November 2026; the last section lists what could not be verified. It builds on the finding that regulation reaches the organisation, the management body or a named person and never a system, and that a dated register of holders, artefacts and evidence ages is re-read every six months (AI Leader, Chapter 24; The Transformed Security Architect, Chapter 18; AI Purple, Chapter 21) (174, Nordqvist, 2026) (166, Nordqvist, 2026) (169, Nordqvist, 2026).

An article is a duty only for an addressee, and one team can hold several roles at once. Five questions come first. Do we supply software to others in the course of a commercial activity? Did we develop an AI system, or change what one is for? Is the processing of personal data ours? Are we an entity of a listed sector? Do we publish software others integrate? The table answers for the book's two organisations; where a cell says the reading is the book's own, no decision supports it.

Primary topics explored

  1. The role test comes first
  2. The AI Act and the development organisation
  3. The Cyber Resilience Act
  4. Product liability: software is a product
  5. NIS 2 and DORA: secure development, change and third parties
  6. The GDPR in the repository

About AI Developer

AI Developer is Book 12 of The Transformed Architecture. It takes the developer as its subject and asks what happens when AI is used broadly in software development: the five developer functions (frame, design, build, prove, steward), the delegation ladder and the Level 4 prohibitions, the stewardship principle (name, understand, revert), verification as the scarce skill, the junior pipeline, adoption and productivity as claims that need evidence, regulation (the AI Act, the Cyber Resilience Act, the Product Liability Directive, NIS 2, DORA, the GDPR), ethics, intellectual property and sovereignty in the toolchain, and the developer as a person, for European enterprises and public authorities.

It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue, AI Purple, AI Operations and AI Leader.

Who should read this

developers at every level, tech leads and engineering managers, architects, platform engineers, site reliability engineers and testers, product owners and designers, leaders who decide on developer tooling, heads of public-sector IT and procurement, works councils and unions, educators, and supervisors and auditors.

Portrait of Gunnar Nordqvist

Gunnar Nordqvist

Conceived, directed and published the books of The Transformed Architecture.

Continue with the full chapter

Read the full chapter online

Chapter 24: Regulation as Constraint: AI Act, Cyber Resilience Act, Product Liability, NIS 2, DORA, GDPR in AI Developer gives the detailed explanations, practical examples and implementation patterns behind this summary.

This whitepaper belongs to “Regulation, Ethics and Responsibility” and is one of 37 drawn from the manuscript.