Builders in the Public Authority: Procurement, Records, Accessibility and Legitimacy

An official who builds a tool on a Friday afternoon, with an AI assistant, for her own team, is doing something that a private company's employee can do with fewer consequences. The authority she works for acts under public law. What it keeps is, in many member states, a public record that anyone may ask to read. What it publishes on the web has to be accessible. What it buys is bought under procurement rules. And the people it serves cannot choose another authority, so they have a stronger claim than a customer has to know that what is done in their name is done lawfully and by someone who answers for it. This chapter takes those four constraints in turn and asks what each means for a builder who is not a developer. It concerns Step 2 Tier, Step 5 Design and Step 11 Own, and the developer functions D1 Frame, D2 Design and D5 Steward: the tier decision is where the public-law line is drawn, the design is where accessibility and records are decided, and ownership is where accountability stays with a named person.

Public-law duties on the builder's path: records, accessibility, procurement and legitimacy end in a supplement to the build record

Figure 18.1: Public-law duties on the builder's path. A build that concerns casework or a decision about a person leaves the lane for the development organisation.

The chapter's organisation is Nordvik Region, a regional authority in a Nordic member state, and its law is the Swedish pattern that the earlier volumes used: where a statement concerns a Swedish text, the chapter says so, and where it concerns EU law that applies in every member state it says that. Other member states have their own public-access, archive and administrative law, and the reader in another state should read the principle and replace the instrument. Every legal point is an organisational implication and not legal advice. The chapter builds on AI Developer, Chapter 18, which treated the developer in the public authority (procurement of coding tools, public code, accessibility, archives and accountability), and on AI Governance, Chapter 14, and takes from both the conclusion that in a public authority legality comes before capability (86, Nordqvist, 2026) (75, Nordqvist, 2026). What is new here is the builder: a person with no training in administrative law, who is nonetheless an agent of the authority when she builds.

A tool built by an official

A tool built by an official is the authority's tool. That sentence is the foundation of the chapter, and it follows from a point of organisation and not a new rule: the authority acts through its employees, and what an employee produces in the course of work for the authority is produced for it. The consequence for a builder is that the questions she would ask of a purchased system apply to hers. Who is accountable for it? Under what legal authority does it act? What does it keep, and for whom? Can a resident or a colleague see what it does?

The Swedish Administrative Procedure Act states the first principles in terms that fit a builder's tool. An authority may act only where the legal order gives support and must be objective and impartial (section 5), and these principles of good administration apply to all administrative activity of an authority, not only to the handling of a matter (section 1). Within the handling of matters, a party must be told of material that matters to a decision before it is taken, unless that is obviously unnecessary (section 25), and a decision that may affect someone's situation to a not insignificant degree must carry reasons stating the rules applied and the circumstances that were decisive (section 32). A decision may be taken by an official alone, by several together, or in an automated way (section 28) (68, Sveriges riksdag, 2017). One limit matters for a region: in matters handled by a municipal or regional authority whose decisions can be reviewed by the lawfulness procedure of Chapter 13 of the Local Government Act, sections 23 to 49 of the Administrative Procedure Act, and so sections 25, 28 and 32, do not apply, while section 5 does (section 2). The three sections therefore describe the Region's casework where decisions are appealed in the ordinary way, as most decisions about individuals are, and not its decisions of the lawfulness-review kind. A municipal or regional committee may delegate decision-making to "an automated decision function" in a given matter or group of matters (Kommunallag 6 kap. 37 §), but not in matters where the decision is appealed under Chapter 13, where the decision may not be appealed at all, or in procurement and certain choice systems (6 kap. 38 § second paragraph) (46, Sveriges riksdag, 2017). The Region's council has decided, as AI Leader, Chapter 24, records, that no such function exists, so that a build in which a step of case handling decides without a person lies outside the delegation order (85, Nordqvist, 2026).

