All courses / AI Governance / Module 4 / Chapter 17
Learning objectives
After the lesson the participant can:
- Explain why a public authority needs legality before capability and how the legal basis is recorded as a property of the system.
- Distinguish decision support from automated decision-making in the data model, the audit log and the metrics.
- Draft a reasons log entry and a public register entry for a system that influences decisions about citizens.
- Reconcile the retention rules of the AI Act, the GDPR and archives law in a retention schedule.
Key concepts
- Decision support versus decision-making
- In decision support a case officer reads the proposal and signs; in decision-making no person is in the path. The line concerns where authority resides, so it must be visible in the data model, the audit log and the metrics that reveal when human review has become a formality.
- Reasons log
- For every decision the system influences, a record of the inputs, model version, output, applied rule and the human action that followed, written in the language of the case and retained for as long as the decision can be appealed. It is distinct from Article 12 logging.
- Algorithm register
- The place where transparency, inventory and AI Act registration converge. Each entry is a version-controlled file the pipeline validates before publishing its public fields to the website and, where required, the EU database.
- FRIA as a promotion gate
- The fundamental rights impact assessment treated as code: the pipeline refuses to promote a high-risk system without an approved assessment, and a change to purpose or affected population reopens it automatically.
- Retention schedule
- Where three rules meet: logs kept at least six months under Article 26(6) of the AI Act, deletion under the GDPR's storage limitation, and possible permanent retention under archives law. The archivist owns it and the pipeline enforces it as configuration.
Interactive exercises
Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.
Interactive exercise 1 · Match
Public-sector constraints and architectural responses
Match each constraint on a public authority with the architectural response the chapter gives for it.
Interactive exercise 2 · Scenario
A new use for the triage score
Apply the chapter's treatment of purpose, prohibited uses and the fundamental rights impact assessment at Nordvik Region.
Teaching plan
| 10 min | Opening: the teacher puts the public-sector architect's three questions: can the output lawfully ground a decision, can the citizen be told why, and can it be appealed to a person who did not depend on the model. |
| 25 min | Teacher presentation of legal basis, Article 22 of the GDPR, the duty to give reasons and Article 86, registers and Article 49(3), public access and archives, interoperability, procurement and sovereignty. |
| 15 min | Guided reading of Nordvik Region's reasons log entry and transparency record, including the published parity gap for single-parent households and the response. |
| 30 min | Exercise in groups: write a reasons log entry and a citizen-facing register entry for one system. |
| 10 min | Debrief: each group reads its register entry aloud; the others answer as a citizen whether a machine decided, what it looked at and what they can do. |
Discussion
- Nordvik Region publishes its own weakness, the parity gap for single-parent households, because a record that reports only good news is not believed. What would your organisation need in order to publish a weakness of that kind?
- The review time recorded in the reasons log shows, in aggregate, whether human review is real. What other signals would tell you that review has become a formality?
- More AI artefacts are records than most programmes expect, including prompt templates and possibly an official's prompts and outputs. How would your records management plan have to change?
Written exercise
Exercise · 30 minutes
Reasons log and public register entry
Take a system in a public authority that ranks, scores or recommends in individual cases, or Nordvik Region's triage of applications for living-support benefit. First write one reasons log entry: the system and model version, the inputs used with their sources, the inputs excluded by policy, the output, the rule applied, the main factors in plain language, the human action including how long the case was open for review, the decision, and the retention period. Then write the public register entry for the same system under the headings the chapter uses: what the system does, what it does not do, what information it uses, the legal basis, and the citizen's rights. Use words an applicant would understand and place legal references after the plain explanation.
Deliverable: One reasons log entry with plain-language factors and human action, and a public register entry under five headings.
Self-test
Choose an answer to see whether it is right, or open the answer below each question.
How does the chapter distinguish the reasons log from the technical logging of Article 12 of the AI Act?
Show the answer
A. It is written in the language of the case and kept for as long as the decision can be appealed
The reasons log records inputs, model version, output, applied rule and the human action that followed in the language of the case, and it serves the decision letter and the appeal body. Article 12 logging remains a separate, technical record.In Nordvik Region's arrangements for its benefit triage system, how are appeals handled?
Show the answer
C. By a separate unit that has no access to the triage score
The transparency record states that appeals are handled by a separate unit without access to the triage score, so that an appeal is decided by a person who did not rely on the model's estimate.Where no rule of Union or Member State law authorises automated decisions with suitable safeguards, what can a public authority's system do, according to the chapter?
Show the answer
B. Only recommend, and a natural person must decide
For authorities, the relevant exception in Article 22 of the GDPR is authorisation by law with suitable safeguards. Where such a rule exists its safeguards become architectural requirements; where it does not, the system can only recommend.