Who is accountable when AI tools process company data without approval?

Why This Matters for Security Teams

When AI tools process company data without approval, the issue is not only shadow IT. It becomes a governance failure across data classification, acceptable-use policy, vendor risk, and technical control enforcement. Security teams need to know whether the tool is handling regulated data, customer records, source code, or internal strategy, because the response depends on the data class and the business impact. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it maps accountability to concrete control ownership rather than informal expectations.

The practical risk is that unapproved AI use can bypass legal review, retention rules, and logging requirements in a single step. In many organisations, employees do not intend to create exposure; they are trying to move work faster. That is why accountability must be assigned before the first upload, prompt, or API connection happens. It also matters whether the AI tool is a public SaaS product, a browser plugin, or an internal assistant connected to company systems. Those are different control problems, even if they look similar on the surface. In practice, many security teams encounter the breach aftermath of unsanctioned AI use only after data has already left the approved environment, rather than through intentional discovery.

How It Works in Practice

Accountability should follow the control domain, but one named owner should coordinate the response. Business leadership usually owns the use case, because it approves the workflow and benefit. Security owns the guardrails, detection, and incident handling. Privacy and legal own data-use boundaries, especially where personal data, confidential material, or cross-border processing is involved. IT or platform teams own technical enforcement such as approved application lists, CASB rules, identity controls, and network restrictions. If the organisation uses AI in a regulated environment, the owner set should also include risk management and compliance.

A workable operating model usually includes four steps:

• Define which AI tools are approved, conditionally approved, or prohibited.
• Classify data by sensitivity and explicitly map what may be entered into each tool.
• Assign review, monitoring, and exception handling to named functions, not committees alone.
• Log approvals, blocklisted tools, and escalations so the process is auditable.

From a control perspective, this aligns with the intent of NIST SP 800-53 Rev 5 Security and Privacy Controls, especially access control, audit logging, configuration management, and incident response. Where AI tools connect to identity systems or internal knowledge bases, the question also becomes whether the tool has legitimate, bounded access or is operating with excess privilege. That is a standard governance issue, not a purely technical one. External guidance from OWASP on AI-related risks also reinforces the need to validate data handling before deployment, not after misuse has already started.

The model breaks down when tooling is adopted through browser extensions, personal accounts, or developer workarounds because central logging and policy enforcement are often incomplete.

Common Variations and Edge Cases

Tighter approval controls often increase friction for teams that rely on fast experimentation, so organisations need to balance productivity against data exposure and auditability. Best practice is evolving for AI governance, and there is no universal standard for every tool category yet.

One common edge case is employee use of generic public AI systems for non-sensitive work. Even if the data seems harmless, prompts can still reveal internal context, project names, or business logic. Another is sanctioned AI embedded in a third-party product, where the business may assume the vendor is responsible, but the organisation still owns the decision to send data there. A third case is development teams using model APIs, where source code, test data, or logs may be transmitted automatically unless safeguards are configured.

This is where policy must be tied to enforcement. If approval exists only in a document, accountability remains theoretical. Stronger governance usually requires identity-based access restrictions, content filtering, contractual review, and periodic usage reviews. For organisations handling personal data or regulated information, privacy impact assessment and recordkeeping should be part of the approval path. NIST CSF is useful for structuring governance and detection, while OWASP guidance helps teams identify the misuse patterns that policy alone will miss. Current guidance suggests the accountable owner should be the function that can actually stop the risk, not merely the one that first notices it.

These controls tend to break down in decentralised organisations with weak procurement discipline because shadow approvals and local exceptions outrun central policy.

Related resources from NHI Mgmt Group

• What breaks when employees use AI tools inside browser sessions without data controls?
• Who is accountable when shadow AI uses corporate credentials to process sensitive data?
• What breaks when AI tools can query endpoint data without tight scoping?
• What breaks when employees use unapproved AI tools with company data?