Regulation as Constraint: AI Act, Cyber Resilience Act, Product Liability, NIS 2, DORA, GDPR

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).

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. A role test comes first, the duty register assigns a holder, the evidence is kept with the change, and a gate that the change cannot alter catches the events that change the role.

The role test comes first

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.

Question Instrument Nordvik Region Hansa Mutual
Software made available on the market in the course of a commercial activity? Cyber Resilience Act (CRA) Art. 2(1), 3(22); Product Liability Directive (PLD) Art. 2(1), 4(7) Not on the profile facts: software for the Region's own use is not made available on the market (CRA recital 16) The mobile claims app and the broker plug-in are supplied by a commercial insurer; the book's reading is that they are in scope, for general counsel to confirm
Provider of an AI system? AI Act Art. 3(3), 3(11), 25(1) Provider and deployer of the benefits-explanations service it built; deployer of the procured benefits-triage system Provider of the systems built on the group AI platform, HM-DEV-002 among them, since putting into service for own use counts
Entity under a cybersecurity regime? NIS 2 Art. 21; DORA Art. 2(1)(n) Essential operator under the Cybersäkerhetslag (2025:1506), as read in AI Leader, Chapter 24 Financial entity under DORA; NIS 2 is displaced for the EU financial entities (NIS 2 Art. 4(1))
Controller of personal data? GDPR Art. 4(7), 25, 32 Yes Yes
Publisher of software others integrate? CRA Art. 3(14), 24 Publishes citizen e-service components as public code since 2027; steward status doubtful on the profile facts Not as a publisher of components; the plug-in is a product

The AI Act and the development organisation

The AI Act reaches development through four routes: the literacy duty, the provider test, the requirements for high-risk systems and the provisions on general-purpose AI models. The text read is Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744, the Digital Omnibus on AI (1, European Union, 2024) (5, European Union, 2026).

Article 4: literacy

As replaced, Article 4(1) requires providers and deployers to "take measures to support the development of AI literacy" of their staff and of other persons "dealing with the operation and use of AI systems on their behalf", and "does not require providers or deployers to guarantee any specific level of AI literacy of any individual". The Commission's question-and-answer page says that no certificate is needed and an internal record of training suffices (97, European Commission, 2026). Coding assistants are AI systems, and the book's reading is that consultants and nearshore developers using them (about 22 at Nordvik and 190 at Hansa) are inside "on their behalf". The duty is one of effort and cannot evidence that a reviewer is competent; the review record and the apprenticeship plan do.

The provider test

A provider is a body that "develops an AI system ... or that has an AI system ... developed and places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge" (Article 3(3)), and putting into service includes supply "for own use in the Union for its intended purpose" (Article 3(11)). An organisation that builds an AI system for its own staff is therefore its provider as well as its deployer: Hansa for HM-DEV-002, the test-drafting assistant, and Nordvik for the benefits-explanations service. For a system that is not high-risk the provider duties are few. For a high-risk system they are the whole of Article 16.

The second route into the provider role can be taken in a single pull request. Under Article 25(1)(c) a deployer or other third party is considered a provider of a high-risk system if it modifies "the intended purpose of an AI system, including a general-purpose AI system, which has not been classified as high-risk" so that it "becomes a high-risk AI system in accordance with Article 6". The intended purpose is the use intended by the provider, "including the specific context and conditions of use, as specified in the information supplied by the provider in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation" (Article 3(12)).

The book's reading, which no decision supports, is that for a general-purpose assistant the specific context and conditions of use are set largely by artefacts a team writes: the system prompt, the retrieval configuration, the tools the assistant may call. Take the casework variant of the Region's staff assistant, which retrieves case documents and calls the case-management API. If a developer changes its configuration so that it proposes whether an applicant is eligible for a benefit, the use falls within Annex III point 5(a): systems "intended to be used by public authorities or on behalf of public authorities to evaluate the eligibility of natural persons for essential public assistance benefits and services ... as well as to grant, reduce, revoke, or reclaim such benefits and services". On that reading the Region becomes the provider of a high-risk system, with the obligations of Article 16 and fines under Article 99(4)(a). Hansa's version is point 5(c), risk assessment and pricing in life and health insurance.

Whether a change crosses the line is a legal assessment; the engineering task is to make the event visible before merge. As replaced, Article 25(2) says the initial provider "shall no longer be considered to be a provider of that specific AI system" and must cooperate with the new one, and Article 25(4) requires a written agreement between the provider of a high-risk system and a third party supplying "tools, services, components, or processes that are used or integrated in a high-risk AI system", open-source tools other than general-purpose models excepted. Breaches of Article 25(2) and (4) carry fines of up to EUR 15 000 000 or 3 per cent of worldwide annual turnover (Article 99(4)(da)). Whether a coding assistant used to write a high-risk system is a tool "used" in it the text I read does not say; the procurement criteria of Chapter 18 should ask the supplier for its position.

What the requirements for high-risk systems ask of the code