For the builder this settles the tier question first. A tool that ranks, selects or decides about a named person, that feeds a case, or that sits in a security-critical path is Tier D, and Tier D is not a citizen build (Chapter 6). A public authority has more of these tools than a private one, because more of its work is casework, and the builder's honest answer to "is this casework?" decides whether the lane is open to her. The test is the one of AI Developer, Chapter 19: does the tool rank or decide about a named person, or feed a high-risk AI system? In a regional authority the Annex III point 5(a) category, systems intended to evaluate the eligibility of natural persons for essential public assistance benefits and services, is the one that matters, and a builder who touches benefits data is almost certainly at that line (Chapter 19 treats the AI Act) (1, European Union, 2024). The Region's rule is that a person who answers yes writes the question on the build record and the development organisation takes the tool over from the first day, or it is not built.

Accountability then needs three names, not one. AI Developer, Chapter 18, put it as a rule for systems: record, per system, which office decides, which office owns the rule, and which team owns the code, so that none of the three is "the system" (86, Nordqvist, 2026). For a builder's tool the same three names go in the build record. A tool that only reports (as Hanna Wikström's does) has no deciding office; it has an owner who is the builder, and a deputy. The point of writing the three names down is that on the day something is wrong, a colleague or a resident asks "who is responsible?" and the answer is a person, not an application.

Whether and when an official's act in building a tool could engage the liability provisions that govern the exercise of public authority is not a question this book answers. The Swedish Tort Liability Act provides that the State or a municipality compensates damage caused by fault or negligence in the exercise of public authority (3 kap. 2 §; a region counts as a municipality for this chapter of the act), and that an employee is liable for damage caused in the service only where there are exceptional grounds (4 kap. 1 §) (70, Sveriges riksdag, 1972). The Criminal Code (20 kap. 1 §) makes intentional or negligent disregard of what applies to a task in the exercise of public authority an offence (misconduct in office), unless the act is petty; that provision is not in this book's bibliography and is stated here from the statute text. Their application depends on whether the person exercises public authority, and an official who maintains a report on opening hours does not. The practical conclusion is the narrower one above: keep the three names, and keep the tool out of casework.

Records and public access

The second constraint is that the things the builder makes may be records. In the Swedish model the Freedom of the Press Act, Chapter 2, gives a right of access to public documents, and a document is public when it is held by an authority and has been received or drawn up there (sections 3, 4, 9 and 10) (69, Sveriges riksdag, 1949). The Archives Act says that an authority's archive consists of its public records, serves public access, the needs of justice and administration and research, and must be preserved and kept in order by the authority, with disposal permitted by section 10 subject to the purposes of the archive and to deviating rules in other law (50, Sveriges riksdag & Regeringskansliet, 1990). Other member states regulate access and archives differently, and some give a narrower right; the general question is the same everywhere there is such a right: which of the builder's artefacts are records, and for how long must they be kept?

Two further points come from the same text. A document that has not been sent out is treated as drawn up when the matter it belongs to has been concluded or, if it belongs to no matter, when it has been finalised (section 10), and a document is received when it has arrived or reached a competent official (section 9). Three kinds of artefact are likely to be records on the Swedish pattern once these conditions are met, and the book's reading, which is its own and no authority's ruling, is that the same is likely in other states. The specification record and the Architecture Decision Record state what the tool must do and why. The build record, the ownership record and the handover pack document who is accountable and what was handed over. The run record shows what an assistant executed, under which mandate and with what result. They are produced in the course of the authority's work and held by it.

The uncertain case is the prompt: the instruction that the builder typed to the assistant. Whether a prompt, or the code the assistant returned before the builder edited it, is a public document or working material is a question that the Region's archivist and legal counsel did not answer for developers in AI Developer, Chapter 18, and this book does not answer it either; no decision of a court or an authority supporting an answer was found. The question has two sides. Keeping every prompt keeps whatever the builder typed, including a case reference she should not have pasted and her own working habits, which is a risk under data minimisation in the General Data Protection Regulation (Article 5(1)(c)) and a matter for the employee representatives (4, European Union, 2016). Keeping none leaves a build that cannot be reconstructed after an incident. A position that fits both sides is a retention class decided with the archivist before the lane opens: run records and accepted outputs are kept with the build record, prompts are kept for a short fixed period in the tool's log for incident review and then removed, and the decision about the period is itself recorded. That is the Region's choice and not a rule of law.

