Developers in the Public Authority: Procurement, Public Code and Legitimacy

A developer in a public authority writes software that carries law into action. The case system applies a statute to a resident, the portal is the only door some residents can use, and the code that sits behind both is, in most countries, a public document that anyone may ask to read. This chapter concerns three of the five developer functions. D1 Frame is the task of turning a legal rule and a public need into intent that can be built and tested. D2 Design is the choice between building and buying, and the constraints that procurement, accessibility and public access place on the design. D5 Steward is the duty to own software that the public has paid for, that others may reuse and that must be kept as a record. D3 Build and D4 Prove appear where the toolchain and its evidence are part of the argument.

The chapter works through Nordvik Region and one tender, NR-2030-041, for development assistants in Applications and Integration. It asks how AI coding tools are procured under public procurement law, what public code and open source ask of an authority, how accessibility, archives and transparency bind development, how public-law accountability reaches the developer, and when in-house development is better than a supplier. Nordvik's administrative law follows the Swedish pattern, as in the earlier volumes; the chapter marks where a statement concerns Swedish texts and where it concerns EU law that applies in every member state. Every legal point is an organisational and architectural implication and not legal advice. Hansa Mutual, a private insurer under financial-sector supervision, appears for contrast.

From need to procured tool in a public authority: the written criteria, the contract and the delegation profile bound the tool, a named steward holds the stop path, and records, public code and exit follow from the same chain.

Figure 18.1: From need to procured tool in a public authority.

Why the public authority is a different place to develop

The previous chapters described the developer role in general. This chapter describes the setting in which the role carries the most borrowed authority. Three features distinguish it.

First, legality comes before capability. AI Governance, Chapter 17 concluded that in a public authority the line between decision support and automated decision is drawn in the data model and the audit log, and that every case has a reasons log. AI Leader, Chapter 18 added that the leader works inside a legal chain of delegation from the council, and that reasons, hearing and appeal are design requirements which AI support must leave intact. For the developer the conclusion is concrete. The Administrative Procedure Act requires that an authority act only where the legal order gives support and be objective and impartial (section 5), that a party be told of material that matters to the decision before it is taken (section 25), and that a decision that may affect someone's situation to a not insignificant degree carry reasons that state the rules applied and the circumstances that were decisive (section 32) (154, Sveriges riksdag, 2017). A case system that cannot produce the material for section 25 or the reasons for section 32 makes lawful administration impossible. The developer who frames the requirement (D1) starts from the provision, not from the screen.

Second, software that mis-encodes the law harms people at scale and the record shows it. The Royal Commission into the Australian Robodebt scheme described the scheme as "a crude and cruel mechanism, neither fair nor legal", and the Federal Court found it unlawful in late 2019, as the Prime Minister's statement on the report records (159, 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 (158, Autoriteit Persoonsgegevens, 2020). Neither case involved AI coding tools. They show what an unexamined translation from rule to system can do; that generated code makes the translation cheaper without making it more examined is this book's own conclusion, not a finding of either source.

Third, the public pays for the code and the public may read it. Public procurement law constrains how the tool is bought. Accessibility law constrains what is built. Public-access and archives law constrain what is kept and what may be asked for. The sections that follow take the constraints in the order a developer meets them: purchase, publication, accessibility, records, answerability.

Procurement of AI coding tools

Procurement is where the mandate and the means of a development organisation are fixed, as it is for leaders (AI Leader, Chapter 18). A developer is not the contracting authority, but is the person who knows what the tool does in the codebase, and the criteria are only as good as that knowledge.

What is being bought

A coding tool bought by an authority is several things at once: a client in the editor, a hosted or self-hosted model, a gateway or account service, logs, and, increasingly, an agentic mode that opens pull requests. In the vocabulary of the series the client and the chat are Mode 2 (embedded workplace assistants), the agentic mode is Mode 3 (agentic work tools), and the Region has no Mode 5 and no coding agent beyond the platform team. The tender must describe the function it wants and the ceiling it will allow, not the brand. Directive 2014/24/EU requires an authority to treat economic operators equally and act transparently and proportionately, forbids designing a procurement to narrow competition artificially (Article 18(1)), and says that a specification 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)) (16, European Union, 2014). A specification that says "the market-leading assistant" fails that test. A specification that says "completion, chat and multi-file edit in the Region's IDEs, running on a model the Region can host itself or that the supplier hosts in the European Economic Area" passes it.

