AI in Public Authorities

A national agency, a region, or a municipality that deploys AI operates under constraints that no private enterprise faces in the same combination: a legal mandate that must exist before a system does, administrative law that demands reasons for every decision, transparency owed to citizens, procurement rules, and a sovereignty question that is also a national security question. The chapter builds on Architecture as Code (Chapter 21), which treated the digitalisation of public administration as codified, auditable infrastructure (66, Nordqvist, 2025). It closes Part IV because public authorities face every organisational question of Chapters 12 to 16A and several of their own; the algorithm register, for example, is the public counterpart of Chapter 16's portfolio register.

Figure 17.1: Public-sector constraints on AI and the architectural responses that satisfy them (the table below).

Constraint	Architectural response
Legal basis and administrative law	Reasons log and decision-support boundary
Transparency duties to citizens	Version-controlled algorithm register
Interoperability and once-only principle	Data contracts with legal basis metadata
Public procurement rules	Model AI clauses and role allocation
Digital sovereignty and national security	Sovereignty posture as configuration
Citizen trust and accountability	FRIA as a promotion gate

Table for Figure 17.1: Constraints on a public authority and the architectural responses.

Why the public sector is different

A private company may deploy a model because it expects a return; a public authority may deploy one only because the law permits it to perform the task, and only in the way the law permits. The architect therefore asks whether the output can lawfully ground an administrative decision, whether the citizen can be told why, and whether the decision can be appealed to a person who did not depend on the model. Authorities act under a principle of legality and need an explicit legal basis for processing, deciding, and often automating. The people affected cannot go elsewhere, so the state owes a higher duty of explanation and redress, and it answers to parliaments, ombudsmen, auditors, and courts in public. The Council of Europe Framework Convention on Artificial Intelligence and Human Rights, Democracy and the Rule of Law binds its parties, which are states, to ensure that AI systems used by public authorities respect human rights, democratic processes, and the rule of law (21, Council of Europe, 2024); its obligations land on the architects who design what governments run.

Legal basis and administrative law

Any public-sector AI system starts from lawful authority. The General Data Protection Regulation, Regulation (EU) 2016/679 (the GDPR), requires a lawful basis for every processing operation; for authorities this is normally Article 6(1)(e), a task carried out in the public interest or in the exercise of official authority, which must itself be laid down in Union or Member State law under Article 6(3) (2, European Union, 2016). The legal department identifies this basis, and the architecture records it as a property of the system: which statute, which section, which processing operations.

Automated individual decision-making

Article 22 of the GDPR gives a person the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects, unless the decision is necessary for a contract, authorised by Union or Member State law with suitable safeguards, or based on explicit consent (2, European Union, 2016). For authorities the second exception is the relevant one. Sweden's administrative procedure legislation, for example, allows an authority to make decisions automatically, which is why Swedish agencies have run automated case handling at scale for years. Where such a rule exists, its safeguards become architectural requirements; where it does not, the system can only recommend, and a natural person must decide.

The consequence is a sharp line between decision support, where a case officer reads the proposal and signs, and decision-making without a person in the path. The line concerns where authority resides, not how the interface is drawn, so it must be visible in the data model that records who decided, in the audit log that shows whether the officer examined the case, and in the metrics that reveal when "human review" has become a formality.

The duty to give reasons

Administrative law in most European jurisdictions requires authorities to state the reasons for a decision, and this duty does not bend to probabilistic systems: if a model contributed, the reasons must still be intelligible to the citizen and the appeal body. The AI Act, Regulation (EU) 2024/1689, reinforces this for high-risk systems listed in Annex III, other than those in point 2 (critical infrastructure): Article 86 gives any affected person the right to obtain from the deployer clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken (1, European Union, 2024).

Explanation is therefore a first-class output. The reasons log records, for every decision the system influences, the inputs, model version, output, applied rule and the human action that followed. It is distinct from the technical logging of Article 12: it is written in the language of the case, not of the model, and retained for as long as the decision can be appealed.

Worked example: reasons log entry

Illustrative example. Nordvik Region deploys a high-risk triage system that ranks applications for its regional living-support benefit by the likelihood that they need manual verification. For every application it touches, the system writes an entry like the following, on which both the decision letter and the appeal body draw.

