OpenAI, the Pentagon, and What It Means for Enterprise AI Buyers Who Didn't Sign Up for It

In July 2025 the Pentagon's Chief Digital and Artificial Intelligence Office awarded contracts worth up to $200 million each to Anthropic, Google, OpenAI and xAI. Every frontier lab an enterprise might build on became a defense contractor in the same week.

The part worth studying came later, and it is a sharper lesson than "pick the vendor with better ethics." Your vendor's operating terms are negotiated by other people, they change after you have built on them, and the outcome can be removal.

What Actually Happened

The Department of Defense is now a customer of every major model provider, alongside the enterprises and developers who built products on those same models.

Anthropic's contract carried its own acceptable use policy: no mass domestic surveillance of Americans, and no fully autonomous weapons that select and engage targets without human intervention. In February 2026 the Pentagon moved to renegotiate that clause so Claude could be used "for all lawful purposes" without limitation. Anthropic refused. On 27 February federal agencies were directed to stop using its products, and on 5 March the Pentagon designated the company a Supply-Chain Risk to National Security, a label normally reserved for foreign adversaries and never before applied to an American firm. Anthropic sued, won a preliminary injunction on 26 March, then lost an emergency motion at the D.C. Circuit in April. As of August 2026 the cancellations are proceeding and Claude is being removed from Department systems on a 180-day clock.

Enterprises running on Claude did not sign up for any of that, were not party to the negotiation, and got a removal timetable set by someone else. None of it was about how good the model is.

This matters because AI models are not like traditional software products where a vendor's other clients are irrelevant to your deployment. The model IS the product, and the model is deeply shaped by who trains it, on what data, with what feedback, toward what objectives. A model that is simultaneously serving enterprise commercial use cases and Department of Defense use cases is being optimized for both. Those optimization objectives are not identical.

The clause Anthropic refused points at the underlying tension: at some level of AI autonomy in lethal decision-making contexts, the risk calculus changes. What constitutes "safe" AI output for a defense application differs from what is safe for an enterprise commercial application. These two requirements pull the model in different directions.

Three Concrete Effects on Enterprise Buyers

This isn't abstract. There are specific, concrete ways that a vendor's defense contract changes the product you're using.

1. Safety filtering will change

The safety tuning on large language models — what gets restricted, what gets permitted, what triggers a refusal — is calibrated to the client mix and use cases the model is intended to serve. A model that serves both consumers and defense contractors will have safety calibration that attempts to accommodate both.

What's restricted for consumer safety reasons may become permissible for defense-approved customers. What triggers a refusal in a commercial context may need to remain available in a classified context. These are not theoretical distinctions. They're engineering tradeoffs that safety teams at AI companies navigate with each model release.

When the client mix includes defense, the tradeoffs shift. Your enterprise deployment sits in that shifting landscape.

2. Training data and RLHF feedback loops change

Reinforcement learning from human feedback is how modern large language models are iteratively shaped toward desirable behavior. The humans providing feedback, and the contexts in which they're providing it, determine what the model learns to do.

When OpenAI's RLHF process includes human raters evaluating model outputs in defense-relevant contexts — operational planning, adversarial scenario analysis, capability assessments — the model learns from that feedback. Those refinements are not segregated from the model you're using. The model is the model.

This is the mechanism behind the clause Anthropic held out on. Writing usage limits into a contract is an attempt to keep certain contexts out of the training and feedback loop in the first place. The inverse matters to you directly: if you are an enterprise customer relying on a vendor's safety behaviour, model changes driven by defense use cases reach your deployment too, and you have no clause of your own.

3. Engineering and product priorities shift toward defense requirements

OpenAI now has a major government customer with specific capability requirements, procurement timelines, and compliance obligations (including ITAR, FedRAMP, and classification handling). Engineering resources follow customer requirements. Product roadmaps reflect revenue and strategic priority.

