Security and policy leaders should separate three tracks: infrastructure planning, developer protection, and workforce readiness. That means funding the underlying compute and data environment, protecting domestic developers from espionage, and recruiting AI talent into public service. At the same time, leaders should establish coordination structures, testing authority, and explicit limits on where AI can be used operationally.
Why AI Programs Need Three Separate Operating Tracks
Introducing AI into military or intelligence work is not one decision, it is three different program problems. Infrastructure must be planned and funded as a real operational dependency, developer talent needs to be protected and retained, and the workforce needs enough capability to use AI without creating unexamined authority or overreach. Treating those as one budget line usually leaves the weakest track under-resourced.
The practical reason to split them is that each track fails differently. Compute and data environments can become bottlenecks, developer ecosystems can be targeted by espionage or poaching, and operators can overtrust systems that are fast but not fully bounded. That is why AI adoption in these environments should be governed as a capability transition, not a software rollout.
For infrastructure, the relevant question is whether the program has dependable compute, data access, logging, and model hosting arrangements that can survive operational pressure. For people, the issue is whether the state can keep scarce technical staff productive and secure enough to build and maintain the capability. For the workforce, the question is whether analysts, commanders, and policy staff know where AI may assist judgment and where it should not be used to make or conceal decisions.
Coordination, Testing, and Use Boundaries
Leaders should create coordination structures that bring policy, security, acquisition, legal, and mission owners into the same decision path before deployment. AI programs in sensitive environments tend to break when one group optimises for speed, another for assurance, and no one owns the final operational rule set. A standing review structure is the simplest way to keep those decisions aligned as the system evolves.
Testing authority matters because military and intelligence use cases require more than generic model quality checks. Leaders need a defined party that can challenge outputs, red-team failure modes, and approve use in context, especially where the model may influence targeting support, intelligence triage, or internal workflow decisions. Without that authority, testing becomes a one-time event instead of a control gate.
Explicit limits on operational use are equally important. Current guidance suggests drawing hard lines around where AI may support analysis, where it may recommend, and where human approval must remain mandatory. The objective is not to forbid AI, but to prevent quiet mission creep from turning a support tool into an unreviewed decision-maker.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST AI RMF set the technical controls, while DORA and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC — Organizational Context | AI use in military and intelligence programs depends on mission context and operating boundaries. |
| GV.RM — Risk Management Strategy | The question is about how leaders should govern AI risk across infrastructure, people, and operations. | |
| GV.SC — Cyber Supply Chain Risk Management | Developer protection and trusted AI programs depend on resilient supply and delivery chains. | |
| Recommendation — Define mission-specific AI boundaries before expanding deployment. Set a risk strategy that separates infrastructure, talent, and operational controls. Assess supply-chain exposure for models, data, tooling, and development support. | ||
| DORA | ICT — ICT risk management | Sensitive AI programs need disciplined ICT planning, resilience, and governance around critical dependencies. |
| Recommendation — Treat AI infrastructure and supporting services as critical ICT assets. | ||
| NIST AI RMF | GOVERN — Govern | Leaders need governance structures, accountability, and policy limits for AI adoption. |
| MAP — Map | The program needs to identify intended uses, stakeholders, and high-consequence contexts. | |
| MANAGE — Manage | The question calls for operational controls, testing authority, and ongoing oversight. | |
| Recommendation — Establish AI governance with clear authority, accountability, and usage limits. Map where AI will be used and where it must remain bounded. Manage AI risk through testing, monitoring, and controlled deployment. | ||
| ISO/IEC 42001:2023 | A.6 — AI system lifecycle | Military and intelligence AI requires lifecycle controls from planning through operation. |
| A.5 — Leadership and commitment | Leadership must own AI direction, limits, and resource allocation. | |
| Recommendation — Build lifecycle controls before operationalising AI capabilities. Assign executive ownership for AI governance and resourcing. | ||
Practitioner Guidance
What to prioritise: Put infrastructure, developer protection, and workforce readiness on separate delivery tracks with separate owners and milestones. If one track is delayed, that should not block the others unless the dependency is real and documented.
What to verify: Confirm that there is named testing authority with the power to stop deployment, that usage limits are written in operational terms, and that staff can explain the difference between advisory AI output and authorised action.
Common mistake: Leaders often fund model access before they fund the environment, the talent pipeline, or the governance structure. That creates impressive demos but brittle capability.
Practitioner takeaway: The safest AI introduction in sensitive programs is the one that separates technical enablement from operational permission, then proves both before scale-up.
Related resources from NHI Mgmt Group
- What should SOC leaders do when AI is being introduced into security operations but the environment is still highly fragmented?
- Why do AI programs increase data privacy liability for security teams?
- How should security teams enforce AI policy without driving users to shadow AI?
- Why do AI security programs need both data controls and identity controls?
