AI Can Find the Assumption. It Still Needs Someone to Prove It.

A useful AI workflow does not declare a business process valid. It helps the team see where the evidence stops and an assumption begins.

A useful AI review of a business workflow can start with a simple question: where has repeated behavior started to look like a fact?

I saw the underlying pattern on a multi-bank payment application before current generative AI tools were part of project delivery. The common customer flow was documented, implemented and working across most integrations. Later, a small minority of banks exposed an additional security-validation path that the common workflow did not represent.

The project had evidence for the standard path. The gap was that the evidence did not cover every external-system variation the workflow was being used to represent.

An AI model could not have discovered a private bank requirement that was absent from the material available to the team. What it could do today is compare the sources behind the workflow and make the boundary of that evidence easier to see.

Claims inside a workflow

Take a step such as: “The user enters the OTP and the transfer proceeds.”

That statement may appear in a process diagram, a requirement, a test case and meeting notes. Several successful integrations may support it as well.

A model reviewing those sources can ask which partners the evidence actually covers, whether any documentation describes an alternate authentication path, whether some external systems lack technical confirmation, and whether a generic actor such as “the bank” is hiding meaningful variation.

This is a good analytical task for AI because the model is comparing a claim with the evidence supplied for that claim. It is not being asked to invent the operating truth.

Automation, AI and people have different jobs

If I were designing this review as a repeatable workflow, I would split the work by capability.

Deterministic automation can gather the latest approved requirements, integration documents, test results and decisions. AI can compare those sources and surface inconsistent wording, implied assumptions and uneven evidence coverage. Accountable people still have to decide whether a gap is material, validate the external behavior and approve the next step.

That distinction prevents two common design mistakes: using a language model for work that a deterministic check can perform more reliably, and asking the model to make a decision that depends on external facts it cannot observe.

Exceptions are where the design gets tested

Most workflow diagrams emphasize the common path. Operational friction usually appears when one partner needs another authentication step, one customer segment needs a different approval, a vendor uses a different status model, or an internal escalation rule was never represented in the system.

Automating only the happy path can leave those exceptions as manual workarounds. Trying to automate every possible exception before the team understands them can create unnecessary complexity.

The first design task is to identify where meaningful variation exists and decide what deserves explicit handling. AI can help the team inspect the evidence and map those uncertainties, but it should not decide the operating policy or approve the risk.

The model sees the evidence it has been given. The external system still determines what happens in the real transaction.

If your team is working through a repetitive cross-tool workflow and the hard part is deciding what should be automated, where AI belongs and where human control should remain, the AI Workflow Diagnostic is built around that decision.

Written by me, drafted with AI assistance. The project, the delivery context, and the lesson are mine.