Regulation for Builders: What Applies When

A builder who is not a developer is not expected to read the General Data Protection Regulation, the Artificial Intelligence Act or the Cyber Resilience Act, and this chapter does not ask her to. It asks something smaller: that she knows which of these instruments can reach a tool like hers, which question decides, and when to stop and call someone. Law is not the builder's job. It is her problem all the same, because the organisation she works for is the addressee of every one of these texts, and a tool she builds can change which role the organisation holds without anyone noticing. The chapter maps the main instruments to the builder in plain terms and by tier, and it ends in a screening that she can attach to her build record. It concerns Step 2 Tier, Step 8 Secure and Step 11 Own, and the developer functions D1 Frame, D2 Design, D4 Prove and D5 Steward: the instruments attach their duties to the intended purpose written in the specification, to design choices with a named owner, to evidence kept with the change, and to ownership over time.

Regulation mapped to tiers: the role test comes first, and the duties follow the tier up to a screening gate

Figure 19.1: Regulation mapped to tiers. The role test comes first; Tier A and B carry little, Tier C the deployer and supplier duties, Tier D the development organisation's.

This is a legal chapter in the sense that every statement of law is attributed to the instrument and article, and in no other. It is not legal advice: the statements are organisational implications, and where a reading is the book's own and no decision supports it, the text says so. The reading is dated. The instruments and articles cited were read as recorded in the bibliography between 10 and 12 November 2026, and the worked examples are placed in the autumn of 2031; the book's rule, from AI Leader, Chapter 24, is that a duty register is re-read against the live text at least every six months, and the screening below carries a date for that reason (85, Nordqvist, 2026). The chapter builds on AI Developer, Chapter 24, which read the same instruments for the development organisation, and on Chapter 26 of that volume for copyright and licences, and on AI Governance, Chapter 4 (86, Nordqvist, 2026) (75, Nordqvist, 2026). It takes from them the finding that regulation reaches the organisation, the management body or a named person and never a system, and adds the builder's side: what a person with no legal training can see from where she stands.

The role test comes first

An article is a duty only for an addressee, and one tool can put its organisation in several roles at once. Five questions come before any article, and a builder can answer them from the specification she has already written.

  1. Does the tool hold or touch personal data, that is, information about an identifiable person? If so the organisation is a controller for it (GDPR).
  2. Does the tool contain or call an AI system when it runs, or did the builder only use an assistant to write it? An assistant that helped write ordinary code does not make the tool an AI system; a tool that sends text to a model at run time may.
  3. Does the tool rank, select or decide about a named person, or feed such a system? If so it is Tier D and not a citizen build (Chapter 6).
  4. Is the tool supplied to anyone outside the organisation, for payment or in the course of a commercial activity, or published for others to integrate? If so product law may apply.
  5. Does the tool run inside an entity under a sector regime, for example a financial entity under DORA or an essential entity under NIS 2? If so the entity's rules for change, supply chain and ICT risk apply to the tool.

The answers go in the build record at Step 2, because the tier decision depends on them, and they are re-asked at Step 11 when the tool's use has changed. The book's conclusion, which no instrument states in this form, is that most builders' tools answer no to questions 2, 3 and 4 and yes to question 5 in a regulated organisation, so that the instruments that matter most to a builder are the GDPR and the entity's change and supplier rules, and that the ones that make headlines, the AI Act and the Cyber Resilience Act, matter at the edges where the answers change.

The General Data Protection Regulation

The GDPR addresses the controller, the body that determines the purposes and means of processing (Article 4(7)), and the processor that acts on its behalf (Article 28). A builder is neither; her organisation is the controller, and she acts for it. That is the first thing to understand, because it means that "I only built a little tool" does not remove the duty. The duty belongs to the organisation and is met through its people, and a builder is one of them (4, European Union, 2016).

Four articles carry most of what a builder meets.

Principles (Article 5). Personal data must be processed lawfully, fairly and transparently, collected for specified purposes, and limited to what is necessary (Article 5(1)(c), data minimisation). For a builder, minimisation is a design question: if a tool needs a claim number to find a missing document, it does not need the claimant's name, and a column that is not needed is not read. The specification's never-do list is where this is written down.

