The cost of checking AI results is not a secondary item. It belongs in the core business case for an AI process. If an employee must review an output, correct it, handle an exception and record a decision, that work belongs in the cost model. Assess value on your own process sample, with actual inputs and actual responsibilities, without relying on market prices or promised returns.
An AI output is not an independent business result. In manufacturing, it may be a proposed classification of a deviation. In accounting, it may be a draft document description. In customer service, it may be a proposed reply. The official decision, posting, status change or customer communication remains a process action with a defined owner.
For that reason, the business case for an AI process does not begin with how convincing the model output appears. It begins with a question: how much work arises before acceptance, upon rejection and while handling an exception?
Review often involves more than reading a result:
If these actions are excluded, the assessment shows only part of the work. AI may shorten one step while increasing the need for control elsewhere. This is not an argument against using AI. It is a reason to use a complete operating model.
The NIST AI Risk Management Framework provides a framework for managing AI risks. It can help structure questions about governance, measurement and process oversight.
The framework does not confirm the accuracy of a specific system in your process. It does not set an acceptable error threshold for your documents, customers, production orders or postings. Those decisions require your own inputs, owners and verifiable acceptance rules.
The practical consequence is straightforward: use an external framework for management discipline, and build the business decision on your own working sample.
A market price for a tool or a promised return is not required for the assessment. It is enough to make the work the process actually requires visible. Separate at least four layers.
Identify what enters the AI step and who owns each input. Inputs may include documents, master data, order history, work orders, approval rules or ERP records.
Poor or incomplete input should not disappear behind a broad label such as "AI error". Separating causes helps determine whether the data, a process rule, operating instruction or the method of applying AI needs improvement.
Define who reviews the result, with what authority and against which verification source. Naming the reviewer role is not enough. Describe the decision that person is allowed to make.
For example, a reviewer may:
Measure review time from opening the item to the recorded decision. Separate simple acceptances from items requiring supplementation, correction or escalation. An average without this distinction can hide the work that carries the greatest risk.
A rerun is not necessarily a failure. An additional attempt may follow a supplemented document, a change in business context or a need for a different sequence of steps. Still, reruns need a visible cost and an owner.
For every exception, record at least:
The ERP system should remain the place for official transactions. AI may prepare a proposal or working material, but the process must state clearly who confirms the record before posting, issuing, changing a status or taking another official action.
Instructions, approved sources, examples, exception rules and acceptance criteria are not a one-time preparation activity. Business processes change, new document types appear and exceptions reveal gaps in existing rules.
Include the work required to:
Knowledge maintenance is not an administrative add-on. It determines whether the process can remain understandable and controlled after the initial test.
Select a sample of items that represents actual work, including straightforward cases, incomplete inputs and known exceptions. Do not select only clean examples with an expected positive outcome.
For each item, keep two comparable records: the standard process without an AI step and the process with an AI proposal and human review. You do not need to assume a single monetary value for every outcome. First, measure operational facts.
Useful measures include:
The business assessment then compares total work and decision quality, not only output-generation speed. The question is not "did AI speed up the first draft?" It is "is the entire procedure, including review and exceptions, acceptable to the process owner?"
Consider a process where AI prepares a proposed classification of incoming documents. The data owner is responsible for the original document and master data. An accounting clerk checks the proposal against the document and ERP rules. The accounting manager decides on items escalated by the clerk. The ERP record becomes official only after a confirmed action by an authorised person.
In this scenario, the assessment must not count only the time needed to prepare the proposal. It must include time for review, corrections, returned items, escalations and instruction updates when a new document pattern appears. Only then is there a basis for comparison with the existing process.
An acceptance criterion should be verifiable, tied to the process and approved by the responsible person. Avoid vague language such as "the result is good enough".
Examples of criterion formats, which the process owner needs to make specific, include:
A criterion is not only a technical check. It defines the boundary between a recommendation and an official business action.
Your own sample does not predict every future case. Rare exceptions, changes in input data and process changes can alter the scope of review. Assessment results apply to the observed sample, the described procedure and the acceptance criteria in place at that time.
Also, a lower number of corrections does not provide enough information on its own. It may indicate a better output, or it may indicate superficial review. Keep a decision trail, verification sources and reasons for exceptions alongside the numbers.
In the ORKA approach, the focus is on process and accountability: ERP remains the system for official transactions, Orkasta: daily collaboration supports the everyday working context, and Trueforce is a specialised engineering offering. Define boundaries between these roles before introducing an AI step into the workflow.
Before deciding whether to expand or continue a pilot process, prepare the following record:
If this list cannot yet be completed, the process is not defined well enough for a credible assessment of the cost of checking AI results. Business process screening can provide a structured starting point focused on the actual workflow, responsibilities and decision points.