AI can do a task without a person deciding when the task meets four conditions: it repeats often, it follows rules that can be written down, its result can be checked without being an expert, and an error is caught before it does damage. We call that rule-based work. The rest is judgment work, where AI prepares and a person decides. Almost every process has both parts, and designing the system is mostly a matter of separating them.
This article explains how to make that separation, with examples from real processes, and why the boundary moves over time.
Rules and judgment
Julien Bek of Sequoia Capital split professional work into two parts. The first is following rules, even complex ones: coding an invoice, checking a document against a list of requirements, writing code from a specification. The second is judgment: deciding which risk to accept, what to do next, when an exception deserves a new rule.
According to the same author, software development was the first field to use AI heavily because it is mostly rules, and it already accounts for more than half of AI tool use across professions. The other categories were still below 10% in March 2026. The shift will reach the other fields, starting with those that have the most rules and the least judgment.
The four-question test
For each task in a process, we ask four questions.
- Does it repeat? A task that happens twice a month rarely pays for a system. One that happens two hundred times almost always does.
- Can the rules be written down? If an experienced person can explain to someone else, in writing, how they decide, the decision can go into a rules table. If the answer is “it depends, I look at each case”, it is judgment.
- Can the result be checked without being an expert? A sum that adds up, a valid tax ID, a filled field: anyone can confirm them. A risk assessment or a strategic recommendation needs someone from the field.
- Is an error caught in time? If the system gets something wrong and the error lands in a review queue, the cost is small. If the error flows into the accounts or reaches the customer unseen, the cost is large.
Four yeses mean rule-based work. A no on the second or third question means that part stays with a person, and the system prepares the work for them.
Where the model ends and the rules begin
In the systems we build, the model reads and writes, and the rules decide. The model turns a free-text request, an email or a scanned PDF into structured fields. Then a table of business rules, written in code, decides what happens: accept, decline, refer, ask for what is missing.
There is a practical reason for this split. A language model reads messy text well, but it is not consistent and cannot explain its decision the same way twice. A rule always gives the same answer for the same case, and when someone asks why, there is a concrete answer. The client owns the rules and can change a threshold without calling a developer. Document extraction follows this design end to end, explained in how to automate document data extraction with AI.
Three processes, split into rules and judgment
Commercial insurance requests. A request arrives by email, by message or as notes from a call. Reading the text, building the risk sheet, checking it against the criteria agreed with insurers and drafting the request for missing information is rule-based. Accepting a risk above the automatic limit is judgment, and it goes to an underwriter with a note of what needs deciding. The full design is in how to automate request triage with AI.
Month-end close at an accounting firm. Classifying invoices and transactions, reconciling and requesting missing documents is rule-based. Reviewing and signing off the accounts is judgment, and it stays with the certified accountant, who answers for them.
Client documents at an insurance broker. Reading the documents and validating each field against the rules is rule-based. Deciding what to do with a document that contradicts another is judgment. In this case, document intake came down from 8 hours to 1 hour per client (see the case).
The exception queue decides whether the system gets used
The boundary between rules and judgment shows up on the reviewer’s screen. Anything that passes the rules with high confidence flows through untouched. Anything that fails a rule, or falls below a confidence threshold, goes to a person with the reason explained in plain language.
“Validation error” leaves the reviewer guessing. “The lines total 1,845 but the document says 1,854, a difference of 9, probably two transposed digits” lets them confirm in seconds. A badly designed queue sends the team back to the old process within a month, even if the system gets most cases right.
The boundary moves
What is judgment today can be a rule a year from now. Every exception a person resolves is an example of a good decision in that process. When the same exceptions repeat and the person always decides the same way, that decision can move into the rules table.
That is why the split between rules and judgment should be reviewed at least once a year, for each process. It is also why whoever runs a process for years learns things a competitor cannot copy: the exceptions and corrections built up over time. The choice between running the system in-house or handing it over is in buy an AI tool, or hand the process to someone who runs it, and the effect of this split on pricing is in paying for results.
Frequently asked questions
Which tasks can AI do on its own?
Those that repeat often, follow rules that can be written down, have a result that can be checked without being an expert, and where an error is caught before it does damage. Collecting and classifying invoices, validating documents and routing requests are common examples.
Does the AI make the decisions in Klevie’s systems?
No. The model reads what comes in and drafts the response, and a table of business rules decides. Decisions that need judgment stay with a person, who gets the case prepared and the reason it was flagged.
What happens when the system is not sure?
The case goes to a review queue, with the original document beside the fields read and the reason explained. The system never fills a missing field with a guess: it marks it as missing.
Does judgment work ever move to the system?
Partly, yes. When the same exceptions repeat and are always decided the same way, that decision can become a rule. That is why the split should be reviewed at least once a year.
Want to know which part of your process is rule-based?
It is the first thing we measure. Book a call and we will separate the rule-based tasks from the judgment tasks with you, with the hours each one takes.
