AI Vendors Are Becoming Infrastructure. Treat Their Failure Like a Public Risk

The strangest thing about the AI arms race is not the science-fiction image of machines making war. It is the paperwork. On May 1, 2026, the Pentagon said it had reached deals with Google, Microsoft, Amazon Web Services, Nvidia, OpenAI, Reflection and SpaceX to use their AI in classified computer networks, with the Defense Department saying the systems would help “augment warfighter decision-making in complex operational environments,” according to the Associated Press¹. Nine months earlier, the Army announced a Palantir enterprise agreement that consolidated 75 contracts, including 15 prime contracts and 60 related contracts, into one framework capped at $10 billion over as long as 10 years for data integration, analytics and AI tools, according to the U.S. Army².

That is the real story. AI is leaving the innovation lab and becoming infrastructure. Not infrastructure in the concrete-and-steel sense, but in the operational sense: the layer through which institutions see, decide, coordinate and respond. The Pentagon’s AI Rapid Capabilities Cell says its warfighting focus areas include command and control, decision support, operational planning, logistics, weapons development and testing, uncrewed and autonomous systems, intelligence, information operations and cyber operations, according to the Chief Digital and Artificial Intelligence Office³. If a private platform helps organize that much of the battlefield picture, it is no longer just a vendor tool. It is part of the nervous system.

I think that changes the regulatory question. The issue is not whether Palantir, OpenAI, Google or AWS should be treated like a water company, with price controls and sleepy hearings about allowed returns. That would be a category mistake. The issue is whether critical AI platforms should carry public obligations once their failure can spill beyond the buyer and harm soldiers, civilians, depositors, markets or national security. My answer is yes.

The best argument against this view is speed. Defense software cannot be governed like a bridge project. The Defense Department created its AI Rapid Capabilities Cell to accelerate adoption of advanced AI across the department, and its own officials have stressed the need to incorporate commercial innovation into critical missions, according to DOD News⁴. FedRAMP, the federal cloud authorization program, has learned the same lesson: its current continuous-monitoring approach says oversight should focus mainly on a cloud provider’s change process rather than preapproving every change, and should generally let authorized providers deploy fixes at their own pace, according to FedRAMP’s M-24-15 documentation⁵. The Cybersecurity Maturity Model Certification program, or CMMC, similarly uses cybersecurity levels, assessments and annual affirmations as contract conditions for defense contractors handling sensitive information, according to the DoD CIO⁶.

That argument is right as far as it goes. A regime that requires a government preclearance meeting before every model update or security patch would make the country less safe. But it does not follow that contracts and certifications are enough. They solve one problem, which is whether a buyer can demand controls from a supplier. They do not solve the harder problem, which is whether the public can govern a concentrated platform whose failure may hit many missions or firms at once.

This is the distinction that matters. A bad software module in one office is a procurement problem. A shared AI platform embedded across targeting workflows, logistics planning, cyber defense and intelligence analysis is a public-risk problem. The danger is not only that the model gives a wrong answer. It is that thousands of users, trained on the same interface and plugged into the same data pipelines, may inherit the same blind spot. A cyber compromise, silent model degradation, poisoned data feed or flawed retrieval system can then propagate like bad weather through an airport network. Each pilot still flies the plane, but the system they rely on has become common infrastructure.

Finance is already living with the same pattern. Treasury’s December 2024 AI report said AI use is increasing across financial services and highlighted risks involving data privacy, bias and third-party providers, according to the U.S. Treasury Department⁷. The Federal Reserve, FDIC and OCC issued third-party risk guidance in 2023 that tells banks to manage vendor risk across planning, due diligence, contract negotiation, monitoring and termination, and says using third parties does not remove a bank’s duty to operate safely and lawfully, according to the FDIC⁸. That is necessary. It is not sufficient.

The Government Accountability Office made the gap plain in 2025 when it found that the National Credit Union Administration lacked authority to examine technology service providers even as credit unions increasingly relied on them for AI-driven services, and said such authority would help monitor and reduce third-party risks tied to AI-service providers, according to the GAO⁹. In other words, the regulator may supervise the institution that buys the AI, but lack direct reach into the company that supplies the AI. That is like inspecting every hospital while being forbidden to inspect a single dominant medical-device supplier whose malfunction could affect them all.

Europe and the United Kingdom are closer to the right model. The EU’s Digital Operational Resilience Act, or DORA, creates an EU-wide oversight framework for critical information and communications technology third-party providers serving financial entities, including designation, risk assessment, oversight examinations, recommendations and follow-up, according to the European Banking Authority¹⁰. The United Kingdom’s critical-third-party regime lets regulators monitor and manage systemic risks posed by certain third parties to the financial sector, while making clear that financial firms still remain responsible for their own resilience, according to the Financial Conduct Authority¹¹.

That is not socialist nostalgia. It is modern operational-resilience law. The provider is not turned into a public agency. The government does not run the codebase. The obligation attaches to a function: if a private system becomes critical to the stability of a regulated sector, the supervisor gets direct visibility into the risks that could bring the sector down.

The United States already accepts this logic elsewhere. In the bulk power system, the Federal Energy Regulatory Commission reviews, approves and enforces mandatory reliability standards developed by the North American Electric Reliability Corporation, and penalties for noncompliance can exceed $1 million per day per violation in severe cases, according to FERC¹². Cybersecurity law is moving in the same direction: the Cyber Incident Reporting for Critical Infrastructure Act requires CISA to develop rules for covered critical-infrastructure entities to report covered cyber incidents and ransom payments, according to CISA¹³. The principle is simple: when failure externalities are large, private ownership does not mean private governance.

So I would not call for “utility regulation” if that phrase means rate cases, monopoly protection or political micromanagement of software design. I would call for a critical AI platform regime. It should have five triggers: (1) use in safety-critical military or intelligence workflows, (2) use by multiple systemically important financial firms or market utilities, (3) dependence by critical cyber-defense functions, (4) high switching costs created by classified integrations or proprietary data schemas, and (5) evidence that an outage, compromise or model failure could cause correlated harm.

Once those triggers are met, the obligations should be direct. Regulators should have secure audit rights into model governance, data pipelines, access controls, incident logs, subcontractors and change-management practices. Providers should run supervised resilience tests and transition exercises, including simulations of model rollback, cloud outage, data poisoning and vendor exit. Contracts should require interoperability, data portability and escrow arrangements for mission-critical configurations. Major incidents should be reported quickly to the relevant public authority, not only to the immediate customer. Liability should attach when vendors misrepresent capabilities, hide material failures or neglect agreed controls.

The deployer still owns the decision. A general, intelligence officer, bank executive or compliance chief cannot blame the machine for a choice the institution made. But the vendor must own the integrity of the operational layer it sells. That is the missing half of accountability.

The next year will show whether Washington understands the difference between buying AI and depending on it. My test is concrete: if the Pentagon and financial regulators create designation rules for critical AI providers, require sector-level stress tests and secure direct audit rights by the end of 2027, the United States will still be early enough to govern the stack. If they wait until the first correlated failure, the architecture will already have hardened around the vendors, and oversight will become an after-action report.