A provider of a high-risk system owes technical documentation before placing on the market (Article 11(1)), automatic recording of events (Article 12(1)), "an appropriate level of accuracy, robustness, and cybersecurity" (Article 15(1)) and a quality management system covering "design, design control and design verification", "development, quality control and quality assurance" and "examination, test and validation procedures to be carried out before, during and after the development" (Article 17(1)(b) to (d)). None of this changes when an assistant wrote part of the code. Read by a developer, Article 17(1)(b) to (d) lists the artefacts of this book: the specification, the verification plan with its independent oracle, the review record, the run record and the provenance record. A provider who has them can show design verification and test validation for a change in which an assistant took part; one with a merged pull request alone cannot.

General-purpose models and the coding tools

Providers of general-purpose AI models owe documentation for the AI Office, information for providers of systems that integrate the model, a copyright policy and a public summary of training content (Article 53(1)); Article 53(2) exempts the first two for open-licence models with public weights, unless the model has systemic risk. A tender can ask for the downstream documentation, and a self-hosted open-weight model, as in Nordvik's pilot NR-DEV-001, may come without it, so that the Region evaluates the model itself (Chapter 9).

Fine-tuning raises the question whether the organisation has become a model provider. The Commission's guidelines say a downstream modifier becomes the provider "only if the modification leads to a significant change in the model's generality, capabilities, or systemic risk", with the indicative criterion that "the training compute used for the modification is greater than a third of the training compute of the original model" (paragraphs 59 and 60), and a fallback of a third of 10²³ FLOP where the original compute cannot be known (paragraph 61). The Commission notes that "currently few modifications may meet the criterion" (paragraph 64) and that the guidelines "are not binding" (paragraph 9) (244, European Commission, 2025). A team that fine-tunes a coding model on its own repositories should record the compute in the run record, so that "we assume we are far below" becomes a figure.

Article 50(2) requires providers of systems "generating synthetic audio, image, video or text content" to mark outputs in a machine-readable format, except "to the extent the AI systems perform an assistive function for standard editing or do not substantially alter the input data". Whether source code is "text content" the article does not say, and I found no guidance; it matters to Hansa as provider of HM-DEV-002. Article 50 applies from 2 August 2026 (Article 111(4), as added, gives systems placed on the market earlier until 2 December 2026). The interim control that costs nothing is a field in the provenance record that says which parts of a change an AI system generated, so that marking can be derived if required.

Dates after the Omnibus

The Omnibus was published on 24 July 2026 and entered into force on 27 July 2026, the third day after publication (Article 4 of the Omnibus). The Commission's AI literacy page says only "mid-July 2026"; the Regulation's own publication date and Article 4 give 27 July, which this book uses. The Omnibus replaced Article 4, parts of Articles 25 and 27, Article 111(2) and points of Article 113, and added Article 42(3) and Article 99(4)(da). Chapter III, Sections 1 to 3 apply from 2 December 2027 to systems under Article 6(2) and Annex III and from 2 August 2028 to those under Article 6(1) and Annex I; high-risk systems intended for public authorities must comply by 2 August 2030 even if already in use (Article 111(2), as replaced). These dates are expected: decided law whose application lies ahead of the reading date. The new Article 42(3) links the AI Act to the Cyber Resilience Act: a high-risk system within the latter's scope is "deemed to comply with the cybersecurity requirements set out in Article 15" where the conditions of CRA Article 12(1) are fulfilled (Part I of Annex I, the processes of Part II and a demonstration in the EU declaration of conformity) (242, European Union, 2024). One body of evidence can serve both, if written once.

The Cyber Resilience Act

Regulation (EU) 2024/2847 is the instrument that most directly touches what developers produce, and the one whose scope is most often assumed instead of tested (242, European Union, 2024).

Is the software a product made available on the market?

The Regulation applies to "products with digital elements made available on the market, the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network" (Article 2(1)). A product is "a software or hardware product and its remote data processing solutions" (Article 3(1)); a manufacturer develops, or has developed, such a product "and markets them under its name or trademark, whether for payment, monetisation or free of charge" (Article 3(13)); and making available is supply "in the course of a commercial activity, whether in return for payment or free of charge" (Article 3(22)). Commercial activity is characterised "not only by charging a price" but by an intention to monetise, "for instance by providing a software platform through which the manufacturer monetises other services" (recital 15); products "developed or modified by a public administration entity exclusively for its own use should not be considered to be made available on the market" (recital 16); and hosting on an open repository is not in itself making available (recital 20).

Hansa's mobile claims app and broker plug-in run on devices of customers and brokers and connect to a network. The book's reading is that an insurer supplying them as part of its business falls within recital 15 and that the Hamburg group entity marketing them is the manufacturer; general counsel confirms or corrects it. Nordvik's case systems, integrations and portal are the Region's own use, and the portal is a web service; on the profile facts the Region is not a manufacturer.

What the manufacturer's developers must do

