AI hype isn't the opposite of real AI capability. The two coexist comfortably, which is what makes the argument so tiring — one side points at a working system, the other points at a valuation, and neither claim touches the other.
The useful reframe is to stop arguing about the market and start classifying evidence. A claim about an AI system sits at one of four levels, and each proves strictly less than people treat it as proving.
| Level | What it proves | What it doesn't |
|---|---|---|
| Demo | The product can do a selected task in a controlled setting | Reliability on your data or workflow |
| Controlled evaluation | Performance against a defined test set | Stable production performance, or adoption |
| Production KPI | A live workflow beat a baseline | Repeatability across teams, periods, volumes |
| Repeatable economics | The outcome survives full operating cost and controls | That any other use case will work |
Most procurement decisions get made on level one and defended as though they were level four.
Provider financials are a worked example of mixing measures
Anthropic's S-1, filed 26 October 2026, is the most detailed provider evidence currently available, and it's useful here precisely because the numbers point in different directions depending on which one you pick up.
Revenue: $41M in 2023, $386M in 2024, $4,585M in 2025, and $16,286M for the six months to 30 June 2026 — roughly fourteen times the $1,163M in the same period a year earlier. Operating loss for that half: $693M, down from $2,135M. Net loss for the same six months: $80,748M.
Those are three different statements about the same company. Revenue growth is evidence of demand. A narrowing operating loss is evidence about operating economics. The net loss is dominated by a non-cash charge tied to the company's rising valuation, which is an accounting consequence rather than money leaving the building. Quote any one of them alone and you can argue either "the boom is real" or "the bubble is bursting," which is a sign the figure isn't doing the work you want it to.
None of it tells you whether your claims workflow, underwriting review, or support queue will improve. That needs a baseline, a controlled evaluation, production monitoring, and a full cost model. Provider health and your deployment's value are separate questions that happen to share a news cycle.
A correction wouldn't hit every layer the same way
Worth separating, because "AI crash" gets used as though it were one event:
- Model providers — consolidation, price changes, reduced subsidies, tighter capacity. Your exposure is API changes, model retirement, concentration. Safeguard: abstract model access, test substitutes, negotiate change notice.
- Infrastructure — delayed projects, higher power and capacity costs. Your exposure is pricing, latency, residency, lead time. Safeguard: model cost at several usage levels, keep regional options.
- Application vendors — funding pressure, acquisition, product withdrawal. Your exposure is workflow disruption and lost integrations. Safeguard: data export rights, dependency disclosure, transition support in the contract.
- Your own deployments — budget scrutiny, paused expansion, tighter ROI bars. Your exposure is stranded integration work. Safeguard: bounded scope, KPI gates, rollback plans. A valuation reset could remove vendors while useful internal systems keep running. Infrastructure delays could raise prices without invalidating a workflow's value. These aren't the same risk and they don't need the same response.
The cost line nobody quotes
A license or API quote omits integration, storage, monitoring, evaluation, retraining, human review, incident response, and process change. McKinsey's May–June 2026 survey of 1,719 participants found 44% reporting enterprise-wide scaling and 37% reporting positive EBIT contribution — and one in five limiting AI use because of operating costs. Self-reported, so treat it as directional, but the pattern is that scaling, value, and cost pressure all show up at once.
Model cost at two, five, and ten times expected volume before signing, not after.
Eight gates before you scale
- Use-case value — baseline time, cost, error rate, target KPI, accountable owner. Red flag: a generic productivity claim with no baseline.
- Production proof — a comparable deployment, the evaluation method, the failure distribution, monitoring results. Red flag: demo-only evidence, or an aggregate accuracy number with no explanation.
- Vendor health — disclosures where available, concentration, support model, roadmap. Red flag: dependence on future funding, or opaque third parties.
- Data fit — rights, quality, lineage, residency, retention, training use. Red flag: unclear reuse, or no way to delete and export.
- Integration — APIs, identity, legacy dependencies, observability, rollback. Red flag: manual work hidden behind the demo.
- Governance — risk classification, oversight, incident response, audit evidence. Red flag: "compliant" with no jurisdiction or control mapping.
- Total operating cost — license, inference, storage, monitoring, retraining, review, integration, change. Red flag: an introductory price with no usage curve.
- Exit path — portability, transition support, termination rights, alternatives. Red flag: lock-in with no export or substitution plan. On governance specifically, there isn't one universal 2026 deadline. The EU AI Act phases by rule and system category — some enforcement powers applied from August 2026, Annex III high-risk rules are scheduled for December 2027, and high-risk AI embedded in regulated products for August 2028. NIST's AI RMF remains voluntary US guidance and structures risk work without being a certification. Neither substitutes for advice on your specific system and jurisdiction.
Questions that reveal what a vendor has actually measured
The aim isn't collecting confident answers. It's finding out what's been measured, what's unknown, and which risks you'd be accepting.
- Which exact workflow changes, what's its baseline, and which production KPI should move?
- What production evidence exists for organizations with comparable data, volume, and regulatory constraints?
- How was quality measured, and what does the failure distribution show beyond the average?
- Which models, clouds, subprocessors, and data stores are operational dependencies?
- How do price and performance change at 2x, 5x, and 10x expected volume?
- What data is retained, reused for training, moved across regions, exported, deleted?
- What happens if the model, provider, price, or product changes materially or disappears? Reference customers may be confidential, and that's fine — audited case evidence, technical artefacts, or a reference under NDA all count. A vendor who can't share any method, failure analysis, or comparable production evidence is asking you to price uncertainty as confidence.
Build for change rather than for a forecast
Make deployments measurable, modular, documented, and reversible before a correction, not in response to one. Separate model access from business rules where practical. Retain evaluation sets. Version prompts and models. Log enough to investigate a failure.
Optionality costs something — supporting several providers slows delivery and adds testing, and full portability is unrealistic when models behave differently. The goal isn't theoretical interchangeability. It's a tested route to preserve critical records and operations if a dependency changes.
Waiting for complete certainty delays workflows that would have worked. Committing your data, architecture, and operations to an immature vendor raises switching cost and regulatory risk. Bounded commitment sits between those: prove one workflow, set a cost ceiling, document the controls, keep an exit.
Full write-up — the evidence table, correction-by-layer analysis, and the full gate criteria: teamvoy.com/blog/ai-hype
Written by Zhanna Yuskevych, Teamvoy. More engineering writing at teamvoy.com/blog.
