AI Governance Shifts: Why OpenAI Added Nakasone

Most AI risk discussions still fixate on model outputs: hallucinations, bias, misuse. That’s the visible layer. The harder problem—and the one that determines whether AI can safely power U.S. digital services at scale—is security: the infrastructure, the model weights, the customer data, and the humans who operate all of it.

That’s why OpenAI’s decision to appoint Retired U.S. Army General Paul M. Nakasone to its Board of Directors (and to place him on the Board’s Safety and Security Committee) matters beyond corporate news. It’s a clear signal that AI governance in the United States is entering a more security-first phase, shaped by people who’ve spent careers dealing with adversaries that don’t play nice.

This post sits in our “AI in Defense & National Security” series for a reason: the same threat actors that target defense networks also target hospitals, schools, banks, and cloud platforms. If your organization is building AI products, deploying AI agents, or buying AI-powered software, the governance choices made by major AI providers ripple down into your own risk profile.

What Nakasone’s appointment signals about U.S. AI governance

Answer first: Bringing a former leader of U.S. Cyber Command and the NSA into AI board governance signals that AI is now treated like critical national infrastructure, not just software.

OpenAI stated that Nakasone’s appointment reflects its commitment to safety and security, and highlighted priorities that sound familiar to anyone who’s defended high-value systems: protecting training supercomputers, securing sensitive model weights, and safeguarding customer data.

This is the shift I’ve watched more companies make in 2024–2025: AI security has moved from “infosec support function” to “board-level issue.” That’s not PR. It’s a recognition that advanced AI systems create new high-impact failure modes:

• Model weight theft can enable replication, misuse, or competitive loss.
• Training and inference infrastructure attacks can cause service disruption, data exposure, or integrity failures.
• Supply-chain compromise (dependencies, plugins, agent tools) can turn AI systems into a new execution path for attackers.

For U.S.-based technology and digital services, this is a national-interest topic even when no one says the quiet part out loud. AI systems increasingly sit inside workflows for identity verification, customer support, fraud detection, logistics planning, and software development. When those systems are compromised, the blast radius isn’t theoretical.

Why board-level security expertise changes decisions

Boards don’t configure firewalls. They decide what gets funded, what gets delayed, and what tradeoffs are acceptable.

A security-oriented board member tends to push three uncomfortable questions:

1. “What’s the real adversary model?” Not “random hackers,” but state-aligned groups, criminal syndicates, insiders, and sophisticated phishing campaigns.
2. “Which assets would we never recover from losing?” In AI, that often includes model weights, privileged access keys, and sensitive training data.
3. “What can we prove?” Mature governance demands evidence: audit logs, red-team results, incident response exercises, and measurable controls.

If you’re a buyer of AI services, this matters because providers that govern security tightly are more likely to offer the things enterprises actually need: clearer controls, safer defaults, and more predictable risk posture.

AI security isn’t only about “misuse”—it’s about cyber resilience

Answer first: The most practical AI safety work in 2025 is boring cybersecurity done extremely well—because attackers target the systems around the model as much as the model itself.

OpenAI called out securing “large AI training supercomputers,” protecting “sensitive model weights,” and safeguarding “data entrusted… by customers.” Those are three distinct security domains, and each has its own playbook.

Securing AI infrastructure: the new high-value target

Training clusters and high-end accelerators aren’t just expensive. They’re strategic assets. If an attacker can disrupt training or inference infrastructure, they can:

• Force downtime (availability impact)
• Exfiltrate data in transit or at rest (confidentiality impact)
• Tamper with pipelines or artifacts (integrity impact)

For organizations deploying AI internally, the equivalent is your cloud tenant, your GPU workloads, your container build pipeline, and your secrets management.

Practical takeaway: Ask vendors (and your own teams) for a simple diagram of the AI production path—from data ingestion to model hosting to user access. If they can’t draw it, they can’t defend it.

Protecting model weights: “the crown jewels” problem

Model weights are valuable because they encode capability. Theft can enable:

• Replica models (loss of control)
• Faster weaponization by adversaries (misuse acceleration)
• IP loss (competitive and strategic damage)

A lot of AI security talk stays abstract; weight security is concrete. It’s about access controls, hardware security modules, strong separation of duties, tight egress controls, and constant monitoring.

Practical takeaway: If your organization fine-tunes models or hosts them privately, treat weights like cryptographic key material: minimal access, strong logging, strict environment segregation, and rehearsed recovery plans.

Customer data: the trust contract for AI-powered services

If AI is powering digital services in the United States, data protection isn’t optional. Customers expect their sensitive data—health, education, financial, identity—to remain protected even as it flows through AI pipelines.