The product must be "designed, developed and produced in accordance with the essential cybersecurity requirements" of Part I of Annex I (Article 13(1)), on the basis of a documented risk assessment kept up to date during the support period (Article 13(2) to (4)). Part I includes making the product available "without known exploitable vulnerabilities", secure by default, with protection against unauthorised access, data minimisation and limited attack surfaces (Annex I, Part I, point (2)(a), (b), (d), (g), (j)).

Two provisions connect to the chapters on building and proving. Under Article 13(5) manufacturers "shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product", including open-source components not made available commercially; under Article 13(6) they report a vulnerability found in a component to its maintainer. An agent's proposal of a dependency is not due diligence. The package proxy and approved-names list of Chapter 10 make diligence demonstrable, and a dependency is a third-party component from the moment it is integrated, whoever or whatever suggested it.

Vulnerability handling runs for the support period, which "shall be at least five years" or the expected time of use if shorter (Article 13(8)). Part II of Annex I requires the manufacturer to "identify and document vulnerabilities and components ... including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies" (point (1)), to apply "effective and regular tests and reviews of the security" (point (3)) and to run a coordinated vulnerability disclosure policy (point (5)). Technical documentation and the declaration of conformity are kept for at least ten years or the support period, whichever is longer (Article 13(13)). Fines for breach of Annex I and Articles 13 and 14 run to EUR 15 000 000 or 2.5 per cent of worldwide annual turnover (Article 64(2)); Member States decide whether they apply to public authorities (Article 64(7)). The book's conclusion is that the provenance record, bill of materials, verification plan and review record of Chapters 9, 10 and 12 are the developer's side of Article 13 and Part II, kept with the change and not assembled when an authority asks.

Reporting since 11 September 2026

A manufacturer must notify an actively exploited vulnerability it becomes aware of: an early warning "within 24 hours", a notification within 72 hours and a final report "no later than 14 days after a corrective or mitigating measure is available" (Article 14(2)); a severe incident follows the first two steps and a final report within one month (Article 14(4)). Notification goes through the single reporting platform of Article 16 to the coordinating CSIRT and ENISA (Article 14(1) and (7)), and affected users are informed (Article 14(8)). The Regulation applies from 11 December 2027, but Article 14 applies from 11 September 2026 (Article 71(2)), including to in-scope products placed on the market before 11 December 2027 (Article 69(3)).

On the reading date the reporting duty has applied for two months. The book's organisations are placed in 2030 and 2031, after both dates if the texts are unchanged. The clock starts when the manufacturer "becomes aware", so the person who reads a dependency alert or a bug report is part of the reporting chain, and the case record of AI Blue, Chapter 19, needs a CRA clock beside the others (168, Nordqvist, 2026). An assistant that triages vulnerability alerts for an in-scope product drafts and flags; a named person classifies and sends. Chapter 23 treats the incident side.

Open-source stewards and Nordvik's public code

An open-source software steward is "a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities" (Article 3(14)), and carries a light regime: a cybersecurity policy, cooperation with authorities and, where involved in development, the reporting duties of Article 14 (Article 24), while Article 64(10)(b) removes the fines referred to in Article 64(3) to (9) for an infringement by a steward. The Region has published its citizen e-service components under an open licence since 2027, for reuse by public bodies and not for commercial activities; the book's reading is that it is neither manufacturer nor steward. A supplier that integrates a component into a monetised product becomes a manufacturer, however, and Article 13(6) obliges it to report a vulnerability to the maintainer, which is the Region. The rule of Chapter 18 (a named maintainer, a security contact and an end-of-support date for every published component) is therefore a design choice and not a statutory duty, and it lets the Region receive such reports.

Product liability: software is a product

Directive (EU) 2024/2853 applies to products "placed on the market or put into service after 9 December 2026" (Article 2(1)) and defines a product as including "software" (Article 4(1)). Recital 13 says that software, "such as operating systems, firmware, computer programs, applications or AI systems", is a product however it is supplied, that "the mere source code of software" is not, and that "a developer or producer of software, including AI system providers within the meaning of Regulation (EU) 2024/1689, should be treated as a manufacturer". Free and open-source software "developed or supplied outside the course of a commercial activity" is excluded (Article 2(2)) (243, European Union, 2024).

Four features matter to a team. Compensation covers death or personal injury, damage to property other than property used exclusively for professional purposes, and "destruction or corruption of data that are not used for professional purposes" (Article 6(1)); pure economic loss is not listed. A product is defective where it does not provide "the safety that a person is entitled to expect or that is required under Union or national law", taking into account "safety-relevant cybersecurity requirements" (Article 7(1) and (2)(f)), so a breach of the essential requirements of the Cyber Resilience Act is exposed on two fronts. Defectiveness is presumed where the defendant fails to disclose relevant evidence, where the product breaches mandatory safety requirements meant to protect against the damage, or where an obvious malfunction caused it (Article 10(2)), and a court may order disclosure once a claim is plausible (Article 9(1)). A manufacturer cannot rely on a defect having arisen after placing on the market where it is due to software, "including software updates or upgrades", or to "a lack of software updates or upgrades necessary to maintain safety", within its control (Article 11(2)). Claims expire ten years after placing on the market or putting into service, or after a substantial modification (Article 17(1)), and 25 years where a personal injury was latent (Article 17(2)).