{
  "entry_id": "RL-2026-0481733",
  "system_ref": "NR-ALG-2026-003",
  "model": {"name": "lsb-triage", "version": "2.3.0"},
  "inputs_used": [
    {"field": "declared_monthly_income", "source": "application form"},
    {"field": "registered_income_last_12_months", "source": "national income register"},
    {"field": "change_of_address_last_6_months", "source": "population register"}
  ],
  "inputs_excluded_by_policy": ["nationality", "country_of_birth", "health_data"],
  "output": {"verification_score": 0.81, "band": "high"},
  "rule_applied": "Score >= 0.70 places the case in the manual verification queue (threshold set in AIDR-0188)",
  "main_factors_in_plain_language": [
    "Declared monthly income differs from the income register average by more than 25 per cent",
    "Address changed within the last six months"
  ],
  "human_action": {
    "officer_pseudonym": "CO-7731",
    "case_opened_for_review_seconds": 412,
    "action": "requested payslips from applicant",
    "decision": "granted"
  },
  "retention": {"until": "appeal period closed plus 5 years"}
}

The plain-language factors are what the officer quotes and an Article 86 explanation draws on; the excluded inputs answer an appeal body's usual first question; and the review time shows, in aggregate, whether human review is real.

Transparency and algorithm registers

Private firms disclose what the law compels; public authorities are expected to disclose what citizens might reasonably want to know. The Open Data Directive, Directive (EU) 2019/1024, established the presumption that public-sector information is re-usable, and the Netherlands has applied that spirit to algorithms themselves (7, European Union, 2019). The Algorithm Register of the Dutch government is a public, searchable catalogue in which Dutch public organisations describe the algorithms they use, their purpose, the data involved, the human oversight applied, and the legal basis (23, Dutch Ministry of the Interior, n.d.). It is part of the institutional response after Dutch risk-scoring in benefits administration ended in the courts and in parliament.

What the AI Act adds

The AI Act turns voluntary transparency into obligation for high-risk systems. Article 49 requires providers to register high-risk AI systems in the EU database, and Article 49(3) extends the duty to deployers that are public authorities, agencies, or bodies (1, European Union, 2024). Article 26 requires deployers to assign human oversight to competent natural persons, ensure that input data is relevant and sufficiently representative, keep logs for at least six months, and, under Article 26(11), inform natural persons that a high-risk system is used in decisions about them (1, European Union, 2024).

Annex III covers eligibility for public assistance benefits, law enforcement, migration and the administration of justice, and Article 5 prohibits social scoring, by public or private actors, that leads to detrimental or unfavourable treatment in unrelated social contexts or treatment that is unjustified or disproportionate (1, European Union, 2024). An authority therefore needs an inventory that classifies every system against these lists before it needs anything else.

The register as an architectural artefact

The register is where transparency, inventory, and AI Act registration converge, so treat it as a version-controlled dataset rather than a web form. Each entry is a file that the pipeline validates, checking that the referenced legal basis and FRIA exist, before publishing its public fields to the website and, where required, the EU database. A public_fields list lets one record serve the internal inventory, the Article 49 registration, and the citizen-facing register, and a model change opens a pull request that the data protection officer and system owner review.

Worked example: public AI register entry

Illustrative example. What the citizen sees is the projection of the internal record. Nordvik Region publishes this entry for the triage system, written for an applicant rather than an auditor.

# Triage of applications for living-support benefit

Register number: NR-ALG-2026-003 · Status: in use since 3 March 2026
Responsible unit: Social Welfare, Nordvik Region

## What the system does
When you apply for living-support benefit, a computer model estimates how likely
it is that your application needs extra checks, for example of income. Applications
with a high estimate are checked first and more thoroughly by a case officer.

## What the system does not do
It does not decide your application. A case officer reads every application
and makes the decision.

## What information it uses
Information from your application, the national income register, and the
population register. It does not use nationality, country of birth, or health
information.

## Legal basis
Regional Welfare Act, section 12 (the task); GDPR Article 6(1)(e) (processing).
Under the EU AI Act this is a high-risk AI system (Annex III, point 5(a)).
EU database registration: EUDB-2026-NR-00412.

## Your rights
You can ask why your application was handled as it was, including the role this
system played (AI Act Article 86). An appeal is always handled by a person who
did not rely on the model's estimate.