A third consequence concerns the algorithm register. AI Governance, Chapter 17, concluded that a public authority's register of algorithms should be generated from version-controlled entries (75, Nordqvist, 2026). A builder's tool that only reports does not enter that register, which concerns systems that support decisions about residents. Its entry in the builder register does the work of making the tool findable, and the build record states that the tool is not a decision-support system. If the tool changes in a way that makes it one, the entry moves, and so does the tier.

Requests for access are answered by the competent official on grounds fixed in law, with the builder's help in finding the material and not by the builder. The Region's rule is that a builder who receives a request forwards it the same day to the registry.

The archivist's view, Nordvik Region

The Region's archivist, consulted before the workspace opened, recorded the following position for the builder lane, in the form of an Architecture Decision Record in the platform team's repository. The records of a build (specification, build record, ownership record, runbook, handover pack and the decision records) are kept with the tool for as long as the tool exists and for the retention class of the Region's general plan afterwards. Run records and accepted outputs are kept with the change they belong to. Prompts are working material for the purpose of the lane, kept for 30 days in the assistant's log, readable by the platform lead and the builder's manager for incident review and not for appraisal of the builder, and then removed. The archivist noted that this does not settle whether a prompt is a public document, that a request received during the 30 days is treated as a request for a document held, and that the position is reviewed when a court or the supervisory authority decides the question. The book records the position as an illustration of a method: decide what is kept on purpose, write down why, and name the review trigger.

Accessibility

The third constraint is accessibility. Directive (EU) 2016/2102 requires member states to ensure that public sector bodies take the necessary measures to make their websites and mobile applications more accessible by making them perceivable, operable, understandable and robust (Article 4), within an exception for disproportionate burden that the body must assess and explain in its accessibility statement (Article 5), with a presumption of conformity for content that meets harmonised standards or, where no references to them have been published, the relevant requirements of European standard EN 301 549 (Article 6), and with an accessibility statement and a feedback mechanism (Article 7) (11, European Union, 2016). It applied to websites from 23 September 2019 (for sites published on or after 23 September 2018) and 23 September 2020 (for others), and to mobile applications from 23 June 2021 (Article 12). A mobile application, for the Directive, is software designed and developed by or on behalf of public sector bodies for use by members of the general public (Article 3). The Swedish act on accessibility of digital public services applies to the digital services of state and municipal authorities and of the decision-making assemblies of municipalities and regions, and equates certain other bodies with them, such as publicly controlled bodies and some privately run, publicly funded schools, health care and social services (section 4; the wording of that section is replaced from 1 January 2027). It requires that a digital service provided through a solution under the authority's control meet the accessibility requirements set in regulations under the act (section 10), and, so far as possible, a service on a third party's solution (section 11). The authority need not comply where compliance would be unreasonably burdensome (section 12), and it must provide an accessibility statement with a way to report failures, stating any such assessment (section 13) (152, Sveriges riksdag, 2018).

What applies to an internal tool, and what to a public one

The question for a builder is which of her tools these rules reach. The Directive's text gives three signposts, and the chapter's reading of them is the book's own and a question for the authority's accessibility specialist and counsel.

The first is audience. The Directive's definition of a mobile application speaks of use by the general public, and the requirement of Article 4 concerns websites and mobile applications of public sector bodies. A tool that produces a file or a page read only by staff does not reach the public. The second is the exclusion of intranets and extranets: the Directive does not apply to the content of closed-group sites not aimed at the general public that were published before 23 September 2019, until they undergo a substantial revision (Article 1(4)(g)). That exclusion is dated, which means that a new internal web page created in 2031 is not covered by it, and that whether such a page falls within the Directive is not a question the exclusion answers. The prudent reading is that a new web interface built for staff is held to the same standard as any other, and the authority's own accessibility rule often says so; whether the Directive requires it is a different question. The third is third-party content and archives (Article 1(4)(e) and (h)), which a builder rarely meets.

For a builder this is a design question. A tool that writes a plain text file or a table into an existing wiki page inherits the accessibility of the wiki and adds nothing of its own to test. A tool that creates a new web page, a form or a mobile application brings new interface code, and generated interface code is not accessible by default. No verified study of the accessibility of code that coding assistants generate was found for this book, and the chapter makes no claim about it. What is documented is the baseline of the web: in February 2025, automated testing of one million home pages found detectable failures of WCAG 2 on 94.8 per cent, with about 51 detected errors per page, and the report cautions that automated detection does not show that a page without detected errors is accessible (153, WebAIM, 2025). That is not a finding about assistants or about public authorities. It is enough to say that an accessible interface is not the default result of code that looks like the code on the web.