The book's conclusion is that a team's records are its evidence in two directions: a manufacturer that can produce the specification, verification plan, review record, provenance record and update history can answer a disclosure order and rebut a presumption, and one that cannot meets Article 10(2)(a) with an empty file. Retention is therefore a legal question and not a storage one: at least ten years or the support period (CRA Article 13(13)), matching the ten-year expiry of Article 17(1); where a personal injury is latent the period of Article 17(2) is longer, and counsel decides whether the records for such a product are kept for 25 years.

For a body's own software the Directive is narrower. A manufacturer includes anyone who develops a product "for their own use" (Article 4(10)(c)), but putting into service means first use "in the course of a commercial activity" (Article 4(9)). The Region's case systems serve a public task and a wrong benefit decision causes mostly economic harm, so the book's reading is that product liability adds little to the Region's exposure, which remains that of administrative and tort law (AI Leader, Chapter 24). For Hansa the mobile app is the exposed product, and the realistic head of damage is corruption of a policyholder's own data. Member States had to transpose the Directive by 9 December 2026 (Article 22(1)). The Swedish government submitted Proposition 2026/27:12 on 15 October 2026, proposing a new product liability act in force on 1 January 2027, three weeks after the Directive's date of application (160, Regeringen, 2026); I read the bill, not the Riksdag's decision, and did not verify the German transposition.

NIS 2 and DORA: secure development, change and third parties

NIS 2 requires essential and important entities to take measures that include "supply chain security" (Article 21(2)(d)) and "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure" (Article 21(2)(e)), and to take into account "the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures" (Article 21(3)) (3, European Union, 2022). The Swedish Cybersäkerhetslag renders the list in 2 kap. 3 §, with "säkerhet i leveranskedjan" (point 4) and "säkerhet vid förvärv, utveckling och underhåll av nätverks- och informationssystem" (point 5) (11, Sveriges riksdag & Regeringskansliet, 2025). For the Region the secure-development measure therefore covers code that consultants write inside its teams, and the weight of 15 for security and secure development in the criteria sheet of tender NR-2030-041 is the Region's way of showing that it took suppliers' secure development into account. No text requires that weight.

For Hansa's EU financial entities Article 21 is displaced, because DORA is a sector act at least equivalent in effect (NIS 2 Article 4(1)). Article 21(2)(e) therefore does not reach Hansa's financial entities, and reaches the nearshore partner Wiślana Software only if the partner is itself within the Directive's annexes, which I did not assess; DORA and its technical standard do the work.

DORA requires documented policies for ICT change management, "including changes to software, hardware, firmware components, systems or security parameters", so that all changes "are recorded, tested, assessed, approved, implemented and verified in a controlled manner" (Article 9(4)(e)) (2, European Union, 2022). Commission Delegated Regulation (EU) 2024/1774 specifies it, and its Articles 16 and 17 read as a specification of the stewardship principle (15, European Commission, 2024):

  • Article 16(3): testing "shall contain the performance of source code reviews covering both static and dynamic testing".
  • Article 16(5) and (6): non-production environments "only store anonymised, pseudonymised, or randomised production data", with narrow exceptions.
  • Article 16(7) to (9): integrity controls for source code "developed in-house or by an ICT third-party service provider", analysis and testing of third-party and open-source code "prior to their deployment in the production environment", and the same rules for systems built by users outside the ICT function, which reaches the low-code builders of Chapter 19.
  • Article 17(1)(b) and (e): "mechanisms to ensure the independence of the functions that approve changes and the functions responsible for requesting and implementing those changes", and "fall-back procedures and responsibilities" for aborting or recovering from changes.

The standard speaks of functions and not of tests, so reading Article 17(1)(b) as the legal form of the independent oracle is the book's own step, and a short one. A change that an agent generated, that tests drafted by the same agent pass and that the author's only colleague approves is the pattern of INC-HM-2029-0207 with a tool added, and Article 17(1)(b) names the control it lacks. Article 17(1)(e) is the legal form of Revert. The rule that an AI review comment never counts as one of the two human approvals (DLG-HM-DEV-01) satisfies both.

Third-party rules reach the coding tools directly. A financial entity "shall, at all times, remain fully responsible" under contracted ICT services (Article 28(1)(a)), keeps a register of information (Article 28(3)), and its contracts state "the locations ... where data is to be processed" (Article 30(2)(b)) and, for services supporting critical or important functions, notice periods for developments with material impact (Article 30(3)(b)) and exit strategies (Article 30(3)(f)). The profile puts the IDE assistant contract HM-PROC-AIDEV-2029-01 on the register as supporting an important function. The book's reading is that its clauses on EU processing and 30 days' notice of model changes correspond to Article 30(2)(b) and 30(3)(b), and that the exit plan must cover coding tools, which EXIT-004 did not. Whether the nearshore partner's staff, working inside Hansa's teams, are "ICT services" ("digital and data services provided through ICT systems ... on an ongoing basis", Article 3(21)) the text does not settle. The question matters less than it appears: either Article 16(7) and (8) apply to the code they deliver, or the rules for in-house code do. The register records the classification as open and applies the stricter reading.

