Why AI development for GovTech stalls at the pilot stage
A demo scenario comes together quickly: take one dataset, label it, show a working model on a closed stand. At this stage everything lines up — and that is exactly why AI projects in the public sector so often stop here. Operation begins where the showcase ends, and that is where three systemic obstacles appear.
First — data. Information about citizens and infrastructure objects is spread across agencies, in non-interoperable reference books and registries, and some of it is in scans and unstructured exports.
Before training anything, entities need to be brought to a common identifier and reconciliation rules agreed upon. This is not model work, it is data work, and it consumes the bulk of the project timeline.
Second — accountability. AI adoption in an agency hinges not on accuracy but on the question of who is responsible for a system decision if it is wrong.
Until regulations distinguish cases where the signature remains with a human from cases where the system only prepares a draft decision, no one will move the process into production operation.
Third — acceptance. Results are checked manually on a sample: a specialist opens the model's answers and reviews them one by one. This kind of review does not produce a reproducible metric and does not catch degradation.
Automating agency processes requires a fixed control set and metrics for the error rate of each class — then quality is discussed in numbers, not opinions.
We break down how each of the three barriers is closed at the level of data preparation, regulations, and measurable acceptance.
What changes in an agency's work after AI implementation
The effect of AI implementation in an agency is measured not by model accuracy but by the share of processes where manual decision-making is no longer required. Parsing an incoming request, a scanned application, an attached certificate — the first candidate for automation.
We take the methodological framework from OECD Principles of Responsible AI: the model's decision is explainable, and the employee sees the basis on which the routing was selected.
Reducing manual processing of requests
Typical requests — a certificate, an extension, a notification, a complaint about a municipal infrastructure object — go through without an operator: document fields are extracted automatically, checked against agency registries, and a draft response is prepared in advance.
Manual processing remains for non-standard and disputed cases; in high-volume flows, 70–80% of requests are closed without human touch. The time an application takes is reduced from days to hours — the wait at the 'forward to the right department' stage disappears.
Unified registry of requests and decisions
Every request, extracted fields, selected route, and decision made are recorded in a unified registry with a change history.
This eliminates a separate class of distribution errors: an application is not lost between agencies and is not re-sent to the wrong assignee, because the route is fixed once and visible to all participants.
Reporting — overdue items, returns, first-time resolution rate — is built from the registry without manual reconciliation.
Work formats: pilot, turnkey solution, support
The work format is chosen based on data readiness and whether the customer has a team that will take the system into operation. Below are three modes and their limitations.
Pilot on a single process
An AI project pilot takes one process with a measurable result — request processing or checking an application for compliance with regulations.
We limit data to a historical slice, and agree on the metric (share of automatically closed requests, accuracy on the control sample) before the start. Limitation: this is hypothesis testing on a data slice, without fault tolerance, role-based access model, or integrations.
Full turnkey solution
A turnkey AI system is a staged implementation from the data schema to handover into operation: integrations with agency systems, role-based access, logging of model decisions, and an update procedure.
It requires access to a production environment during testing and a dedicated process owner on the customer side.
| Option | When it fits | Limitations |
|---|---|---|
| AI project pilot | One narrow process, historical data available | Result on a slice, no integrations or fault tolerance |
| Turnkey AI system | Process is critical, access and regulations are needed from day one | Requires a production environment for tests and an owner on the customer side |
| AI system support | The system is running, data or load is changing | Without quality metrics, the effect cannot be measured |
AI system support covers data drift, metric degradation, and model updates — it is a separate mode, not a default continuation of the solution.
Stages of engineering work: from assessment to handover
We fix the work order before the start: each stage is closed with an artifact that can be verified, not a report on time spent. The AI implementation stages proceed sequentially — from process assessment to handover into operation.
- Process and data assessment: interviews with operators, source registry, personal data restrictions.
- Solution design: which models and rules are used, where data is stored, how we embed into existing regulations.
- Assembly and configuration: data preparation, model training and calibration, operator interface, service monitoring.
- Historical data validation: run on labeled past periods, error analysis by class.
- Employee training: regulations for working with the system, review of disputed cases, responsible roles.
- AI system acceptance: acceptance against agreed metrics, accesses, documentation, backups.
- Handover into operation and support: quality monitoring, retraining on new data, scheduled updates.
Historical data validation
We run the solution on labeled data from past periods and look not at average accuracy but at error analysis by class: where similar categories are confused, which requests go to an operator for manual processing. AI system acceptance follows the metrics fixed at the start.
Training and operational handover
We train operators and administrators: how to read quality reports, what to do with questionable answers, where to escalate a failure. Handover into operation includes accesses, regulations, documentation, and the model update procedure; support continues after launch.
Delivery package: schemas, access policies, regulations
A system is considered delivered not when the model responds to demo requests, but when the receiving team has a set of documents by which it can operate, develop, and verify the solution without us.
AI system documentation is assembled throughout the project and matches the actual configuration, rather than being written just before handover.
Access policies and role separation
- Solution design: components, data flows between them, trust boundaries, and interfaces with municipal information systems.
- Role and access matrix: who works with raw data, who sees only aggregates, who manages model settings.
- Access policies: procedure for granting and reviewing rights, logging of requests, separation of development and production environments.
- Description of processing environments: where data resides, what goes to external services, what does not leave the protected perimeter.
Regulations and instructions for operators
- Data handling regulations: from intake to archiving, retention periods, anonymization procedure, and incident review.
- Operator instructions: how to handle a disputed trigger, whom to escalate to, which actions are unacceptable.
- Set of validation scenarios: reference examples with expected results — the team uses them to check the system after retraining or settings updates.
- Change procedure: how a change to model logic is approved and who records the new version in the documentation.
Such a package removes dependence on the contractor: new employees are onboarded using instructions, not verbal explanations.
Case study: request processing in a municipal service
Thousands of requests arrive at the municipal service every day — through the website form, hotline, and messaging apps.
Previously they went into one queue, and the decision depended on the operator: they read the text, determined the topic, chose the assignee, and set the deadline manually.
Using the Unified Contact Center project, we will examine what automated processing delivered and which metrics confirm it.
How it worked before
The average time from request arrival to assignee appointment was about nine hours: the application waited until an operator got to it.
The topic was determined by keywords in the subject line, so "pothole in the yard" and "garbage is not being collected" regularly went to the wrong department — the distribution error rate stayed at 18%.
Manual intervention was required almost always: even a typical request about the collection schedule passed through a human, and urgent ones were lost in the common queue.
What changed after launch
The model classifies the request by category and subcategory, extracts the address and urgency indicators, and distribution rules based on regulatory deadlines immediately select the assignee.
Assignment happens at the moment of intake: the average time dropped to 12 minutes, the share of decisions without manual intervention rose to 74%, and distribution errors fell to 3.5%.
The operator only gets involved in disputed cases: the system sends them to a separate queue along with a confidence score, so review is noticeably faster. Every operator correction goes into retraining, and the share of automatic decisions grows without rewriting the rules.
Closed environment or cloud: how to choose deployment
The choice between a closed environment and the cloud is determined not by team habits but by the data class and protection requirements.
If the system contains personal data of citizens, restricted geospatial information, or exports from agency registries, we first answer one question: can the traffic and the data itself leave the perimeter. This answer eliminates half the options before the stack is even discussed.
| Deployment option | When it fits | Limitations |
|---|---|---|
| Closed environment | Data cannot be taken outside the perimeter, there is an on-premises node | Updates go through an approved channel, growth is limited by hardware |
| Isolated cloud | Fast start and elastic resources are needed | Requires confirmed data placement, own keys, and access logs |
| Hybrid | Training on anonymized datasets, result is brought into the environment | Two exchange environments, model version traceability is needed |
A closed environment is not just the absence of an external route. The model is delivered as an artifact and updated through an approved channel, telemetry does not go outside, and every call to the service is logged on the customer side.
In the cloud, the same isolation is provided by a dedicated segment with separate keys, role separation, and network policies: data is encrypted, and access is confirmed by a log.
In practice, the decision is made based on three checks: where the data and backups physically reside, who holds the encryption keys, and how to roll back to the previous model version without losing accumulated state.
Regulatory requirements — FSTEC of Russia and industry regulations — set the lower bound below which the deployment simply will not be approved.
Customer concerns: quality, data, accountability
Customer concerns are part of engineering work: they are addressed before the start, not after launch. Four questions most often decide the fate of a project in the public sector and smart city — we answer them without promises that cannot be verified.
Will there be enough data to train the model?
Lack of data is a common reason projects never reach implementation, so we start with an inventory of registries, request logs, and archives, then assess the achievable quality on a labeled sample.
If there are few real examples, we supplement with synthetic data and rules for rare scenarios — and fix what result we consider sufficient for launch.
What if the system makes a mistake?
Absolute error-free operation does not exist, so the quality of an AI solution is defined by numbers before development: target share of correct answers and acceptable miss rate.
Where a decision has legal consequences, the operator remains in the decision-making loop, and the system highlights disputed cases and keeps a log of outputs by which every error is reviewed.
Who is responsible for the result?
The contractor is responsible for the agreed metrics on the test set and for the working operation of the AI system, not for the impossibility of error.
The warranty period, retraining procedure when data changes, and knowledge transfer to your team are fixed in the contract — the system does not remain hostage to its author.
The data is closed — how do we work and what happens after acceptance?
Training and debugging take place in your environment: data does not leave the customer's infrastructure, access is regulated and logged, and for validation we use anonymized slices.
After the acceptance act is signed, documentation, model artifacts, and a support plan remain, including updates when input data changes.
Let's discuss the task: where we start and what we need from you
Estimating an AI project in the public sector rests not on the model but on the environment: where the data lives, who owns it, and what approvals are needed before the first launch.
That is why work starts with an analysis of processes and constraints, not with tool selection — this way the estimate is based on the actual scope of work, not assumptions.
- Processes: how the task is solved now, who is involved, how much time manual operations take, and where the result is lost.
- Data: examples of exports, formats, volume, share of unlabeled records, presence of personal data, and anonymization requirements.
- Environment: where the system can be deployed — the customer's isolated network, a private cloud, or a hybrid scheme, and which communication channels are allowed.
- Integrations: which agency and internal systems the solution needs to connect to, in what format, and at what frequency data is exchanged.
- Timelines: desired date for the first result, what we consider a pilot launch, and which metrics confirm the effect.
- Responsible parties: the process owner on the customer side, a specialist to grant access, and the person who accepts the work.
- Constraints: regulatory requirements for data processing, logging rules, and explainability of decisions.
Describe the task in this scope — we will come back with an estimate and an implementation plan: stages, scope of work, checkpoints, and metrics by which we will measure the result.
