TL;DR: Most enterprise AI projects are deterministic problems wearing an LLM wrapper. The fix isn't a better scoring framework; it's a four-question pre-evaluation filter that runs before any AI tool gets scoped. When the filter passes, the tool choice follows naturally, and the cost model becomes defensible to your CFO.

Key Takeaways: - Wavestone, Microsoft BXT, EY, Credo AI, and Deloitte all score AI candidates, but none of them disqualify non-AI problems. - The AI-Fit Test asks four questions about hidden structure, enumerable failure, drift velocity, and bounded cost before any prompt is written. - The cloud invoice is a distraction; cost per correct answer, cost per drift incident, and amortized GPU-hour cost are the metrics that survive repatriation.

You approved an expensive AI project to automate a process that could have been a small if-statement. You're not alone, and the invoice your CFO just saw is only the visible half. Underneath sits a second invoice: engineering labor, GPU amortization, and monitoring overhead. There's also the quiet cost of a system that's been solving the wrong problem all along.

The pattern is consistent. The most common "AI" project is a deterministic problem with a transformer glued on top. Once the model is in production, the bill shows up twice.

There's the cloud invoice for inference. Then there's the hidden cost of maintaining a non-deterministic system for a job rules could do cheaper.

When organizations try to recover by repatriating workloads in-house, the cloud line item vanishes but the cost does not. As Splunk's analysis on AI repatriation puts it: "AI workloads in house removes cloud invoices, so teams need new ways to measure and track the true cost of running AI across GPUs, memory, and engineering time."

The real bill is engineering labor, GPU amortization, and monitoring. The cloud meter was the easiest part to read, not the biggest part to pay.

The dominant evaluation frameworks don't catch this. Wavestone's scoring rubric, Microsoft's BXT, EY's AI Bill of Materials, Credo AI's lifecycle model, and Deloitte's industry mapping all measure AI readiness. They assume AI is the answer and rank suitability from there. None of them ask whether AI belongs in the solution at all, because that question was never part of their design.

Wavestone scores use cases on a structured matrix for value and complexity. Microsoft BXT (business, experience, technology) weights each candidate across three dimensions and produces a priority ranking. EY's AI Bill of Materials documents technical components and risk surfaces.

Credo AI maps the lifecycle from procurement through monitoring. Deloitte maps AI by industry, function, and type. Every one of them shares a starting assumption: that the use case in front of them warrants AI at all.

That assumption is the flaw. Once a use case enters a structured evaluation pipeline, organizational momentum takes over.

The scoring matrix is open. The vendor is in the room. The board has already heard the pitch. Saying "this doesn't need AI" carries a prestige cost that no engineer wants to pay.

The sunk-cost trap isn't just financial. It's political. Vendor demos, competitive FOMO, and AI mandates from above all push the use case toward ship. Choosing between a rule-based system and an AI decision is supposed to happen before the scoring matrix opens.

The fix is not a better scoring matrix. It's a pre-evaluation filter that runs before any framework gets opened. Think of it as a gate that the five dominant approaches skip entirely. The project that should never have started is the one that costs the most.

Gate 1: Hidden structure. Does the input space have patterns your rules don't capture? If the answer is no, this is a rule problem. Write the rules. Move on.

Gate 2: Enumerable failure. Will the answer be wrong in ways humans can predict and list? If yes, write the rules for those cases. AI is only justified when the wrong-answer surface is larger than what humans can enumerate.

Gate 3: Drift velocity. Does your data drift faster than your change-management process? Rules are cheaper to maintain when the world moves slowly. When inputs shift quarterly and your deploy process is weekly, AI pays for itself. When inputs shift yearly and deploys take a sprint, rules win.

Gate 4: Bounded cost. Is the cost of a wrong answer measurable and capped? If a wrong answer can cascade into regulatory exposure, customer harm, or unbounded liability, you need human-in-the-loop, not full automation. AI is the wrong tool when the blast radius is unknown.

Run all four gates before any other evaluation. Audit trails, explainability, and model risk management all demand this filtering step before any LLM gets scoped. Teams that skip it spend the next year trying to measure AI ROI on a system that should never have been built.

Once you've passed those four gates, the next question is which kind of AI, and the answer changes your invoice structure dramatically.

Deterministic → Rules. Filename routing, form validation, eligibility checks, threshold-based approvals. All of these belong in a rules engine or a small Python script. Here's a real example of what an LLM was scoped to handle:

Twelve lines. Zero GPU. Fully auditable. This is the case for knowing when not to use AI before the GPU invoice arrives.