In late 2025, buyers increasingly demand:

• Clear retention and deletion policies
• Tenant isolation (for enterprise deployments)
• Robust access controls and auditability
• Incident response commitments that aren’t vague

Practical takeaway: Push for contract language that defines security responsibilities, logging, breach notification windows, and the scope of data usage. Legal clarity is part of security.

Why national security experience matters for commercial AI

Answer first: National security leaders tend to operationalize risk: they plan for persistent threats, deception, and long timelines—exactly what commercial AI now faces.

Nakasone’s career included leading U.S. Cyber Command and the NSA, and playing a pivotal role in the creation of USCYBERCOM. Regardless of where you stand politically, that background typically means comfort with:

• Threat intelligence and attribution complexity
• Defending against advanced persistent threats (APTs)
• Balancing mission speed with operational security

For commercial AI, those instincts translate into governance choices that can affect the whole ecosystem:

• More rigorous internal red-teaming and adversarial testing
• Stronger controls around privileged access and insider risk
• A bias toward resilience: graceful degradation, containment, recovery

The under-discussed overlap: hospitals, schools, and banks

OpenAI explicitly referenced institutions “frequently targeted by cyber attacks like hospitals, schools, and financial institutions.” That’s not incidental—those sectors are prime examples of where AI adoption is rising while security budgets and staffing often lag.

AI is already used in these environments for:

• Patient and student communications (support and triage)
• Fraud detection and document processing
• Scheduling, routing, and operations planning

Here’s the reality: when AI becomes part of operations, AI availability and integrity become safety issues. A ransomware incident that interrupts a hospital’s systems is already bad. Add AI-powered scheduling or clinical documentation, and the dependency stack gets deeper.

Practical takeaway: If you’re deploying AI in regulated or critical services, build “break glass” procedures. Humans need a documented, tested way to keep operating when AI tools are unavailable.

What this means for organizations adopting AI in the U.S.

Answer first: Expect AI procurement and deployment to look more like critical infrastructure onboarding: deeper vendor review, tighter controls, and more governance.

A board-level focus on safety and security tends to raise the baseline expectations across the market. If you run technology, security, compliance, or product for a U.S. business, you’ll feel this in three places: vendor diligence, internal controls, and incident readiness.

A security-first checklist for AI deployments (practical)

Use this as a starting point for your next AI initiative—whether it’s an internal assistant, customer-facing chatbot, or agentic workflow.

1. Define the “blast radius”

   • What happens if the AI tool is wrong, unavailable, or compromised?
   • Which workflows must continue without it?

2. Separate data classes

   • Don’t feed sensitive data into tools that don’t support your retention, isolation, and audit needs.
   • Create explicit rules for PII, PHI, financial data, and source code.

3. Control identity and access like you mean it

   • SSO, MFA, least privilege, and role-based access aren’t “nice to have.”
   • Limit who can change prompts, tools, connectors, and agent permissions.

4. Log the right events

   • Prompt and tool execution logs (with privacy controls)
   • Admin changes
   • Data connector access
   • Unusual output patterns (exfil behavior)

5. Red-team the workflow, not just the model

   • Test jailbreaks, prompt injection, tool abuse, and data leakage paths.
   • Simulate realistic adversaries, including phishing-driven account takeover.

People also ask: “Does this mean AI companies are becoming defense contractors?”

Not necessarily. But governance choices like this reflect a trend: commercial AI providers are being held to expectations closer to those placed on critical service operators. Even if you never sell to government, your systems may still be targeted like you do.

People also ask: “Will this slow AI innovation?”

It should slow the wrong kind: shipping powerful capabilities without hardened controls. In my experience, organizations that invest early in security and governance ship faster over the long run because they spend less time in crisis mode.

The bigger story for AI in defense & national security

Answer first: The U.S. AI landscape is converging on a single truth: capability without security becomes a liability.

OpenAI’s appointment of General Nakasone reads as a recognition that advanced AI systems bring both promise and pressure. The promise is obvious—AI can help detect and respond to cyber threats faster, support overworked teams, and harden services that Americans rely on every day. The pressure is that adversaries adapt quickly, and AI increases the value of the targets.

If you’re leading AI strategy in a U.S. organization, take the hint: governance and security aren’t bureaucratic overhead. They’re what make scale possible.

If you want help pressure-testing an AI rollout—vendor review, threat modeling, AI security controls, or an incident response tabletop—this is the moment to do it before the next audit, the next breach, or the next surprise from an AI agent with too many permissions.

Where do you think the biggest gap is right now: model behavior risk or the security of the systems around the model?