Greece told every public body to list its AI, but the list is the easy part.

I was going through the law while drafting notes on what the new register would mean in practice, and at first I was reading it exactly as I suspect many organisations will: as a list of fields to complete. Name of the system, purpose, timeline, the data it uses. Then I reached three items close together and stopped. One asked about the decisions the system supports or makes. Another asked about risks to people’s rights. Another asked about the measures taken to keep the system operating safely.

I went back and read them again because, put together, they were not really asking what AI a public body owns. They were asking what the system is allowed to influence, what can go wrong for a person when it does, and what stands between that failure and the person affected. Those are the same questions I ask when I work on human oversight. I had started the morning thinking I was writing about an AI inventory. I ended up writing about something much closer to an oversight map.

Since July, every public body in Greece that uses an artificial intelligence (AI) system has a new duty. It has to declare that system in a national register kept by the Special Secretariat for AI and Data Governance.¹ For systems that were already running before the law took effect, the declaration is due without delay, and no later than 31 December 2026.¹ A new system has to be declared before it starts working.¹

The law lists at least eleven things each declaration must contain.¹ It gives no template, and when I last checked, on 9 October, the Secretariat had published no guidance on how to fill them in.

Most of the eleven are what you would expect. The name of the system. What it is for. When it runs. What data it uses and produces. What it can do and how it works. How it is classified under the EU AI Act. Whether an impact assessment was needed and done.¹ An IT department can answer those from a contract, a vendor's documentation and an afternoon with the data protection officer.

Three of the items are different. They ask in which decisions the system takes part, what risks it creates for people's rights, and what measures keep it operating safely.¹ You cannot answer those from a brochure. They are the questions human oversight exists to answer, and the register asks every public body to answer them in writing.

Will your declaration describe a system nobody checks?

The easy reading of the law treats the declaration as an asset register: list the system, describe it, file it, move on. I expect many bodies to fill it in that way, because that is what an IT department is set up to do and the deadline is close.

The trouble is that an inventory answer to the three hard items describes a system nobody checks.

Take the systems already in use. Going through public procurement and spending records for the outreach on my guide, I found AI in places you would expect and some you would not. By type:

• a large city's website assistant that answers residents' questions;
• a regional authority's assistant that answers from the decisions of the region's councils;
• a regulator piloting a model that estimates players' risk of developing problem gambling;
• a water utility buying a platform to build and govern its own AI applications;
• a small town commissioning a plan for where AI could help.

Now read the three hard items against them.

Decisions. A website assistant looks like it takes part in no decisions. But if it tells a resident they are not eligible for a benefit and the resident never applies, it has taken part in one. The regional assistant quotes council decisions back to citizens. When it misquotes one, who notices?

Risks to people's rights. The law asks for the risks to the rights, freedoms and legitimate interests of people and organisations, especially for groups defined by race, ethnicity, social position or age, and for people with disabilities or chronic illnesses.¹ A model that estimates who is at risk of problem gambling is about specific people by design. A chatbot that cannot be used with a screen reader shuts out exactly one of the groups the law names.

Measures for safe operation. This is where the inventory answer is most tempting, and most hollow. "A member of staff reviews the output" is the sentence I expect to read most often. It describes an intention. It says nothing about whether that person can catch the system's errors, under the workload they actually have, with the screen they actually use.

I ran into this during a review where the reassurance was that a person always checked the system before anything became final. On paper, that sounded like human oversight. So I started asking what that check actually involved. What was the reviewer looking for? How many cases did they handle in a day? How much time did they have for each one? What did the interface show them that would help them recognise a bad recommendation? And if they thought the system was wrong, could they simply override it — and what happened next? Nobody could give me a clear answer.

There was a human in the workflow, but we could not describe the conditions under which that human was expected to catch a mistake. That distinction has stayed with me. Putting a person between an AI output and a final decision is easy to draw in a process diagram. Demonstrating that they can actually intervene is much harder.

That gap is not a Greek problem. The EU AI Act will ask deployers of high-risk systems in public services to assign oversight to people with the competence, training and authority to do it,² from 2 December 2027.³ A declaration written as an inventory now becomes the document someone reads later to ask whether that oversight was ever real.

