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

In early 2026, OpenAI signed a contract with the US Department of Defense to provide AI services for military applications. Around the same time, Anthropic declined a similar deal. Anthropic's stated reason: concerns about deploying AI in contexts where autonomous systems could be involved in lethal decision-making, and a commitment to their constitutional AI principles.

Two companies, similar technical capabilities, opposite strategic decisions. The gap between them is not a minor business development story. It will shape AI model development for years, and enterprise buyers who rely on these models are affected whether or not they were involved in the decision.

What Actually Happened

OpenAI is now a defense contractor. The Department of Defense — historically called the War Department until 1947 — is now an OpenAI customer alongside the enterprises and developers who built products on GPT-4 and its successors.

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.

Anthropic's refusal was explicit about the concern: 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's 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.

Anthropic's concern was precisely this: that training a model to perform well in lethal decision-making contexts would require changing the model in ways that conflicted with their safety principles. The inverse is also true: if you're an enterprise customer relying on those safety principles, model changes required by defense use cases affect your deployment.

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.

Anthropic's stated position is that they're not comfortable deploying AI in contexts where it could be involved in lethal autonomous decision-making. That's a clear position that enterprise buyers can evaluate. OpenAI's position, revealed by the contract they signed, is different. Enterprise buyers should evaluate that difference too — not politically, but as a vendor risk matter that directly affects the product they're paying for.

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 early bird 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.