Lawful basis (Article 6). Processing needs a lawful basis. For a public authority the usual one is a task carried out in the public interest or in the exercise of official authority (Article 6(1)(e)); for an insurer it is typically contract or legitimate interest. A builder does not choose the basis. She asks the data protection officer whether the tool's purpose is covered by a basis that exists.

Data protection by design and by default (Article 25). The controller must implement appropriate measures, such as pseudonymisation, "at the time of the determination of the means for processing and at the time of the processing itself" (Article 25(1)), and ensure that by default "only personal data which are necessary for each specific purpose of the processing are processed" (Article 25(2)). Developers are not the addressees, but the controller's measures are made of their work and of the builder's: synthetic data in the workspace, a secrets store, a tool that reads only the fields it needs. That is why the lane of Chapter 17 holds synthetic data and not a copy of production.

Security (Article 32) and the processor contract (Article 28). Security measures must be appropriate to the risk and include regular testing of their effectiveness (Article 32(1)). Where a provider processes personal data on the controller's behalf, Article 28(1) and (3) require sufficient guarantees and a contract. A builder meets this when she types anything into an assistant: a prompt can carry personal data, and the assistant's provider is then, on the usual reading, a processor, so that only the approved assistant, under the organisation's contract, is a place to put it, and a credential pasted into an unapproved one is an Article 32 matter if it gave access to personal data (4, European Union, 2016).

The impact assessment (Article 35). Where processing is likely to result in a high risk to the rights and freedoms of natural persons, the controller must carry out an assessment of the impact first (Article 35(1)). Whether a builder's tool needs one is a decision for the data protection officer, and the builder's contribution is to make the question answerable: what data, whose, for what, how long, who sees it. Infringements of the controller's and processor's obligations in Articles 25 to 39 carry administrative fines of up to EUR 10 000 000 or, for an undertaking, up to 2 per cent of total worldwide annual turnover, whichever is higher (Article 83(4)(a)).

Two further points matter for a builder. Special categories of data, among them health data, are subject to a stricter regime (Article 9), and a field that "may hold" such data counts: free text is the usual way in. And automated decision-making about individuals has its own article (Article 22); the book's reading is that a tool that decides nothing and whose output a named person reviews and sends does not engage it, and that a tool that does decide belongs to Tier D.

What this means for the two builds

Hanna Wikström's service-point-check holds no personal data at all, which the build record states in one line and the pipeline's synthetic-data rule enforces. Katarzyna Nowak's claims-doc-check reads claim identifiers, claim types and document types, which is personal data of claimants. Hansa's group data protection officer, Dr. Sabine Vogel, screened the build and narrowed its scope to property-damage claims, because injury claims may hold health data in free-text fields (Article 9) and including them would raise the tier. She recorded that no impact assessment was required for the narrowed scope (AIDR-1251, 20 October 2031). The tool reads no free-text field and logs only claim identifiers and counts. Those are Article 5(1)(c) and Article 25(2) written as a specification and enforced by a pipeline.

The AI Act

Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744 (the Digital Omnibus on AI), reaches a builder by four routes, and the first is the one most often missed (1, European Union, 2024) (5, European Union, 2026).

Literacy (Article 4). 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 them to guarantee any specific level of literacy of any individual. The Commission's question-and-answer page says that no certificate is needed and an internal record of training is enough (45, European Commission, 2026). A builder who uses an approved assistant is a person using an AI system on the organisation's behalf, so the duty reaches her: the organisation shows that it took measures. The measure in this book is the builder learning plan (BLP-*) and the record that she followed it. The duty is one of effort and cannot show that she is competent; the oracle cases and the takeover test do.

The provider test. A provider is a body that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name, and putting into service includes supply "for own use" (Article 3(3) and 3(11)). A deployer is a body that uses an AI system under its authority (Article 3(4)). The answer to the second role-test question decides which applies. A tool written with an assistant but running ordinary code is not an AI system and the Act's provider duties do not attach to it; the assistant's provider, not the builder, is the provider of the assistant. A tool that calls a model at run time to classify, rank or generate is an AI system the organisation builds for its own use, which makes the organisation its provider and its deployer, with few duties if it is not high-risk and the whole of the high-risk regime if it is (86, Nordqvist, 2026). Neither of the two builds calls a model at run time: service-point-check compares tables and claims-doc-check applies rules and fills templates, so both are ordinary software on these facts.

