Security teams should start with readiness assessment, then move clients through modernization, policy setting, and controlled pilot use. If the data is fragmented and the access model is weak, AI will create more governance friction than value. The right sequence is foundation first, automation second, because identity and data boundaries have to exist before AI can be safely expanded.
Why This Matters for Security Teams
When clients are not ready for automation, the risk is not that AI is unavailable. The risk is that AI is introduced into weak identity, fragmented data, and unclear change-control environments where it amplifies confusion faster than it delivers value. Current guidance from the NIST Cybersecurity Framework 2.0 still points security teams back to basic governance: inventory, access control, monitoring, and response. That sequencing matters more when AI is advisory, semi-autonomous, or embedded in operational workflows.
The practical mistake is treating AI adoption as a tooling decision instead of a readiness decision. If a client cannot explain who owns the data, who approves access, and how exceptions are tracked, then even a helpful AI assistant can create more governance friction than productivity. NHIMG research on The 2026 Infrastructure Identity Survey found that 67% of organisations still rely heavily on static credentials and only 44% have policies to manage AI agents, despite broad agreement that governance is critical. In practice, many security teams encounter AI-related control failures only after access sprawl or unsafe change requests have already reached production, rather than through intentional pilot design.
How It Works in Practice
The right approach is to move clients through readiness first, then controlled automation. That starts with a narrow assessment of identity maturity, data classification, privileged access, and operational ownership. Security teams should define what the client can support today, what must be remediated before AI expansion, and what use cases remain human-approved until the control environment improves.
For AI-enabled workflows, the operating model should be explicit:
- Use policy and process reviews to determine whether the client can tolerate machine-generated recommendations, but not autonomous execution.
- Bind any AI workflow to a named business owner, a technical owner, and a rollback path.
- Keep high-risk actions human-in-the-loop until access boundaries, logging, and exception handling are tested.
- Prefer limited pilots on low-impact tasks such as summarisation, triage, or drafting, rather than direct system changes.
This sequencing aligns with NIST Cybersecurity Framework 2.0 because readiness is a control problem, not a sentiment problem. It also reflects the broader NHIMG position that weak identity foundations will undermine any AI rollout, which is consistent with lessons seen in the DeepSeek breach and the Schneider Electric credentials breach, where exposure and access weakness created outsized operational risk. Security teams should treat AI as a bounded capability until governance, data quality, and access review processes are stable enough to absorb it. These controls tend to break down when clients expect AI to compensate for missing identity discipline because the automation simply inherits the same broken permissions model at higher speed.
Common Variations and Edge Cases
Tighter AI governance often increases delivery time and stakeholder friction, so organisations have to balance speed against operational safety. That tradeoff becomes especially visible when clients want AI benefits but cannot yet support mature access reviews or consistent data ownership. In those cases, best practice is evolving toward staged enablement rather than all-or-nothing deployment.
There are a few common edge cases. Some clients can support AI for internal drafting or analysis but not for actions that touch infrastructure or customer data. Others have strong security teams but poor business ownership, which means the technical controls exist but no one is accountable for exceptions. There is also no universal standard for how much automation is acceptable in regulated environments, so security teams should document the acceptable use boundary instead of assuming an industry norm.
Where a client is early in maturity, the safest path is often to keep AI advisory, limit its data scope, and require human approval for any action that changes state. Once the client can demonstrate stable identity governance, the automation boundary can widen. For more on the governance lens, the NIST Cybersecurity Framework 2.0 remains the most practical anchor for sequencing control improvement alongside adoption.
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, NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Client readiness begins with clear organisational context and ownership. |
| NIST CSF 2.0 | PR.AA-01 | AI adoption fails when identity and access controls are immature. |
| NIST AI RMF | AI RMF fits readiness-first governance for limited, controlled deployment. |
Verify identities, access rights, and privileged workflows before enabling client-facing AI.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