The GDPR in the repository

The GDPR addresses the controller. Article 25(1) requires measures "such as pseudonymisation", implemented "at the time of the determination of the means for processing and at the time of the processing itself"; Article 25(2) that "by default, only personal data which are necessary for each specific purpose of the processing are processed"; Article 32(1) measures appropriate to the risk, including regular testing of their effectiveness. Infringements of Articles 25 to 39 carry fines of up to EUR 10 000 000 or 2 per cent of worldwide annual turnover (Article 83(4)(a)) (4, European Union, 2016). Developers are not addressees; recital 78 says only that producers "should be encouraged" to take data protection into account and that the principles belong "in the context of public tenders". The controller's measures are nonetheless made of the developer's work. Fixtures, seed data and agent sandboxes hold pseudonymised or synthetic data, which for Hansa is also Article 16(5) of the DORA standard. Code, logs and fixtures sent to a tool can hold personal data, and where the tool provider processes them on the controller's behalf Article 28(1) and (3) require sufficient guarantees and a contract. And a credential pasted into an unapproved assistant, as in INC-NR-2030-0071, is an Article 32 matter if it gave access to personal data; the framework NR-2025-102 had no clause on AI tools. Telemetry is a matter for Chapter 22.

Public law at the repository

For a public authority the repository carries one more rule. In Sweden a decision "kan fattas av en befattningshavare ensam eller av flera gemensamt eller automatiserat" (Förvaltningslag § 28) (154, Sveriges riksdag, 2017), and a committee may delegate to "en automatiserad beslutsfunktion i ett visst ärende eller en viss grupp av ärenden" (Kommunallag 6 kap. 37 §) (98, Sveriges riksdag, 2017). The Region's council has decided that no such function exists (AI Leader, Chapter 24), so a build that lets a step in case handling decide without a person lies outside the delegation order, and the pipeline has to stop it.

From articles to artefacts: the duty register

A register in version control, next to the decision rights register of AI Leader, is read when a decision is taken. The legal annex, DRR-NR-001-LEG at Nordvik and DRR-HM-001-LEG at Hansa, gains a developer section with the annex's fields and one more, the ceiling for AI. The dates in the registers below are in the book's fictional year; the chapter's own reading of the law is dated 11 November 2026. The table collects the mapping.

Instrument and article Addressee What the text asks What developers do Artefact Function
AI Act Art. 4 (as replaced) Provider, deployer Measures to support AI literacy Record what was offered to staff and consultants using the tools CMP-* records D5
AI Act Art. 3(12), 25(1)(c) Deployer or third party Intended-purpose change can make the changer a provider Treat prompt, retrieval and tool configuration as a change of intended purpose; gate before merge Change record with provider-test answer D1, D2
AI Act Arts. 11, 12, 15, 17 Provider of a high-risk system Documentation, logs, robustness, quality system Keep design verification and test validation evidence per change SPC-*, VER-*, RVW-*, PRV-* D2, D4
AI Act Art. 53; Commission guidelines paras 59 to 64 Model provider; downstream modifier Documentation to downstream providers; modifier threshold Ask for the documentation; record fine-tuning compute Tender criteria; run record D3
AI Act Art. 50(2) Provider of a generating system Machine-readable marking of synthetic text, with exceptions Record AI-generated parts in provenance; position on code open PRV-* field D5
CRA Art. 13(1) to (8), Annex I Manufacturer Secure by design; diligence on components; vulnerability handling for the support period Risk assessment, bill of materials, tests, update path Technical file, PRV-*, VER-* D2, D4, D5
CRA Art. 14 Manufacturer 24 h, 72 h and 14-day or one-month reports Open a CRA clock when a person becomes aware Case record clock D5
CRA Art. 24 Open-source steward Cybersecurity policy; cooperation Maintainer, security contact, end-of-support date for published code OWN-* D5
PLD Arts. 7, 9, 10, 11(2) Manufacturer Safety expected; disclosure; presumptions; no exemption for software updates Retain records at least ten years; keep update history Retention rule in the register D5
NIS 2 Art. 21(2)(d), (e), 21(3) Essential or important entity Secure acquisition, development, maintenance; supplier practices Weigh suppliers' secure development; apply to consultants Tender criteria; contract clauses D3, D4
DORA Art. 9(4)(e); Reg. 2024/1774 Arts. 16, 17 Financial entity Change management; source code review; test data; independence; fall-back Static and dynamic review; pseudonymised test data; independent approver; revert path RVW-*, VER-*, CHG-* D3, D4, D5
DORA Arts. 28, 30 Financial entity Register of information; contract provisions Keep coding tools and nearshore teams on the register with exit Register entry; contract D5
GDPR Arts. 25, 28, 32 Controller, processor Design and default; processor guarantees; security Pseudonymised fixtures; processing contract for tools Data section of SPC-* D2, D3
Kommunallag 6:37; Förvaltningslag § 28 Region, committee Automated decision function only by delegation Do not build an automated decision step outside the delegation order Gate; delegation order D1, D2