The Region buys more than tools. Its framework agreement NR-2025-102 for about 22 consultant developers had no clause on AI tools, so nothing in the contract addressed the case in which a consultant pasted a test-database connection string into an unapproved public assistant in March 2030 (INC-NR-2030-0071, illustrative). The platform team rotated the credential within 40 minutes and no access from outside was found. The lesson for procurement is that the tool the Region chooses is not the only tool in its repositories: the criteria for the new assistant and the clauses for consultants have to be written together, or the assistant becomes one more approved tool beside an unapproved one.

The rules that shape the tender

Four provisions of Directive 2014/24/EU matter most for a tender of this kind. Award is to the most economically advantageous tender (Article 67(1)), identified by price or cost, for example life-cycle cost, or by the best price-quality ratio, where quality may include "technical merit, aesthetic and functional characteristics, accessibility, design for all users" (Article 67(2)) (108, European Union, 2014). Criteria must be linked to the subject matter, must not give the authority unrestricted freedom of choice, and must allow the information that tenderers give to be verified (Article 67(3) and (4)). Special conditions for the performance of the contract may cover economic, innovation-related, environmental, social and employment-related considerations if they are 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: by clear, precise and unequivocal review clauses in the original documents, for non-substantial changes, or for the other listed cases, and a change that extends the scope considerably or shifts the economic balance to the contractor is substantial (16, European Union, 2014).

Article 72 is the provision a developer should read twice. A coding tool is not a delivered system. The supplier changes the model behind it, the price of a seat and the set of features, often with short notice. If the tender documents contain no review clause that describes how model changes, price changes and new agentic features are handled, the Region will find that the changes it needs are either substantial and need a new procedure, or are not available at all. The clause states in advance what the Region treats as a change of the tool it bought, and so what triggers a new evaluation against the delegation profile.

The Region's procurement policy requires an executive committee decision above EUR 2 million. In the illustration the tender is estimated at EUR 1.6 million over four years, so the CIO decides, and the decision is recorded as AIDR-1118 (dated 2030-10-14): open procedure, award on best price-quality ratio, criteria as in the sheet below, report to the executive committee for information. The tender closes in November 2030. The recorded decision is the Region's first evidence that the procurement route was chosen and not drifted into.

Lock-in, data and exit

Three further instruments bear on the criteria, and each needs a developer's reading of what it means for a repository.

The GDPR applies because source code contains personal data more often than teams assume (names in comments, test data, fixtures) and because prompts and logs may contain case content. The Region is a controller; a supplier that processes prompts is a processor, and Article 28 requires a contract with defined terms (4, European Union, 2016). The developer's contribution is to say, from the codebase, what a prompt can contain. The Socialia stored procedures and the benefits-triage rules are the obvious cases, and the current rule that the enterprise assistant may not receive them becomes a criterion in the tender.

The Data Act's rules on switching between data processing services (Chapter VI) oblige providers to remove obstacles to switching, require contract terms with a maximum notice period of two months and a mandatory transitional period of at most 30 calendar days (Article 25(2)), and withdraw switching charges from 12 January 2027 (Article 29) (7, European Union, 2023). Whether a hosted coding assistant meets the Act's definition of a data processing service is a question for the Region's legal counsel and this chapter does not conclude it. The criteria ask for the rights in any case, because an assistant whose prompt history and configuration cannot be exported ties the Region 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; that applies unchanged to this one.

The NIS 2 Directive requires essential and important entities to take measures on supply chain security (Article 21(2)(d)) and on security in the acquisition, development and maintenance of network and information systems, including vulnerability handling (Article 21(2)(e)), and to take into account the vulnerabilities specific to each direct supplier and the quality of its products and secure development practices (Article 21(3)). Public administration entities at regional level fall within scope where a member state so defines them under Article 2(2)(f)(ii) and a risk-based assessment finds that their services could, if disrupted, significantly affect critical societal or economic activities (3, European Union, 2022). For a region on the Swedish pattern the question is narrower than the Directive suggests: the Swedish Cybersäkerhetslag (2025:1506), in force from 15 January 2026, applies to a region, a municipality or a municipal association (section 3) (11, Sveriges riksdag & Regeringskansliet, 2025), and counsel confirms what that means for the Region's tooling. The criteria below are written as if the Region were in scope; the NIST secure development framework and its community profile for generative AI describe the practices that Article 21(3) points to (232, Souppaya et al., 2022) (233, Booth et al., 2024).

