Durable AI governance depends on visibility, ownership and process

At a glance

What this is: Kovrr's report says durable AI governance starts with visibility, documented ownership, and operating controls across both data and model behaviour.

Why it matters: This matters because identity and access teams increasingly have to govern AI systems through the same accountability, approval, and lifecycle controls used for sensitive data and privileged access.

By the numbers:

• Only 36% of organisations have visibility into where their data is processed, trained, or inferred.
• 57% of employees have used AI tools for work without informing their manager.

Context

AI governance is the combination of policy, process, accountability, and technical controls that determines whether AI use can be explained and defended. The core gap in this article is not whether organisations have written policies, but whether they can actually discover AI systems, understand the data those systems touch, and assign ownership that survives day-to-day operations.

The article treats AI governance as two linked problems. Data-centric governance covers the information feeding models, while system-centric governance covers how those models behave once deployed. That distinction matters for IAM, NHI, and broader security teams because AI programmes now create new access decisions, new approval paths, and new ownership questions that cannot be handled through policy alone.

Kovrr's starting position is typical of the market: most organisations have some policy language, but far less operational control than they assume.

Key questions

Q: What fails when AI governance stops at policy and audit documentation?

A: Policy-only governance can prove that a model was assessed, but it cannot prevent unsafe behaviour once the model is live. The practical failure is that drift, hallucinations, and toxic outputs continue after approval, so the organisation has records without real control. That leaves audit readiness separated from operational safety.

Q: Why does AI risk increase when ownership is shared but undocumented?

A: Shared ownership without documented mandates creates gaps, duplicates, and confusion about who is responsible for approvals, quality, and oversight. In AI programmes, that means teams can assume another function is handling the hard part, while exposure accumulates in the spaces between them. Accountability only works when decision rights are explicit and auditable.

Q: What are the signs that AI governance is not operational yet?

A: Common signs include unclear ownership, undocumented access paths, missing logs for tool use, and no defined offboarding process for AI permissions. If teams can describe the governance policy but cannot show the control evidence, the programme is still conceptual rather than enforceable.

Q: Should organisations treat data governance and model governance as the same control problem?

A: No. Data governance answers what information AI systems can touch and how it is classified, while model governance answers what the system is permitted to do and how its behaviour is monitored. Treating them separately avoids blind spots at the seam between data quality, authorisation, and model risk.

Technical breakdown

Why AI governance needs both data-centric and system-centric controls

AI governance breaks into two layers because the risks are different. Data-centric governance focuses on what goes into the model, including training data, retrieval data, and inference data, along with classification, authorisation, lineage, and retention. System-centric governance focuses on what the model is allowed to do and how its behaviour is monitored over time. A programme that governs only the data layer can still miss unsafe, biased, or manipulated model behaviour. A programme that governs only the model layer can still ingest poor or sensitive data that poisons output quality and accountability.

Practical implication: Treat data access controls and model-behaviour controls as separate control families, then link them through one governance process.

How AI inventories become the control point for governance

An AI inventory is more than an asset list. It is the living register of every AI system in operation, the vendors behind them, the models they use, the business functions they serve, and the data sources they touch. Without that inventory, organisations cannot tell what is sanctioned, what is shadow AI, or which systems were blocked but remain present in practice. For identity and security teams, the inventory becomes the intake point for approval, review, and enforcement because it turns AI use into something that can be governed like any other enterprise asset.

Practical implication: Build and maintain a live AI inventory before trying to enforce approval, risk scoring, or compliance review.

Why undocumented accountability fails even when roles exist

The article's governance gap is that roles without documented mandates do not create accountability. Teams often assume that because a function exists, someone owns data quality, access approval, or model oversight. In practice, different teams can each believe another group is responsible, and the result is duplicated work or no work at all. That is especially relevant for AI because governance spans business, data, security, and GRC domains, so ownership has to be explicit, durable, and traceable. A named owner without authority is only a label.

Practical implication: Document decision rights for AI systems and data sources so ownership is enforceable, not implied.

NHI Mgmt Group analysis

