I worked on a GenAI compliance project that permanently changed how I think about process improvement.

A company I worked with had people manually reviewing highly technical project documents before their clients submitted them to authorities. The process was slow, inconsistent, and expensive. Worst of all, we found that the same document would get approved by one reviewer and rejected by another. Every false approval meant a rejected project later.

What most companies would have done

Most companies would’ve done this:

• Review the checklists continuously

• Launch a new training program for reviewers

• Maybe get 15-20% improvement if you’re lucky

We asked something else: “Should humans be looking at these documents first at all?”

What we built instead

We built an LLM system that pre-screens everything and flags issues. Humans still make the final call. The results, after some careful engineering, were quite astonishing. We were able to have zero false approvals in production, with 90% rejection accuracy.

This meant that the work to be done became structurally different.

Reviewers stopped opening documents to find out whether there was a problem. They opened the ones where something had already been flagged, and spent their time on the judgement call instead of the search.

The engineering effort went almost entirely into the false approval rate. Letting a bad document through was the expensive failure, so we tuned for that and accepted that the system would flag some things a person then cleared. That trade has to be made deliberately, because tuning for one error type costs you on the other.

The question most teams ask

Most teams default to ask how AI can speed up an existing process. They optimize workflows and focus on making the individual parts faster.

AI-first companies ask different questions entirely:

• Instead of asking how to review applications faster, ask whether most applications need human review at all.

• Instead of asking how to cut manual data entry, ask why you are typing in data that already exists in six systems.

• Instead of asking how to speed up income verification, ask whether income can be verified without anyone touching it.

The difference:

• Classic redesign makes your process 20% better.

• Zero-based redesign changes what you spend money on.

The second one is harder to get approved, because the saving does not show up as a percentage on an existing line. It shows up as a line that gets smaller or disappears, and that line usually belongs to someone.

Why teams avoid it

So why don’t more teams do this? Because legacy systems feel like permanent beasts with associated roles being untouchable. Essentially, “this is how we do it” feels safe.

There is also a sequencing trap. Zero-based redesign looks like the bigger, riskier project, so teams do the classic version first and plan the real one for later. By the time later arrives, the faster process has its own users and its own budget line, and changing it is harder than it was at the start.

It is worth separating the two fears, because they need different answers. A system that genuinely cannot change is a technical constraint you can test. A role that feels untouchable is a conversation with the person who owns it, and that one does not get easier by waiting.

But if AI can do what used to take three people, if real-time data eliminates manual checks, if accuracy beats human performance. Then what exactly are we protecting?

Originally posted on LinkedIn