The Commission's model contractual clauses for the procurement of AI, which buyers may use and customise, are a starting point for the clauses, written for AI systems in general; they do not know the repository, the pull request or the agent's merge rights, and the Region adds those (101, European Commission, 2025). The Commission's Cloud Sovereignty Framework shows how sovereignty can be turned into objectives that a bid is scored against; it is the Commission's own procurement instrument and not a legal requirement for the Region (8, European Commission, 2025). Chapter 26 treats sovereignty in the toolchain.

Evidence in the criteria

A tender for a tool whose benefit is the main reason for buying it invites claims. The evidence on AI coding tools is real and varied. A controlled experiment in which developers were asked to write an HTTP server in JavaScript tested one task (175, Peng et al., 2023). Three randomised field experiments at three companies with 4,867 developers report a pooled 26.08 per cent increase in completed tasks (standard error 10.3 per cent), with results that vary across the three experiments (176, Cui et al., 2024); the bibliography entry records that the full text was not read. Industry analyses of code quality and security, such as GitClear's analysis of 211 million changed lines and Veracode's tests of code from over 100 models, are vendor research with the vendor's own classification and tests (177, GitClear, 2025) (229, Veracode, 2025). None studied a regional authority's codebase of Java 8, PL/SQL and stored procedures, and none can stand in for a measurement there.

The Region's own number has the same weakness. The pilot NR-DEV-001 reported a 31 per cent acceptance rate and "about four hours saved a week" from a survey answered by 9 of 12 developers (AVR-NR-2030-01, April 2030), and a note to the executive committee turned that into "a third faster" although nobody had measured delivery time. The evidence criterion of the tender therefore asks two things. Bidders must state, for each performance claim, the population, task, period and method behind it, and the Region will score the statement, not the claim. And the Region commits to measuring the tool on its own work with a stop rule, as Chapter 20 describes, so that the award is not the last time the claim is examined.

Practical guide: Writing procurement criteria for an AI coding tool

Purpose. Produce a criteria sheet that a procurement officer can put into the tender documents and a developer can check against a repository.

Roles. Head of Applications and Integration (accountable), a tech lead and a senior developer from a team that will use the tool, the platform lead, a quality engineer, an accessibility specialist, the procurement officer, the data protection officer, legal counsel, the archivist, and the union's IT representative as a reviewer.

Inputs. The delegation profile DLG-NR-DEV-01, the inventory of repositories and their classification, the incident record INC-NR-2030-0071, the framework agreement NR-2025-102, the pilot record AVR-NR-2030-01, and the public-access and archives rules.

Steps.

  1. Write the function the Region needs in terms of work classes (generate, refactor, test, document) and usage modes, never in terms of a product. State the highest degree of delegation that the Region will allow per class and that the tool must be able to be configured to that ceiling and no higher.
  2. List the mandatory requirements as pass or fail: processing location, no training on the Region's code, export of logs and configuration, administrative control over mode and permissions, and a switch that disables the agentic mode without the supplier's help.
  3. Choose the scored criteria and their weights, each linked to the subject matter (Article 67(3)) and each with a way to verify the bid (Article 67(4)): a scored trial on a copy of a Region repository, a documented secure development process, accessibility of the tool's own interface, and the exit terms.
  4. Add the review clause: how model changes, price changes and new features are notified, tested against the delegation profile and accepted or refused (Article 72).
  5. Write the record clause: what the tool logs, who may read it, how long it is kept, and how it can be exported to the Region's archive.
  6. Review the sheet with the union's IT representative before publication, because logs that identify a named developer's queries fall under the negotiation record MBA-NR-2030-03 that the Region opened in September 2030 (Chapter 22).
  7. Record the decision as an AI Decision Record and store the sheet with the tender documents.

Artefact. A criteria sheet in version control, referenced from the AI Decision Record.

Worked example (illustrative): the criteria sheet for NR-2030-041