High-risk screening. A system is high-risk where Article 6 and Annex III say so. Two entries matter for the two organisations: systems intended to be used by or on behalf of public authorities to evaluate the eligibility of natural persons for essential public assistance benefits and services, and to grant, reduce, revoke or reclaim them (Annex III point 5(a)), and systems used for risk assessment and pricing in relation to natural persons in life and health insurance (point 5(c)). Article 25(1)(c) adds that 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 not classified as high-risk so that it becomes high-risk. For a builder this is the reason for the Tier D line: a tool that feeds eligibility or pricing is not a citizen build, and a change that turns a harmless tool into one that does is a change of tier made by use, which Step 11 asks her to notice (86, Nordqvist, 2026). A public-authority deployer of a high-risk system has further duties, among them a fundamental rights impact assessment (Article 27), and the deployer's own duties are set out in Article 26; they are the organisation's, and a builder cannot carry them.

Transparency (Article 50). Providers of systems generating synthetic text must mark outputs in a machine-readable format, except where the system performs an assistive function for standard editing or does not substantially alter the input. Whether source code is "text content" in this sense the article does not say, and no guidance was found (AI Developer, Chapter 24). For builders the question is mostly one of tools that generate text for others: a draft request to a claimant that a model wrote would raise it; one filled from a template does not. The interim control that costs nothing is a field in the provenance record that says which parts of a change an assistant generated.

Dates after the Omnibus. The Omnibus entered into force on 27 July 2026. The requirements of Chapter III, Sections 1 to 3, apply from 2 December 2027 to systems under Article 6(2) and Annex III, and high-risk systems intended for use by 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, and which the Union may amend again.

Product and liability law: when a tool becomes a product

Two instruments of 2024 treat software as a product, and each turns on a question the role test already asks: is the tool supplied to others?

The Cyber Resilience Act. Regulation (EU) 2024/2847 applies to "products with digital elements made available on the market" whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network (Article 2(1)). Making available means supply "in the course of a commercial activity, whether in return for payment or free of charge" (Article 3(22)). Recital 16 says that 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, and recital 20 that hosting on an open repository is not in itself making available; a body that is not a public administration, such as Hansa, has no such recital to rely on, and for it the test is the one of Article 3(22), whether the tool is supplied for distribution or use on the market in the course of a commercial activity (147, European Union, 2024). A builder's tool for her own team, or for another unit of her own organisation, is on the book's reading not made available on the market (for the Region by recital 16, for Hansa because nothing is supplied to anyone outside it), and the two builds are out of scope on the profile facts. The case that changes the answer is a tool that the organisation begins to supply to customers, brokers, suppliers or other bodies in the course of its business: an insurer that gives brokers a small script to check their submissions has made a product available, with the manufacturer's duties of Article 13 (secure by design, diligence on components, a support period of at least five years or the expected time of use if shorter) and of Part II of Annex I (identifying and documenting components, including by drawing up a software bill of materials) and, from 11 September 2026, the reporting duties of Article 14 (an early warning within 24 hours of becoming aware of an actively exploited vulnerability); the Regulation applies in full from 11 December 2027 (Article 71(2)). The book's reading is that this is a Tier D event for a builder and not a citizen build, and that the register entry should say "internal use only" so that a change of audience is visible.

The Product Liability Directive. 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 the mere source code of software is not a product and that a developer or producer of software, including AI system providers, 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)). Compensation covers death or personal injury, damage to property other than property used exclusively for professional purposes, and destruction or corruption of data not used for professional purposes (Article 6(1)); pure economic loss is not listed. 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)) (148, European Union, 2024). The Swedish government submitted a bill for a new product liability act on 15 October 2026, proposing it in force on 1 January 2027; the bill was read, the Riksdag's decision was not, and on the bill's terms Swedish law would apply from 1 January 2027, three weeks after the Directive's date of 9 December 2026 (73, Regeringen, 2026).

