Jaime Velez holds a glowing AI Governance block, considering where it fits in a stack of Corporate, IT, Security, Data, and Privacy Governance.

Where Does AI Governance Belong in the Enterprise?

As I was preparing for my CISSP Certification exam this question popped in my head. I was reading through Domain 1, the section on security governance, and I hit a sentence that made me ponder on this.

It said that through proper security governance, those who are accountable for increasing the value of the organization can be supported and enabled to achieve their goals.

Read that again. Governance is not a compliance exercise. It is not a binder on a shelf.

Governance exists to support the people who are accountable for creating value.

That one sentence does more work than most frameworks I have read lately.

And it forced a question I could not shake: Where does AI Governance belong in the enterprise?

Jaime Velez holds a glowing AI Governance block, considering where it fits in a stack of Corporate, IT, Security, Data, and Privacy Governance.

Does it stand alone? Does it live under security governance? Under enterprise IT governance? Under corporate governance? Since AI relies almost entirely on “Data”, should it be part of Data Governance?

I have spent my entire career in enterprise IT and the last few years deep in cybersecurity while gradually shifting my focus more and more towards AI Security and Governance inside a regulated financial services organization.

This question is not an academic one to me. It determines budgets, reporting lines, accountability for controls implementation, and whether AI risk gets managed or gets ignored.

Here is my answer.

Start With the Governance Stack

Before we can place AI Governance, we need to understand what already exists. There is a hierarchy of accountability here, even where responsibilities overlap.

Corporate governance sits at the top. It is the board and executive accountability structure for the entire enterprise. It defines risk appetite. It answers to shareholders, regulators, and the communities where the organization operates. Everything else draws its authority from this level.

IT governance typically is a subdomain of corporate governance.

Think COBIT. It governs how technology investments are made, how systems are managed through their lifecycle, and how technology risk is measured and reported upward.

Security governance is also a subdomain, and it overlaps IT but is broader than IT.

Security covers anything that represents value. People. Facilities. Data. Reputation.

The CISSP material makes this point directly: security should not focus only on information, because information is just one category of asset that carries value.

Corporate governance provides the authority. IT, security, and data governance provide distinct but overlapping disciplines.

AI makes their interdependence impossible to ignore.

AI Governance Refuses to Nest

So, where does AI Governance belong? Here is the uncomfortable truth: it does not nest. It cuts across.

AI Governance is a horizontal discipline, the same way privacy governance is horizontal.

It touches every layer of the stack and borrows from each one, but no single layer can contain it.

The data agrees. When the IAPP’s AI Governance Profession Report 2025 asked organizations which function holds primary responsibility for AI governance, the answers were all over the map: privacy (22%), legal and compliance (22%), IT (17%), data governance (10%), ethics and compliance (6%), and security (5%). The IAPP’s own conclusion was that there is no clear best practice for where AI governance sits.

Six different answers. That is not a box. That is a mesh.

Corporate Governance

My strong belief is that AI Governance draws its authority from corporate governance. Board-level risk appetite. Ethical commitments.

Regulatory exposure like the EU AI Act and the model risk expectations regulators already apply to financial institutions.

When an AI system makes a decision that harms a customer, the accountability question lands in the boardroom, not the server room.

IT Governance

AI Governance borrows its machinery from IT governance. Model lifecycle management. Change control. Asset inventory. Version tracking. You cannot govern what you cannot see, and the operational discipline for seeing it already lives in IT.

For AI, that machinery has to stretch. A new model version, a tweaked system prompt, or a refreshed document index can change how a system behaves just as much as a code change, so they belong in the same change control process.

The same goes for the AI features vendors switch on inside software you already own. If they never show up in the asset inventory, they never get governed.

Data Governance

AI Governance also depends on data governance. Data owners and stewards establish accountability for the information the organization uses: what it means, where it came from, how its quality is maintained, and which uses are permitted. These are business decisions supported by technology, security, privacy, and legal expertise. They are not simply matters of database administration.

For AI, those responsibilities extend beyond training data. They include evaluation datasets, the documents an assistant retrieves, and the information an agent consumes or produces. The question is not simply whether the data is accurate or protected. It is whether the data is suitable for this system, this purpose, and the people affected by its use.

Consider an assistant that retrieves an outdated policy from a perfectly secure document repository. The access controls can work exactly as designed while the assistant gives advice the organization should no longer be following.