tender: NR-2030-041
procedure: open
decision_record: AIDR-1118
decided_on: 2030-10-14
decided_by: Henrik Dahl            # CIO; value below the EUR 2 million committee line
accountable_for_use: Gunilla Roos
subject: development assistants for Applications and Integration
specification:
  functions: [completion, chat, multi-file edit]
  optional_module: agentic_mode      # enabled only by a separate decision
  named_brand_allowed: false         # Directive 2014/24/EU Article 42(4)
  delegation_ceiling_ref: DLG-NR-DEV-01
  ceiling_enforced_by: configuration the Region controls
mandatory:
  - processing in the EEA, or self-hosted on the Region's reserved capacity
  - no training on the Region's code, prompts or logs
  - export of logs, configuration and prompt history in an open format
  - administrative switch that disables the agentic mode without supplier action
  - no use of an unapproved public service by the tool or its sub-processors
award:
  method: best price-quality ratio    # Directive 2014/24/EU Article 67(2)
  weights:
    life_cycle_cost: 35
    fit_on_region_stacks: 20          # scored trial on a repository copy
    security_and_secure_development: 15
    data_handling_and_logging: 10
    accessibility_of_the_tool: 5
    exit_and_portability: 10
    evidence_for_claims: 5            # population, task, period, method
performance_conditions:               # Article 70
  review_clause: notice of model, price and feature changes at least 30 days
  change_test: delegation profile re-reviewed before a model change is accepted
  exit: export within 30 days of notice; deletion confirmed in writing
records:
  log_retention_class: to be fixed with the archivist
  log_reader: team lead and platform lead, not for appraisal
review: before award, with the IT union representative

The sheet shows the shape of a decision, not a recommendation of weights. The weights are the Region's illustration. The elements that matter are that the delegation ceiling is a property of the contract and not of the vendor's default, that the agentic mode is a separate decision, and that the review clause makes a model change an event that the Region can test and refuse.

Public code and open source

Public code is software developed with public money and published for reuse under an open source licence. The European frame is short. The Interoperable Europe Act, Regulation (EU) 2024/903, applies from 12 July 2024. It requires a public sector body to make available to any other public sector body that asks an interoperability solution that supports a trans-European digital public service, with its technical documentation and documented source code, subject to listed exceptions such as third-party intellectual property rights and public security (Article 4(1)), and, when deciding on the implementation of interoperability solutions, to prioritise those without restrictive licensing terms, such as open source, where they are equivalent in functionality, total cost, user-centricity and cybersecurity (Article 4(6)) (18, European Union, 2024). The Commission's Implementing Decision (EU) 2017/863 released the European Union Public Licence version 1.2 so that public administrations can share and reuse software; its annex lists compatible share-alike licences (19, European Commission, 2017). The Region has published the code of its citizen e-service components on the national public-code platform since 2027.

Three decisions follow from publication, and a developer owns each.

What to publish. A component is a candidate when it is generic, has no secrets or personal data in its history, and has an owner who can maintain it. The inventory of July 2030 (OWN-NR-2030-00) found that 31 per cent of the Region's 96 repositories have an owner who has left the Region or changed team. A repository without an owner is not published until it has one, since a published repository with no steward makes the Revert test impossible in public: the code cannot be recalled, and users may build on it. Generated code adds a precondition. The Region's incident of March 2030 shows how a secret can leave a repository through a prompt, and the same discipline applies to a commit history on its way to a public platform: a scan of history for credentials and personal data, a provenance record for generated files (Chapter 10), and a licence check for code of unknown origin (Chapter 26).

Under what licence. The Region uses a licence from the family that the Commission recommends for public administrations. Which licence suits a given component is a choice with consequences for reuse by suppliers and by other authorities, and for the Region's own rights if a supplier contributes. Chapter 26 treats the licence question when AI generated part of the code. Here the rule is procedural: the licence choice and the reasons are recorded before the first push.

Who maintains it. Publishing creates an expectation. Whether the Region owes outside users a response is not settled by law for an authority that is not placing a product on the market commercially. The Cyber Resilience Act's treatment of open source stewards, and of software supplied outside a commercial activity, is an open question that Chapter 24 takes up; the writer of that chapter verifies the articles (242, European Union, 2024). Until it is answered, the Region treats a published component as a product it will maintain: a named maintainer, a security contact, and a stated end-of-support date.

Public code also runs the other way. Before the Region adopts code from outside, including a suggestion whose origin cannot be traced, it records the origin and the licence. For contributions to its published repositories, the contribution guide asks whether AI assistance was used and which tool, so that review in D4 knows what it is reviewing; that is the Region's own convention, and no source consulted requires it.

