Who is accountable when AI is deployed without a formal decision or review?

Accountability usually falls on the organisation that allowed the tool, integration, or default feature to operate in production without adequate review. Compliance frameworks expect teams to know where AI exists, what it does, and who approved it. If no one can explain that path, governance ownership is already failing.

Why This Matters for Security Teams

When AI is deployed without a formal decision or review, accountability does not disappear. It shifts to the organisation that permitted the system to run, even if the approval path was informal, implied, or buried inside a platform default. That makes this a governance failure first, and a technology issue second. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful baseline because it expects control ownership, reviewability, and traceability, not just deployment speed.

For AI and NHI programs, the practical risk is that no one can explain who accepted the risk, what data or secrets the system could access, or whether the deployment crossed a policy boundary. That is especially dangerous when an AI feature has tool access, can call APIs, or can influence downstream workflows. In those cases, a missing review is not a paperwork gap. It is an active control gap that can become a breach path.

In practice, many security teams discover the absence of ownership only after the system has already generated output, accessed data, or been integrated into production workflows.

How It Works in Practice

Formal accountability for undeclared AI deployment should be anchored in three questions: who approved it, what scope was approved, and what controls were required before production use. For autonomous or semi-autonomous systems, that review should include identity, data access, logging, and revocation paths. Current guidance suggests treating the AI system like any other privileged workload, with explicit owners and documented policy enforcement, rather than assuming a business unit’s informal adoption is acceptable.

Where AI tools touch secrets, credentials, or API-driven actions, the review should also verify whether the system has a non-human identity, whether that identity is scoped per task, and whether runtime permissions are constrained. NHIMG’s The State of Secrets in AppSec highlights how fragmented secrets management and slow remediation can amplify governance failures when controls are unclear. If a team cannot show who owns the deployment path, it usually cannot show who owns the secrets path either.

• Record the system owner, business owner, and technical approver before production use.
• Map the AI feature to the data, secrets, and tool permissions it can reach.
• Require runtime logging for prompts, actions, approvals, and revocations where feasible.
• Use policy-as-code or equivalent review gates so approvals are repeatable, not verbal.
• Document whether the system is human-assisted, agentic, or fully autonomous, because accountability changes with execution authority.

For threat-context, NHIMG’s DeepSeek breach is a reminder that uncontrolled data exposure and undeclared access paths can turn a model rollout into a broad security incident. These controls tend to break down in fast-moving product teams that can enable AI features through default settings, plugin marketplaces, or shadow IT SaaS, because the approval record never exists in a system security owner can audit.

Common Variations and Edge Cases

Tighter AI approval controls often increase delivery friction, so organisations have to balance speed against the cost of unmanaged risk. There is no universal standard for this yet, but best practice is evolving toward explicit decision ownership, especially where AI can read data, invoke tools, or affect external systems.

A common edge case is vendor-managed AI embedded in a platform update. Even when the vendor ships the feature, the organisation is still accountable for deciding whether it is enabled, what data it can see, and whether it is consistent with internal policy. Another edge case is experimentation in non-production environments. That does not remove accountability if production data, credentials, or downstream integrations are exposed. The practical rule is simple: if the system can create impact, someone must own the approval record.

For teams operating under NIST-based governance, NIST SP 800-53 Rev 5 Security and Privacy Controls can support formalisation of approvals, while NHIMG’s research on secrets and AI abuse shows how quickly weak ownership turns into exposed credentials and uncontrolled access. The hard part is not writing the policy. It is enforcing it when the AI feature arrives through a product default or a business-led exception.

Related resources from NHI Mgmt Group

• Who is accountable when a high-risk SaaS or AI tool is used without documented purpose or review?
• Who is accountable when AI-assisted design review misses a security issue before release?
• How should security teams use AI-assisted query building for access governance without weakening review quality?
• What breaks when organisations launch AI systems without formal risk assessment and approval workflows?