Why Traditional GRC Tools Cannot Govern AI

Most regulated enterprises already have a Governance, Risk, and Compliance platform. ServiceNow, Archer, MetricStream, IBM OpenPages. One of these is almost certainly running somewhere in the organisation, capturing risks, managing controls, tracking compliance activities, and generating board reports.

The question being asked with increasing frequency is: can we use our existing GRC tool to manage AI governance? The answer is: partly, and not for the parts that matter most.

This article explains what GRC tools are designed to do, what assumptions they make about the assets they govern, and why those assumptions break down for AI agents, leaving three specific gaps that traditional GRC cannot close without AI-native tooling.

GRC tools are excellent at governing what you know about. The AI governance problem, in most enterprises, is that you do not know what you have. GRC cannot solve the discovery problem.

The Assumptions Behind GRC

Traditional GRC platforms were designed around a set of assumptions about the assets they govern. Understanding these assumptions is the starting point for understanding why they do not transfer cleanly to AI governance.

Known inventory

GRC tools assume that the assets being governed are known. The risk register covers known risks. The control framework covers known systems. The compliance programme covers known obligations. The entire GRC workflow (assess, control, monitor, report) starts from an inventory that someone has already compiled.

This assumption holds for traditional IT assets. Servers, applications, databases, SaaS tools procured through formal channels. These appear in IT asset registers and can be imported into GRC platforms. The GRC tool governs what is in the register.

For AI agents in 2026, the inventory assumption breaks down. AI agents are being deployed at a speed and through channels (individual user OAuth grants, embedded SaaS features, low-code automations) that outpace the formal inventory processes GRC tools depend on. The GRC tool can only govern what is in its inventory. If the inventory is materially incomplete, the governance is materially incomplete.

Stable assets

GRC tools assume that the assets being governed are relatively stable between review cycles. A risk assessed today will be substantially the same risk in three months. A control implemented today will be substantially the same control in six months. The GRC workflow is designed around periodic review of a stable landscape.

AI agents are not stable assets. Their capabilities change with model updates from providers. Their data access scope changes when users add new integrations or when permission inheritance changes. Their risk profile changes when they are used in new contexts or when their configuration is modified. A GRC review cycle designed for quarterly or annual cadences will consistently miss changes that occur between cycles.

Human-mediated operation

GRC tools assume that the activities being governed are carried out by humans, with humans making decisions and generating the evidence of their activity. Control testing assumes a human followed a procedure. Monitoring assumes a human reviewed something. The evidence the GRC tool captures is typically evidence of human activity.

AI agents operate autonomously. That is their purpose. The evidence of their activity is not human-generated. It is system-generated: API call logs, OAuth grant activity records, output artefacts. Capturing and interpreting this evidence requires a different approach than GRC control testing was designed to support.

How AI Breaks GRC Assumptions: The Three Gaps

Gap 1: The inventory gap

As described above, GRC tools depend on an inventory they did not compile. For AI governance, the inventory problem is the hardest problem. And it is one that GRC platforms, by design, cannot solve. They can manage an inventory once it exists. They cannot discover what is running in the environment.

Discovering AI agents requires querying workspace admin APIs (Google Workspace Admin SDK, Microsoft Graph API, Salesforce connected apps, OpenAI workspace admin interfaces, AWS IAM for Bedrock agent roles). This is a programmatic discovery function, not a risk management function. GRC tools do not do it.

The practical consequence is that AI governance programmes built on GRC platforms alone will consistently govern a subset of the actual AI agent population, the approved subset. The unapproved subset, which may represent the majority of actual risk, is invisible to the GRC tool because it was never added to the inventory.

Further reading: The AI Inventory Crisis Nobody Is Talking About is the pillar piece on this discovery problem.

Gap 2: The cross-platform evidence gap

GRC tools aggregate risk information from across the organisation. They do not aggregate operational evidence from across platforms. The distinction matters because the evidence Article 26 and the ICO require is not risk register data, it is operational evidence of what AI agents are doing.

An AI agent operating across Google Workspace, Microsoft 365, and Salesforce simultaneously creates an evidence challenge that no single platform's logs answer, and that GRC tools, which consume risk data rather than platform operational data, cannot aggregate. The cross-platform finding (agent reads customer data on Google, sends external communications via Microsoft, has no human-in-the-loop approval) is not visible in any GRC platform because no GRC platform is querying the relevant API surfaces.

