Practical AI for institutional operations, without the theatre

The question nobody asks first: how good is the current process?

Before a model is trained, someone should measure how accurately the existing manual process performs. How often is a document misclassified today? How often is a form field transcribed incorrectly? What does an error currently cost, and who catches it?

This is skipped remarkably often, and its absence makes the whole project unfalsifiable. A model reporting 94% accuracy sounds impressive until you learn the clerical process it replaced was running at 98%. It sounds transformative if the manual process was at 76% and consuming four staff. The same number means opposite things, and only the baseline distinguishes them.

Why smaller models usually win institutional work

Institutional AI problems are dominated by three shapes: classify this document, extract these fields, predict this quantity. All three are well served by purpose-trained models that are small enough to run on modest hardware, cheap enough to run at volume, and specific enough to evaluate honestly.

Large general-purpose models are genuinely useful for open-ended language work — drafting, summarising, answering questions over a knowledge base. They are a poor fit where the output must be consistent, auditable and cheap at scale. They also introduce a dependency on an external service, which raises data residency questions that many public-sector clients cannot answer affirmatively.

The engineering advice follows: pick the smallest model that solves the actual problem, and only reach for a larger one when the task genuinely requires open-ended language understanding.

Explainability is not optional when a decision affects a person

When a model influences an entitlement, a payment, a clinical pathway or an enforcement action, the affected person is entitled to know why. 'The model decided' is not an answer a tribunal or an ombudsman will accept, and it is not one an institution should be comfortable giving.

In practice this means three things. Every automated decision is logged with its inputs, its confidence and the model version that produced it. Cases below a confidence threshold are routed to a human rather than decided automatically. And the human reviewer has the authority and the information to overturn the model, with that override recorded and periodically analysed.

That last point matters more than it appears. A steady stream of overrides in one category is the earliest reliable signal that a model has drifted or was never right for that segment of cases.

The data is the project

Teams consistently underestimate how much of an AI engagement is data work: locating records, resolving inconsistent labels, handling missing fields, deciding what the ground truth actually is, and assembling an evaluation set that the model never sees during training.

For document-heavy institutional work there is an additional obstacle. Real inputs are poor scans, photographs taken at an angle, forms filled in by hand, and mixed Bangla and English. A pilot trained on clean examples will demonstrate beautifully and then fail on the actual post bag. The only defence is to build the evaluation set from genuinely representative inputs from the beginning.