Stop Funding AI Workarounds for Broken Systems

A support team asks for an AI assistant because employees cannot find the current policy. The proposal includes document ingestion, embeddings, retrieval, access filters, citations, evaluation, monitoring, and a conversational interface.

It sounds like a serious AI project. It may even be one.

But suppose the policy library has five versions of the same document, nobody owns updates, permissions reflect an old organization chart, and important exceptions exist only in email. The assistant does not repair those conditions. It builds a more convenient entrance to them.

This is a recognizable failure mode in modern technology work: a project is approved to compensate for a defect that the project leaves in place. The new layer may reduce pain for a while. It may also make the underlying problem harder to see, easier to tolerate, and more expensive to remove.

Not every workaround is foolish. Production systems need adapters, retries, fallbacks, migration layers, manual review, and other forms of compensation. The issue is whether the extra layer is an intentional control with a bounded job or an indefinite subsidy for a bad foundation.

The distinction matters now because generative AI can make a workaround look unusually capable. A fluent interface creates an impression of coherence even when the data, process, ownership, or architecture underneath it remains incoherent.

Failure mode 1: The new interface launders the old confusion

AI assistants are attractive when users struggle with a fragmented system. They can search many sources, translate technical fields into plain language, summarize records, and guide a person through a workflow. Those are useful capabilities.

They also create a temptation to treat every usability problem as an interface problem.

Consider a sales operations team with customer status spread across a CRM, billing platform, ticket system, and local spreadsheets. An assistant could call each source and compose an answer. Before building it, however, the team has to establish what “customer status” means, which system owns each fact, how fresh the answer must be, and which users may see it. Without those decisions, the model becomes an improvisational reconciliation layer.

The visible failure will appear as an unreliable answer. The root failure may be conflicting business definitions or missing data ownership.

This is why pull-first project scoping starts with the future workflow rather than the inventory of tools a team already owns. If the desired workflow requires one authoritative account status, define that contract first. Then decide whether an assistant belongs on top.

A better interface can reduce cognitive load. It cannot decide organizational truth on behalf of the organization.

Failure mode 2: Human review becomes permanent error handling

“A person will review it” is often presented as proof that an AI workflow is safe. Sometimes review is exactly the right control. A clinical, financial, legal, or high-impact decision may require accountable human judgment regardless of model quality.

But human review can also conceal a weak design.

Imagine an extraction system that turns supplier contracts into structured records. If reviewers correct a small number of ambiguous clauses, their work may be a sensible risk control. If they routinely repair malformed fields, search for missing pages, reconcile vendor names, and rewrite most outputs, the organization has not automated the process. It has moved the exception-handling burden to a less visible queue.

The test is not whether a human appears in the diagram. It is whether the human has a defined decision to make.

NIST’s AI Risk Management Framework Core calls for organizations to document system scope, expected benefits and costs, human oversight, third-party components, testing, and production monitoring. That lifecycle view is useful here. Review should be designed, measured, and assigned—not invoked as a vague promise after the rest of the system has been chosen.

Track at least:

• what reviewers are authorized to approve, correct, or reject
• the share of cases that require intervention
• time per intervention and the queue’s service level
• recurring correction categories
• the upstream change each recurring category should trigger
• the point at which review cost invalidates the business case

If the same correction happens hundreds of times, it is no longer an edge case. It is a product requirement waiting to be acknowledged.

Failure mode 3: Evaluation is asked to rescue a missing product decision

Evaluation is essential for AI systems. A team should test retrieval, groundedness, tool selection, structured output, safety behavior, latency, cost, and task outcomes where relevant.

Yet an impressive evaluation pipeline cannot rescue an undefined product.

Teams sometimes build large test sets while basic questions remain unanswered: Who is the user? What action follows the output? Which errors are tolerable? What baseline is the AI system expected to beat? When should it abstain? Who owns the outcome after launch?

In that situation, evaluation becomes another compensating project. It produces scores without resolving what should count as success.

Suppose an agent drafts responses to customer refund requests. A benchmark may show that its answers resemble previous responses. That says little about whether the policy is applied consistently, escalations are caught, customers receive a timely resolution, or agents spend less total effort. A technically respectable metric can stabilize the wrong objective.

Before expanding the evaluation stack, write a short outcome contract:

1. Name the user and the decision or task being supported.
2. Record the current baseline in time, quality, cost, or risk.
3. Define the behaviors that make an output acceptable.
4. Identify unacceptable failures and the response to each.
5. Specify who can stop or narrow the system.

Evaluation then tests a product decision instead of substituting for one.

Failure mode 4: Integration spend protects a purchase from scrutiny

Buying a platform does not eliminate design work. It changes where design work happens.

A vendor may offer a compelling AI search product, agent platform, data catalog, observability service, or workflow suite. After purchase, the team discovers that identity does not map cleanly, data contracts are inconsistent, essential APIs are missing, or the operating model conflicts with the product. More connectors, synchronization jobs, transformation layers, and custom exceptions are commissioned to close the gap.