How to fill in the three items that matter

These are the steps I give public bodies. They work for any organisation that has to explain its AI to someone outside it.

1. Map decisions, not features

For each output the system produces, write down who acts on it, what they decide, and what they have in front of them when they decide. "The assistant answers questions about property tax" is a feature. "Residents decide whether to pay, appeal or apply for a reduction based on the assistant's answer, without seeing the rule it used" is the decision map the item asks for.

Include the decisions nobody records: the application never made, the complaint never filed.

2. Write risks by who is affected

List the people the system touches, then ask what goes wrong for each group if the system is wrong. The law names groups to look at; start there, then add your own. Two checks catch a lot:

• Can everyone use the service? An interface that fails with a screen reader or a keyboard excludes people the law names, and public-sector websites and mobile apps already have to be accessible under EU law.⁴
• Who is most likely to be wrong about? Systems trained on the common case fail at the edges, and the edges are where the named groups are.

3. Describe measures as evidence, not intentions

A measure is something you can show working. For each human check, write down where in the process a wrong output can still be stopped, who stops it, and how you know they would. The last part is the one nobody writes.

The way to know is to test it. Put a small number of cases with known errors into the real review flow for a week, with the staff who normally review them, and count how many are caught. Agree in advance what rate is good enough. A low catch rate is not a failure of the staff; it tells you what to change in the screen, the workload or the rules, and it gives you a real sentence for the declaration.

If a system has no point where a wrong output can be stopped before it takes effect, say so. That is a finding, and it belongs in the declaration more than a reassuring line does.

4. Start with the system closest to people's rights

If you have several systems, do not declare them in alphabetical order. Start with the one whose errors land on a specific person: eligibility, risk scores, anything that ranks or flags people. Give that one the decision map, the risk list and the test. The website assistant can follow.

5. Keep the declaration alive

A declaration describes the system as it is on the day you file it. The law makes the person who files it responsible for keeping its information up to date as well,¹ so when the system, its use or its data changes, the declaration should change with it. Put a review date on it, and tie the review to the moments that matter: a new model version, a new use, a complaint.

A register is a promise someone can check

Registers of public AI are usually discussed as a transparency measure, something for journalists and researchers. That is part of it. The bigger effect is on the body that fills it in, because the form makes it write down, once, what its oversight actually consists of.

Written as an inventory, the declaration will read as one: a list of systems with a reassuring sentence under each. Written from the three hard items, it becomes a short record of where a person can stop the system, what they have in front of them, and how well that works. The first version satisfies the deadline. The second is the one that will still make sense when someone asks, two years from now, what the human in the loop was there to do.

The reaction I got when I raised those questions was revealing: the conversation started with what information had to go into the register, and shifted only when I asked, “If the human disagrees with the system, what can they actually do?” That was the point where it stopped being a documentation question and became an operational one.

Sources

1. 1. Law 5321/2026 (Greece), Government Gazette ΦΕΚ Α΄ 114, 20 July 2026: Article 21 (the Registry at the Special Secretariat for AI and Data Governance; declaration before a new system starts operating; at least eleven items, α to ια; responsibility for collecting, recording and updating the information) and Article 25(2) (systems in use before the law: without delay and no later than 31 December 2026). aade.gr (PDF) (checked 2026-10-09) ↩
2. 2. Regulation (EU) 2024/1689 (AI Act), Article 26(2). eur-lex.europa.eu (checked 2026-10-09) ↩
3. 3. Regulation (EU) 2026/1744 (Digital Omnibus on AI), amending Article 113 of Regulation (EU) 2024/1689: Chapter III, Sections 1 to 3 apply from 2 December 2027 to high-risk AI systems under Article 6(2) and Annex III. eur-lex.europa.eu (checked 2026-10-09) ↩
4. 4. Directive (EU) 2016/2102 on the accessibility of the websites and mobile applications of public sector bodies, Article 4, eur-lex.europa.eu in Greece, Law 4591/2019, Article 4, Government Gazette ΦΕΚ Α΄ 19, 12 February 2019. aade.gr (PDF) (checked 2026-10-09) ↩