Observable: the Interoperable Europe Act applies and the EUPL 1.2 is released. Expected: more authorities will be asked to share code under the Act's sharing rule. Speculation: a common public-code programme shared by every authority in a member state is plausible and not evidenced.

Accessibility

A public authority's website or app is, for some residents, the only way to reach the authority. Directive (EU) 2016/2102 requires member states to ensure that public sector bodies make their websites and mobile applications accessible by making them perceivable, operable, understandable and robust (Article 4), within a disproportionate-burden exception that the body must assess and explain (Article 5), with a presumption of conformity for content that meets the harmonised standards, of which EN 301 549 is the European standard behind them (Article 6), and with an accessibility statement and a feedback mechanism (Article 7). It applied to mobile applications from 23 June 2021 (14, European Union, 2016). The Swedish act applies to the digital services of state and municipal authorities and to regions' elected assemblies; it requires that a digital service on a solution the authority controls meet the accessibility requirements, allows an exception where compliance would be unreasonably burdensome, and requires an accessibility statement with a way to report failures (sections 4 and 10 to 13) (257, Sveriges riksdag, 2018).

The European Accessibility Act, Directive (EU) 2019/882, applies from 28 June 2025 to listed products and services offered to consumers, including e-commerce services, consumer banking services and, for regional public transport, the self-service terminals; 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 the Act (17, European Union, 2019). For Nordvik the two instruments meet at the regional public transport function, where the terminal and the ticketing website may fall under different regimes. Hansa Mutual is a private insurer and outside the 2016 Directive. Whether its customer portal is an e-commerce service within Article 2(2)(f) of the Act is a question for its counsel.

What changes with AI coding tools is where the accessibility defects come from and how they are found. 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: in February 2025, automated testing of one million home pages found detectable WCAG 2 failures 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 (258, WebAIM, 2025). That figure is a baseline for the web in general, 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 design consequences run through the functions. In D1 Frame, accessibility belongs in the acceptance criteria of the specification record, written by the product owner and the accessibility specialist, not added at the end. In D2 Design, the Region's component library and design system carry accessible patterns, so that a tool that generates a form reuses a component that has been tested. In D4 Prove, the oracle must not be the generator. Saga Edvardsson's regression pack for the portal can include automated checks, which catch part of the failures, and the manual testing with assistive technology by the Region's two accessibility specialists remains. Alternative text or form labels drafted by an assistant are Level 2 Supervised at most, checked by the page's author before merge, as DLG-NR-DEV-01 says for documentation.

Archives and transparency

The Region's code, design documents and decisions are public documents in the sense of the public-access rules, unless an exception applies, and they are part of the archive. In the Swedish model, the Freedom of the Press Act, Chapter 2, gives a right of access to public documents; under sections 3, 4, 9 and 10, a document is public when it is held by an authority and has been received or drawn up there (155, 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 organised and protected by the authority, with disposal (gallring) permitted by section 10 subject to the cultural-heritage and access purposes of the archive and to any deviating rules in other law (103, Sveriges riksdag & Regeringskansliet, 1990). Whether a prompt to a coding tool, or the code it returned before the developer edited it, is a public document or working material is a question the Region's archivist and legal counsel have not yet answered. I do not answer it here. The design consequence is to decide what the Region keeps on purpose and not by accident.

Three kinds of artefact are certainly records. The specification record SPC-NR-* and the Architecture Decision Record are decisions about what the system must do and why, and they state where AI took part. The delegation profile and the AI Decision Records are decisions of the authority. The agent run record RUN-NR-*, where the Region uses an agent, shows what was executed, under which mandate and with what result. The prompts are the uncertain case. Keeping every prompt keeps case content and developers' working habits, a risk under data minimisation in the GDPR (Article 5(1)(c)) and a matter for the union. Keeping none leaves a run that cannot be reconstructed. The Region's working position is a retention class decided with the archivist before the tool is switched on: run records and the accepted outputs are kept with the change they belong to, 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. This is the Region's choice and not a rule of law.