The entry answers, in order, the questions applicants ask: whether a machine decided, what it looked at, and what they can do about it, with legal references below the plain-language explanation.

Worked example: algorithmic transparency record

Illustrative example. Nordvik Region also publishes a detailed transparency record for journalists, researchers, the ombudsman, and appeal bodies, generated from the same repository.

# registers/transparency/NR-ALG-2026-003.yaml (excerpt)
record_id: NR-ALG-2026-003-TR
organisation: Nordvik Region
owner: {senior_responsible_owner: Director of Social Welfare, system_owner: Head of Benefit Services}
tool:
  name: Living-support benefit triage
  ai_act_role: deployer   # procured; provider TriageSoft (fictional); see AIDR-0188
  risk_class: high
  annex_iii: "5(a)"
purpose:
  prohibited_uses:
    - Refusing or reducing a benefit on the basis of the score
    - Use for fraud investigation or referral to the police
decision_process:
  human_in_the_loop: Every application is decided by a case officer, grade 3 or above
  officer_does_not_see: raw score
  appeals: Handled by a separate unit without access to the triage score
data:
  sources: [application form, national income register, population register]
  excluded_fields: [nationality, country_of_birth, health_data, ethnic_origin]
performance:
  precision_at_queue_capacity: 0.64
  random_sampling_baseline: 0.21
  group_parity_checked: [age_band, sex, municipality, household_type]
  largest_parity_gap: "Single-parent households flagged 1.3x the overall rate"
  response: Gap traced to address-change feature; feature capped, retest due 2026-12
risks_and_mitigations:
  - risk: Score treated as a decision by officers under time pressure
    mitigation: Raw score hidden; review time monitored; quarterly sample audit
assessments: {fria: fria/NR-ALG-2026-003-v2.md, dpia: dpia/NR-ALG-2026-003-v3.md}

The record publishes its own weakness, the parity gap for single-parent households, with the response, because a record that reports only good news is not believed. The prohibited_uses list mirrors the AI Decision Record and is what the authority will be held to if use later expands.

Across the usage modes

Register and transparency duties bite mainly where the authority builds or operates a system that affects citizens directly. Records management and access-to-documents law, by contrast, reach every mode, because AI output that enters casework becomes part of the official record.

Mode	Register and transparency duties	Records management and access to documents
Mode 0 Ambient AI	Keep published guidance authoritative and dated	Automatic meeting notes may be official documents
Mode 1 Conversational assistants	Disclose AI use where it shaped a decision	Prompts and outputs used in casework may be records
Mode 2 Embedded workplace assistants	Normally internal	AI drafts fall under existing retention rules
Mode 3 Agentic work tools	Normally internal	Agent transcripts record changes to case systems
Mode 4 Built AI applications	Article 49(3) registration if high-risk; register entry	Reasons log and change history
Mode 5 Autonomous production agents	As Mode 4, plus disclosure of unapproved actions; GDPR Article 22 boundary	Each action is a case record

Nordvik Region's register team therefore concentrates on Modes 4 and 5, while its retention schedule names AI-generated notes, drafts and transcripts explicitly.

Public access, records and archives

Documents held by an authority fall under public-access and archives law long before any AI rule applies; in the Nordic tradition, a document received or drawn up by an authority is in principle open to anyone who asks unless a specific secrecy provision applies. More AI artefacts are records than most programmes expect: prompt templates, evaluation reports, reasons log entries, the FRIA, the provider contract and, depending on national practice, an official's prompts and outputs.

Three design rules follow. First, classify AI artefacts in the records management plan at design time, with a secrecy assessment per artefact type. Second, keep artefacts disclosable, for example a reasons log that separates personal data from model features. Third, reconcile the retention rules. Article 26(6) of the AI Act requires deployers of high-risk systems to keep the automatically generated logs under their control for a period appropriate to the intended purpose and of at least six months, unless other Union or national law provides otherwise (1, European Union, 2024); the GDPR's storage-limitation principle in Article 5(1)(e) pushes towards deletion (2, European Union, 2016); and archives law may require permanent retention. The three meet in the retention schedule, which the archivist owns and the pipeline enforces as configuration.

Records must also remain intelligible after the system is gone, so archive the model card, evaluation report and configuration of each version that supported decisions alongside the decisions, and treat retirement as an archival transfer rather than a deletion.

