Who should be accountable for AI governance when business teams adopt tools first?

Why This Matters for Security Teams

When business teams adopt tools first, accountability fragments fast: procurement sees a productivity gain, the business sees a pilot, and security sees an unregistered risk. That gap is especially dangerous for AI-enabled workflows because the tool may already be handling sensitive data, secrets, or privileged actions before anyone has defined ownership. NHI Management Group’s guidance on the Top 10 NHI Issues and the governance perspective in the Ultimate Guide to NHIs — Regulatory and Audit Perspectives both point to the same operational problem: ownership is often discovered after exposure, not before approval. Current guidance from the NIST Cybersecurity Framework 2.0 and the NIST AI Risk Management Framework supports distributed accountability, but that only works if the business sponsor is named early and control owners are assigned explicitly.

In practice, many security teams encounter shadow AI and unreviewed access only after a data event, a vendor review, or an audit finding has already forced the issue.

How It Works in Practice

The cleanest operating model is shared accountability with clear decision rights. The business owner is accountable for the use case, intended data use, and acceptable risk. Security is accountable for the control baseline, including data handling, secrets management, logging, and approval gates. IAM, platform, and data teams are accountable for enforcement, such as conditional access, token hygiene, and storage boundaries. Governance or risk functions then validate that the use case was registered, classified, and reviewed before production.

This model works best when intake is mandatory and tied to technical enforcement. A team should not be able to move from experiment to production without a recorded owner, documented data classes, and an identified system of record for access decisions. That is consistent with NIST’s emphasis on governance and continuous monitoring in both the NIST AI Risk Management Framework and the NIST AI 600-1 Generative AI Profile, where oversight is not a one-time approval but an ongoing control function.

• Register the tool or AI workflow before data access is granted.
• Assign a business owner who can approve use, scope, and exceptions.
• Require security review for secrets, logging, retention, and external sharing.
• Use IAM and platform controls to enforce approved access paths.
• Review production use periodically, not only at procurement time.

For NHI-heavy environments, lifecycle discipline matters because AI tools often consume credentials, tokens, or service accounts under the hood; the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful for mapping that ownership chain. These controls tend to break down when a business unit can self-provision SaaS or AI features without central identity enforcement.

Common Variations and Edge Cases

Tighter governance often slows adoption, so organisations have to balance speed against the cost of unmanaged risk. That tradeoff becomes sharper when tools are piloted inside a department that has its own budget, vendor contract, and technical admin rights. Best practice is evolving here, but current guidance suggests that “business-owned, security-governed” is stronger than pushing accountability entirely onto central IT, because the business is the only party that can truly answer why the tool exists and whether the risk is worth it.

There are edge cases. In highly regulated environments, legal, privacy, or compliance teams may need to co-own decisions about data categories and retention. In lower-risk experimentation, a temporary exception path may be acceptable, but only if the exception has an expiry date and a named approver. If the AI tool can create or use non-human identities, secret sprawl becomes a practical concern, and the compromise patterns highlighted in the DeepSeek breach show why owners must be able to answer for the workflow, not just the software license. In short, accountability gets muddled when ownership is treated as a procurement formality instead of an operational control.

Related resources from NHI Mgmt Group

• How should security teams evaluate GRC tools for business application governance?
• What should identity teams prioritise first when governance is weak?
• How should teams connect ERM tools to identity governance processes?
• When should teams move from pilot governance to production governance for AI?