Pakistan’s digital-transformation agenda is moving from general ambition toward specific AI-enabled government workflows. In the government’s August 24 account of its agreement with Google, the partnership includes AI-powered data analytics for the Federal Board of Revenue’s digitisation programme and the use of AI to improve public-service delivery.
That creates an opportunity to make government work faster and more consistent. It also creates a less visible management problem: the better automation becomes at routine cases, the more important the remaining exceptions become.
Those exceptions are where policy ambiguity, unusual citizen circumstances, incomplete data, security concerns and system failures tend to surface. If an agency measures only how much work AI completes automatically, it can miss the human effort required to correct, escalate and recover the cases that matter most.
Pakistan therefore needs an exception ledger alongside its AI expansion.
The concept is straightforward. For 30 days before a consequential AI-assisted government workflow receives more authority, the responsible agency should record every meaningful case in which a human has to override, correct, escalate, reinterpret or recover the system’s work. The purpose is not to create another reporting burden. It is to learn what the automation still cannot safely handle.
The first field in the ledger should be the type of exception. Some will involve missing or inconsistent data. Others will involve a rule that does not fit the citizen’s circumstances, a security or privacy concern, a technical outage, or an output that appears plausible but is wrong. Grouping exceptions by category quickly shows whether the problem is random noise or a recurring design flaw.
The second field should capture who noticed the problem. An AI workflow is safer when errors are detected by a control built into the process rather than by a frustrated citizen after a bad result. Agencies should therefore distinguish exceptions caught automatically, identified by frontline staff, raised by supervisors or reported externally.
The third field is the intervention required. Did an employee simply verify a result, or did someone need to reconstruct the case from scratch? Was a supervisor required? Did the workflow have to move to a different system? Did the agency need to contact the citizen again because context was lost?
This matters because automation can move work rather than eliminate it. A visible task may disappear while verification, exception handling and recovery quietly expand. The technology can still be worthwhile, but its economics and operating model look different once that hidden work is counted.
The fourth field should be recovery time. A system that performs well in normal conditions can still be fragile if a single unusual case ties up experienced staff for hours. Tracking recovery time reveals whether the organisation has a repeatable process or depends on a small number of people who know undocumented workarounds.
The fifth field is recurrence. If the same exception appears repeatedly, the agency should decide whether to fix the data, change the rule, improve the system, narrow the AI’s authority or formally route that category to a human from the start.
That last option is important. Good automation does not require every case to become automated. In some workflows, the most effective design will be a clear boundary: routine cases move quickly through the automated path, while defined exceptions receive human judgement immediately.
Pakistan already has examples showing why operational design matters as digital systems expand. The Pakistan Observer recently reported on NADRA’s shift toward QR-code-based identity verification, noting both the convenience of easier digital verification and the importance of secure implementation because identity information is sensitive. The broader lesson applies to AI-enabled public services as well. A technological capability becomes trustworthy through the way institutions govern access, verification and failure.
An exception ledger can help turn that principle into a measurable practice.
Consider an AI system used to support tax administration. A headline metric might show that the system analysed thousands of records or flagged likely anomalies. The exception ledger would answer a different set of questions. How often did officers disagree with the system? What kinds of records caused the disagreements? Which cases required specialist interpretation? How long did corrections take? Did similar errors recur after the system was updated?
Those answers matter before the agency expands the system’s authority.
The same approach applies to citizen-service chatbots, document processing, agricultural forecasting, licensing, benefits administration and internal government analytics. The details differ, but the operating question is consistent: what happens when the automated path stops being straightforward?
A strong 30-day test should end with a second-operator handoff. Another qualified employee who did not build the workflow should be able to review the exception categories, understand the escalation rules and manage a realistic failure without private guidance from the original team. If that handoff fails, the agency has discovered a dependency that should be fixed before scaling.
The ledger also improves governance because it makes authority boundaries concrete. Instead of saying vaguely that humans remain “in the loop,” an agency can specify which exception categories require human approval, who owns the escalation and what condition stops the automated workflow entirely.
That is more useful than a generic promise of oversight.
Pakistan’s AI strategy is arriving alongside a larger digital push. The Google agreement includes skills development, student access to AI tools, an AI centre of excellence, support for digital commerce and applications of AI across government and economic sectors. The scale of that agenda makes operating discipline more valuable, not less.
Agencies do not need to wait for a major failure to learn where automation is fragile. They can use ordinary exceptions as early evidence.
A small ledger maintained for one month can reveal whether a workflow is ready to scale, needs redesign, should remain narrow or should keep certain decisions human-led. It can also show where staff training and better documentation will produce more value than additional technology.
The most important measure of government AI will not be how many tasks a system can perform when everything goes right. It will be how reliably the institution recognises and manages the cases when something goes wrong.
Before Pakistan gives AI systems more authority over consequential public workflows, those exceptions should become visible.
Gleb Tsipursky
PhD, a behavioural scientist, CEO of Disaster Avoidance Experts, and author of The Psychology of AI Adoption at Work: From Resistance to Results (Georgetown University Press, 2026).
