Back to Blog Listing

When Your AI Vendor Loses $12B A Quarter, Vendor Risk Is A Live Data Feed

When Your AI Vendor Loses $12B A Quarter, Vendor Risk Is A Live Data Feed
Jakub Pietroszek Aug 29, 2026 4 min read

Written by: Jakub Pietroszek, Partnership Manager, Digital Colliers

OpenAI posted $6.7B in Q2 sales, up 18% quarter over quarter. In the same quarter, losses widened from $9.3B to $12.3B. If you're a bank running any production workload on OpenAI, that pair of numbers is not a headline. It's a data point that should already be flowing into a vendor-viability model, next to your credit exposures and your third-party operational risk registers.

Most banks I talk to don't have that model. They have a screenshot of a Gartner quadrant from the last board deck and a signed MSA. That's not vendor risk management. That's vendor risk theatre.

Financials as a live feed, not an annual review

The pattern that works is treating strategic AI vendors the same way you'd treat a counterparty bank. You want their financials on a refresh cadence that matches how fast the picture can change. For a private, cash-burning AI lab, that's quarterly at minimum. Any leaked S-1, any secondary tender, any credible press report on burn rate goes into the file within a week.

The data model itself is not complicated. For each critical AI vendor, you want:

  • Latest reported revenue and net loss, with QoQ delta
  • Cash on hand and last known raise, with implied runway at current burn
  • Concentration risk on their side (how much of their revenue comes from one hyperscaler or one customer)
  • Any covenant, governance, or control shifts from recent funding rounds
  • Regulatory exposure in your jurisdictions

That last row matters more than people realise. Under DORA, in force since 17 January 2025, financial entities in the EU have to manage ICT third-party risk with contractual and monitoring requirements that assume you actually know what's happening at the vendor. "We saw it on Bloomberg" is not a control.

Contractual exit rights that survive a bad quarter

When a vendor is burning nearly twice its revenue, the interesting clauses in your contract are the ones you never negotiated. Termination for material adverse change. Source code escrow. Data portability windows. Step-in rights if they file. Assignment restrictions if they get acquired by someone your compliance team can't stomach.

If your paper on your largest AI vendor doesn't cover those, that's a project, not a panic. But it's a project with a clock on it. The clock is the vendor's runway, and you don't get to see the clock face directly.

Worth remembering: EU AI Act high-risk obligations apply from 2 December 2027, and Article 50 transparency obligations kick in from 2 August 2026. Fines run up to €15M or 3% of global turnover. GDPR sits behind that at up to €20M or 4%. If your vendor collapses mid-migration and you can't produce the documentation those regimes require, the fine doesn't wait for you to find a replacement.

Fallback vendor readiness is a muscle, not a memo

A named fallback in a BCP document is not readiness. Readiness is a second vendor already integrated behind a routing layer, with a monthly synthetic traffic test and a documented cutover runbook that someone has actually executed in the last quarter.

The operators I see getting this right treat their model layer the way payments teams treat card networks. Primary, secondary, and a tertiary you can spin up in days. Prompts, evals, and guardrails are version-controlled and portable. The application code does not know or care which model is answering.

This costs money. It's also the reason around 95% of enterprise AI projects fail to reach production or ROI. Teams build tightly coupled prototypes, then discover they've built a single point of failure on top of a vendor whose income statement is a live risk.

Who owns the alert

The hardest question is not what to monitor. It's whose pager goes off when the number crosses a threshold. In most banks I've seen, vendor risk sits in procurement, model risk sits in a second-line function, and AI production sits in a business line. Nobody owns the composite.

Pick someone. Give them a named dashboard, a refresh SLA, and three defined thresholds: watch, act, exit. Wire the thresholds to concrete plays. "Vendor posts a quarter with losses greater than 1.5x revenue" is a watch trigger. "Runway drops below 12 months at current burn" is an act trigger. "Auditor issues going-concern language" is an exit trigger.

The cost of not having this is not that you fail an audit. It's that you find out your production AI vendor is in trouble the same week your regulator does, and by then your only lever is a press release.

Related Posts