The European Accessibility Act, Directive (EU) 2019/882, applies from 28 June 2025 to listed products and services offered to consumers. It covers, among others, e-commerce services and the self-service terminals of passenger transport, and its recital 46 explains that the 2016 Directive defines the requirements for public sector websites and applications, and that activities on such sites that fall within the Act, such as passenger transport or e-commerce services, should in addition comply with it (14, European Union, 2019). A builder's internal tool is not a service offered to consumers. For Nordvik the two instruments meet at regional public transport, where the terminal and the ticketing website may fall under different regimes, which is a matter for the transport function's accessibility lead and not for a builder.

The builder's rule is therefore short. Say in the specification whether the tool has a user interface, who uses it and whether any user is a resident. If it has none, write "no interface; outputs are plain text in an existing page" and test that claim by looking at the output. If it has one for staff, reuse a component from the Region's design system and add the accessibility check to the oracle cases (Chapter 11). If it has one for residents, it is not a builder's tool.

Procurement of builder platforms and assistants

The fourth constraint is procurement. A builder does not buy anything; the authority buys the workspace, the assistant and the template platform, and what it buys decides what builders can do. The EU procurement directive for public contracts, Directive 2014/24/EU, requires an authority to treat economic operators equally and act transparently and proportionately, and forbids designing a procurement to narrow competition artificially (Article 18(1)). Technical specifications for procurement intended for use by people should, except in duly justified cases, take into account accessibility criteria for persons with disabilities or design for all users (Article 42(1)); and they should not name a specific make, source, trade mark or patent unless the subject matter justifies it, and then only with the words "or equivalent" (Article 42(4)) (13, European Union, 2014). Award is to the most economically advantageous tender, which may be identified by a best price-quality ratio where quality includes accessibility and design for all users (Article 67(2)) (51, European Union, 2014). Conditions for performance of the contract may cover social and other considerations if linked to the subject matter and stated in the procurement documents (Article 70). A contract may be modified during its term without a new procedure only within the limits of Article 72, which names clear and precise review clauses in the original documents, certain additional supplies or services, circumstances that a diligent authority could not have foreseen and non-substantial changes (13, European Union, 2014).

These articles shape a builder platform in four ways, and each is a design decision for the authority and not a builder's task. First, the tender describes the function and the ceiling, and not the brand: "an assistant for non-developers that runs in a sandbox with no route to production, on a model the Region can host or that the supplier hosts in the European Economic Area, with an administrative switch that limits it to Mode 2 and Mode 3" passes the test of Article 42(4); "the market-leading assistant" does not. Second, the accessibility of the tool's own interface is a criterion, since the builder and her colleagues are users. Third, the review clause of Article 72 matters because the supplier of an assistant changes the model, the price and the features at short notice. A tender with no clause that says how model changes and new agentic features are handled will find that the changes the authority needs are either substantial and need a new procedure, or are not available. The clause makes a model change an event that triggers a retest against the builder mandate, and so a reason for refusing the change. Fourth, exit: the Data Act's rules on switching between data processing services oblige providers to remove obstacles to switching, with contract terms of at most two months' notice and a mandatory transitional period of at most 30 calendar days (Article 25(2)), and withdraw switching charges from 12 January 2027 (Article 29) (6, European Union, 2023). Whether a hosted assistant meets the Act's definition of a data processing service is a question for the authority's counsel and this chapter does not conclude it. The criteria ask for export of prompt history and configuration in any case, because an assistant whose history cannot be exported ties the authority to the supplier even where the law gives no remedy (AI Leader, Chapter 26, concluded that a dependency accepted without an exit has not been decided).

The Commission's model contractual clauses for the procurement of AI, which buyers may use and customise, are a starting point; they are written for AI systems in general, and they do not know the repository, the branch or the builder's mandate, which the authority adds (48, European Commission, 2025). The NIS 2 Directive asks essential and important entities to weigh supply chain security and the quality of suppliers' secure development practices (Article 21(2)(d) and (e) and 21(3)), and the Swedish Cybersäkerhetslag applies to regions among others, so that counsel confirms what the Region's builder platform has to show (3, European Union, 2022) (9, Sveriges riksdag & Regeringskansliet, 2025). Chapter 19 returns to this.