Some integration is normal. The warning sign is when integration exists mainly to avoid revisiting the original decision.

Sunk cost makes this difficult. Leaders may prefer another quarter of technical work to admitting that a selected product does not fit. The implementation team then inherits a political objective disguised as an engineering objective: make the purchase appear correct.

The answer is not to reject vendors. It is to preserve decision rights after contract signature. As I argue in build-versus-buy strategy, buying software does not remove responsibility for architecture, integration, data, security, or exit planning.

At each major integration milestone, compare three options honestly:

• continue integrating the selected product
• narrow the use case to where the product fits naturally
• exit and replace it, including the cost of transition

If the “continue” option is automatically favored because money has already been spent, the review is ceremonial.

Failure mode 5: Guardrails become a substitute for boundaries

An agent with broad access can be surrounded by prompt rules, classifiers, approval nodes, allowlists, step limits, retry logic, audit logs, and policy checks. Many of these controls are good engineering.

The trouble begins when controls are used to justify unnecessary scope.

If an internal research agent only needs read access to four approved sources, giving it broad workspace access and adding layers of instructions is a poor trade. If a coding agent should never deploy directly to production, a reliable permission boundary is stronger than a prompt asking it not to deploy. If a customer assistant cannot safely answer account-specific questions, a clear handoff may be better than increasingly elaborate detection logic.

Guardrails should manage residual risk after scope and permissions have removed avoidable risk. They should not compensate for a system being allowed to do too much.

This principle also protects cost and operability. Each additional classifier, model call, retry path, and review stage adds latency, failure modes, monitoring, and ownership. The most sophisticated workflow is not necessarily the most mature one. Often, maturity means reducing what the system is asked and authorized to do.

Use the workaround ledger before approving another layer

The following ledger turns suspicion into a decision. Use it when a proposal contains words such as bridge, wrapper, reconciliation, temporary sync, manual validation, exception queue, compatibility layer, or AI assistant over existing systems.

The ledger does not force every project to eliminate its root cause. Sometimes the cause cannot be removed affordably. A partner API may remain inconsistent. A regulated manual approval may remain mandatory. A merger may require two identity systems to coexist for a year. A legacy platform may be too risky to replace during a peak business period.

In those cases, the organization can deliberately accept compensation. It should record why, price the continuing burden, and set a review condition. Conscious acceptance is different from forgetting that the layer was ever meant to be temporary.

Choose among four actions, not just build or cancel

When the ledger exposes a compensating project, leaders often assume the only choices are to proceed or stop. There are four useful actions.

Stop when the proposed layer has weak benefit, high continuing cost, and mainly protects an earlier decision from scrutiny. Stopping is not waste if it prevents a larger commitment.

Repair first when the root cause is tractable and removing it simplifies everything above it. Clean the document set, establish the data owner, narrow permissions, redesign the approval step, or standardize the API contract before adding AI.

Contain when immediate replacement is too risky but the pain is real. Build the smallest bridge, restrict its scope, observe it, and give it an expiration or reassessment condition.

Accept deliberately when compensation is structurally appropriate. Distributed systems sometimes require explicit recovery logic. Microsoft’s compensating transaction pattern is a good counterexample to careless workaround thinking: it describes a designed way to undo steps in an eventually consistent operation, with stored recovery information, monitoring, idempotency, and attention to failure in the compensation itself. That is not denial of a defect. It is architecture responding to a real constraint.

The quality of the decision depends on naming which action is being taken. “Phase one” is not a strategy if nobody can say what phase two changes.

Make temporary architecture tell the truth

Teams cannot avoid every compromise. Deadlines, acquisitions, vendor limits, regulation, old contracts, and operational risk all constrain technical choices. Pretending otherwise produces beautiful diagrams and unusable advice.

The practical standard is truthfulness.

A temporary layer should say what it compensates for. Its dashboard should expose both the benefit and the burden. Its owner should have authority to improve the source, not merely maintain the wrapper. Its funding should include retirement or reassessment. Its users should know where the system is authoritative and where it is translating uncertainty.

This is especially important with AI because fluency can disguise structural ambiguity. A model can summarize conflicting records without resolving them, draft around a broken process without improving it, and produce confident language from material nobody maintains. The interface may feel modern while the operating system behind it remains unchanged.

AI strategy requires choosing what not to build. It also requires choosing what no longer deserves protection. The strongest technical decision may be a smaller assistant after a data cleanup, a narrow integration with an exit date, a conventional rules engine, or no new layer at all.

Before approving the next clever addition, ask what condition makes it necessary. Then decide whether the organization is fixing that condition, consciously containing it, or quietly paying to preserve it.

That answer tells you whether the project is a useful control or an expensive way to avoid the real work.