Common signs include slow policy development, limited internal expertise, weak oversight of use cases, and inconsistent training across teams. If an organisation cannot staff specialist roles, maintain inventories of AI use, or keep pace with threat activity, its AI programme is likely being managed reactively rather than as a governed security capability.
How to recognise an AI security programme that is reacting instead of governing
The most reliable signal is that the programme cannot turn AI use into a managed security capability. That usually shows up as slow policy and control updates, weak ownership, and poor visibility into where AI is being used. When teams cannot answer basic questions about approved use cases, accountable owners, or security review status, readiness is already behind actual adoption.
A second sign is that programme activity lags the pace of deployment. If new tools, models, or integrations are being introduced faster than the security team can assess them, the organisation is relying on informal judgment instead of repeatable review. That gap matters most in critical infrastructure, where AI failures can affect operational continuity, safety, and recovery.
A third sign is that the programme lacks operational evidence. Mature readiness is not just policy text, it is inventories, review records, training completion, exception handling, and escalation paths that can be shown under pressure. For infrastructure contexts, a programme that cannot demonstrate those basics should be treated as immature even if the intent is sound.
What under-resourcing looks like in practice
Under-resourcing rarely appears as one dramatic failure. It usually appears as several smaller constraints at once, including too few specialist staff, inconsistent training, and no durable process for tracking AI assets across teams. If security, risk, engineering, and operations each describe AI differently, the programme is not yet operating as a shared control model.
Another practical indicator is that the organisation can discuss AI risk in principle but cannot perform routine governance work at pace. That includes classifying use cases, validating vendors, checking logging and monitoring, reviewing data flows, and deciding when human oversight is required. In critical infrastructure settings, those tasks need a steady operating rhythm, not ad hoc meetings.
Visibility is especially important. A programme that cannot maintain an inventory of AI use will miss shadow deployments, unmanaged integrations, and gaps between approved policy and actual practice. That is why CISA Industrial Control Systems guidance and ENISA threat landscape reporting are useful reference points for teams trying to anchor AI governance in real operational exposure rather than abstract policy language.
Why critical infrastructure readiness demands a higher bar
Critical infrastructure use changes the readiness threshold because the consequences of error are larger and the margin for unmanaged change is smaller. A programme may be acceptable for low-risk internal experimentation but still unfit for environments where availability, safety, integrity, and recovery are mission-critical. That is especially true when AI outputs influence operational decisions, change management, or incident response.
Readiness also depends on whether the organisation can maintain control over the full lifecycle of AI use. That includes intake, approval, monitoring, retraining, retirement, and exception handling. If the programme has no clear process for retiring obsolete use cases or reviewing changes in model behaviour, it is not ready for high-consequence deployment.
For teams comparing their programme to broader cybersecurity expectations, NIST Cybersecurity Framework 2.0 remains a useful baseline for governance, identification, protection, detection, response, and recovery. For AI-specific risk structure, NIST AI Risk Management Framework helps translate readiness into governance, map, measure, and manage activities that can be applied to an AI security programme.
Risk and Threat Considerations
Under-resourced AI security programmes create exposure because they leave too much trust in undocumented use, delayed review, and uneven oversight. In critical infrastructure, that can turn AI from a productivity tool into an unmanaged dependency, especially when decisions are time-sensitive or systems are tightly coupled.
Failure mechanism: Security teams do not have enough staff, process maturity, or inventory discipline to keep pace with deployed AI use, so unsafe use cases, weak configurations, and poorly governed integrations persist long enough to matter.
Impact: The organisation can miss unsafe or unauthorized AI use, fail to detect risky model or workflow changes, and accept operational exposure that becomes harder to reverse once AI is embedded in critical processes.
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 ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | AI readiness depends on defining mission-critical use cases and impact boundaries. |
| GV.RM-01 — Risk Management Strategy | Under-resourced AI programmes need a clear risk threshold for escalation and restraint. | |
| PR.AA-05 — Least Privilege | AI programme readiness includes limiting who and what can change or operate AI-connected systems. | |
| Recommendation — Define which AI use cases are operationally critical before approving wider deployment. Set explicit risk thresholds for when AI use in critical operations must be paused or restricted. Restrict AI-related access to the minimum needed for approved operational tasks. | ||
| NIST AI RMF | GOVERN — Govern | The question is about whether AI is governed well enough for high-consequence use. |
| MAP — Map | Readiness requires knowing where AI is used, by whom, and with what dependencies. | |
| MANAGE — Manage | Under-resourced programmes fail when risk treatment and monitoring cannot keep pace. | |
| Recommendation — Establish accountable AI governance roles, policies, and oversight gates before scaling use. Inventory AI use cases, dependencies, and operational context before approving critical use. Assign owners and monitoring actions to each AI risk that could affect operations. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | AI programme readiness depends on enforcing and reviewing access to AI systems and data. |
| A.5.37 — Documented operating procedures | The programme needs repeatable procedures for approvals, review, and exception handling. | |
| Recommendation — Apply access control rules to every AI system, data source, and integration. Document the operating steps for AI approval, monitoring, and escalation. | ||
Practitioner Guidance
What to verify: Confirm that every AI use case has an owner, a defined approval path, an inventory record, and an explicit review cadence. If any of those are missing, treat the programme as incomplete rather than merely early stage.
Decision rule: If the team cannot staff specialist oversight or keep an inventory current, limit AI to low-consequence use cases until controls are stable. Do not expand into operationally critical workflows on the assumption that policy will catch up later.
What good looks like: Security, operations, and risk teams can name approved use cases, explain who can change them, and show evidence of review, training, and exception handling without assembling a one-off narrative.
Practitioner takeaway: Readiness is not measured by ambition or pilot count, it is measured by whether the programme can reliably govern AI use at the speed the organisation is deploying it.
Related resources from NHI Mgmt Group
- How should critical infrastructure teams validate cybersecurity controls under Bill C-8?
- What are the signs that an AI governance programme is not ready for regulatory scrutiny?
- What are the signs that a data security programme is not ready for agentic AI?
- What are the signs that an AI banking programme is not ready for scale?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
