Big Tech’s AI Spending: Test Your Business Exposure

By Lazar Milicevic · Published November 1, 2026 · 9 min read

You run an automation that reads leads from Gmail, classifies them with an AI model, creates CRM records, and queues replies. It saves you two to four hours a day. Then a headline says the companies behind those models are burning cash and borrowing heavily, and you wonder what that means for your workflow. The honest answer is that the headline can't tell you. A test on your own system can.

What the reports actually say (and what they don't)

The facts are narrow: big tech companies are spending enormous sums on AI infrastructure, and financing that spending is putting pressure on cash flow and balance sheets. That is a statement about the companies' finances, not about your subscription price, your uptime, or your provider's survival.

According to TechCrunch's October 30 report, Alphabet, Amazon, Meta and Microsoft outlined plans over two weeks to spend more than $740 billion on capital expenditures in 2026. The same report notes:

• Alphabet posted negative free cash flow of $9.1 billion in Q3 2026, its second straight quarter in the red, with quarterly capex of $51.4 billion.
• Meta posted negative free cash flow of $2.1 billion in Q3.
• Per S&P Global Market Intelligence, Microsoft, Alphabet, Amazon, Meta and Oracle raised a combined $326 billion in debt in 2026, triple last year's amount.

CNBC reported that Amazon's trailing-twelve-month free cash flow was negative $42.4 billion and that it held its 2026 capex forecast at $220 billion, with shares down more than 6% in extended trading. Microsoft lowered its 2026 capex forecast to $170 billion from $175 billion.

Now the counterweight, from a primary source. Alphabet's own 8-K filing states $174 billion of operating cash flow in the 12 months to March 31, 2026. Companies generating that kind of cash are not obviously about to switch off a product line.

So what can a small business conclude? Very little about any individual provider. Per-company capex guidance has shifted several times this year, and different sources disagree on the figures, so I'm only citing numbers tied to a specific report. The useful question isn't "will my provider survive?" It's narrower: how exposed is my operation to a service whose future terms I don't control?

Model terms already change on a schedule, with or without a financial crisis

You don't need a hypothetical bust to have a dependency problem. Providers retire models routinely, and the notice windows are published.

• OpenAI's deprecation policy gives at least 6 months' notice for generally available API models and at least 3 months for specialized variants. Preview models can be retired with much shorter notice, such as 2 weeks.
• OpenAI notified developers on October 14, 2026 that GPT-4o, GPT-4o mini, GPT-4.1 and GPT-4.1 mini will be removed from the API on January 14, 2027, according to one tracker. That is roughly three months, shorter than the 6-month minimum for GA models. Read the policy as a baseline, not a guarantee.
• Anthropic commits to at least 60 days' notice before retiring publicly released models for customers with active deployments. It notified developers on September 30, 2026 that claude-sonnet-4-5-20250929 retires on November 30, 2026.
• Google's Gemini API page lists gemini-2.0-flash and gemini-2.0-flash-001 with a June 1, 2026 shutdown date.

Platform choice shifts the dates too. According to one deprecation tracker, Claude Sonnet 4 retired on Anthropic's API on June 15, 2026 but stayed on Amazon Bedrock until October 14, 2026.

The takeaway: the realistic near-term risk to your workflow is not a provider collapse. It's a model you depend on being retired on 60 to 180 days' notice while your workflow has no clean way to swap it. The test below covers both scenarios, because from your workflow's point of view, "provider down," "model retired," and "pricing changed" all end the same way: the model step stops returning what you expect.

Find where your business logic actually lives

Dependency isn't one thing. Take the lead-handling flow and separate it into layers:

1. Interpretation: the model reads an email and extracts the request and category.
2. Decision: something chooses the next action (create record, draft reply, escalate).
3. State: something remembers which leads were processed, which replies were approved, which CRM records exist.
4. Records: where the original input and outcomes are stored.

Replacing a model that only does layer 1 is an afternoon of prompt tuning. The trouble starts when one provider also holds layers 2 through 4: conversation history that serves as your only record, "the agent decides" as your only business logic, and no copy of the original request outside the provider's system.

For a founder, the real switching cost isn't the model bill. It's the time to reconstruct pending work when something changes. Which leads were processed? Which replies were approved? Which CRM records were created? A cheaper replacement model can't answer those questions if you never kept the records.

A quick self-assessment, answered per workflow:

If you have even two answers in the right-hand column, the drill below will show it quickly.

The provider-unavailable drill

Here's exactly how I run this on a small workflow. Pick something low-stakes, like lead classification. You need an hour and five saved example messages with sensitive details removed.

Setup:

• Use a test environment, not production.
• Collect five anonymized inbound messages. Make them different: one clean, one vague, one with an attachment reference, one duplicate of another, one in a hurry-up tone.
• Pause or disable the model step so it fails or times out, the way an outage or retired model would.

Run: submit all five messages, then answer four questions:

1. Do they enter a visible pending queue, or do they vanish?
2. Does anyone get notified?
3. Can a person finish the task manually from what's stored?
4. When the model step comes back, does the workflow resume without creating duplicate contacts or sending the same reply twice?

Score: write one outcome per message: received, waiting, completed, or failed. Five inputs must produce five accounted-for outcomes. If you get four, one message was lost somewhere between steps, and that's your finding.

These are numbers you collect yourself. No savings estimate, no vendor claim. A passing result looks like five items sitting in waiting with the original text attached, plus an alert. A failing result looks like silence.

Make the failure visible: a minimal state record

If messages disappeared in the drill, fix that before evaluating any other model. Swapping providers won't help a workflow that doesn't track its own state.

Here's a minimal pattern. Every inbound item gets a row before any model call, and every step updates it:

import sqlite3, hashlib, json, time

db = sqlite3.connect("leads.db")
db.execute("""
CREATE TABLE IF NOT EXISTS lead_jobs (
  id TEXT PRIMARY KEY,          -- hash of message id, used for idempotency
  raw_message TEXT NOT NULL,    -- original request, stored by YOU
  status TEXT NOT NULL,         -- received | waiting | completed | failed
  category TEXT,
  crm_record_id TEXT,           -- filled only after CRM write succeeds
  reply_state TEXT DEFAULT 'none',  -- none | queued | approved | sent
  last_error TEXT,
  updated_at REAL
)""")

def ingest(message_id: str, body: str):
    job_id = hashlib.sha256(message_id.encode()).hexdigest()[:16]
    db.execute(
        "INSERT OR IGNORE INTO lead_jobs (id, raw_message, status, updated_at) "
        "VALUES (?, ?, 'received', ?)", (job_id, body, time.time()))
    db.commit()
    return job_id

def classify(job_id: str, model_call):
    row = db.execute("SELECT raw_message, status FROM lead_jobs WHERE id=?",
                     (job_id,)).fetchone()
    if row[1] == "completed":
        return  # idempotent: re-runs never duplicate work
    try:
        category = model_call(row[0])
        db.execute("UPDATE lead_jobs SET category=?, status='completed', "
                   "updated_at=? WHERE id=?", (category, time.time(), job_id))
    except Exception as e:
        # model unavailable: park it visibly instead of dropping it
        db.execute("UPDATE lead_jobs SET status='waiting', last_error=?, "
                   "updated_at=? WHERE id=?", (str(e)[:200], time.time(), job_id))
    db.commit()

Three details matter more than the code itself:

• Store the original request first. If the model step fails, a human still has the lead.
• Key every job on a stable ID. That's what lets you resume without duplicate contacts or double-sent replies.
• Keep credentials out of these logs. Store statuses and record IDs, never API keys or tokens.

For outgoing email or accounting entries, make the approval and completion states explicit (queued, approved, sent). That also gives you evidence when a manual-entry mistake needs investigating later.

Reduce exposure without a panic migration

The spending story makes this a sensible moment to inspect your connections. It doesn't justify moving everything because of a headline; a rushed migration creates more disruption than staying put. A calmer sequence:

• Keep the model call behind one function. In the code above, model_call is a parameter. Swapping vendors then means changing one adapter, not rewriting the workflow.
• Pin model versions and calendar the retirement dates. Deprecation pages list shutdown dates and replacements. Put the ones that affect you in a calendar with a reminder 90 days out, since notice periods can be as short as 60 days to three months.
• Re-run the five-message drill whenever the model changes. Same inputs, compare outputs. If the new model categorizes one of five differently, you know before customers do.
• Own your records. Original messages, statuses, and CRM/invoice IDs live in a database or sheet you control. Conversation history at a provider is a convenience, not a system of record.
• Keep a manual path. A visible waiting queue that a person can work through by hand is the cheapest fallback there is.

My take: infrastructure spending is a weak buying criterion for business automation. A provider can spend heavily and still be the right choice. Investor skepticism can rise while a tool stays useful. Choose based on the job it completes, its measured cost, and your ability to recover when it stops completing that job.

Where bizflowai.io fits

I build AI automations for small teams at bizflowai.io. The design principle behind that work is exactly what the drill tests: the model is one replaceable step, and the state, original records, and approval history live in your own systems. That way a provider change or outage shows up as a visible queue a person can work, not as missing work discovered weeks later.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.