Most first AI projects in public bodies stall before the model is built. Seven checks to run before you commit.
In brief
- Public-sector AI projects rarely fail because the AI is weak. They stall on unclear services, scattered records and unclear accountability.
- Seven checks cover service, data, staff, process, accountability, run cost and ownership.
- You don’t need to pass all seven. You do need to know which ones you are failing.
- A “not ready yet” result is useful: it tells you what to fix first.
Many agencies begin an AI project with a demo or a vendor proposal. Months later there is a prototype that impressed a meeting and never reached daily use by the officers who handle the cases.
The cause is usually not the model. It is that nobody asked whether the organisation was ready to use one.
The real issue is not the technology. It is the starting point.
AI works on records, inside a process, for an officer who has to trust the result and answer for the decision. In a public body that is harder than it sounds: records sit in separate departments, leaders and sponsors rotate, and every decision that affects a citizen must be explainable.
Readiness is not a score to be proud of. It is a plain list of what must be true for a project to reach real use.
The seven checks
| Check | Ready looks like | Not ready looks like | |
|---|---|---|---|
| 1 | Service | A specific service or task with a measurable cost today, such as queue time or case backlog | “We should use AI somewhere” |
| 2 | Data | The records for that service exist, are reachable across units and are trusted | Records in separate departments that disagree |
| 3 | Staff | The officers who do the work are involved and willing | The project is run only by IT or a vendor |
| 4 | Process | The current procedure is written down and applied consistently | Each office does it differently |
| 5 | Accountability | Rules for data use, privacy and who signs off decisions that affect citizens | No one has decided what the AI may recommend and what only a person may decide |
| 6 | Run cost | Someone has planned how the pilot will be operated and maintained afterwards | A pilot with no plan for operation |
| 7 | Ownership | A named owner in the service unit who stays accountable if leadership changes | The project belongs to “the committee” |
Going through each check
1. Service: can you name the task?
“Improve public service” is not a problem. “Reduce the time to answer a permit query” or “flag applications with missing documents” is. A good first problem is narrow, frequent and painful enough that officers and citizens notice when it improves.
2. Data: do you trust the records it would learn from?
Ask whether the records for that service sit in one place, whether departments agree on what the fields mean, and whether they are accurate. If two reports about the same thing disagree, fix that first. AI built on disputed records inherits the dispute.
3. Staff: are the officers who do the work in the room?
The people who handle cases know the exceptions. If they are not involved early, they will not trust or use the result, and they are the ones who answer to the public.
4. Process: is there a procedure to improve?
AI inserted into an undefined procedure produces confusion. Write the current steps down. Often the written version already shows improvements that need no AI.
5. Accountability: what may the AI touch, and who decides?
Decide in advance what records it may use, who can see the results, and which decisions must always be taken by a named official. Include privacy requirements and the explanation a citizen is entitled to from the start.
6. Run cost: who operates it afterwards?
A pilot is cheap compared with keeping it running, monitoring it and updating it. Decide who does that, and what it will take.
7. Ownership: who stays accountable when leaders rotate?
One named owner in the service unit, not only in IT, who owns the outcome and decides when the project is working or should stop. Write the ownership into the unit’s role, not only a person, so the project survives a transfer.
How to read your results
- Mostly ready: pick the narrowest service and run a small, time-boxed pilot with a clear success measure.
- Data or process not ready: this is the common case. Spend the first phase on the foundation: connected, trusted records and a documented procedure. It is not wasted work; most useful reporting depends on it too.
- Accountability or ownership not ready: pause. A pilot without a decision-maker will end as a demonstration.
Five mistakes we see repeatedly
- Starting with the tool. Choose the service problem first, then the technology.
- Picking a showpiece. A flashy use case with no daily users teaches little.
- Skipping the baseline. If you don’t measure today’s performance, you can’t show an improvement.
- Treating the pilot as the project. A pilot that cannot become daily operation is an experiment, not a start.
- Ignoring continuity. Plan for operation, monitoring and a change of sponsor from the beginning.
Our experience
In our work with enterprise data and systems, we build the data foundations that AI depends on: connecting records from several systems and agreeing what the numbers mean. We are not describing delivered AI products here. This is a checklist drawn from how projects like these tend to go.
We can explore a readiness review of your data and process with you, using the seven checks. Which of the seven worries you most?
Know what you are missing before you spend
A readiness check is not a reason to delay. It is a way to spend the first phase on the right thing. Run the seven checks, write down where you stand, and start with the weakest one.
Talk to Balerion about running a readiness review for your organisation. Email us at talk@balerion.co.th.