Interoperability and the once-only principle

Public authorities rarely own all the data a model needs. The European Interoperability Framework of 2017 set out the once-only principle: citizens and businesses supply information to public administrations once, and administrations re-use it (17, European Commission, 2017). The Interoperable Europe Act, Regulation (EU) 2024/903, gave the framework a statutory footing: Article 6 requires the framework to be taken into account in the interoperability assessment, and Article 3 requires a Union entity or public sector body to carry out an interoperability assessment before taking a decision on new or substantially modified binding requirements, an assessment that covers the effects on cross-border interoperability (8, European Union, 2024).

A model can therefore be fed data collected by another register, but only where the legal basis for the original collection permits the new purpose, because the GDPR's purpose limitation principle in Article 5(1)(b) does not lapse when data already sits in a government database (2, European Union, 2016). Data contracts should carry the legal basis and permitted purposes as metadata, and the AI gateway should refuse requests outside them. The European Digital Identity Framework, Regulation (EU) 2024/1183, adds wallets that present verified attributes to public services (10, European Union, 2024), so the intake layer should record which attributes came from a wallet and which from a legacy register.

Procurement constraints

Most authorities buy rather than build. Directive 2014/24/EU requires open, transparent, and non-discriminatory procedures above the thresholds, with technical specifications that do not favour a particular supplier (9, European Union, 2014). For AI this creates a tension: the authority must describe what it needs without naming a vendor, yet the behaviour it gets depends on which model it gets.

The European Commission's model contractual AI clauses translate AI Act obligations into contract terms covering documentation, transparency, human oversight, data governance, and the supplier's duties when the system changes (18, European Commission, 2023). The contract must also allocate the AI Act roles correctly: if the authority uses a bought high-risk system for its intended purpose, the supplier is the provider and the authority the deployer, but if it substantially modifies or repurposes the system, Article 25 can make the authority the provider (1, European Union, 2024). The technical specification must therefore state the intended purpose precisely.

Digital sovereignty and national security

Where a model runs and who can compel access to its inputs is a national security question as much as a data protection one, and in the public sector the risk appetite is set by law and policy that change. Make the sovereignty posture a configuration choice rather than a rebuild, with the deployment target recorded in an AI Decision Record and enforced by policy as code. Self-hosted open-weight models remove one dependency but make the authority responsible for evaluation and patching, a trade to make explicitly per system.

Citizen trust and accountability

A citizen-facing AI service spends the trust of the authority that runs it. Three commitments protect it. First, honesty about what the system is: Article 50 of the AI Act requires that natural persons interacting with an AI system are informed of that fact unless it is obvious from context, and authorities should set the bar for "obvious" low (1, European Union, 2024). Second, a documented, tested route to a case officer from every automated channel. Third, errors corrected in the open, including how affected people are contacted.

Fundamental rights impact assessments

Article 27 of the AI Act requires deployers that are bodies governed by public law, or private entities providing public services, to perform a fundamental rights impact assessment (FRIA) before putting a high-risk AI system into use, and to notify the market surveillance authority of the results (1, European Union, 2024). Chapter 10 covers its content. For an authority the task is to keep it alive: treat the FRIA as code, as Chapter 8 treats risk registers, so that the pipeline refuses to promote a high-risk system without an approved FRIA and a change to purpose or affected population reopens it automatically.

Worked example: public FRIA summary

Illustrative example. Article 27 requires notification, not publication, but Nordvik Region publishes a summary of the full FRIA from Chapter 10 alongside the register entry, generated from the assessment file.

# Fundamental rights impact assessment: summary
System: Living-support benefit triage (NR-ALG-2026-003) · Assessment version 2
Completed: 2026-02-11 · Notified to market surveillance authority: 2026-02-18
Next review: 2027-02 or on any change of purpose, data, or affected group

## Process and use
Orders the manual verification queue for about 31,000 applications a year.
A case officer decides every application.

## People affected
Applicants and their households; groups at higher risk include single parents
and people with recent changes of address.

## Main risks identified
1. Applicants in some groups are checked more often, causing delay and burden.
2. Officers may treat a high score as a presumption of error.
3. Register errors may raise an applicant's score without their knowledge.