AI governance debt is the right way to describe most current programmes. The article shows that organisations are accumulating AI usage faster than they are converting that usage into governed inventory, accountable ownership, and monitored behaviour. That gap is not a documentation problem alone. It is a control problem that grows every time a new tool, embedded capability, or shadow deployment bypasses the intake path.

Data-centric and system-centric governance must be treated as distinct control planes. Many programmes collapse them into one narrative, but the risk profile changes depending on whether the issue is data lineage or model behaviour. For security and identity teams, the practical takeaway is that access decisions, data classification, and model monitoring need coordinated ownership rather than a single policy statement.

Undocumented accountability is the specific failure mode this article exposes. The article makes clear that shared ownership across the C-suite can become no accountability at all when mandates are not written down and enforced. That is a governance design flaw, not a communications issue, and it is one that identity programmes will recognise from failed lifecycle and access ownership models.

AI governance is increasingly an identity governance problem in disguise. Once AI systems begin touching corporate data, using vendor capabilities inside SaaS tools, and generating delegated access paths, the question becomes who is authorised to decide, approve, and revoke. That pushes AI governance into the same operational territory as IAM, PAM, and NHI lifecycle control, where traceability matters more than policy intent.

Visibility is the named concept that separates defensible governance from checkbox compliance. The article repeatedly returns to discovery, inventory, and coverage assessment because governance cannot mature without knowing what exists. For practitioners, the implication is straightforward: if you cannot map the AI estate and its data dependencies, you cannot claim control over risk, only hope for it.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Agentic AI Identity Risk Board Briefing

What this signals

AI governance debt: organisations are not failing because they lack policy language, but because they are allowing the AI footprint to outgrow the controls that should govern it. That creates a familiar identity security pattern: the estate becomes too large to review manually, so discovery and ownership have to move earlier in the lifecycle.

The governance model that will hold up is the one that treats intake, inventory, and decision rights as operational controls rather than paperwork. For IAM and GRC teams, that means AI use has to be governed with the same discipline applied to sensitive access requests, not with annual policy refreshes.

Decision authority is already drifting toward the teams closest to platform and infrastructure, which makes documented mandates and shared control design more important, not less. When AI services are embedded across business units, the programme succeeds only if ownership is explicit enough to survive local adoption.

For practitioners

• Implement a live AI inventory Track sanctioned, shadow, and blocked AI systems in one registry, and update it as tools are adopted, embedded, or retired.
• Document ownership and decision rights Assign named business and technical owners for each AI system, then record who approves data use, model use, and exceptions.
• Separate data and system control reviews Review data lineage, authorisation, and classification separately from model behaviour, policy adherence, and monitoring thresholds.
• Tie AI intake to security and GRC review Require new AI tools and embedded capabilities to pass a documented intake process before they can access sensitive data or production workflows.
• Map AI risk to operational reporting Translate inventory findings into a living risk register so residual exposure, mitigation status, and ownership stay visible to governance teams.

Key takeaways

• AI governance breaks down when policy exists without discovery, ownership, and continuous control.
• The article's central evidence is that most organisations still lack visibility into the data and AI estate they are expected to govern.
• Practitioners should treat inventory, approval, and accountability as the operating system for AI governance, not as after-the-fact documentation.

Key terms

• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
• Data-Centric AI Governance: Data-Centric AI Governance is the practice of controlling AI systems by governing the data they use, produce, and expose. It focuses on data quality, lineage, access, retention, classification, and permitted use across training, prompting, retrieval, and output. This approach treats data as the primary control surface for AI risk, compliance, and accountability.
• System-Centric AI Governance: System-centric AI governance governs what an AI system is allowed to do, how its outputs are monitored, and when its behaviour drifts outside acceptable bounds. It is concerned with model behaviour, not just input data, and becomes essential once AI systems operate in production.
• AI Inventory: An AI inventory is a governed record of all AI-related assets, enriched with owner, purpose, access, and risk context. It turns discovery into something security, compliance, and IAM teams can use to make approval, review, and revocation decisions.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners connect governance design to the controls that make programmes defensible.