فرصت AI را از صف استثناها انتخاب کنید، نه از دموی پرزرق‌وبرق

Many AI selections begin with the wrong question: which model delivers the most impressive demonstration? A more useful question is where daily work departs from its standard path, who is left waiting, and what evidence is needed to close the case. Exception queues are often a more practical starting point than an attractive demo.

This note is prepared by “Amir Sharifi,” an AI-based persona in the role of a business strategist. Its purpose is to provide a decision-making framework, not to recount personal experience or claim success in a real project.

A demo usually presents clean, controlled conditions: the input is clear, the objective is defined, and someone promptly validates the answer. Operations, however, face incomplete information, inconsistent identifiers, changing priorities, delayed approvals, and unclear responsibilities. AI value is measured at these friction points, not only by the quality of a demonstration response.

An exception is any event that a standard process cannot move through without additional judgment, investigation, or intervention. An order with incomplete specifications, a maintenance request with an unknown cause, an inventory discrepancy, or a case passed among several departments are all examples. Such cases are commonly scattered across inboxes, tickets, files, messages, and approval queues.

Not every exception is an AI opportunity. An exception becomes a suitable candidate when it recurs, its delay or rework impact is visible, the scope of the proposed action remains bounded, evidence for the decision can be assembled, and the resolution outcome can feed later learning. This definition shifts project selection from “model capability” to “solvability within a process.”

To compare candidates, create a five-criteria matrix: exception recurrence, visible cost of delay or rework, bounded and reversible action, sufficiency of evidence for a recommendation, and the ability to record the final outcome. Rate each criterion as low, medium, or high. The objective is not to produce a seemingly precise score; it is to reveal the difference between executable opportunities and merely appealing ideas.

The first criterion is recurrence. The evaluation question is: does the problem structure or type of ambiguity return repeatedly over a defined period? Low means cases are scattered and lack a clear decision similarity. Medium means a recognizable pattern exists, but case categorization remains unstable. High means cases can be clustered using clear rules and a similar handling path can be designed for them.

The second criterion is visible cost. The question is: if this queue becomes shorter, which operational consequence will observably change? Low means there is only a general sense of waste. Medium means waiting time, back-and-forth, extra contact, or rework is recorded, but its connection to a process consequence remains unclear. High means the exception’s effect on schedule disruption, delivery delay, capacity use, or rework is traceable.

The third criterion is bounded and reversible action. The question is: does AI merely propose, complete, classify, or route, or does it make a decision with an immediate and difficult-to-reverse effect? Low means the AI output directly creates a commercial commitment, schedule change, purchase instruction, or other irreversible action. Medium means a human can correct the output, but the authority boundary is unclear. High means the proposed action is bounded, reviewable, and has a clear path for correction or stopping.

The fourth criterion is sufficiency of evidence. The question is: for every case, are the authoritative source, minimum required data, and decision owner known? Low means data is scattered, contradictory, or lacks a reference source. Medium means some evidence is available, but its validity or freshness requires manual checking. High means permitted sources, core data, instruction versions, and the responsible approver are defined for the case type.

The fifth criterion is closing the learning loop. The question is: after handling a case, can the team determine what the AI recommended, what decision was taken, and why the result was accepted or rejected? Low means no useful trace remains after resolution. Medium means the final outcome is recorded, but the reason for correcting or rejecting a recommendation is unknown. High means the input, evidence, recommendation, human decision, final action, and reason for divergence are recorded.

The combination of these five conditions should lead to a decision outcome. A case with at least four high ratings and no low rating is a pilot candidate. A case with high recurrence and cost but weak evidence or learning loop first needs process repair, definition of a source of truth, or result-recording design. A case with irreversible action or no visible cost should not yet be selected as an AI project, even if its demo is appealing.

Apply this matrix before choosing a tool. First, collect a limited period of past exceptions, cluster similar cases, and document the process owner, evidence source, required decision, and consequence of delay for each cluster. Then advance only those cases that have a defensible position across all five criteria to the design stage.

Suppose a factory intends to invest in “AI for maintenance.” This label is too broad. A better starting point could be a hypothetical queue of ambiguous repair requests: cases moving back and forth among operators, maintenance, inventory, and planning because the fault description is incomplete, the replacement part is unclear, or the priority of the stoppage is not evident.

In this hypothetical example, the AI objective is not to predict every failure. Its initial task may be to identify missing information, extract relevant signals from permitted records, propose a request classification, and route the case to the right role. When evidence is insufficient for a recommendation, the desired output is “I do not know,” together with the information required, rather than a confident-looking guess.

Each case should retain an operational trace: what the original input was, which evidence the AI relied on, what it recommended, who approved or corrected it, what final action was taken, and under what status the case was closed. This trace is necessary for accountability and also provides raw material for process improvement and future evaluation.

In a workflow based on n8n or a similar tool, treat the exception—not the incoming message—as the unit of design. The flow can begin by receiving a request, validating core data, calling permitted sources, classifying the case, and using deterministic rules to send it for approval, completion, or routing. The language model should operate within defined boundaries rather than replace the entire process.

The error path must be designed from the beginning. A transient connection failure, invalid input data, the absence of an authoritative source, and a logical conflict are not the same and should not receive the same response. For example, retrying may suit a temporary disruption, while an incomplete fault description should create a request for additional information. This distinction prevents errors from being hidden beneath a plausible-looking answer.

Evaluation should not be limited to labeling accuracy. Examine whether the AI sent the case down the correct path, requested sufficient evidence, stopped when ambiguity remained, and reduced handling time or unnecessary back-and-forth. Metrics should connect to the quality of process decisions, not merely to the similarity of output text to a reference answer.

Human oversight capacity is also part of opportunity selection. If a queue requires specialist review every day but the responsible role lacks sufficient time or authority, adding AI creates only another volume of alerts and recommendations. Before implementation, define who sees each type of exception, when they respond, what action is permitted, and which situations require a stop or higher escalation.

Start a pilot with a clear boundary: one exception type, a limited data scope, a defined user group, and an output that remains reviewable. Define stop conditions from the outset, such as insufficient evidence, conflict among sources, or a decision consequence beyond the workflow’s authority. Expansion should follow observed handling quality and stable controls, not a successful demonstration.

Choosing an industrial AI opportunity is not about selecting the most complex problem or the flashiest model. The right choice is finding a queue where exceptions recur, the cost of friction is visible, the proposed action is bounded, and every closed case adds to process knowledge. From there, tools, models, and automation become parts of an operational design—not the strategy itself.