But governing the data does not finish the job. AI governance still has to address the system’s behavior, its limitations, the decisions it is allowed to influence, and when human intervention is required.

Data governance is a foundation for trustworthy AI. It is not a substitute for governing the AI itself.

Security Governance

AI Governance also very much depends on security governance. Model security. Training data protection. Access control. Adversarial threat management. An ungoverned model is an unprotected asset, and protecting assets is what security does.

AI also brings attack paths security teams did not have to think about a few years ago. Prompt injection. Data poisoning. Model theft. Sensitive data leaking out through a chatbot’s answers. Plus whatever new creative attacks the bad actors will think of next.

And once an AI agent can read email, call APIs, or move data, it is no longer just an application. It is an identity, and it needs the same least privilege, monitoring, and off switch we expect from any privileged account.

What AI Governance Adds

AI systems introduce new risks and reshape existing ones. Model risk, bias and fairness, explainability, and human oversight require coordinated ownership across established functions. These are areas of scope that expand well beyond IT.

The problem is not that every responsibility is new. It is that no single function covers the whole problem.

AI Governance connects those responsibilities and establishes the additional controls needed for AI systems and their use.

Three Wrong Answers

Because AI Governance does not nest cleanly, organizations keep forcing it into boxes where it does not fit.

Based on my more than three decades inside enterprise IT, I can see these three failure modes playing out across the industry.

Some organizations may try to force it entirely under security, and AI gets treated as just another attack surface. The security team is excellent at threat modeling and access control. But security was never built to answer whether a model is fair, whether its decisions are explainable, or whether a human should override it. You get a hardened model that still makes ungoverned judgments.

I say that as a security guy. Even Gartner advises CISOs to influence enterprise AI governance and lead the cybersecurity piece, not own the whole thing.

Force it entirely under IT, and AI Governance becomes a technology project instead of an accountability question. IT will inventory the models, manage the pipelines, and track the versions. What IT will not do is decide who answers when the model is wrong. Ownership without accountability is administration, not governance.

Let it stand fully alone, with no anchor to the existing stack, and you get the third failure: the paper committee. A charter, a quarterly meeting, a set of principles on the intranet, and zero enforcement teeth.

Standalone AI Governance with no connection to corporate authority and no operational arms is just one more form of corporate theater.

It reviews. It recommends. It changes nothing. Great slides, though.

Every one of these failures comes from asking the wrong question.

Ask a Better Question

The wrong question is: which box does AI Governance live in?

The right question is: which accountability chain does it report through, and which existing functions operationalize it?

This reframe matters because governance is not about org charts.

Go back to that CISSP sentence.

Governance exists so that the people accountable for value creation are supported and enabled.

The moment you ask about accountability chains instead of boxes, the structure becomes obvious.

I am now preparing for the IAPP’s AI Governance Professional (AIGP) certification, and its Body of Knowledge lands in the same place. It never tells you which department owns AI governance. Instead, it expects you to define roles and responsibilities for every AI governance stakeholder, build cross-functional collaboration, and tailor the approach to the organization’s size, maturity, industry, and risk tolerance.

It also tells you to update the privacy, security, data governance, and intellectual property policies you already have, rather than start from scratch, and to train every stakeholder on AI.

One more detail I like. The BoK uses “developer” and “deployer” to describe tasks, not organizations, and notes that many organizations fill both roles. When a bank grounds a vendor model in its own documents or builds an agent on top of it, it is doing developer work, whatever the org chart says. Accountability follows the task, not the label.

Where Does AI Governance Belong?

It belongs anchored in corporate governance, with named business owners accountable for AI use and outcomes. IT, security, and data teams make the controls operational, with privacy, legal, and risk functions providing their respective expertise and oversight.

Jaime Velez carefully places an AI Governance block beneath Corporate Governance, spanning IT, Security, and Data Governance, with Privacy Governance below.

Anchored in corporate governance because that is where accountability for enterprise value lives, and AI is now a driver of enterprise value and enterprise risk in equal measure.

The IAPP’s new AI Governance Skills Framework puts it the same way: strategic leaders set the AI vision, priorities, and risk appetite, and they are the ultimate point of accountability.

The board owns risk appetite. The board must own AI risk appetite.

Anything less puts the accountability below the authority, and that arrangement always fails.

IT, security, and data teams make governance operational through existing controls, metrics, monitoring, inventories, lifecycle management, and data stewardship.

