Skip to main content
Insightech
4 min read

What a government agency should prepare before deploying AI

Most public sector AI projects do not fail because the technology is weak. They fail because four things were not ready before the software was installed.

  • deployment
  • digital transformation
  • lessons learned

We have sat through enough scoping meetings to notice a pattern: when an AI project in a government agency runs into trouble, the cause is rarely the model. It is the things that should have been settled before the software was installed.

This is the checklist we walk through with customers before discussing any solution at all.

1. Where is the data, and what form is it in

This is the single biggest determinant of success, and the one most often underestimated.

AI can read documents, but output quality depends directly on input quality. Some questions to answer first:

  • Where are documents stored — in the document management system, on a shared drive, or on individual officers’ machines?
  • What proportion is digital, and what proportion is still paper?
  • For scanned material: is there a searchable text layer, or are they just images?
  • Do the reports units send in follow a consistent template?

If most of your material is image-only scans, the first step is not AI — it is digitisation. This is not a side task; it usually takes the bulk of the early phase.

2. Are your business processes written down

The software needs to know which steps a document passes through, who approves at which stage, and what sections a report template contains. If that knowledge lives only in the heads of a few long-serving officers, configuration becomes a struggle.

This sounds obvious but comes up constantly: each department does it slightly differently, and no document describes the standard. At that point the AI project quietly becomes a process standardisation project — which is valuable work, but it needs to be recognised and planned for at the start rather than discovered halfway through.

3. Server infrastructure

On-premises AI needs hardware, and the expensive part is the GPU in the AI processing server. Establish in advance:

  • Does the organisation have a server room with adequate power, cooling and physical security?
  • Is there existing hardware you can reuse, or does this require new investment?
  • Does the internal network have enough bandwidth for concurrent users?
  • Is there a backup and restore procedure, and has the restore ever actually been tested?

That last question deserves emphasis. Many organisations have backups but have never tested a restore. A backup that has never been verified should not be counted as a backup.

4. Who operates it after handover

This is the most frequently skipped item, and a common reason systems run well for six months and then quietly fall into disuse.

Answer in advance: who administers the system, who updates templates when regulations change, who handles it when an officer reports a fault. If the answer to all three is “call the vendor”, the organisation is building a long-term dependency.

A good project must be handover-ready: system documentation, training, and at least one person inside the organisation who understands the system well enough to handle day-to-day work.

Where to start

If those four items are not fully in place, that is not a reason to postpone. It is a reason to start narrow.

Pick one department, or one ward. Pick one specific, measurable problem — cutting the time to produce the monthly report, for instance. Run a trial on that unit’s real data. Measure before and after.

This approach has three advantages. Risk stays low because the scope is small. You get real numbers to make the internal case for expansion. And most importantly, you discover your data and process problems while they are still cheap to fix, rather than after a province-wide rollout.

A note on numbers

When selecting a vendor, be wary of anyone quoting a specific accuracy figure before they have seen your data. Recognition and extraction accuracy depend heavily on document quality, typeface, scan condition and how standardised your templates are. A number offered without seeing the data has nothing behind it.

The right approach is to run a trial on a real sample of your documents and report the figure measured on that sample — including the cases the system handled poorly.


If your organisation is at the considering stage, we are happy to walk through this checklist with you in a survey session, even if the conclusion is that now is not the right time.

See it run on your own documents

Every solution sounds good in a description. The only way to know whether this one works for you is to run it against your real documents, templates and workflows. That is exactly the kind of demo we do.

The demo is free and carries no obligation. If it turns out we are not the right fit, we will say so.