The Line Governments Keep Getting Wrong on AI

Say a building permit shows up missing a required document. Or a procurement team is staring down dozens of vendor submissions with no clear way to prioritize them. Or a finance director wants to know why one department’s spending jumped between January and February and nobody can say why yet.

In all three cases, a machine can help. It can spot what’s missing, compare documents side by side, summarize what changed, and pull out the details that need a second look, quickly and, most of the time, consistently.

What happens after that is the harder part. Does the machine just help someone understand the situation, or does it get to act on it? Does it recommend a decision, make the decision outright, or stay out of the room entirely?

Nobody’s asking anymore whether machines can handle routine business tasks. They can, clearly. What matters now is figuring out which tasks can be handed off responsibly, and which ones still need a person who understands the context, can weigh what’s at stake, and will answer for the outcome.

This shows up everywhere, but it counts for more in government work, where paperwork is tied to public money, legal compliance, and services people depend on. Every organization deals with bureaucratic friction. In government, getting automation wrong doesn’t just slow things down, it erodes trust. Inside an agency, a permit or procurement request might look like one more item in a queue. To the person waiting on the other end, it might decide whether their project moves forward, whether they get paid, or whether a service they need shows up at all. Just because a process feels routine to the organization running it doesn’t mean the outcome feels routine to the person it happens to.

Walk into any large organization, in Mumbai or New York, and you’ll find the same pile of administrative friction, the red tape that slows everything down. People dig through multiple systems to find one policy. They compare documents line by line, by eye. They check whether forms are complete. They re-enter information that already exists somewhere else in the system. They chase approvals, put together the same reports every month, and burn hours just figuring out what changed since last time.

None of that work is optional. But it’s also not a good use of an experienced employee’s time, and it’s exactly the kind of task a machine can take on safely, as long as the rules are clear and someone can check the output.

Information retrieval is the easy first step. In most organizations, finding an answer is harder than acting on it once you have it. The relevant information might be scattered across policies, contracts, emails, meeting notes, and half a dozen separate systems, and an employee might know the answer exists somewhere without having any idea where to look. A machine can search across all of that, pull the relevant records, summarize a long document, or connect pieces of information that were never linked before. That saves time, and it cuts down on the frustration of hopping between systems all day.

There’s a boundary worth drawing here, though. The machine’s job is to point an employee toward the source of truth, not to become the source of truth itself. People still need to know where an answer came from. They need to be able to open the original record, check the language themselves, and notice when something’s incomplete or out of date.

The machine’s job is to point an employee toward the source of truth, not to become the source of truth itself.

Document review works the same way. Most processes start with the same basic checks. Is the form complete? Are any required fields blank? Does it follow the expected format? Did the submitter attach what they were supposed to? Does the wording drift from an approved template? A machine can run that first pass without much trouble. In procurement, that means flagging missing documents. In permitting, it means catching incomplete submissions. In finance, it means surfacing entries that don’t add up, and in contract work, it means comparing proposed language against the standard terms. None of this replaces a trained employee. It just means they spend less time hunting for basic problems and more time on the ones that actually need their judgment.

Routing works on the same logic. Most delays aren’t caused by hard decisions, they’re caused by a request landing with the wrong team, an approval sitting unnoticed in someone’s queue, or nobody being quite sure who owns the next step. A machine can classify incoming requests, suggest where they should go, flag when something’s overdue, and notice where work keeps getting stuck in the same place. It’s not exciting work, but it can genuinely change how fast an organization responds to people.

Reporting is another place this pays off. Leaders spend far too much time waiting for someone to pull the numbers together, and not nearly enough time actually discussing what those numbers mean. A machine can put together a first draft of a summary, flag what changed, organize recurring data, and point to what deserves attention. And when that first draft is solid, it frees people up to ask the questions that matter: why did this number move, is this a one-off or part of a pattern, does it need action now or just watching, what’s still missing. Those are human questions. The machine’s only job is to make it faster to get there.

Drafting fits the same pattern. A machine can put together meeting notes, standard notices, internal updates, plain-language policy explanations, and first passes at emails, and it can get someone started when the facts are known but the wording still needs work. That word, draft, is doing a lot of the heavy lifting here. Anyone who’s read machine-written text knows it can be perfectly clean grammatically and still completely wrong for the moment: it might skip an important fact, overstate a conclusion, land in the wrong tone, or miss what the audience is actually going to hear. Someone still has to decide what should be said, and whether the draft actually fits the situation.

Once a task touches someone’s rights, their livelihood, their finances, their job, their safety, or their access to a public service, the line gets a lot clearer. A machine can assist with decisions like that. It shouldn’t get to own them.

Routine processes look easy right up until reality refuses to follow the script. A resident shows up with a situation the standard form never anticipated. A vendor raises something that looks minor on paper but actually matters a great deal in context. A department has to move fast in an emergency. Two policies contradict each other. Employees who’ve been doing this work for years know that exceptions aren’t a break from the job, they’re often the part of the job where judgment matters most.

A machine can spot that a case doesn’t fit the usual pattern, pull up similar past cases, and lay out the options for someone to consider. What it can’t do is decide, on its own, when a rule should bend, which risk is worth taking, or when an unusual situation calls for different treatment.

The same holds for anything touching public trust. A machine can help draft a statement or summarize what happened. What it can’t do is understand the history behind the issue, read the mood of the audience, or grasp the weight an institution’s words carry in that moment. In a sensitive situation, accuracy isn’t the only bar to clear. The statement also has to be responsible, timely, clear, and right for the people it’s going to reach, and that takes a person’s judgment, not a model’s.

Before handing a task to a machine, it’s worth asking three plain questions.

None of these questions is complicated, and that’s exactly the point. They pull the conversation away from what a machine is technically able to do and toward what an organization can responsibly let it do.

It’s easy to forget that machines depend entirely on the systems around them. If the underlying information is incomplete, if permissions are unclear, if processes differ from one team to the next, or if data lives scattered across disconnected systems, the machine inherits every one of those problems. And it might still hand back an answer that sounds complete, even when what’s underneath it isn’t. That’s its own kind of risk: people trusting the confidence of an answer without ever seeing the gaps hiding behind it.

Using this responsibly takes more than just picking a tool. It takes reliable information, workflows people actually understand, sensible access controls, and clear ownership when something goes sideways. Employees need to know where a result came from. Managers need visibility into where machines are actually being used. And organizations need a real process for catching errors and deciding who’s accountable when one slips through. In government especially, the technology needs to fit into the work people already do, not become one more disconnected app, one more search box, or one more system that creates more work than it saves.

The best reason to bring AI into government work isn’t to cut people out of it. It’s to clear away the administrative weight that keeps people from doing the jobs they were actually hired for. Public employees should have more time to solve hard problems, serve residents, manage risk, fix broken processes, and plan ahead. Managers should have more time to lead. Specialists should have more room to do what they’re actually good at. Machines can help create that space.

Machines are getting better and better at handling the routine. People still have to answer for what happens next.

Success shouldn’t be measured by how many tasks got automated. It should be measured by whether the work itself got more accurate, easier to understand, and quicker to respond to what people actually need.