The Agreement You Probably Haven't Read
Every AI provider has an acceptable use policy. You agreed to it when you signed the contract, clicked "I agree," or set up the API key. Most of those documents are 15–40 pages about not using the service for spam, illegal content, and a dozen other things that seem obviously not your problem.
Until this week, that was largely where the story ended.
On February 27, 2026, the US Secretary of War designated Anthropic a "supply-chain risk." The Trump administration formally banned Anthropic from government use. The stated reason: Anthropic refused to remove safety constraints for two use cases that were never in the original contract — autonomous lethal targeting decisions and offensive cyber operations.
Within hours, OpenAI announced it had secured a deal to deploy on the same Department of War classified network. Sam Altman posted on X. The press release was clearly pre-staged.
By the end of the day, the enterprise AI vendor landscape had a documented case study: two vendors, same customer request, very different answers, very different outcomes.
I'm not here to argue the politics. What I want to walk through is what this means for engineering teams that are evaluating, or already depending on, AI providers — which at this point is most of us.
What Changed — and What Was Always True
Nothing about the technology changed. Claude is still Claude. GPT-4 is still GPT-4.
What changed is visible: we now have a documented case where a major enterprise AI vendor's safety constraints directly conflicted with a customer request, became a public confrontation, and ended with the vendor losing the contract.
But here's what was always true: every AI provider has constraints built into their service that can, in the right circumstances, conflict with your use case. This isn't new. It just wasn't visible before.
Think about it from a platform engineering perspective. When you build on any external service — a database, an API, a cloud platform — you do dependency risk assessment. What happens if they change their pricing? What happens if they get acquired? What happens if they have a regional outage?
For AI providers, there's now a fourth question: what happens when your use case conflicts with their policy?
That question wasn't in most vendor evaluation frameworks a year ago. It needs to be now.
Why This Matters for Engineering Teams, Not Just Legal
The reflex response is to hand this to legal or procurement. That's a mistake.
The people who understand whether a use case conflicts with an acceptable use policy are the engineers building the system — not the lawyers reviewing the contract.
Acceptable use policies are written in general terms. "You may not use our API for activities that may cause physical harm." That sounds clear. But your platform is doing automated security response, which can block user access, which in theory could restrict someone's access. Does that conflict? Your lawyer will say "consult us before expanding that feature." Your engineer who built the system will know immediately whether it does.
The same applies to AI-specific constraints:
Human oversight requirements. Many providers require a human in the loop for decisions above a certain risk threshold. Risk thresholds aren't defined in the policy — they're left to interpretation. As you automate more with AI agents, you need to know where your provider draws that line, because they get to decide what counts as "high risk."
Data retention and training. Some providers train on your data by default. Some don't. Some have enterprise exceptions. The default setting may not be what you think it is, and it can change with a policy update.
Jurisdictional coverage. Your provider might be compliant in the US but not EU AI Act territory. If your customers span jurisdictions, this is your engineering problem, not just a legal checkbox.
Use case scope creep. You start with a customer support chatbot. You expand to automated escalation decisions. You expand to automated contract review. Each step seemed incremental. At some point you crossed a line in the policy — and you won't know where that line was until something breaks.
The Vendor Dependency Model Has Changed
This is the part that engineers consistently underestimate.
A cloud provider like AWS or Azure is largely a utility. They care about uptime, security, and compliance. They don't have strong opinions about what you build on top of them, as long as it's legal.
Frontier AI providers are not that. They have specific, documented, auditable positions on what their technology should and shouldn't be used for. Those positions are part of their brand, their investor relationships, and in some cases their regulatory strategy.
The difference in dependency model:
====================================
Cloud utility (AWS / Azure / GCP):
Your workload → Infrastructure API → Compute / Storage / Network
Risk surface: availability, pricing, regional outage
NOT dependent on: vendor's strategic priorities or values
AI frontier provider (OpenAI / Anthropic / Google / Mistral):
Your product → Model API → Generated output
Risk surface: availability, pricing, output quality changes
ALSO dependent on: vendor's policy decisions, safety stance,
geopolitical relationships, regulatory posture
That second column is new. It wasn't part of the infrastructure risk model two years ago. Now it is. And this week proved it can surface suddenly, at enterprise scale, with no warning.
The other thing the week demonstrated: vendor speed is a risk signal. OpenAI had a classified network deal staged and ready. They moved within hours of Anthropic's expulsion. That isn't improvised logistics. It means OpenAI had already decided, before any of this became public, that they were willing to take on those use cases. The contracting was ready. The infrastructure was probably ready. The decision had already been made.
If you're an enterprise buyer, that speed tells you something about the vendor's strategic posture. Not that they're wrong — just that they've made a choice, and that choice has implications for what you can expect from them going forward.
How to Actually Evaluate This
Here's a practical framework I'd apply to any AI provider evaluation or existing vendor review.
Step 1: Get the actual policy document. Not the FAQ. Not the "Trust and Safety" landing page. The full acceptable use policy, the terms of service, and any supplemental enterprise addendums. Save it with a date. Set a calendar reminder to check for updates quarterly — most providers change their policies at least once a year, often with minimal notice.
Step 2: Map your current use cases. For each AI-powered feature in your product, write one sentence describing what it does and what decisions it influences. Then read the policy clauses and flag any that could apply.
Step 3: Map your planned use cases. Your roadmap for the next 6–12 months. Which features involve AI? Where are those features heading? Flag anything that could touch restricted categories before you build it, not after.
Step 4: Identify your single points of dependency. Which parts of your product would break if your AI provider was suddenly unavailable — by outage, policy change, or contract termination? These are your highest-risk dependencies.
Step 5: Build in substitutability. If your AI integration is built against a provider-agnostic interface — same abstraction layer, swappable backend — you can migrate if you need to. If it's deeply coupled to one provider's specific API, migration will be painful and slow. This is good engineering regardless of vendor risk. Do it now.
Step 6: Check the change notification clauses. Most enterprise contracts include a clause about notice periods before terms change. Find that clause. Thirty days is common. That's how long you have to react if your use case suddenly falls outside their policy. Plan accordingly.
AI Vendor Risk Checklist
========================
Policy Review
- [ ] Full acceptable use policy obtained and dated
- [ ] Terms of service and enterprise addendums reviewed
- [ ] All restrictive clauses documented with plain-English interpretation
- [ ] All clauses mapped against current use cases
- [ ] All clauses mapped against 12-month roadmap
- [ ] Flagged clauses assigned engineering owner for monitoring
- [ ] Review cadence set (recommended: quarterly)
- [ ] Change notification period confirmed in contract
Use Case Assessment
- [ ] All current AI use cases catalogued (one sentence each)
- [ ] Risk category for each use case (low / medium / high)
- [ ] Human-in-the-loop requirements mapped to high-risk use cases
- [ ] Jurisdiction coverage confirmed for user geography
- [ ] Data handling: confirmed whether inputs are used for training
Dependency Assessment
- [ ] Critical path AI dependencies identified
- [ ] Fallback behavior defined for each critical dependency
- [ ] Provider-agnostic interface design in place or planned
- [ ] Data portability confirmed (can you export fine-tunes or embeddings?)
Vendor Posture
- [ ] Vendor's public stance on safety constraints reviewed
- [ ] Alternative providers identified for highest-risk use cases
- [ ] Contract includes policy change notice period (note: how many days?)
- [ ] Escalation path confirmed if use case is flagged or restricted
You won't need every item on this list for a simple chatbot integration. You'll need all of it if you're building AI agents with elevated system access, automated decision-making in regulated contexts, or infrastructure automation that runs without human review.
What I'd Do From Here
If you're mid-evaluation of an AI provider: add vendor policy review to your evaluation criteria alongside performance benchmarks and pricing. It should carry real weight.
If you're already deployed on an AI provider: run through the checklist above. The goal isn't to trigger a migration — it's to understand your exposure so you can make informed decisions if the landscape shifts.
If you're building an internal platform that routes to AI providers: abstract the interface now. Provider-agnostic design costs almost nothing to implement correctly from the start and can save weeks of work if you ever need to switch.
If you're in a regulated industry or building for regulated customers: this is already mandatory due diligence. Treat it as such.
The week of February 28, 2026 was a clear case study in how AI vendor policy decisions propagate into customer infrastructure. It won't be the last one.
The teams that did this review before it mattered are in a much better position than the teams that have to do it under pressure. That's always true of due diligence — and it's still true here.
Top comments (0)