Transparency has a second face. The algorithm register is generated from version-controlled entries (AI Governance, Chapter 17), and that works only if the entries are written where the developers work. The benefits-triage system, the benefits-explanations service built in house around it and the claims ranker each have a register entry, and a change to any of them is a change to the entry. A developer who changes the explanation service changes what a resident is told about a decision (AI Boss, Chapter 27 on contestability). The pull request template therefore asks whether the change alters a register entry, and the answer is part of the review record.

Withholding is decided case by case on grounds fixed in law. The Region's rule is that a request is answered by the competent official, with the developer's help in finding the material, and not by the developer.

Accountability under public law

The stewardship principle says that a named developer or team passes three tests for every change in production: Name, Understand and Revert (Chapter 4). In a public authority the first test has a legal edge. The administrative decision is taken by a named official, and the system supports the official. The caseworker is necessary and not sufficient (AI Leader, Chapter 18). A developer is not the decider and should not be asked to become one by default: a developer who frames the rule in a specification and a reviewer who confirms it decide how the system behaves, but the Region's legal counsel and the business owner own the interpretation of the statute. The specification record for a case-handling change therefore names the provision, the person who interpreted it and the date, and the verification plan names a test written from the provision by someone other than the author of the change.

The Swedish Tort Liability Act provides for the liability of the State or a municipality or region for faults in the exercise of public authority, and for the liability of employees (chapter 3, section 2 and chapter 4, section 1), and the Criminal Code makes misconduct in the exercise of public authority an offence (chapter 20, section 1) (156, Sveriges riksdag, 1972) (157, Sveriges riksdag, 1962). Whether and when the act of a developer could engage either provision is not something this book concludes; it depends on whether the developer exercises public authority, and a developer who maintains the system that supports the decision does not decide the case. The practical conclusion is narrower: the Region records, 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".

In-house or supplier

The Region both builds and buys. About 25 of its employees write code as their main work, about 22 consultants work inside its teams, and the supplier teams of TriageSoft (tender NR-2026-117) and of the national shared-service provider SamDrift (framework NR-2026-088) are not the Region's staff and write code the Region does not review. The in-house or supplier question is asked of every component, and AI changes some of the terms.

AI Purple, Chapter 19 concluded for a different function that a mixture of operating models is the normal result, that the decision is made per stage and recorded with exit criteria, and that what must stay with the organisation is the coordinator, the register of record and the right to stop. The same shape applies to software. The table sets out a way to ask the question per component.

Question Tends towards in-house Tends towards supplier
Does the component encode the Region's own legal interpretation? Yes: the Region must be able to explain and change it No: a generic service
How often does the rule change? Often, on the Region's timetable Rarely, or on the supplier's timetable
Can the Region test it with an oracle it owns? Yes No: it cannot judge what it cannot test
Can the Region leave? Not applicable Only with an exit plan that has been exercised
Does the Region have people who can own it? Yes, with an apprenticeship route (Chapter 13) No, and the supplier offers continuity
Is the code reviewable by the Region? Yes The contract gives review and escrow rights

The benefits-triage system is bought from an external provider and its scoring is in the supplier's hands. The Region's own decision record for it (AIDR-0007, AIDR-0011) fixes human oversight and the right to retire it (AIDR-0018). The benefits-explanations service is built in house, because the Region has to answer for what it tells residents. The case system SVC-NR-003 rests on a vendor product that the Region has customised for fourteen years, with vendor support ending in 2033; Chapter 12 treats the decision about its modernisation.

AI affects the question in two ways. It makes some in-house work cheaper to start. It also makes review more expensive when volume rises, because the reviewer is the same small team. No verified study of the net effect on a regional authority's cost of ownership was found for this book, so that in-house work becomes cheaper overall is speculation; that review capacity is the binding constraint on supplier code the Region does not review is observable in its own profile. For supplier code, the contract gives the Region the right to require that AI-assisted changes be declared, that the supplier's tests are available to the Region, and that the Region's own oracle runs at acceptance. For consultants inside Region teams, framework NR-2025-102 is amended to carry the same clauses as the new tender and the Region's rule on public assistants.

The decision for each component is recorded in the Architecture Decision Record for the component, with its exit criteria, and reported in the annual review of the delegation profile.

Across the usage modes

The table gives, for each usage mode, what the public-authority setting adds and the highest degree of delegation that Nordvik's delegation profile DLG-NR-DEV-01 allows today. The ceiling is not a licence; practice before the profile was Level 0 except for ambient completion.

