Most AI evaluations start with the wrong question.
They start with what the system could do if it works. Demos, pilots, and vendor decks all answer that question, and they answer it well. The question that actually determines whether a project succeeds is different: what happens when it is wrong.
Every AI system produces wrong outputs. Not occasionally, as a defect awaiting a patch, but as a property of how the technology works. The useful question is never whether errors occur. It is whether your process can absorb them, detect them, and recover from them at the rate they arrive.
That reframing disqualifies a lot of proposals before anyone spends money. Here is how to apply it.
Some Uses Are Prohibited, and the Rules Moved Recently
Start with the hard constraint, because it is the only part of this decision with a legal answer.
The EU AI Act bans a category of practices outright rather than regulating them, covering things like certain forms of social scoring, manipulative techniques that exploit vulnerability, and specified uses of biometric categorisation and emotion inference in workplace and education settings. Those prohibitions were never deferred. They apply now.
The rest of the picture shifted in 2026, and it shifted in a way that is widely misread. The Digital Omnibus on AI, in force since July 2026, moved compliance deadlines for stand alone high risk systems under Annex III, covering uses such as recruitment, credit scoring, and education, from August 2026 to December 2027. Systems embedded in regulated products moved to August 2028.
Two things matter more than those dates.
The obligations were postponed, not softened. The deferral happened because harmonised technical standards were not ready, not because anyone changed their mind about risk management, data governance, documentation, human oversight, or conformity assessment. Teams treating the extension as cancellation will meet identical requirements with less runway.
And the transparency obligations were not delayed at all. Disclosure that a person is interacting with an AI system, and labelling of AI generated content, applied on the original August 2026 schedule. These bind by function rather than by risk tier, so most generative AI products are already in scope. A further deadline for machine readable marking of generative AI already on the market falls in December 2026, which is weeks away.
Verify your own position with counsel. This area has changed twice in a year, and anything written about it ages fast, including this.
The Failures That Hurt Look Right
Obvious failures get caught. A system that produces nonsense gets reported on day one.
The expensive failure mode is different: plausible, confidently stated, subtly wrong output, accepted by someone who had no practical way to check it. Be cautious wherever three conditions hold together. The output looks authoritative. The reviewer lacks independent information to verify it. The consequence compounds quietly over time.
Financial reconciliation, regulatory filings, clinical and legal summarisation, and anything feeding an automated downstream decision all sit in that territory.
The standard mitigation is human review. Interrogate that claim hard. Review only means something if the reviewer can realistically detect the error, has time to do so at production volume, and is not under pressure to clear a queue. Review that degrades into clicking approve is worse than no automation, because it manufactures the appearance of control and quietly moves accountability onto someone who never had a chance to catch anything.
No Data, No System
This kills more enterprise proposals than anything else, and it usually surfaces late.
If the behaviour you want has never been recorded, there is nothing to learn from. If it was recorded inconsistently across business units, the system learns the inconsistency. If your history reflects decisions you would not want repeated, the system reproduces them faithfully and at scale.
Three checks before committing: do you have enough examples, including the edge cases that matter most and occur least; does the recorded outcome reflect what should have happened rather than merely what did; and has the underlying process changed recently enough that history no longer describes current conditions.
Pretrained models shift this but do not remove it. You still need representative data to evaluate against. Without it you cannot tell whether a system works, only whether its output reads well. Those are not the same property.
When the Problem Has an Exact Answer
A meaningful share of requests labelled as AI projects describe problems with correct answers.
Tax calculation. Eligibility against written criteria. Inventory reconciliation. Routing by defined rules. Compliance checks against a published standard. A rule engine gets these right every time, explains itself by construction, costs almost nothing to run, and can be tested exhaustively.
Putting a probabilistic system inside a deterministic problem buys nothing and costs correctness, explainability, and testability. It happens anyway, usually because the rules are complex and badly documented and AI looks like an escape from writing them down. It is not. It defers the work and makes the result harder to audit.
The sensible hybrid: AI to extract structure from unstructured input, deterministic logic to decide what happens next.
When the Real Problem Is Upstream
Some proposals are technically feasible and still wrong to build.
If a team burns hours on a task because an upstream system emits bad data, automating the task preserves the bad data and adds a layer. If approvals are slow because two of three signatories are unavailable, a summariser does not help. If a report takes a week because nobody agreed what it should contain, AI produces the disagreement faster.
Trace the work backwards to where the cost originates. A real fraction of AI proposals are requests to automate around an organisational problem someone gave up trying to fix, and automating around it makes that problem permanent.
The Same Test Kills Blockchain Projects
We build blockchain systems, so take this as the section worth reading twice.
The questions are nearly identical. Who else needs to verify this record. What breaks when it is wrong? Would a conventional database with strong access control and signed audit logs serve this better. Frequently the answer is yes. A distributed ledger earns its place only when multiple organisations write to a shared record, no neutral party already holds it, and participants have genuine reason to dispute history later. Absent that, you are paying for consensus you do not need.
When tokenization genuinely is right, the discipline continues into the build: eligibility and transfer restrictions enforced inside the token standard under something like ERC-3643 rather than bolted on as a manual process, independent audit before value moves, and a documented decision on who holds signing keys, in what hardware, under what approval thresholds. Key handling causes more incidents than contract logic does.
What a Good “No” Looks Like
Declining is only useful with an alternative attached. A rule engine where logic is expressible. Better search where the real complaint is that people cannot find things. Conventional automation for structured repetitive work. Fixing the upstream process. Or a narrowly scoped assistive tool that drafts while a person decides.
And one test for whoever you engage. A partner worth hiring should be willing to talk you out of a project. If nobody in the conversation has articulated what would make this the wrong build, the evaluation is not finished.
If you cannot describe how a wrong output gets caught, you do not have a human in the loop. You have a human in the audit trail.
RWaltz is a technology partner building blockchain, AI, and enterprise software, including smart contracts, tokenization platforms, and custom integrations. Our approach is security-first and build-to-own: honest scoping, independent audits, and client-owned IP and keys, so what we deliver belongs to you.
📖 Read the full blog: https://www.rwaltz.com/blogs/when-not-to-use-ai-a-decision-guide-for-enterprise-teams
Connect with RWaltz:
LinkedIn: https://www.linkedin.com/company/rwaltzsoftware
X (Twitter): https://twitter.com/rwaltzsoftware
Facebook: https://www.facebook.com/RWaltz-Software-PvtLtd-255590135349493
Telegram: https://t.me/RWaltzCrypto
GitHub: https://github.com/rwaltzsoftware
Clutch: https://clutch.co/profile/rwaltz-software
Website: https://www.rwaltz.com
Top comments (0)