Hansa's developer section follows in an excerpt of four rows. The comments show where the reading is the book's own.

register: DRR-HM-001-LEG
section: developer_duties
version: 2
decision_record: AIDR-1174
approved_on: 2031-02-03
texts_read: 2031-01-28            # the dated reading; entries expire
reverify_by: 2031-07-28           # six months, and on every announced amendment
jurisdictions_mapped: [DE, EU]
jurisdictions_not_mapped: [NL, SE, PL, NO, UK, CH]
duties:
  - ref: CRA Art. 13(5)-(8), 14; Annex I Part II(1), (3)
    scope: mobile claims app and broker plug-in   # book's reading: in scope; counsel confirms
    addressee: manufacturer
    holder: Dr. Philipp Reinhardt
    deputy: Lukas Frey
    artefact: PRV with bill of materials; VER; vulnerability policy; CRA clock in the case record
    evidence_max_age_days: 90
    applies_from: 2027-12-11      # Art. 14 since 2026-09-11
    ai_ceiling: generate Level 2 Supervised; patch class (MND-HM-DEV-01) Level 3 only for approved names
  - ref: DORA Art. 9(4)(e); Reg. 2024/1774 Art. 16(3), (5), (8), 17(1)(b), (e)
    addressee: financial_entity
    holder: Dr. Philipp Reinhardt
    deputy: Lukas Frey
    artefact: RVW and VER per change; pseudonymised test data; revert path in CHG
    evidence_max_age_days: 90
    ai_ceiling: review Level 1 Assisted (AI comment is not a human approval); deploy Level 0; Level 4 prohibited
  - ref: AI Act Art. 3(12), 25(1)(c); Annex III 5(c)
    addressee: deployer_or_third_party
    holder: Ulf Zimmermann
    deputy: Anja Weiß
    artefact: provider-test answer on every change to prompt, retrieval or tool configuration
    evidence_max_age_days: 365
    ai_ceiling: specify Level 1 Assisted; a change to an AI system's own mandate Level 4 prohibited
  - ref: CRA Art. 13(13); PLD Arts. 9, 10(2)(a), 17(1)
    addressee: manufacturer
    holder: Ulf Zimmermann
    deputy: Dr. Philipp Reinhardt
    artefact: retention of SPC, VER, RVW, PRV and update history
    retain_years: 10              # or the support period, whichever is longer
    ai_ceiling: document Level 2 Supervised

Nordvik's equivalent for the provider test is a rule in the platform pipeline. It is small on purpose: the part the team must not be able to skip.

pipeline_rule: intended-purpose-change
decision_record: AIDR-1124
accountable: Gunilla Roos
rule_owner: Maja Lindqvist        # platform team; not the author's team
triggers:                         # a changed path in any repository that holds an AI system
  - system_prompt
  - retrieval_configuration
  - tool_permissions
  - model_route
  - allowed_use_statement
requires:
  provider_test:
    answered_by: Maria Åkesson    # regional legal counsel, deputy named in the register
    question: does the change make the system fall within Annex III, or alter a high-risk one (Art. 25(1))?
    outcome: [no_change_of_role, route_to_ai_governance, stop]
  reviewer_outside_author_team: true
merge: blocked_until_provider_test_answered
rule_file_write_access: platform_team_only   # no agent identity may change the rule or its owners
evidence_max_age_days: 365

Practical guide: reading an instrument into the repository

Purpose. Turn the role test and the mapping into a register, records kept with the change and a gate in the pipeline.

Roles and inputs. The tech lead drafts the register, the platform engineer builds the gate, legal counsel answers the role test, the data protection officer reviews the GDPR and test-data rows, the product owner confirms what each product is for, and a works-council member reads the rows that touch telemetry (Chapter 22). Inputs: service records, the inventory of AI systems and tools, contracts and the texts.

Steps.

  1. List every product the organisation supplies, publishes or builds for itself and every AI system it builds or configures; apply the role test and record the answers with the reading date.
  2. For each role, copy the operative words of the articles and decide whether the addressee is the organisation, a management body or a named person.
  3. Name the artefact in version control that evidences each duty and its age limit, preferring SPC-*, VER-*, RVW-*, RUN-*, PRV-* and OWN-*.
  4. Identify the events that change the role (publishing a component, supplying an app, changing what an AI system is for, sending repository contents to a tool provider) and gate each, in a pipeline owned by a team other than the author's.
  5. Assign a holder and a deputy to every row, set the ceiling for AI and mark where the Level 4 prohibitions apply.
  6. Record the date each text was read and re-read at most six months later, and on every announced amendment.
  7. Approve the register as an AI Decision Record.

Artefact. A developer section of the legal annex in version control, with a diff on every re-reading.

