AI Governance vs AI Security

Different questions, different failure modes

A governance failure looks like a policy nobody could apply: an engineer pastes a customer list into a consumer AI tool because no control stopped them and no record exists that it happened. Nobody attacked anything. The organization simply cannot say what its data did.

A security failure looks like manipulation: content in a repository causes an agent to add a dependency nobody chose, or a crafted input extracts information the system was not meant to reveal. There is an adversary, even an indirect one.

The two need different expertise. Governance draws on policy, data classification and compliance; security draws on threat modelling and adversarial testing. Assigning both to whichever team happens to have capacity is a reliable way to do one of them badly.

Where they genuinely overlap

The overlap is not conceptual, it is architectural. Both disciplines need something in the path of an AI-assisted action that can evaluate it and decide.

A rule blocking credentials in prompts is a governance rule by intent — the organization decided credentials do not leave. Its effect is a security control, because it also stops a credential leaving via an agent that was manipulated into sending it. One mechanism, two justifications.

This is why building them as separate stacks tends to produce two half-instrumented systems that disagree. The productive split is separate policies and separate owners on top of a shared enforcement and evidence layer.

• Shared: the point of enforcement, the context available at that point, and the audit trail.
• Distinct: which risks are catalogued, how they are assessed, and who signs off.
• Distinct: the measures of success — coverage and policy adherence, versus resistance to a modelled attack.

Frameworks lean one way or the other

The published material splits along the same line, which is a useful way to choose what to read. The NIST AI Risk Management Framework and ISO/IEC 42001 are governance-shaped: they describe how to organize the program, assign accountability and manage risk over a lifecycle.

OWASP's Top 10 for Large Language Model Applications and MITRE ATLAS are security-shaped: catalogues of how these systems are attacked. Google's Secure AI Framework sits between them, organizing security practice into something a program can adopt.

Most organizations need one from each column. Adopting only a governance framework produces a well-documented program with no threat model; adopting only a security catalogue produces a threat model with nobody accountable for the decisions.

Who owns what, in practice

The arrangement that tends to hold: security owns the threat model and the enforcement mechanism; legal and compliance own the classification scheme and the regulatory mapping; engineering leadership owns what is workable and the exception process; and one named person owns the policy itself, because a policy owned by a committee is not reviewed.

The arrangement that tends to fail is ownership landing entirely with whoever wrote the policy document, since that is rarely the team with the ability to enforce it.

Examples

• An employee uses an unapproved AI tool to summarize an internal document. No attacker is involved.

  A governance question. The control is the same one security would build, but the justification, the owner and the remedy are all governance-side.

• A coding agent reads a hostile issue comment and attempts to exfiltrate an environment variable.

  A security question, answered by the same enforcement layer: the action is evaluated on what it is, regardless of the instruction that produced it.

• An auditor asks how the organization knows its AI policy is being followed.

  Purely governance, and answerable only from the evidence layer — which is why the audit trail belongs to both disciplines rather than to either.

Frequently asked questions

Should the same team own both?

Usually not, but they should share infrastructure. Separate policies and separate accountability on top of one enforcement and evidence layer avoids both the duplicated tooling and the gap that appears when each assumes the other covered something.

Which should an organization start with?

Visibility, which serves both. Until AI usage is measured, the governance program writes generic rules and the security program models threats against a surface it cannot see.

Is AI safety a third thing?

In this context yes. Safety usually refers to model behaviour and its harms — what a model outputs and how it can affect people — and is largely a property of the model and its provider. Governance and security are about what an organization does with the system and what it permits the system to do.

Does an AI governance tool make an AI security tool unnecessary?

No. A control at the point of action addresses a specific, important surface. It does not model adversarial behaviour against systems you build, test your own AI applications, or cover the model supply chain. They are layers, not alternatives.

Sources

• AI Risk Management Framework (AI RMF 1.0)NIST
• OWASP Top 10 for Large Language Model ApplicationsOWASP
• MITRE ATLAS — adversarial threat landscape for AI systemsMITRE
• ISO/IEC 42001:2023 — Artificial intelligence management systemISO