If you work in a bank, you will recognize the shape. It is the Three Lines of Defense, applied to AI.

LayerWhoWhat they own
AccountableBoard and executive leadershipAI risk appetite and ultimate accountability
OwnsBusiness owners (first line)AI use cases, decisions, and outcomes
OperatesIT, security, and data teams (first line)Controls, inventories, monitoring, and lifecycle
ChallengesRisk, compliance, privacy, and legal (second line)Policy, oversight, and effective challenge
AssuresInternal audit (third line)Independent assurance that it all works


Separation of duties still applies here. The people who build and run an AI system should not be the ones who grade it. In banking, we call that effective challenge. I have spent years defending first-line controls under second-line challenge. It is not always fun, but the controls that survive it are the ones I trust.

AI Governance should not rebuild what already works. It should connect those capabilities, establish AI-specific requirements, and make accountability explicit.

Business owners remain accountable for AI use and outcomes, while the teams responsible for the systems and data make the controls real, measurable, and auditable.

This is the structure that survives contact with a regulator. In financial services, that is not optional. Model risk management has decades of regulatory precedent behind it, and the examiners will not accept a paper committee or a purely technical program.

They will ask who is accountable, and they will expect the answer to reach the top of the house.

And in April, regulators raised the stakes. The Fed, OCC, and FDIC replaced SR 11-7 with new model risk guidance, SR 26-2. A footnote puts generative and agentic AI models outside its scope and says each bank’s own risk management and governance practices should decide the controls for those systems.

Translation: for copilots and AI agents, there is no regulatory template to lean on. You have to build the accountability chain yourself.

What This Looks Like on Monday

So what does the accountability chain actually do when a new AI use case shows up?

  1. Intake. Every AI use case comes through one front door, with a named business owner attached.
  2. Inventory. If it is not in the inventory, it does not exist. Shadow AI disagrees, which is why this step never ends.
  3. Risk tiering. Not every chatbot needs a board briefing. Tier by impact so the high-risk systems get the scrutiny.
  4. Control mapping. Map each tier to the controls you already run, then add the AI-specific ones.
  5. Evidence. If you cannot show it, you did not do it.
  6. Production monitoring. Watch what the system actually does after go-live, especially agents.
  7. Escalation and shutdown. Decide in advance who can pull the plug, and test that the plug works.

This lines up with how the NIST AI RMF treats risk management across the AI lifecycle.

None of this is exotic. It is the same control discipline regulated organizations already run, but pointed at a new kind of system. AI systems.

The Frameworks We Have Today

The good news: you do not have to invent this from scratch. The frameworks exist.

Three that matter most to me right now.

The NIST AI Risk Management Framework leads the pack.

It is built on four core functions: Govern, Map, Measure, Manage.

Map establishes context and identifies AI risks.

Measure assesses, analyzes, and tracks them.

Manage prioritizes and acts on them.

And Govern is the one to watch. It is not a step in a sequence.

Govern is cross-cutting. It sits at the center and wraps around the other three, covering culture, policies, and accountability.

NIST placed accountability at the core of the framework and made everything else orbit it. That design choice validates everything I argued above. The framework also defines what trustworthy AI actually means: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed.

ISO/IEC 42001 takes a different angle.

It defines an AI management system, the way ISO 27001 defines an information security management system.

Unlike the NIST AI RMF, it is certifiable.

Expect it to become the audit currency for AI programs, especially for vendors who need to prove governance maturity to enterprise buyers.

The EU AI Act is the regulatory hammer.

It is not voluntary, not a framework, and not optional for anyone touching the EU market.

It classifies AI systems by risk tier and attaches binding obligations to the high-risk tiers, with penalties that got the attention of every board in global financial services.

Where the Frameworks Fall Short

Now the honest part. These frameworks are necessary and not sufficient.

The NIST AI RMF is voluntary, like the NIST CSF before it. Not a regulation. Not certifiable. It tells you what good looks like and leaves adoption, depth, and enforcement entirely to you.

A voluntary framework in the hands of an unaccountable organization produces beautiful documentation and nothing else.

As I previously stated, the NIST AI RMF calls for risk management throughout the AI lifecycle, including ongoing monitoring.

The challenge is turning those expectations into operational assurance as systems, data, and deployment conditions change. A review milestone is not a substitute for knowing what the system is doing between reviews.