This is not a limitation of any specific GRC product. It is a structural limitation of what GRC platforms are designed to do. They govern risk. They do not generate operational evidence of AI system behaviour across the platforms where that behaviour occurs.

Gap 3: The cryptographic evidence gap

The evidence that Article 26 requires (verifiable, reproducible, signed) is not a category of evidence that GRC platforms produce. GRC platforms generate risk reports, control testing records, audit logs of governance activities, compliance dashboards. These are governance records. They are not cryptographically signed evidence artefacts that can be verified as unaltered under examination.

The distinction matters because a supervisor asking for Article 26 evidence is not asking for a risk report. They are asking for a verifiable record of what the AI system was doing, when, and what oversight was in place, signed in a way that confirms the record has not been altered since generation. GRC platforms do not produce this. They were not designed to.

What GRC Tools Are Good For in AI Governance

The argument above is not that GRC tools have no role in AI governance. They have a significant role, in the parts of AI governance that fit their design:

• Risk register management. Recording identified AI risks, their likelihood and impact, and the controls in place to address them.
• Control framework documentation. Maintaining the governance framework, ownership assignments, and control testing records.
• Policy and procedure management. Documenting AI governance policies, approval workflows, and exception management processes.
• Reporting and board-level visibility. Aggregating AI governance status into board and executive reporting.
• Audit and compliance tracking. Recording compliance activities, evidence collection requests, and regulatory correspondence.

These are valuable functions. They are also functions that depend on the underlying data being accurate. If the AI agent inventory feeding the risk register is incomplete, the risk register is incomplete. If the evidence feeding the compliance tracking is unverified, the compliance tracking is unverified. GRC tools amplify the quality of the data they receive. They do not compensate for data that is missing or unverified.

The Infrastructure Gap: What AI-Native Tooling Provides

AI-native governance tooling addresses the three gaps that GRC cannot close:

• Programmatic discovery. Querying workspace admin APIs to enumerate what is actually running, not just what was approved. This closes the inventory gap.
• Cross-platform operational evidence. Stitching together what AI agents are doing across platforms to produce unified evidence of agent behaviour. This closes the cross-platform evidence gap.
• Cryptographic signing. Generating evidence packs signed at generation, verifiable under examination. This closes the cryptographic evidence gap.

The right architecture for AI governance in a regulated firm is AI-native tooling providing discovery, cross-platform evidence, and signed artefacts, feeding a GRC platform that manages the risk framework, control records, and board reporting. The two are complementary, not competing.

How AETHER Pulse Fills the GRC Gaps

AETHER Pulse is designed specifically for the functions that GRC platforms cannot perform. It discovers AI agents programmatically across seven platforms, classifies them using a five-dimensional risk framework, detects eight cross-platform toxic-combination patterns through deterministic logic, and generates HMAC-SHA256 signed evidence packs at configurable cadences.

The outputs (inventory data, risk classifications, findings, and signed evidence) can be integrated with GRC platforms to provide the underlying data quality that makes GRC-based AI governance programmes accurate and defensible. AETHER provides the discovery and evidence infrastructure. GRC provides the risk management and reporting framework.

Published methodology: aetherpulse.app/methodology

Frequently Asked Questions

Can we integrate AETHER Pulse with our existing GRC platform?

AETHER Pulse's findings, inventory data, and risk classifications are designed to feed into downstream governance processes, including GRC platforms. The specific integration mechanism depends on the GRC platform in use. Contact the AETHER team to discuss integration options for your environment.

If we have a mature GRC programme, what specifically do we need to add for AI governance?

The three specific additions are: (1) programmatic AI agent discovery to close the inventory gap, (2) cross-platform evidence generation covering agent behaviour across all platforms the agents operate on, and (3) cryptographically signed evidence artefacts to satisfy the Article 26 and ICO evidence obligation. These are additive to a GRC programme, not replacements for it.

What about AI governance features being added to GRC platforms?

Several GRC platform vendors are adding AI governance modules. These typically address the risk register and control framework components well. They do not, in most cases, address programmatic discovery or cryptographic evidence signing, because these require API-level integration with workspace admin surfaces that is not part of the GRC platform's existing architecture. Evaluate specific vendor claims against the three gap criteria described in this article.

See How AI Governance Infrastructure Differs from GRC →