The hardest question before an AI project is rarely a technical one. It concerns the authority itself: can it describe, reliably, how work is actually done there? Five questions that should be answered beforehand, and the order in which it makes sense to answer them.
Most projects begin with a technical question. Which model, which provider, which way of running it, which legal basis? The question is legitimate, and in recent years it has become much easier to answer. There are procurement routes, operating models within the European Union and well-practised procedures for the data protection impact assessment and for involving the staff council. These are demanding tasks, but the ways of solving them are known.
More often, projects get stuck on a question that comes earlier and is less often treated as a project question. How is work actually done in this authority? Which workflows exist, who decides at which point, which rule applies when, and where do written and lived practice diverge?
This gap is not a failing. Every organisation that has grown over time has it, in business as much as in the public sector. In public administration it weighs more heavily, because three things are fixed here that are matters of discretion elsewhere. Responsibility is assigned, decisions must be reasoned, and every case must be kept on file. A system built into this order before the order has been described meets requirements in operation that never came up during the project.
Five questions can be settled with relative ease before the start. Once the project is running, they take considerable effort.
1. Does the workflow run the way it is described?
Every automation needs a workflow to start from. What gets used is whatever exists: a service instruction, an organisation manual, a procedure description from the last certification. These documents describe the intended workflow, as a rule with care.
The actual workflow is rarely identical to it, and for good reasons. A temporary stand-in arrangement has become permanent. A query to the specialist department appears in no document, yet without it a considerable share of cases would not be ready for a decision. Mostly these are adjustments that make the work better. They are simply not written down anywhere.
Where intended and actual diverge, automating the intended workflow means automating a fiction. The result is not technically wrong; it just does not fit what happens in the authority. The effort of making it fit then falls after the project instead of before it.
So asking "Have we documented the process?" does not settle the matter yet. What counts is whether we know where the documentation departs from practice, and whether the departure is a flaw or a quiet improvement.
2. Who is responsible, and what does "take over" mean?
AI agents, it is said, can take over routine tasks. In a company that is an organisational statement. In public administration it is a legal one.
Responsibility here is assigned: by statute, regulation, the schedule of responsibilities and signing authority. Whoever takes over a task takes over a responsibility. Whether a system can technically handle the activity is therefore only half the question. The other half is whether the activity can be delegated at all, to whom it reverts in case of doubt, and who signs at the end.
That rules out less than it sounds. Preparing, compiling, checking for completeness and putting forward a reasoned proposal all precede a decision without being one. The line between preparation and decision is drawn by law, and it has to be known in advance for every single step. A general commitment to keeping a human in the loop does not replace that.
3. Can every proposal be traced back to a source?
Keeping a complete case record, traceability and the duty to give reasons are part of administrative action, and they are older than any system meant to fulfil them. They cannot simply be ticked off in a specification. A decision must be reasoned, the reasoning rests on something, and whatever it rests on belongs in the case file.
A system whose outputs cannot be traced back to a nameable source therefore runs into conflict at the core, not merely at the edges. However plausible the result may sound, it cannot be used in the case.
In practical terms: for every statement, can you name the place it comes from, meaning the document, the paragraph or the record? And is that reference solid enough to belong in the file, instead of lying next to it?
4. Where is the data held, and what does the system learn from?
The obvious part has become quite negotiable: operation within the European Union, no training on your own holdings, a deletion concept worthy of the name. Commitments like these are available on the market. What remains to be checked is whether, in the specific case, they are contractually guaranteed and technically verifiable and which parts of the service they cover, because sign-in, support and sub-processors are not always located in the same place as the data.
The less comfortable part lies on your own side. Data minimisation presupposes knowing what is there: which file shares, drives, mailboxes and legacy holdings a project touches, and which personal data sit in documents nobody still thinks of as personal. This inventory is laborious and unspectacular. It decides whether the provider's commitments refer to the right object.
5. What exists only in the specialist systems?
A considerable part of what a project would need to know sits in the specialist systems: in field names, status models, mandatory fields, validation rules and deadline logic. These systems have grown over years, often across several replacements. They contain decisions whose rationale nobody would write down any more, because it has become self-evident.
Getting at these holdings is uncomfortable. Interfaces are missing or expensive, contracts do not cover access, and the people who really know the system are needed everywhere anyway. A project that leaves out the specialist systems works with half the information, and it is in that half that the exceptions lie.
What such a system cannot do
It would be convenient to claim that a system can understand an organisation. It cannot. It reads what is there and lays it together. What comes out is a proposal with a source reference, traceable back to the passage it came from. It becomes insight only once people in the authority check it, correct it and use it. This boundary determines how such systems have to be built.
Contradictions should not be smoothed over either. If the service instruction says something different from the specialist system, a clean model could be produced by siding with one of them. That would make a better diagram and a worse result. The places where two descriptions contradict each other are almost always the places where a project later gets stuck. They need to be named.
The order
None of these five questions argues against using AI in public administration. They describe the conditions under which it holds up, and they point in one direction: understanding comes before automating.
A larger model does not reverse that order either. An authority that cannot reliably say how it works can neither automate its work nor evidence it nor move it to a new system. The tools are not the problem. What is missing is the ground they need to take hold.
That ground is not lost if a project is postponed. A reliable description of your own workflows is needed for replacing a specialist system just as much as for audit evidence and onboarding. It remains once the project is over, even if the technology changes again.
Further reading
The theory behind it is under Thinking. How aiio's solutions build on one another is set out in "Why one solution became three".