AI in practice · Mixed

Process automation: where a model adds and where it's redundant

In one line: If the process is fixed and clear, write code; a model is worth exactly the places where judgment on unstructured text is needed.

Break down the process

Almost every business process is made of three kinds of step: moving data, a decision rule, and interpretation. The first two belong to code and a rules engine; only the third justifies a model.

Such a mapping shrinks the expensive, unpredictable part to one small component, and everything else stays testable and predictable.

Typical examples

Reading a free-text email and extracting order details — model. Checking whether stock is sufficient — code. Phrasing a reply to the customer — model. Sending the message and updating the system — code.

Measure from day one

How many cases passed on their own, how many required a human, and how many were corrected after being approved. The third is the metric that reveals whether automation really works or just moves work elsewhere.

Going deeper

Start in proposal-only mode for a defined period, and measure the human's agreement rate with the proposal. The move to automatic action is made by that number and by the type of action — not by a feeling that the system “looks good.”

Process & teams Architecture

Next: Experiments: how you know the change improved something · Previous: Small, local and edge models · Back to library