When not to build AI

The problem may need another intervention

A request for AI often expresses a real difficulty: scattered information, repetitive tasks, delays, or decisions consuming attention. Recognizing the difficulty does not mean accepting the proposed solution.

Before building, identify what creates the effort. A task can be slow because it requires interpreting complex information, but also because inputs are incomplete or nobody has authority to resolve an exception. These are different problems even when they occur within the same activity.

If a delay comes from an approval with no owner, producing a proposal faster may not change the outcome. If information arrives in an unnecessarily irregular format, changing the input may remove part of the interpretation work.

The appropriate intervention is not always technical. It may involve agreeing on policy, removing steps, or clarifying what one team should deliver to another. These decisions can make a later application useful, but they can also resolve enough of the problem that an application is unnecessary.

This does not require a perfect organization before AI can be introduced. It avoids asking a system to compensate indefinitely for ambiguity the company could resolve more directly.

A decision not to build is more defensible when it offers another intervention. Rejecting a technology while leaving the problem untouched is not itself an improvement. Engineering should explain which path enables progress, what it resolves, and where its limits remain. The alternative should be accountable to the same current business need as the proposed AI project.

Not all variability requires interpretation

Models are useful when work involves inputs or situations difficult to express through simple rules. Yet some variability inside a company is accidental.

A field written in several ways, a sequence that differs by person, or a category without a shared definition can create work that appears to require intelligence. Before automating interpretation, ask whether that variation has a reason to be preserved.

Where inputs can be structured without harming use, a validation rule or form can reduce uncertainty at its source. Where conditions are explicit and stable, rules may produce behavior that is easier to check.

Google's Rules of Machine Learning discusses starting a product without machine learning and using simple heuristics. It also warns about the complexity of heuristics that grow too far. Simplicity must be judged in the actual solution rather than assigned automatically to a category of technology.

A rule set needing continual exceptions may stop being the simpler option. A model can contribute when it handles necessary variability with sufficiently reliable results and reasonable review effort.

The criterion is therefore not always preferring rules to models. It is identifying which difficulty can be removed and which needs interpretation. Using AI to preserve avoidable variation may conceal an opportunity to simplify; rejecting it where variation is necessary may preserve unnecessary work. Both choices need to be tested against the work rather than defended as general principles.

Uncertainty must fit the use

An AI application can produce useful proposals without offering the same kind of guarantee as a deterministic check. That does not invalidate it. It requires understanding which uncertainty the work can tolerate and where additional controls are needed.

In some uses, a person can review a proposal easily and retain the decision. In others, checking the output requires repeating almost all the work. The same capability can be valuable in the first situation and unattractive in the second.

The consequences of an incorrect answer differ too. A disposable suggestion and an operation affecting shared information do not justify the same scope. If the system cannot recognize or contain important errors, it may need a less consequential role.

Insufficient evidence is a reason to postpone implementation, not proof that the capability is useless. A bounded experiment may be worthwhile if it resolves a particular uncertainty. Exploration should not be treated as if it had already established a case for operation.

Autonomy itself can be unnecessary even when AI adds value. Anthropic recommends starting with the simplest solution that addresses the problem and adding complexity when needed, while noting cost and latency tradeoffs in agent systems. Dispensing with an agent is different from dispensing with every AI capability.

The decision should state which use the evidence supports. Preparing information, recommending an action, and executing it are different scopes. Narrowing the role can preserve substantial value without accepting uncertainty the company cannot manage. The choice is often about how far to proceed, rather than whether the technology has any value at all.

Compare alternatives on the same work

A comparison loses value if it credits AI with the full outcome while describing only the alternative's limitations. Both should be examined against the same goal and comparable conditions.

The reference may be the current procedure, an improved version of it, or a conventional solution. It need not be perfect. It should make clear what actually changes and how much work remains under each option.

The analysis needs preparation, review, integration, and exception handling as well as execution time. If an automatic proposal requires a complete check, that effort is part of its cost. If a rules-based solution requires frequent maintenance, that must be included too.

Volume and frequency matter. An occasional task may justify an assistance tool without justifying a permanent system. Recurrent use may support greater investment, but only when the operation can actually benefit from the improvement.

Time released does not automatically become a financial saving. It may enable other work, reduce delays, or improve quality. Evaluation should identify which consequence is plausible and what organizational changes are needed to realize it.

The comparison should expose assumptions. If its case depends on future volume, very brief reviews, or sources not yet available, those conditions are not results. Making them visible identifies what to check before committing more resources.

Opportunity cost matters as well. A project can create value and still be less urgent than fixing an integration or source affecting several activities. Building should be considered within a portfolio of needs, rather than in an empty space containing only this opportunity.

Maintenance capacity also limits the choice

A solution can pass a test while remaining unsuitable for the organization that must operate it. People need the capacity to review changes, handle incidents, and maintain the information on which the system depends.

Buying a tool does not necessarily supply that capacity. Providers may assume technical tasks, but the company still needs decisions about use, exceptions, and expected outcomes. Certain responsibilities must retain a recognizable owner.

If nobody can perform those functions, narrower scope or a simpler alternative may be preferable. Building first and hoping the organization later discovers how to maintain it defers a viability condition until dependency already exists.

Concentrated knowledge also deserves examination. If one person alone understands how to correct the system or interpret its outputs, operation can be fragile. The answer need not be a larger team. It may be less complexity or capabilities the existing team already knows how to administer.

Organizational capacity can improve. A responsibility can be assigned, a review process prepared, or a maintenance agreement established. Those actions belong in the decision with their effort and limits, rather than remaining informal expectations about what someone will eventually do.

Choosing not to build yet can prevent a useful possibility from becoming a service the business is unprepared to sustain. The timing matters: postponement tied to a verifiable condition differs from abandonment without criteria. It preserves the possibility of acting when the conditions become suitable.

A useful no explains what would change the decision

Rejecting an initiative has more value when it leaves a conclusion that can be revisited. What problem remains? Which alternative will be used? What evidence is missing for another approach?

Some reasons may endure: stable rules already handle the work, and a small improvement does not justify replacement. Others are temporary: no reliable source, insufficient volume, or an inability to evaluate output quality yet.

Reconsideration should not depend on every new model announcement. Identify which change would matter to the work: less checking effort, better access to information, or a capability that resolves a specific limitation.

It is also valid to conclude that further research is unnecessary. When an alternative meets the need and the cost of exploration exceeds the expected learning, continued experimentation can consume resources without improving the decision.

Disagreement may reflect different benefits being pursued. One person wants to save time, another wants to learn, and another wants a strategic capability. Clarifying these objectives establishes whether the decision concerns an operational solution or an investment in learning.

Both can be justified, but not with the same argument. An experiment may deserve resources for the knowledge it will produce even before it promises savings. Its scope should be limited to that learning and avoid creating operational dependency before the case for use has been demonstrated.

The discipline is to retain the freedom to choose the appropriate intervention. Sometimes that will be an AI system; sometimes a conventional improvement or organizational decision. Design quality lies in the relationship between the problem and the selected solution, rather than the presence of a particular technology.

The resulting decision should remain specific enough to act on. If the answer is to simplify, identify the source of avoidable variation. If it is to limit the use, define the smaller responsibility the system may take. If it is to wait, retain the condition that would make another assessment worthwhile. These are different outcomes, each with a practical consequence for the work.