Your software stack breaks in predictable ways. A dependency ships a bad version, a config drifts, an API endpoint goes dark. You've built runbooks for these. You know the shape of the failure.
AI systems break differently. And most teams — especially lean ones — haven't mapped those shapes yet.
The Old Supply Chain Problem Didn't Go Away
Every AI product is still a software product. It runs on servers, calls APIs, pulls from package managers, and depends on third-party services. All the classic supply chain risks apply: compromised dependencies, silent version changes, deprecated endpoints, credential leaks.
If you're piping user data through an LLM API, you already have a data-handling dependency. If that provider changes their retention policy, their model version, or their uptime SLA — your product changes with it, whether you consented or not.
This is the baseline. The AI layer doesn't replace these risks. It stacks on top of them.
What's Actually New: The Model Is a Black-Box Dependency
Traditional dependencies are deterministic. Call the same function with the same inputs, get the same output. You can pin a version, write a test, and trust the contract.
Models aren't like that.
When a provider silently updates a model — same name, same endpoint, different weights — your outputs change. Your carefully tuned prompts may degrade. Your downstream logic that parses structured output may break. And you won't get a changelog. You'll get confused users and a support ticket.
This is a new failure mode: non-deterministic dependency drift. It's invisible until it isn't.
For a solo operator running a content workflow or a client-facing automation, this isn't theoretical. If your summarisation prompt suddenly starts producing longer outputs, your email formatter breaks. If your classification step shifts confidence thresholds, your routing logic misfires. You didn't change anything. The supply chain did.
Prompt Injection Is a Supply Chain Attack
Here's one that doesn't get enough attention outside security circles: prompt injection.
If your AI system processes external content — web pages, user-submitted text, scraped data — that content can contain instructions designed to hijack your model's behaviour. It's the AI equivalent of a SQL injection, and it travels through your data pipeline like any other malicious payload would travel through a traditional supply chain.
For SMBs building automations that ingest third-party content, this is a real attack surface. A competitor could embed instructions in a public document your system ingests. A bad actor could craft a support ticket designed to manipulate your AI triage tool.
The failure mode isn't in your code. It's in the data you trusted.
Evaluation Rot: When Your Benchmarks Go Stale
Software teams test before they ship. AI teams often test once — at launch — and then assume the system stays calibrated.
It doesn't.
Model updates, data drift, and shifting user behaviour all erode the accuracy of a system that once passed your eval suite. This is evaluation rot: your benchmarks become a historical artifact rather than a live signal.
For a solo operator, this is particularly dangerous because there's no dedicated QA function watching for degradation. You're relying on user complaints to surface what a monitoring layer should catch. By the time a client notices the output quality has slipped, the damage is already done.
The Concentration Risk Nobody Talks About
Traditional supply chain advice includes diversification: don't depend on a single vendor for a critical component.
Most AI stacks violate this immediately. One foundation model provider. One vector database. One embedding service. If any of those goes down, changes pricing, or gets acquired — your entire workflow is hostage to that decision.
For SMBs, the economics push toward consolidation. You use one provider because it's cheaper and simpler. That's rational. But you should know what you're trading: resilience for efficiency. And you should have at least a rough contingency for 'what if this provider doubles pricing or deprecates this model in 90 days?' — because both have happened, repeatedly, in the last two years.
What Lean Teams Can Actually Do
You don't need an enterprise MLOps team to manage these risks. You need a few deliberate habits:
Pin your model versions explicitly. Most providers let you specify a model version rather than calling the 'latest' alias. Use it. Accept the upgrade on your schedule, not theirs.
Log inputs and outputs. Not forever, and not everything — but a rolling sample. When behaviour shifts, you need evidence to diagnose whether it's a model change, a prompt regression, or a data issue.
Treat external data as untrusted. If your automation ingests content from outside your control, sanitise it before it touches your prompt. At minimum, be aware of what you're piping in.
Run a monthly output audit. Pick 20 representative inputs, run them through your system, compare to last month's outputs. This is your lightweight eval pipeline. It takes an hour and catches drift before users do.
Know your single points of failure. Map your AI dependencies the same way you'd map any critical vendor. What breaks if this API goes dark for 24 hours? What's the fallback?
The Takeaway
The AI supply chain inherits every fragility of traditional software — and adds model drift, prompt injection, and evaluation rot on top. If you're building on AI tools without a basic dependency map and a monitoring habit, you're not running a system. You're running a hope.
Map the failure modes before they find you.