The conclusion for builders is the book's own and is modest. An internal tool, built for the organisation's own use, is unlikely to be a product under either instrument on the texts read, and the question is worth asking once, at Step 2, and again when the audience changes. A builder who is told to "just give it to the brokers" has found the stop sign. Where the answer turns to yes, the records of the twelve steps (specification, verification plan, review record, provenance, update history) are the manufacturer's evidence in two directions, and retention becomes a legal question and not a storage one.

NIS 2 and DORA: supply chain, change and ICT risk

Inside an organisation under a sector regime, the instruments that reach a builder's tool are not about the tool as a product but about how the organisation manages its systems, changes and suppliers.

NIS 2. Directive (EU) 2022/2555 requires essential and important entities to take measures that include supply chain security (Article 21(2)(d)) and security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure (Article 21(2)(e)), and to take into account the quality of their suppliers' products and secure development procedures (Article 21(3)) (3, European Union, 2022). The Swedish Cybersäkerhetslag (2025:1506), in force from 15 January 2026, applies among others to regions, municipalities and municipal associations (1 kap. 3 §), though not to a regional or municipal council (1 kap. 14 §), and lists the same measures in its 2 kap. 3 § (points 4 and 5) (9, Sveriges riksdag & Regeringskansliet, 2025). For Nordvik, a tool built inside its teams is development inside an entity: the "development and maintenance" measure covers it. The builder meets this as the template's pipeline rules (secret scanning, pinned dependencies, review before merge), which the platform team wrote so that the measure is demonstrable without a builder having to know its article number.

DORA. Regulation (EU) 2022/2554 is a sector-specific Union act: where its requirements are at least equivalent in effect to NIS 2's, the relevant provisions of NIS 2 do not apply to the financial entities it covers, among them insurance undertakings (NIS 2 Article 4(1) and (2); DORA Article 2(1)), and it asks more specifically. It requires documented policies for ICT change management, so that changes "to software, hardware, firmware components, systems or security parameters" 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. Its Article 16 asks for source code reviews covering static and dynamic testing (Article 16(3)), for non-production environments that "only store anonymised, pseudonymised, or randomised production data" (Article 16(5) and (6)), for integrity controls and for analysis and testing of third-party and open-source code before deployment, and applies the same rules, on a risk-based approach, to systems developed or managed by users outside the ICT function (Article 16(7) to (9)). Its Article 17(1)(b) and (e) require mechanisms to ensure the independence of the functions that approve changes from those that request and implement them, and fall-back procedures for aborting or recovering from changes (12, European Commission, 2024). Read for a builder: the synthetic data of the lane is Article 16(5); the pipeline that tests and scans is Article 16(3), (4) and (8); the rule that the builder does not promote her own tool is Article 17(1)(b); and the tested switch-off and restore are Article 17(1)(e). The standard speaks of functions and not of oracles, so reading Article 17(1)(b) as the legal form of the independent test oracle is the book's own step, and a short one.

Third-party rules reach the builder's assistant. A financial entity "shall, at all times, remain fully responsible" under contracted ICT services (Article 28(1)(a)), keeps a register of information on its contractual arrangements (Article 28(3)), and its contracts state the locations where data is processed (Article 30(2)(b)) and, for services supporting critical or important functions, provide for notice of developments with material impact and for exit (Article 30(3)(b) and (f)) (2, European Union, 2022). Hansa's register of information lists the contract for the development-environment assistant (HM-PROC-AIDEV-2029-01); the book's reading is that the builder lane's assistant belongs on the register too, either under that contract or as its own entry, and that the group's ICT third-party risk team decides which, because a builder cannot.

Two questions arise about what a builder makes, and neither is settled.

Who owns generated code? For computer programs created by an employee in the execution of duties or on the employer's instructions, the employer alone may exercise the economic rights unless the contract provides otherwise (Directive 2009/24/EC, Article 2(3)) (15, European Union, 2009). A builder's tool therefore belongs to her organisation by default, which is also why it must be handed over. Whether code mostly generated by an assistant is protected by copyright at all is a different question. The Directive's test is built on a person's own intellectual creation, and the book's reading, with no decision of a court of a Member State found, is that code a builder selects, edits and tests is a stronger candidate than code accepted whole and unread. The United States Copyright Office concluded in January 2025, for works in general and under United States law, that tools used to assist human creativity do not affect the protection of the output, that protection extends to the human contribution and not to purely generated material, and that prompts alone do not give sufficient control (149, United States Copyright Office, 2025). The practical rule is the provenance record: it states where an assistant took part, and it is the evidence of human contribution if the organisation must assert rights.