## Measures
- Quarterly parity testing; flag-rate gap above 1.25x triggers review.
- Raw score hidden from officers; review time monitored.
- Appeals handled by a unit with no access to the score.

## If risks materialise
The system owner can suspend triage within one working day; applications
then return to random sampling, and affected applicants' cases are re-examined.

The summary follows the order of Article 27(1), and it already records the single-parent risk that later surfaced in the transparency record's parity results, which shows the assessment doing its job: naming a risk early so that monitoring is pointed at it.

Lessons from Nordic and Dutch administrations

The Nordic countries met the problems of automated decision-making before the AI Act named them. Automating rule-based decisions works well where the rules are clear and the citizen can see the calculation; trouble starts when statistical models replace rules without the explanation discipline the rules provided. The agencies that fared best also involved audit and legal functions in design rather than at release. The Dutch register adds a further lesson: transparency is expensive to maintain unless automated, since a register that depends on officials updating a web form decays, whereas one generated from version-controlled entries stays current because the pipeline refuses to deploy what is not registered (23, Dutch Ministry of the Interior, n.d.).

Nordvik Region and Hansa Mutual

This chapter is Nordvik Region's: the reasons log entry, the public register entry, the transparency record and the public FRIA summary all describe its procured benefits-triage system, deployed under Annex III point 5(a). Its public-law duties shape the architecture: reasons for every application, disclosable records, retention schedules that name AI-generated documents, and a caseworker who decides every case.

Hansa Mutual has none of these public-law duties and publishes no algorithm register, yet it faces analogous demands: supervisors in each market can require the evidence that Nordvik publishes, the Article 50 transparency notices must be given to the persons concerned in a clear and distinguishable manner in every market, which in practice means in that market's language (1, European Union, 2024), and its underwriting-support model is high-risk under Annex III point 5(c), which brings it within the fundamental rights impact assessment of Article 27(1), a duty the AI Act extends from public bodies to deployers of life and health insurance pricing and risk assessment. Nordvik's transparency is owed to the public; Hansa's is owed to supervisors and customers, market by market.

Summary

Public authorities deploy AI under a combination of constraints that private organisations do not face together: legality before capability, the GDPR's Article 22 limits on solely automated decisions, the duty to give reasons, transparency owed to citizens, procurement rules, and a sovereignty posture set by national policy. The AI Act sharpens each for high-risk systems through Article 26 deployer obligations, Article 27 fundamental rights impact assessments, Article 49 registration, and Article 86 explanations.

The architectural response is to record the legal basis as a property of the system, draw the line between decision support and automated decision in the data model, produce a reasons log in the language of the case, maintain the algorithm register as version-controlled entries, and treat the FRIA as a control that gates promotion and reopens on change.

Chapter 18 opens Part V and moves from mechanism to experience, with case studies showing how these disciplines played out when real organisations met real constraints.

Sources

1. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union. (1, European Union, 2024)
2. European Parliament and Council of the European Union (2016). Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the European Union. (2, European Union, 2016)
3. European Parliament and Council of the European Union (2019). Directive (EU) 2019/1024 on open data and the re-use of public sector information (Open Data Directive). Official Journal of the European Union. (7, European Union, 2019)
4. 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). Official Journal of the European Union. (8, European Union, 2024)
5. European Parliament and Council of the European Union (2014). Directive 2014/24/EU on public procurement. Official Journal of the European Union. (9, European Union, 2014)
6. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1183 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework. Official Journal of the European Union. (10, European Union, 2024)
7. European Commission (2017). New European Interoperability Framework: Promoting seamless services and data flows for European public administrations. Publications Office of the European Union. (17, European Commission, 2017)
8. European Commission (2023). EU model contractual AI clauses to pilot in procurements of AI. Public Buyers Community. (18, European Commission, 2023)
9. Council of Europe (2024). Framework Convention on Artificial Intelligence and Human Rights, Democracy and the Rule of Law (CETS No. 225). Council of Europe. (21, Council of Europe, 2024)
10. Ministry of the Interior and Kingdom Relations, Netherlands (n.d.). The Algorithm Register of the Dutch government. algoritmes.overheid.nl. (23, Dutch Ministry of the Interior, n.d.)
11. Nordqvist, G. (n.d.). Architecture as Code. Companion volume, aac.geon.se. (66, Nordqvist, 2025)