The builder's part in procurement is to supply what only a user knows: which of the template's pipeline rules she met first, which the assistant's refusals blocked, whether the sandbox's synthetic data was good enough to build against. The platform team collects that in the dry run (Chapter 17) and carries it into the next tender's criteria.

Legitimacy

The last constraint is the least legal. A resident cannot be asked to trust what an official built on a weekend. That is not an accusation, because most such tools are harmless and many are good. It is a statement about what a public authority owes the people whose affairs it handles, which is more than that the tool works. They are owed that the tool is known to exist, that someone answers for it, that it does not do what only a person may do, and that its failure can be seen and corrected.

Two documented cases show what happens when a rule is encoded without examination. The Royal Commission into the Robodebt scheme in Australia described the scheme as "a crude and cruel mechanism, neither fair nor legal", and the Federal Court had found it unlawful in 2019, as the Prime Minister's statement on the report records (72, Prime Minister of Australia, 2023). The Dutch data protection authority investigated the processing of the nationality of applicants for childcare benefit and in 2020 found three kinds of processing unlawful, among them the use of nationality as an indicator in a system that automatically selected applications for review (71, Autoriteit Persoonsgegevens, 2020). The Hague District Court's SyRI judgment of 5 February 2020 is a third reference point for what an unexplained selection looks like when it reaches a court (49, Rechtbank Den Haag, 2020). None involved AI coding tools or builders. They show what an unexamined translation from rule to system can do to people. That generated code makes the translation cheaper without making it more examined is this book's own conclusion, not a finding of any of the three sources.

Legitimacy for a builder's tool rests on four things that cost little. The tool is in the register, so that it can be found. It names its owner and its deputy, so that it can be answered for. It says what it does not do (the specification's never-do list), and the pipeline enforces what it can. And it stays out of casework unless the development organisation has taken it over, with the mandate, the impact assessment and the decision record that Tier D requires. A resident who reads the register entry for service-point-check sees a tool that compares opening hours and writes to a wiki page for staff. That is a statement the Region can stand behind, and it is the reason the chapter prefers a boring tool.

Practical guide: A public-authority checklist for a builder

Purpose. Check a build against the public-law duties of the authority before it is promoted from Tier B to Tier C, and attach the result to the build record.

Roles. Builder (accountable for the answers), deputy, receiving developer, the authority's registry or archivist, the accessibility specialist, the data protection officer, the builder's manager, and, for any procurement question, the procurement officer.

Inputs. The build record, the specification, the tier decision, the register entry, the retention class of the lane, the authority's accessibility rule and the list of services the tool reads or writes.

Steps.

  1. Casework. Does the tool rank, select or decide about a named person, feed a case or touch benefits data? If yes, stop: the tool is Tier D, and the development organisation takes it over.
  2. Three names. Write the deciding office (none, for a reporting tool), the office that owns the rule the tool encodes, and the team that owns the code.
  3. Records. List the artefacts the tool produces and keeps; mark each as record, working material or not kept, with the retention class agreed with the archivist, and state where prompts and run records are kept and for how long.
  4. Access. State who receives a request for access to the tool's material and confirm that the builder forwards it to the registry the same day.
  5. Accessibility. State whether there is a user interface, who uses it and whether any user is a resident. If there is a staff interface, name the design-system component used and the oracle case that tests it; if there is none, state how the output was checked.
  6. Procurement. List the services bought for the tool (assistant, workspace, hosting) and the contract through which each is bought; state whether any new purchase has been made outside procurement and, if so, stop.
  7. Legitimacy. Confirm that the register entry reads as a statement the authority can stand behind, in words a resident would understand.
  8. Sign. The builder and her manager sign; the archivist and the accessibility specialist confirm the points that concern them; the date and the validity (90 days for a running tool) are recorded.

Gate. The supplement is complete, every point has an answer or "not applicable, because ...", and any "yes" at step 1 or "stop" at step 6 has been acted on.

Artefact. A public-authority supplement to the build record. The one for service-point-check:

supplement: public-authority
build: BLD-NR-2031-0001
organisation: Nordvik Region
completed_on: 2031-12-10
valid_days: 90
casework:
  ranks_or_decides_about_persons: false
  touches_benefits_data: false
  reasoning: reads opening hours and notices of 24 service points; writes a weekly report for staff
three_names:
  deciding_office: none
  rule_owner: e-services team, product owner Hanna Wikström
  code_owner: Hanna Wikström, deputy Elin Berg
records:
  specification: record, kept with the tool
  build_record_and_ownership: record, kept with the tool
  run_records_and_accepted_outputs: kept with the change
  prompts: working material, kept 30 days, then removed   # archivist's position, ADR 0003
access_requests: forwarded to the registry the same day
accessibility:
  user_interface: none
  output: plain table in the e-services wiki page "Service point check"
  checked_by: Saga Edvardsson
  checked_on: 2031-12-09
  note: if a web page for residents is ever generated, the tool leaves the lane
procurement:
  services: [builder workspace (AIDR-1200), approved assistant of the builder workspace]
  purchases_outside_procurement: none
legitimacy:
  register_entry_text: Compares opening hours for 24 service points in three places and reports differences to staff. Writes nothing to the portal.
signed_by: [Hanna Wikström, Gunilla Roos]
confirmed_by: [archivist, accessibility specialist]

The two organisations

Across the degrees of delegation

Tier Public-law reading Assistant at most
A personal Private working notes; still the authority's material if they concern the authority's work Level 2 Supervised
B team A tool for colleagues; in the register, with the three names Level 2 Supervised, Level 3 Bounded for tests and formatting
C business A tool others depend on; supplement attached; archive and accessibility questions answered Level 3 Bounded for listed classes
D project Casework, decisions about persons, benefits data; the development organisation, with a mandate and an impact assessment Not a citizen build; Level 4 never for a decision about a named person's access to work

Nordvik Region and Hansa Mutual

