There is a lot of confusion about what AI governance actually should do, why it is important, and ultimately how it should work in practice, given that many companies already have data and security. The subject is extensive, but I will try to cover the key ideas and practical guidelines in this post.

AI governance is, in practice, a set of procedures, practices, tests, and code specific for validating and continuously checking AI models’ output. It is the operational layer that makes sure AI and agentic systems behave as expected over time: not just at deployment, but day after day, dataset after dataset, release after release.

Done properly, AI governance means you have:

  • Defined policies and procedures for how models are trained, deployed, updated, and retired.

  • Testing work instructions and scripts to check corruption, drift, safety properties, and accuracy.

  • Registers and inventories to record which models exist, which tests were executed, who approved what, and when incidents happened and were closed.

  • Clear incident response plans specific to AI systems: how incidents are detected, triaged, investigated, communicated, and linked back to corrective and preventive actions.

In other words, AI governance is the “continuous validity check” on AI behavior, not a one-off compliance exercise.

The Three Types of Governance Every Tech Company Needs

In a tech or tech-enabled company, governance in practice falls into three major buckets:

  • Security governance

  • Data governance

  • AI governance (if AI or agentic architectures are used, which increasingly will be the case)

Let’s simplify: whatever tech or AI-enabled service you provide, your service will produce an output that may sometimes go wrong. A wrong output can, a priori, be related to any of the three governance domains above.

You need to know why the output went wrong. You cannot fix what you cannot explain.

To make this concrete, consider three simple scenarios:

  • Security governance: if a security breach occurred and a hacker corrupted the system, or a disgruntled employee used unauthorized data or wrong data in client outputs, that is security governance. You are looking at access control, incident response, logging, segregation of duties, and information security policy failures.

  • Data governance: if data quality, taxonomy, or standardization is messed up (ambiguity, mislabelling, inconsistency, etc.), so the generated report includes wrong information, that’s data governance. Here, the root cause is a better semantic layer, lineage, quality checks, metadata standards, retention rules, and how curated datasets are managed and changed.

  • AI governance: if the AI model output accuracy degraded over time unchecked, or the agentic architecture called the wrong tools, or the retrieval ranking stopped surfacing the right information, that’s AI governance. Now you are in the domain of risk assessments, TEVV (testing, evaluation, verification, validation), model management policies, and incident response plans tailored to AI behavior.

As you can see, when the output of a software solution goes wrong, you cannot exclude a priori one of the three. Only an investigation can root cause the “why” and hence indicate in which type of governance(s) the problem really resides.

The Intersection: AI vs Data vs Security Governance

You can imagine the governance landscape as a simple, layered flow:

  • Data Input → Data Tests & Governance (data quality, taxonomy, standards, lineage)

  • Cybersecurity Layers → Security Tests & Governance (access controls, breach handling, logging)

  • AI Output → AI Output Validity Checks – and then the key questions:

    • “Is Data correct?”

    • “Is AI correct?”

    • “Is Security performing?”

This captures the intersection:

  • AI solutions depend on data governance and security governance, but data and security solutions do not necessarily depend on AI.

  • When an AI solution misbehaves, the root cause may sit in AI governance, data governance, security governance—or a combination of them.

  • When a data-only system fails (e.g., wrong data in a BI report), that does not automatically indicate an AI governance problem, even if AI exists elsewhere in the organization. Same logic for pure security incidents.

So, there is a clear intersection: AI governance sits on top of and alongside data and security governance. An AI incident often “touches” all three domains during investigation, but the reverse is not symmetrical: a data governance issue is not automatically an AI governance issue, and a security incident is not automatically about AI.

For better or worse, having properly functioning AI (or agentic) solutions at scale implies you already need strong data and security governance in place. Or, if you are developing a new AI solution with new data, it almost always means spending more on data and security infrastructure, with the corresponding addition of governance around them.

Making Governance More Efficient: Integrated vs Separate Systems

There are ways to make governance more efficient than running three completely separate silos.

One approach is an “integrated management system” for AI + data: instead of having one governance track for data and another for AI, with different owners and roles, you harmonize them under a single management system manual. The benefits are obvious: fewer duplicate documents, easier cross-references, clearer combined roles (a steward can be both an AI and data steward).

However, this is not always advisable or practicable. It depends case by case:

  • If data and security governance are already mature and well structured, it can be more efficient to “plug” AI governance into them with clear boundaries, rather than re-architect everything.

  • If you are building AI capabilities from scratch, you might decide to design AI governance and data governance together from day one, but still keep security governance partly separate because of regulatory and operational constraints.

  • If your company scales a significant number of different AI solutions, then it may become unfeasible for the same individual professional to perform both AI and data steward (or other governance) roles.

  • If instead the company scales many AI solutions that are very similar, a combined data+AI steward role may still work: the role is the same, just more volume of work. You might need more governance people for capacity, but it should be unnecessary to split AI and data governance purely on principle.

In short, integration can save effort, but it must respect the different scopes and regulatory drivers of data, security, and AI.

Why AI Governance Is Hard to Standardize (Yet)

Unlike data governance, which can benefit from different products both for managing the data and the governance layers, at the moment it is very hard to rely on AI governance products, for two main reasons:

  • It is a relatively new field, and most workflows or AI solutions themselves are still in the “early adoption and experimentation” phase. The underlying technology is not mature and is moving too fast.

  • There is no “standard way” to assess AI risk across industries. Two companies in the same sector, depending on how they already manage security or data, may have totally different AI risk exposure. As a consequence, the practical testing they need, and therefore their AI governance system, will look quite different.

Some organizations choose risk-based AI governance, using impact × likelihood scoring and model-specific risk assessments. Others, especially in safety-related environments, use safety classification approaches, defining usage levels and technology classes with safety properties such as robustness, interpretability, and verifiability. The choice between these directions already introduces substantial variation.

Nevertheless, if in the near future agentic solutions mature enough to have a decent level of standardization—essentially meaning different companies structure their agentic or AI solutions in very similar ways—then full AI governance products will make more sense:

  • “Full package” agentic + governance products could become customizable, but largely off-the-shelf, so that a company could outsource their whole agentic system more effectively than building, maintaining, and governing everything in-house.

  • Vendors would be able to rely on relatively standard risk profiles and test suites, making scale and automation easier (through AI governance products).

If one has to bet, the first scenario—more standardized agentic structures plus integrated governance offerings—arguably makes more sense in the long term. But we are still too early to know; the diversity of current architectures and regulatory contexts is high.

I hope it helps.

PS: Where Current AI Governance Products Really Are

As a closing remark: yes, there are already AI governance products out there trying to solve some pieces of the overall governance problem. Some focus on the policy/legal side, others on monitoring and practical testing, others on documentation and audit trails.

However, they face two big limitations:

  • They suffer from the lack of standardization in AI architectures and risk assessment methods, so they often fit only narrow, well-defined use cases.

  • They typically do not solve the full governance lifecycle end-to-end; they tend to focus on specific segments (policy templates, or evaluation dashboards, etc.) rather than the whole chain from risk assessment to incident response and continuous improvement.

In that sense, many of these early products, in practice, do not solve enough of the AI governance problem to be truly viable for a large number of companies on their own. They are useful building blocks, but not replacements for an ad hoc, robust AI Management System that is integrated with your data and security governance.