Licence contamination. Code that arrives with licence terms the organisation cannot meet, usually an obligation to release source code, can attach to a tool that was not meant to carry it. One study of 14 models reported that even the best-performing produced between 0.88 and 2.01 per cent of code that is strikingly similar to existing open-source implementations, and that most models failed to give accurate licence information (150, Xu et al., 2025). Some products offer a setting that suppresses suggestions matching public code, which is one vendor's control for one product (151, GitHub (n.d.), n.d.). For a builder the control is the template: dependencies are listed in a lock file, the pipeline produces a bill of materials, and the platform team's policy names the licences that may not enter. The builder's own rule is not to paste in code of unknown origin.

The map by tier

The table collects the chapter. A cell says what applies in the usual case and what the builder does; a legal point not settled is marked as the book's reading.

Instrument Tier A personal Tier B team Tier C business Tier D project
GDPR (Arts. 5, 25, 28, 32, 35) No personal data of others by definition of the tier Internal data only; minimise; approved assistant only Controller duties through the organisation; data protection officer screens; synthetic data in development Impact assessment likely; development organisation
AI Act: Art. 4 literacy Learning plan and record Learning plan and record Learning plan and record As Tier C
AI Act: provider and deployer, high-risk Not engaged unless the tool calls a model Provider test if it calls a model at run time Provider test; screening against Annex III High-risk screening is the reason for Tier D; Arts. 26, 27 are the organisation's
Cyber Resilience Act, Product Liability Directive Not engaged Not engaged Engaged only if supplied outside the organisation; register entry says internal use only Where supplied: manufacturer duties; development organisation
NIS 2 (Art. 21) and DORA (Arts. 9, 16, 17, 28, 30) Entity's rules reach only what touches its systems Template pipeline meets the measures Change, source review, independent approval, fall-back; assistant on register of information As Tier C, with the development organisation's controls
Copyright and licences Employer holds rights; provenance Provenance; licence rule in template Provenance; bill of materials; contract clauses with suppliers As Tier C
Public law (Chapter 18) Working material Register, three names Supplement; archive and accessibility answers Development organisation

Practical guide: Screening a build against the regulatory map

Purpose. Answer the five role-test questions in writing, find which instruments can reach the build, name who decides each open point and set a date at which the answers expire.

Roles. Builder (answers), deputy, the data protection officer (personal data), the platform team or the security architect (entity rules), the receiving developer (supply and licences), legal counsel (open points), the builder's manager (signs).

Inputs. The specification and its never-do list, the build record, the register entry, the list of data fields the tool reads and writes, the list of services and dependencies it uses, and the dated duty register of the organisation, if it has one.

Steps.

  1. Answer the five role-test questions from the specification. Where an answer is "I do not know", write that and stop at that row.
  2. For personal data, list the fields read, written and logged; mark any that may hold special-category data; ask the data protection officer whether an impact assessment is needed, and record the decision with its date.
  3. For AI, state whether the tool calls a model when it runs; if so, name the model's provider and the purpose, and stop until the development organisation has run the provider test and the Annex III screening.
  4. For audience, state who receives the tool or its output; if anyone outside the organisation, stop.
  5. For entity rules, name the change policy the pipeline satisfies, the register of information entry for the assistant, and the supplier clauses that cover generated code.
  6. For licences, attach the bill of materials and the licence check from the pipeline.
  7. Write the review date: 90 days for a running tool, and earlier if any instrument or the audience changes.
  8. Sign, and attach the screening to the build record.

Gate. All five role-test answers are written, every "I do not know" has an owner and a date, and the signatures are in place; the screening is valid for 90 days.

Artefact. A regulatory screening in the build record. The one for claims-doc-check:

screening: regulatory
build: BLD-HM-2031-0001
organisation: Hansa Mutual
tier: C
completed_on: 2031-12-05
read_law_on: 2031-12-05           # the dated reading; entries expire
valid_days: 90
role_test:
  personal_data: true             # claim_id, claim_type, doc_types_received, country, language
  contains_or_calls_ai: false     # rules.yaml and templates; no model at run time
  ranks_or_decides_about_persons: false
  supplied_outside_organisation: false   # internal use by claims handlers; register says internal use only
  runs_inside_regulated_entity: true     # EU financial entity; DORA applies
gdpr:
  dpo: Dr. Sabine Vogel
  decision: AIDR-1251
  scope: property-damage claims only (motor_collision, motor_parking_damage, motor_glass)
  special_category_risk: injury claims excluded; free-text fields not read
  dpia_required: false
  logs: claim ids and counts only
ai_act:
  article_4: builder learning plan BLP-HM-2031-01 followed, record kept
  provider_or_deployer: not an AI system on these facts
dora:
  change_management: group pipeline job claims-doc-check run; independent approver Tomasz Wrona
  non_production_data: synthetic claims only (SYN-0001 onwards)
  assistant_on_register_of_information: decision by group ICT third-party risk team
open_points:
  - {item: whether the builder-lane assistant needs its own register entry, owner: group ICT third-party risk team, due: 2031-12-15}
signed_by: [Katarzyna Nowak, Joanna Kaczmarek]

The two organisations

Across the degrees of delegation

The regulation does not change the delegation ladder; it fixes four places where Level 4 is never used for a builder's assistant.

Class of action Highest degree for the builder's assistant Instrument behind the limit
Edit a branch, run tests, draft documentation Level 3 Bounded within the mandate Entity change rules; GDPR Article 32 (the assistant never reads secrets or production data)
Merge, release, promote to production Level 0 Advisory: a person and the pipeline identity act DORA Delegated Regulation Article 17(1)(b) (independence of the approver)
Change the assistant's own mandate, pipeline gates or oracle cases Not delegated: Level 4 never Stewardship principle; independence of the oracle
Anything that ranks or decides about a named person Not a citizen build AI Act Annex III; GDPR Article 22; national administrative law

Nordvik Region and Hansa Mutual

