What breaks when organisations launch AI systems without formal risk assessment and approval workflows?

Without risk assessment and approval workflows, high-impact AI use cases can move into production without clear ownership, documented safeguards, or visibility into harm. That creates gaps in accountability, weakens audit readiness, and increases the chance that systems affecting people, data, or business decisions exceed approved risk tolerance.

Why This Matters for Security Teams

Launching AI systems without formal risk assessment and approval workflows turns governance into an afterthought. The immediate problem is not just missing paperwork. It is missing decisions about purpose, data exposure, human oversight, and failure tolerance before a system is allowed to influence customers, employees, or operations. NIST’s NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce that risk decisions should be traceable, not improvised after deployment.

For NHI and agentic AI programs, this matters because an AI system often arrives with embedded secrets, API access, and tool execution paths that can reach far beyond the original use case. NHIMG research on the Ultimate Guide to NHIs — Why NHI Security Matters Now shows why teams cannot assume these identities are benign by default, while the OWASP NHI Top 10 highlights how unmanaged non-human access becomes an operational risk, not just an IAM issue.

In practice, many security teams discover the absence of approval controls only after an AI workflow has already touched sensitive data or automated a business decision that no one explicitly signed off on.

How It Works in Practice

Formal risk assessment and approval workflows create a gate between experimentation and production. At minimum, they force teams to document the system’s intended use, data classification, model and tool dependencies, failure modes, override paths, and accountable owner. For AI systems that act autonomously, approval should also cover whether the system can call external tools, write back to systems of record, or trigger downstream actions without human confirmation. This is where standard access review alone falls short: authorization is only one part of the control set.

Current guidance suggests pairing risk review with security sign-off, privacy review, and business approval before release. NIST CSF 2.0 supports governance as a core function, not a post-incident activity, while NIST SP 800-53 Rev 5 provides control families that map to auditability, change control, and least privilege. For NHI-heavy AI workflows, that means checking whether service accounts, secrets, and tokens are scoped to the approved use case and whether expiration, rotation, and revocation are enforceable. NHIMG’s Top 10 NHI Issues is useful here because many failures begin with unreviewed machine credentials rather than the model itself.

• Define the use case, owner, and risk tier before any production access is granted.
• Require data, security, legal, and operational approvals for high-impact systems.
• Attach approval to concrete controls: secrets scope, logging, rollback, human override, and review cadence.
• Reassess whenever the model, tools, data sources, or decision authority changes.

These controls tend to break down when teams ship rapidly changing AI agents into production environments with multiple tool integrations, because the approved risk profile becomes stale faster than the workflow can be reviewed.

Common Variations and Edge Cases

Tighter approval gates often increase delivery time, so organisations must balance speed against the cost of unreviewed AI behaviour. That tradeoff is real, especially for low-risk internal copilots where a heavy process can create avoidance and shadow deployment.

Best practice is evolving, but current guidance is clear that not every AI system needs the same approval depth. A low-impact summarisation tool may justify a lightweight review, while an agent that can modify records, approve transactions, or access regulated data should go through formal risk acceptance. The more autonomy, the stronger the approval workflow should be. That is also where the distinction between model risk and non-human identity risk matters: a harmless model wrapped around an overly privileged service account can still create material exposure.

One useful exception is controlled experimentation in isolated sandboxes, where approval can be narrower and time-bound. Even then, organisations should set explicit exit criteria for production promotion. NHIMG’s Ultimate Guide to NHIs – Key Challenges and Risks and the DeepSeek breach illustrate how quickly unmanaged access and unclear governance can turn a technical deployment into an organisational incident.

Where this guidance breaks down is in federated environments with inconsistent approval standards across business units, because the same AI capability can be treated as low risk in one team and high impact in another.

Related resources from NHI Mgmt Group

• What breaks when reactive AI systems can take identity actions without approval?
• How should organisations control access to frontier AI systems without creating surveillance risk?
• What breaks when organisations do not test inference risk in AI systems?
• How do organisations control the risk of AI systems performing offensive workflows?