What was verified and what is open

Observable. Every article quoted was read on 11 November 2026 in the Official Journal text on EUR-Lex, the AI Act both as adopted and as amended by Regulation (EU) 2026/1744, and the Swedish texts on the Riksdag's site. The Omnibus entered into force on 27 July 2026, Article 14 of the Cyber Resilience Act has applied since 11 September 2026, and the Commission's guidelines on general-purpose AI models are C(2025) 7719 final of 19 November 2025.

Expected. Chapter III, Sections 1 to 3 of the AI Act apply from 2 December 2027 for Annex III systems; the Cyber Resilience Act applies from 11 December 2027; the Product Liability Directive applies to products placed on the market or put into service after 9 December 2026; and the Swedish government proposes 1 January 2027 for its new act, which becomes law only if the Riksdag adopts it. These are decided law or a tabled bill whose dates lie ahead of the reading date.

Speculation. That a standards body or the Commission will fix a format for marking source code under Article 50(2), and that harmonised standards under the Cyber Resilience Act will name the practices of this book, are plausible. No text I read says either.

Not verified, and therefore not claimed. Whether the single reporting platform of Article 16 was operating from 11 September 2026 (commentary differed and I found no primary statement); the German transposition of the Product Liability Directive; the Riksdag's decision on Proposition 2026/27:12; whether the mobile app and the plug-in are supplied "in the course of a commercial activity"; whether the nearshore partner's staff are ICT services under DORA and whether the partner is itself an NIS 2 entity; whether source code is "text content" under Article 50(2); whether a coding assistant is a tool "used" in a high-risk system under Article 25(4); Commission guidance on Articles 27 and 50; and the law of the other jurisdictions of the group. A reader who needs any of these has to ask counsel.

Across the degrees of delegation

The table sets the ten classes of development work against the provisions that reach them. The ceilings are those of the delegation profiles; the law can lower a ceiling and cannot raise it.

Work class Provisions that reach it What the text adds DLG-NR-DEV-01 DLG-HM-DEV-01
Specify AI Act Art. 3(12); CRA Art. 13(2) to (3); GDPR Art. 25 Intended purpose, security requirements and data are fixed in the specification; changing them changes the legal role Level 0 Advisory Level 1 Assisted
Design CRA Annex I Part I; AI Act Arts. 12, 15; GDPR Art. 25 Security, logging and data protection by design have a named owner Level 0 Advisory Level 0 Advisory
Generate CRA Art. 13(5); Reg. 2024/1774 Art. 16(3); GDPR Art. 32 Generated code is the manufacturer's code; static and dynamic review before production Level 1 Assisted Level 2 Supervised; Level 1 in security-critical and payment paths
Refactor CRA Arts. 3(30), 13(8); PLD Art. 11(2) A change that affects Part I compliance of a supported product can be a substantial modification Level 1 Assisted Level 2 Supervised
Test Reg. 2024/1774 Arts. 16(2), 17(1)(c); AI Act Art. 17(1)(d) Test and validation before, during and after; oracle independent of the generator Level 1 Assisted for drafts Level 1 Assisted for drafts
Review Reg. 2024/1774 Art. 17(1)(b) Approver independent of requester and implementer; an AI comment is not an approval Level 0 Advisory Level 1 Assisted
Deploy DORA Art. 9(4)(e); Reg. 2024/1774 Art. 17(1)(e) to (g) Recorded, tested, assessed, approved, verified; fall-back; Level 4 prohibited without a gate the change cannot alter Level 0 Level 0
Operate CRA Arts. 13(8), 14; NIS 2 Art. 21(2)(e) Vulnerability handling for the support period; reporting clocks; a named person classifies and sends Level 0 Advisory Level 0 Advisory
Document CRA Art. 13(13); AI Act Art. 11; PLD Art. 9 Documentation kept ten years or the support period; evidence disclosed on request Level 2 Supervised Level 2 Supervised
Migrate Reg. 2024/1774 Art. 16(8); CRA Art. 69(2) Migration of a supported product can be a substantial modification; code analysed before deployment Level 0 Advisory Level 0 Advisory

No row is satisfied by Level 4. Every instrument assigns its duty to a named holder, and the tests of Chapter 4 apply to each change: a named owner, an owner who understands it, and a revert path outside the pipeline.

Nordvik Region and Hansa Mutual

Nordvik Region. The Region is a provider and deployer of AI systems, an essential operator under the Swedish act, a controller, and on the profile facts neither a CRA manufacturer nor a steward. Its sharpest regulatory risk in development is a quiet change of role: a configuration change that turns a general-purpose assistant into an eligibility tool under Annex III point 5(a). The CIO Henrik Dahl decided on 21 January 2031 (AIDR-1124) that the developer section is added to DRR-NR-001-LEG (AIDR-1024, December 2029) as version 2; that the pipeline rule intended-purpose-change is introduced on the golden paths under Maja Lindqvist's platform team; that legal counsel Maria Åkesson answers the provider test and confirms the steward position by 31 March 2031, the rule of Chapter 18 applying meanwhile; and that the register is re-read by 21 July 2031. The delegation order of the council stands: no automated decision function exists.