Usage mode What the public authority adds Highest degree allowed at Nordvik
Mode 0 Ambient AI Completion switched on by an IDE update with no prior record (AIDR-1102); a retrospective decision and a place in the criteria Level 1 Assisted for generate and refactor
Mode 1 Conversational assistants Enterprise tool only; no source code with special-category data, credentials or the benefits-triage rules Level 1 Assisted
Mode 2 Embedded workplace assistants Pilot NR-DEV-001 and the tender NR-2030-041; criteria on data, logs, accessibility and exit Level 2 Supervised for document; Level 1 Assisted otherwise
Mode 3 Agentic work tools Platform team only; the tender's agentic module is a separate decision Level 0 Advisory for applying change
Mode 4 Built AI applications None built for developers Not applicable
Mode 5 Autonomous production agents None, by the Region's rule Not used

Level 4 Autonomous is not used for any class at Nordvik. In a public authority the prohibitions of the book bite in particular places: no tool changes the benefits-triage rules or code in the authentication and authorisation path without a named developer's review, no tool alters its own mandate or the pipeline gates, and no tool decides about a named person's access to benefits or employment.

Nordvik Region and Hansa Mutual

Nordvik develops under public-law accountability. It buys under Directive 2014/24/EU and its own policy, it answers requests for public documents, it keeps records under the Archives Act, it publishes citizen e-service components as public code, and it owes accessibility to residents under the 2016 Directive and the Swedish act. The tender NR-2030-041 shows the discipline: a decision record (AIDR-1118), criteria written as a sheet in version control, a delegation ceiling that belongs to the contract, and a review clause for model changes. Its constraints are the long procurement cycle, a small team of about 25 who write code, 22 consultants under a framework agreement with no AI clause, and 31 per cent of 96 repositories with no living owner.

Hansa Mutual is a private insurer, outside the Procurement Directive and the Web Accessibility Directive, with no duty to publish code. It faces other constraints. Its IDE assistant HM-DEV-001 was bought under contract HM-PROC-AIDEV-2029-01 with clauses on no training on the group's code, EU processing and 30 days' notice of model changes, approved retrospectively (AIDR-1151). Those clauses are close to the Nordvik sheet, reached by a different route: DORA, under which the contract is on the register of information as a service supporting an important function and the group's third-party policy requires an exit plan. The differences are that Hansa decides without a tender, that it need not answer requests for its source, and that the supervisor, not the public, reads its records. Hansa's mobile claims app and broker plug-in raise the Cyber Resilience Act question for Chapter 24, and whether its customer portal falls under the European Accessibility Act is for its counsel. What the two share is the part the earlier chapters stress: a contract term is a promise until a model change, a log request or an exit shows it works.

Summary

This chapter concerned D1 Frame, D2 Design and D5 Steward in a public authority. The setting adds legal duties to every stage. D1 starts from the provision and its interpreter, because section 5, section 25 and section 32 of the Administrative Procedure Act ask for support in law, a hearing and reasons that the system must make possible. D2 begins with the purchase: Directive 2014/24/EU requires functional specifications, equal treatment, award criteria linked to the subject matter and verifiable, performance conditions, and strict limits on changing the contract, which a coding tool will test through model, price and feature changes. D5 requires that what the Region owns be owned by a named steward, that published code be maintained, and that records be kept on purpose.

The conclusions are the book's own. The tender is the first delegation decision: the ceiling of DLG-NR-DEV-01, the agentic switch and the review clause belong in the contract. Claims about a tool's benefit enter the procurement as statements with population, task, period and method, and the Region measures its own work after award. Public code is a promise of maintenance, so an unowned repository is not published. Accessibility needs an oracle the generator did not write. What the Region keeps of prompts and runs is decided with the archivist, counsel and the union before the tool is switched on. In-house or supplier is decided per component and recorded with exit criteria.

Observable: the procurement, accessibility and archives rules described here are in force, and the tender NR-2030-041 is open in the illustration. Expected: more authorities will write delegation ceilings and logging into contracts for coding tools, as the Commission's model clauses and the Data Act's switching rules spread. Speculation: a shared public-sector coding model for every authority in a member state would reduce lock-in but is not evidenced.