That challenge becomes sharper with generative and agentic AI. When an AI agent makes a series of decisions and takes action, governance must address more than how the model performed before deployment. It must establish who monitors its behavior in production, what limits apply to its actions, and when human intervention is required.

The implementation gap is not simply a missing framework. It is the work of translating governance expectations into controls, evidence, and accountability that remain effective after deployment.

Frameworks provide structure. Organizations still have to make that structure work.

And organizations now face framework sprawl. NIST for structure, ISO for certification, the EU AI Act for compliance, plus sector regulators layering on top.

I decided to stop paying attention to my LinkedIn for a while because lately all the algorithm shows me is one AI governance framework after another and different variations of each. (Yes, I see the irony of saying that on LinkedIn.)

The AI Governance framework sprawl is real, my friends.

Mapping across them consumes governance capacity that should be spent governing.

This is where AI Governance professionals, and their judgment, enter the picture.

The Next Three to Five Years

Here is what I expect to emerge by 2030… or at the rate we are moving, maybe by next month.

Harmonization. Crosswalks between NIST, ISO 42001, and the EU AI Act will mature into unified control catalogs, the way security frameworks converged over the past two decades.

Some industry groups, such as the Cloud Security Alliance (CSA), are already attempting this with their introduction of the CSA AI Controls Matrix.

Comply once, attest many times.

Continuous assurance. Point-in-time review will give way to always-on monitoring of model behavior, with governance metrics reported like security metrics. KPIs, KRIs, and KCIs for AI risk, feeding dashboards the board actually reads. Governance will become telemetry.

Agentic governance. As AI agents take real action in business processes, expect new framework layers for autonomy limits, human checkpoint design, and machine-to-machine accountability. The frameworks will be forced to govern judgment, not just models.

Regulatory teeth in financial services. Banking regulators are already redrawing the lines. SR 26-2 left generative and agentic AI to each bank’s own governance, and the agencies have promised a request for information focused on AI. If you run AI in a bank, your examiner will get there before Congress does.

An assurance ecosystem. ISO 42001 certifications, AI audit firms, and governance attestations will become standard procurement requirements.

Proving your AI is governed will be as routine as proving your data center is.

This Is the Org Mesh

Readers of my earlier work will recognize the shape of this answer. This is what I started calling the Org Mesh in action.

The Org Mesh is a governed accountability structure connecting humans and AI systems across an organization. It rejects the idea that AI can be managed inside a single silo, because AI does not operate inside a single silo.

Models make decisions in credit, in operations, in HR, in customer service. The governance structure has to mesh across those domains the same way the technology does.

Vertical accountability. Horizontal enforcement.

A Human at the Helm at every point where machine judgment touches real outcomes.

That is not a committee. That is an operating structure. And notice that the frameworks are converging toward it: NIST put Govern at the center, wrapping every other function. The AIGP Body of Knowledge asks for defined roles and cross-functional collaboration, not a single owner.

The mesh is where this entire field is heading.

Where does AI Governance belong?

It belongs at every intersection of the mesh, drawing authority from the top and enforcement from the functions that already know how to run controls.

Jaime Velez studies an Org Mesh screen connecting human owners and AI across four business areas, beside a completed governance stack in a cinematic office.

The question was never about finding AI Governance a home in the old hierarchy.

The question was about admitting the hierarchy alone is no longer enough.

The Bottom Line

Where does AI Governance belong?

Anchored in corporate governance, with named business owners accountable for AI use and outcomes. Operationalized through coordinated controls across IT, security, and data management. Independently challenged by risk and compliance, and assured by internal audit.

Structured and modeled by the NIST AI RMF, certified against ISO 42001, compliant with the EU AI Act where it applies, and other regulatory requirements that apply to your org.

Owned by named, accountable humans. Never standalone, never buried in a silo, never delegated entirely to technologists.

If you take one thing from this piece, take the reframe.

Stop asking which box AI Governance lives in.

Start asking which accountability chain it reports through and which functions give it teeth.

Boxes are for org charts. Accountability is for governance.

The CISSP study guide had it right all along. The AIGP Body of Knowledge agrees.

Passing the CISSP exam has turned out to be the gift that keeps on giving.

One more time: Governance exists to support the people accountable for creating value.

AI is now central to how organizations create value.

Govern it like you mean it, from the top, with a Human at the Helm.