Hansa Mutual. Hansa carries the heavier set: DORA and its technical standard for every change, the Cyber Resilience Act and product liability for the mobile app and the plug-in, and the AI Act for the systems it builds. The group CIO Rainer Lehmann decided on 3 February 2031 (AIDR-1174), with Dr. Annette Krämer and Ulf Zimmermann, that the two products are treated as in scope of the Cyber Resilience Act until counsel concludes otherwise; that Dr. Philipp Reinhardt holds the manufacturer's duties with Lukas Frey as deputy; that a CRA clock is added to the case record with Tobias Richter's site reliability function; that evidence is retained at least ten years or the support period; that the provenance record carries a field for AI-generated parts while Article 50(2) is open; and that the nearshore partner's DORA classification is recorded as open with the stricter reading applied. DRR-HM-001-LEG (AIDR-1074) gains the developer section as version 2, read by the Konzernbetriebsrat for the telemetry rows. The UK and Swiss entities are not mapped.

Summary

The instruments of this chapter attach to products, systems, processing and entities, and none of the development provisions read distinguishes code written by a person from code written with an assistant, with Article 50(2) as the open exception. For D1 Frame, the intended purpose of an AI system and the data a product may touch are written in the specification, and a change to them can change the legal role: under Article 25(1)(c) of the AI Act a configuration change can make a deployer the provider of a high-risk system. For D2 Design, security, logging and data protection by design are named owners' decisions (Annex I of the Cyber Resilience Act; Articles 12 and 15 of the AI Act; Article 25 of the GDPR). For D3 Build, generated code and proposed dependencies are the manufacturer's own, with due diligence under Article 13(5). For D4 Prove, Articles 16 and 17 of the DORA technical standard require source code review, pseudonymised test data and independent approval, the legal form of the independent oracle. For D5 Steward, support periods of at least five years, reporting clocks applying since 11 September 2026, retention of at least ten years and a fall-back procedure are Name, Understand and Revert in legal form.

The practice that follows is a role test, a dated duty register in version control with a holder, an artefact, an evidence age and a ceiling for AI for each row, and a gate for the events that change the role. DRR-HM-001-LEG and the pipeline rule intended-purpose-change show the form. The conclusions are the chapter's own readings of the texts; texts change, and the register is re-read every six months and on each announced amendment.

Chapter 25 turns from what the law requires to what judgement must add: where the law ends and the developer's professional responsibility begins.

Sources

  1. European Parliament and Council of the European Union. 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. Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). Official Journal of the European Union, 24 July 2026. (5, European Union, 2026)
  3. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union, 20 November 2024. (242, European Union, 2024)
  4. European Parliament and Council of the European Union. Directive (EU) 2024/2853 on liability for defective products and repealing Council Directive 85/374/EEC. Official Journal of the European Union, 18 November 2024. (243, European Union, 2024)
  5. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
  6. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
  7. European Commission (2024). Commission Delegated Regulation (EU) 2024/1774, Articles 16 and 17. Official Journal of the European Union, 25 June 2024. (15, European Commission, 2024)
  8. European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (4, European Union, 2016)
  9. European Commission (2025). Commission Guidelines on the scope of the obligations for providers of general-purpose AI models established by Regulation (EU) 2024/1689 (AI Act). C(2025) 7719 final, 19 November 2025. (244, European Commission, 2025)
  10. European Commission. AI Literacy: Questions and Answers. Shaping Europe's digital future, page last updated 20 October 2026. (97, European Commission, 2026)
  11. Regeringen (2026). Regeringens proposition 2026/27:12 En ny produktansvarslag. 15 October 2026. (160, Regeringen, 2026)
  12. Sveriges riksdag, Regeringskansliet. Cybersäkerhetslag (2025:1506). Svensk författningssamling, in force 15 January 2026. (11, Sveriges riksdag & Regeringskansliet, 2025)
  13. Sveriges riksdag. Kommunallag (2017:725), 6 kap. 37 and 38 §§. Svensk författningssamling 2017:725. (98, Sveriges riksdag, 2017)
  14. Sveriges riksdag. Förvaltningslag (2017:900), 28 §. Svensk författningssamling. (154, Sveriges riksdag, 2017)
  15. Nordqvist, G. (2026). AI Leader: How Leadership Roles Change When AI Is Used Broadly in European Enterprises and Public Authorities. The Architecture as Code Series, Book 11. (174, Nordqvist, 2026)
  16. Nordqvist, G. (2026). The Transformed Security Architect. The Architecture as Code Series, Book 6. (166, Nordqvist, 2026)
  17. Nordqvist, G. (2026). AI Purple. The Architecture as Code Series, Book 9. (169, Nordqvist, 2026)
  18. Nordqvist, G. (2026). AI Blue. The Architecture as Code Series, Book 8. (168, Nordqvist, 2026)