For the reader: take the next coding-tool contract or framework agreement your organisation signs and check three clauses: who may change the model and with what notice, what is logged and where it can be exported, and which delegation ceiling the tool can be configured to. Chapter 19 turns from the professional developer to the citizen developer, who builds applications in low-code tools that the same public-law constraints reach.

Sources

  1. 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. (16, European Union, 2014)
  2. European Parliament and Council of the European Union (2014). Directive 2014/24/EU on public procurement and repealing Directive 2004/18/EC, Article 67 (Contract award criteria). (108, European Union, 2014)
  3. European Parliament and Council of the European Union (2016). 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. (14, European Union, 2016)
  4. 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. (17, European Union, 2019)
  5. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/903 laying down measures for a high level of public sector interoperability across the Union (Interoperable Europe Act). (18, European Union, 2024)
  6. European Commission (2017). Commission Implementing Decision (EU) 2017/863 updating the open source software licence EUPL. Official Journal of the European Union L 128, 19 May 2017. (19, European Commission, 2017)
  7. Sveriges riksdag (2018). Lag (2018:1937) om tillgänglighet till digital offentlig service. (257, Sveriges riksdag, 2018)
  8. Sveriges riksdag (1990). Arkivlag (1990:782). (103, Sveriges riksdag & Regeringskansliet, 1990)
  9. WebAIM (2025). The WebAIM Million (2025 report). (258, WebAIM, 2025)
  10. Sveriges riksdag. Förvaltningslag (2017:900). Sections 5, 25 and 32 were read in the live text. (154, Sveriges riksdag, 2017)
  11. Sveriges riksdag. Tryckfrihetsförordning (1949:105). Chapter 2. (155, Sveriges riksdag, 1949)
  12. Sveriges riksdag. Skadeståndslag (1972:207). (156, Sveriges riksdag, 1972)
  13. Sveriges riksdag. Brottsbalk (1962:700), 20 kap. 1 §. (157, Sveriges riksdag, 1962)
  14. Prime Minister of Australia (2023). Final report of the Royal Commission into the Robodebt Scheme. (159, Prime Minister of Australia, 2023)
  15. Autoriteit Persoonsgegevens (2020). Belastingdienst/Toeslagen: De verwerking van de nationaliteit van aanvragers van kinderopvangtoeslag. (158, Autoriteit Persoonsgegevens, 2020)
  16. European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). (4, European Union, 2016)
  17. European Parliament and Council of the European Union. Regulation (EU) 2023/2854 (Data Act). (7, European Union, 2023)
  18. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (3, European Union, 2022)
  19. Sveriges riksdag, Regeringskansliet. Cybersäkerhetslag (2025:1506). (11, Sveriges riksdag & Regeringskansliet, 2025)
  20. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 (Cyber Resilience Act). (242, European Union, 2024)
  21. Souppaya, M., Scarfone, K. & Dodson, D. (2022). Secure Software Development Framework (SSDF) Version 1.1. NIST SP 800-218. (232, Souppaya et al., 2022)
  22. Booth, H. et al. (2024). Secure Software Development Practices for Generative AI and Dual-Use Foundation Models. NIST SP 800-218A. (233, Booth et al., 2024)
  23. European Commission, Community of Practice on the Procurement of AI (2025). Updated EU AI model contractual clauses now available. (101, European Commission, 2025)
  24. European Commission (2025). Cloud Sovereignty Framework, Version 1.2.1. (8, European Commission, 2025)
  25. Peng, S. et al. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. (175, Peng et al., 2023)
  26. Cui, Z. et al. (2024). The Effects of Generative AI on High-Skilled Work. (176, Cui et al., 2024)
  27. GitClear (2025). AI Copilot Code Quality: 2025 Look Back at 12 Months of Data. (177, GitClear, 2025)
  28. Veracode (2025). October 2025 Update: GenAI Code Security Report. (229, Veracode, 2025)
  29. Nordqvist, G. (2026). AI Governance. The Architecture as Code Series, Book 2. (162, Nordqvist, 2026)
  30. Nordqvist, G. (2026). AI Boss. The Architecture as Code Series, Book 7. (167, Nordqvist, 2026)
  31. Nordqvist, G. (2026). AI Purple. The Architecture as Code Series, Book 9. (169, Nordqvist, 2026)
  32. Nordqvist, G. (2026). AI Leader. The Architecture as Code Series, Book 11. (174, Nordqvist, 2026)