The capabilities that DoD needs — structured outputs for operational systems, multi-hop reasoning for intelligence analysis, reliable performance in adversarial conditions — may or may not overlap with what your enterprise application needs. When they don't overlap, you're lower on the priority list.

"We Have a BAA" Doesn't Cover This

Some enterprises believe their data processing agreement or business associate agreement with an AI vendor addresses these concerns. It doesn't.

A BAA governs what happens to your data. It doesn't address what happens to the model. The questions raised by a vendor's defense contract are not data governance questions — they're model behavior questions. No contract clause addresses whether the model's safety calibration shifted in ways that affect your deployment. No DPA tells you whether RLHF feedback from defense use cases changed how the model handles sensitive topics in your domain.

The contractual layer and the technical reality are operating in different dimensions here.

The Precedent Problem

This isn't the first time a major technology vendor's military contracts affected commercial products. Defense-driven investments in cloud infrastructure, networking, and semiconductor development have repeatedly reshaped commercial technology markets.

But for AI, the effect is more direct. When AWS took on defense contracts, commercial customers continued to use the same compute infrastructure — the compute didn't behave differently because a defense customer was also using it. When an AI vendor takes on defense contracts, the model itself is what changes. The model IS the product, and you're using the same model.

The gap between "vendor also serves defense" and "defense use cases shape the model you're using" is the gap between traditional software vendor risk and AI vendor risk. Enterprise buyers need to update their risk frameworks accordingly.

The Historical Context That Isn't Being Discussed

It's worth acknowledging what the Department of Defense actually does. It plans and conducts military operations, including lethal operations. The question of whether AI systems should be involved in those operations — and at what level of autonomy — is not a niche ethics debate. It's a policy question with direct implications for how AI models get trained and calibrated.

Each lab has taken a public position on where its models may be used, and those positions are worth reading, because they are the terms your deployment inherits. The lesson of the past year is that they are also negotiable by parties you will never meet. Evaluate them as a vendor risk matter that directly affects the product you are paying for, and assume they can move.

What Enterprise Buyers Should Do Now

Evaluate your AI infrastructure vendor risk explicitly. Understand what strategic decisions your vendor has made and what they imply for the model you're using. This is now a standard due diligence question, not an edge case.

Test model behavior on your domain-specific evaluation set after major vendor announcements. If OpenAI releases a new model version, run your eval set. Behavior changes. Document the baseline before the change so you can detect drift.

Assess whether API dependency is appropriate for your most critical workloads. If your product's core functionality depends on a vendor's model, you've accepted that vendor's strategic decisions as operational events for your business. For mission-critical workloads, that may not be acceptable.

Consider model ownership for your highest-stakes applications. A fine-tuned model trained on your data, with your objectives, running on your infrastructure, is not subject to vendor-level strategic pivots. The training priorities were set by your team. No defense contract changes what your model was trained to do.

Your fine-tuned model's behavior is determined by your training data and your objectives. No vendor's new client changes that.

That's the structural difference between API dependency and model ownership. When you own the model, your enterprise's requirements are the only requirements it was optimized for. See pricing → — Ertas fine-tuning SaaS lets you upload your dataset, fine-tune on cloud GPUs without code, and download a GGUF you run locally.

For enterprises in regulated industries who need more than just a fine-tuned model — who need an on-premise data preparation pipeline with full audit trail and air-gapped operation — book a discovery call with Ertas →.

Related Reading

The OpenAI/DoD deal is one instance of a broader pattern of vendor-level strategic changes that enterprise buyers need frameworks for. See the full vendor risk framework →

The underlying question the deal raises — about the appropriate role of AI in consequential, hard-to-reverse decisions — is addressed directly in our guide to high-stakes AI deployment.

If your enterprise uses AI for regulated functions and you're assessing your infrastructure posture, the vendor risk guide for enterprise AI covers the broader evaluation framework. And for the most precise analysis of what API dependency actually costs you in terms of control, see API dependency means no model control.