Bounded variability → Classical ML. Tabular data with a known feature space: churn prediction, fraud scoring, lead prioritization. XGBoost or logistic regression before any neural network. Per-inference cost approaches zero, and the model fits in memory on commodity hardware.

Unstructured input → Small models first. Document understanding, entity extraction, layout analysis. LayoutLMv3, DistilBERT, or a fine-tuned 7B model before reaching for GPT-4-class APIs. You get most of the accuracy at a fraction of the inference cost.

Open-ended reasoning → LLMs with guardrails. Only when the first three fail, and only with structured output schemas, retrieval grounding, and eval-set regression checks. This is where the monthly invoice actually lives. The cost gradient is steep: rules approach zero per inference, classical ML is GPU-cheap, and LLMs are where the budget dies.

But sometimes you've passed every gate and the answer is genuinely an LLM. That's when the real cost question shows up, and it has nothing to do with the cloud line item.

The cloud line item hides the real expense. When AI workloads are repatriated in-house, the hyperscaler meter disappears. Engineering labor, GPU amortization, and eval-set regression costs remain, and per Splunk's repatriation analysis, teams need new ways to measure the true cost of running AI across GPUs, memory, and engineering time, because the bill is no longer being itemized by a hyperscaler.

What to actually track. Cost per 1k tokens processed. Cost per correct answer on a held-out eval set. Cost per drift incident, including the human hours spent diagnosing it. Amortized GPU-hour cost across all tenants running on the same hardware.

These four metrics are what your CFO can defend in a board meeting. They're also what sustainable AI ROI measurement looks like in practice.

The repatriation math. When self-hosted on H100 or A100 hardware, the unit economics shift to cost-per-token-plus-labor. That's the same itemized model used by GPU marketplaces like Vast.ai, where every transaction is a line item you must instrument yourself. The cloud hyperscalers hid this labor cost behind a usage meter. Self-hosting exposes it. The trade is favorable only when your measurement discipline matches your cost discipline. Stopping the bleed on LLM inference starts with knowing what each correct answer actually costs, not what the monthly invoice rounds to.

Turn the instrumented metrics into a per-decision cost, and the board sees the same number the engineering team sees. That's the moment the AI budget becomes defensible.

When the evaluation, the tool choice, and the cost model all line up, the outcome is a system that keeps running, not a demo that gets sunsetted.

Teams that run the pre-evaluation filter first deploy faster than in-house teams that skip the fitness check. The speed comes from choosing the right tool the first time, not from cutting corners.

Systems that passed the AI-Fit Test are still running in production because they were right-sized to the problem rather than over-scoped to the latest model. They don't break when the vendor changes its API, because the dependency surface was never artificially large. Evaluating AI use cases properly means asking whether AI is the answer, then asking what kind.

The board question is simple: "Why is this AI and not a rule?" When you can answer it, the project moves forward. When you can't, the project becomes the expensive if-statement someone else has to explain at the next audit.

Q: How do you evaluate an AI use case before committing budget?

A: Run the four-question AI-fit test first. Check whether rules already capture the structure. Check whether wrong answers are predictable and enumerable. Check whether data drifts faster than your change process. Check whether the cost of a wrong answer is bounded. Only use cases that pass all four gates warrant full evaluation against heavier frameworks like Microsoft's BXT or Wavestone's scoring rubric.

Q: When should you not use AI?

A: When the input space is fully known. When wrong answers are enumerable. When data does not drift. When a wrong answer is catastrophic and unbounded. In these cases, a deterministic rule or a constrained classical ML model will outperform an LLM on cost, latency, auditability, and explainability.

Q: How do you measure AI ROI when the cloud invoice disappears after repatriation?

A: Instrument cost per correct answer, cost per 1k tokens processed, and cost per drift incident. According to the Splunk analysis on AI repatriation, the cloud line item vanishes when workloads move in-house. But engineering labor, GPU amortization, and eval-set regression costs remain. Those are the numbers that matter for ROI.

Q: What is the difference between a rule-based system and an AI system for enterprise use cases?

A: Rule-based systems execute deterministic logic over known inputs and are cheap, auditable, and stable. AI systems generalize across unstructured or drifting inputs but introduce non-determinism, inference cost, and a new monitoring surface. The right choice depends on whether your problem has hidden structure that rules cannot capture.

Q: How long does an enterprise AI deployment actually take when the use case is properly evaluated?

A: For teams that run the pre-evaluation filter first, deployments land much faster. The speed comes from choosing the right tool the first time, not from cutting corners.