At Nordvik the tool's regulation is mostly public law and the Region's role as a deployer. The Region is deployer of the procured benefits-triage system, which is high-risk under Annex III point 5(a), and provider and deployer of the benefits-explanations service it built; neither is a builder's tool, and the lane's rule at Step 2 keeps benefits data out of it. service-point-check holds no personal data and calls no model, so the instruments that reach it are the Region's change and supplier rules under the Cybersäkerhetslag, which the template's pipeline meets, the literacy measure of Article 4 (Hanna Wikström's learning plan BLP-NR-2031-01) and the public-law supplement of Chapter 18.

At Hansa the regulation is financial-sector regulation and data protection across markets. The group's DORA register of information, its rules for tools in the claims value chain, and the data protection officer's screening shape claims-doc-check. Its pipeline job is the controlled change the group's policy asks for, the independent approver is the receiving developer, its development data is synthetic, and the production export is read only by the pipeline identity. The open point at the end of the screening, whether the lane's assistant has its own entry in the register of information, belongs to the group's ICT third-party risk team and is the kind of question a builder should leave to it.

When to call a developer

Stop and call the data protection officer, counsel or the development organisation when the tool reads a field that may hold special-category data; when it calls a model at run time; when it feeds anything about a named person's eligibility, pay, ranking or access to work; when anyone outside the organisation is to receive it; when it will run in a regulated entity's production environment without the pipeline's change path; when a supplier contract does not mention generated code; and when a dated duty in the register is more than six months old.

Observable, expected, speculation

Observable. The instruments and articles cited are decided law, read as recorded in the bibliography on the dates given there. The GDPR's duties on the controller, Article 4's literacy duty as replaced, the Cyber Resilience Act's reporting duty from 11 September 2026 and DORA's change and third-party rules are in force or have dates fixed in the texts (4, European Union, 2016) (147, European Union, 2024) (2, European Union, 2022).

Expected. The Product Liability Directive applies to products placed on the market after 9 December 2026; the AI Act's high-risk requirements apply from 2 December 2027 and, for systems intended for public authorities, by 2 August 2030; the Cyber Resilience Act applies in full from 11 December 2027. How these apply to a tool a non-developer builds for her own organisation is expected to be settled by guidance and practice; on the texts read it is mostly outside their scope, and a change of audience is what changes that.

Speculation. That regulators will issue guidance specific to citizen developers, or that an authority will treat a builder's tool as a product, is plausible and has no evidence behind it.

Summary

Law is not the builder's job, but she holds the facts that decide which instruments apply, and five questions on the specification (personal data, AI, persons ranked or decided, audience, entity rules) are enough to point to the right ones. The GDPR attaches to the organisation as controller and reaches the builder through minimisation, design and default, security and the processor contract. The AI Act asks the organisation to support the literacy of those who use AI systems on its behalf, decides the provider and deployer roles by whether the tool calls a model, and draws its high-risk line where Tier D begins. The Cyber Resilience Act and the Product Liability Directive turn on whether the tool is supplied to others in the course of a commercial activity, which an internal builder's tool is not. NIS 2 and DORA reach the builder through the entity's change, supplier and source-review rules, which a good template makes the builder's default. Copyright and licences are answered by the provenance record and the bill of materials. The chapter concerned Step 2 Tier, Step 8 Secure and Step 11 Own, and the functions D1 Frame, D2 Design, D4 Prove and D5 Steward.

The screening is the practical result: five answers, a named owner for each open point and a date at which the reading expires. The next chapter, Chapter 20, stages the debate that the whole part has prepared: whether everyone should build.

Sources

  1. 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)
  2. 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)
  3. European Parliament and Council of the European Union. Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 (Digital Omnibus on AI). Official Journal of the European Union, 24 July 2026. (5, European Union, 2026)
  4. European Commission. AI Literacy: Questions and Answers. Shaping Europe's digital future. (45, European Commission, 2026)
  5. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 (Cyber Resilience Act). Official Journal of the European Union, 20 November 2024. (147, European Union, 2024)
  6. European Parliament and Council of the European Union. Directive (EU) 2024/2853 on liability for defective products. Official Journal of the European Union, 18 November 2024. (148, European Union, 2024)
  7. Regeringen (2026). Regeringens proposition 2026/27:12 En ny produktansvarslag. 15 October 2026. (73, Regeringen, 2026)
  8. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
  9. Sveriges riksdag, Regeringskansliet. Cybersäkerhetslag (2025:1506). Svensk författningssamling. (9, Sveriges riksdag & Regeringskansliet, 2025)
  10. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 (Digital Operational Resilience Act, DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
  11. European Commission (2024). Commission Delegated Regulation (EU) 2024/1774, Articles 16 and 17. Official Journal of the European Union, 25 June 2024. (12, European Commission, 2024)
  12. European Parliament and Council of the European Union (2009). Directive 2009/24/EC on the legal protection of computer programs, Articles 1 and 2. Official Journal of the European Union L 111, 5 May 2009. (15, European Union, 2009)
  13. United States Copyright Office (2025). Copyright and Artificial Intelligence, Part 2: Copyrightability. (149, United States Copyright Office, 2025)
  14. Xu, W., Gao, K., He, H. & Zhou, M. (2025). LiCoEval: Evaluating LLMs on License Compliance in Code Generation. ICSE 2025; arXiv:2408.02487. (150, Xu et al., 2025)
  15. GitHub (n.d.). Managing GitHub Copilot policies as an individual subscriber. GitHub Docs. (151, GitHub (n.d.), n.d.)
  16. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Transformed Architecture, Book 2. (75, Nordqvist, 2026)
  17. Nordqvist, G. (2026). AI Leader: How Leadership Roles Change When AI Is Used Broadly in European Enterprises and Public Authorities. The Transformed Architecture, Book 11. (85, Nordqvist, 2026)
  18. Nordqvist, G. (2026). AI Developer: How the Developer Role Changes When AI Is Used Broadly in European Enterprises and Public Authorities. The Transformed Architecture, Book 12. (86, Nordqvist, 2026)