At Nordvik, service-point-check is internal and not casework. The checklist shows why it stays so: it reads opening hours and notices only, it never writes to the portal, the phone script or the notices spreadsheet (the never-do of its specification), and its output is a table in a staff wiki page. It has no deciding office. If it ever wrote to the portal, it would change what residents read, and the question of accessibility of public web content and the question of who answers for an official's weekend tool would both open at once, which is the reason the specification forbids it. The archivist's position on prompts (30 days in the assistant's log, then removed) is recorded as an Architecture Decision Record in the platform team's repository, with the review trigger stated.

Hansa Mutual is a private insurer and outside Directive (EU) 2016/2102. The chapter applies to it only by contrast, and the contrast is an observation of the book and not a finding of a source. In several of its markets Hansa deals with public bodies as customers or counterparties, and a public body's duties then reach the group through contract clauses (accessibility of what it supplies, retention of records, an exit clause), which are met by the same artefacts that the Region keeps: the build record, the register entry and the retention class. Whether the group's customer portal is an e-commerce service within the European Accessibility Act is a question for its counsel, and claims-doc-check is not that portal: it is an internal tool, it writes draft texts that a claims handler reviews and sends, and it never sends a message itself.

When to call a developer

Stop and call a developer, the registry or counsel when the answer to the casework question is yes or uncertain; when the tool would write to anything residents read; when a request for access names a builder's material; when a purchase for the build has been made outside procurement; when an assistant's log would keep case content; or when a court, a supervisory authority or the archive authority decides a question this chapter marks as open.

Observable, expected, speculation

Observable. The accessibility directive, the procurement directive, the access and archive rules and the administrative-procedure rules cited are decided law, and the authors of the cited reports and judgments have stated what they found. Automated tests of a million home pages find detectable accessibility failures on most of them (153, WebAIM, 2025).

Expected. Public authorities will be asked, by auditors, supervisory authorities and the press, what records an AI assistant leaves and what a builder's tool is for. The question whether a prompt is a public document is expected to be decided in some member states in the coming years; its answer is open.

Speculation. That the retention class chosen here will survive a court's decision unchanged, or that builders in authorities will be asked to publish their tools as public code, is plausible and has no evidence behind it.

Summary

A tool built by an official is the authority's tool, and public law reaches it through four constraints. Accountability needs three names (the deciding office, the rule owner, the code owner) and keeps casework out of the lane, so that Tier D is the development organisation's. Records and public access raise a question for every artefact, and the open case of the prompt is handled by a retention class decided with the archivist and a stated review trigger. Accessibility attaches to the interface, and a tool without one inherits the accessibility of the page it writes to. Procurement shapes what builders can do through the tender's function and ceiling, an accessibility criterion, a review clause and an exit. Legitimacy is the sum: a tool that is findable, answered for, limited and open to correction. The chapter concerned Step 2 Tier, Step 5 Design and Step 11 Own, and the functions D1 Frame, D2 Design and D5 Steward.

The checklist is the practical result: a supplement to the build record that the builder signs and that the registry and the accessibility specialist confirm. The next chapter widens the lens from public law to the regulation that applies to every builder, public or private: data protection, the AI Act, product and liability law, and the supply-chain and resilience rules of NIS 2 and DORA.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 (Artificial Intelligence Act), Annex III point 5(a). (1, European Union, 2024)
  2. Sveriges riksdag. Förvaltningslag (2017:900). Svensk författningssamling. (68, Sveriges riksdag, 2017)
  3. Sveriges riksdag. Kommunallag (2017:725), 6 kap. 37 and 38 §§. Svensk författningssamling. (46, Sveriges riksdag, 2017)
  4. Sveriges riksdag. Skadeståndslag (1972:207). Svensk författningssamling. (70, Sveriges riksdag, 1972)
  5. Sveriges riksdag. Tryckfrihetsförordning (1949:105), Chapter 2. Svensk författningssamling. (69, Sveriges riksdag, 1949)
  6. Sveriges riksdag, Regeringskansliet. Arkivlag (1990:782). Svensk författningssamling. (50, Sveriges riksdag & Regeringskansliet, 1990)
  7. 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)
  8. European Parliament and Council of the European Union. Directive (EU) 2016/2102 on the accessibility of the websites and mobile applications of public sector bodies. Official Journal of the European Union L 327, 2 December 2016. (11, European Union, 2016)
  9. Sveriges riksdag (2018). Lag (2018:1937) om tillgänglighet till digital offentlig service. Svensk författningssamling. (152, Sveriges riksdag, 2018)
  10. European Parliament and Council of the European Union (2019). Directive (EU) 2019/882 on the accessibility requirements for products and services (European Accessibility Act). Official Journal of the European Union L 151, 7 June 2019. (14, European Union, 2019)
  11. WebAIM (2025). The WebAIM Million: An annual accessibility analysis of the top 1,000,000 home pages (2025 report). WebAIM. (153, WebAIM, 2025)
  12. European Parliament and Council of the European Union (2014). Directive 2014/24/EU on public procurement, Articles 18, 42, 70 and 72. Official Journal of the European Union L 94, 28 March 2014. (13, European Union, 2014)
  13. European Parliament and Council of the European Union (2014). Directive 2014/24/EU, Article 67 (Contract award criteria). (51, European Union, 2014)
  14. European Parliament and Council of the European Union. Regulation (EU) 2023/2854 (Data Act). (6, European Union, 2023)
  15. European Commission, Community of Practice on the Procurement of AI (2025). Updated EU AI model contractual clauses now available. (48, European Commission, 2025)
  16. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (3, European Union, 2022)
  17. Sveriges riksdag, Regeringskansliet. Cybersäkerhetslag (2025:1506). (9, Sveriges riksdag & Regeringskansliet, 2025)
  18. Prime Minister of Australia (2023). Final report of the Royal Commission into the Robodebt Scheme. Media statement, 7 July 2023. (72, Prime Minister of Australia, 2023)
  19. Autoriteit Persoonsgegevens (2020). Belastingdienst/Toeslagen: De verwerking van de nationaliteit van aanvragers van kinderopvangtoeslag. (71, Autoriteit Persoonsgegevens, 2020)
  20. Rechtbank Den Haag (2020). Judgment of 5 February 2020, NJCM c.s. v the State of the Netherlands (SyRI), ECLI:NL:RBDHA:2020:1878. (49, Rechtbank Den Haag, 2020)
  21. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Transformed Architecture, Book 2. (75, Nordqvist, 2026)
  22. 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)
  23. 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)