Key takeaways
- A governance risk and compliance tool is a single system of record for policies, risks, controls, obligations and the evidence that ties them together. Its value is the data model, not the dashboard.
- What AI changed is the scope of that model. The AI systems a company builds or buys are now a regulated asset class in their own right, not just another process to control.
- Article 17 of the EU AI Act lists twelve elements a provider’s quality management system must document. Read as a procurement checklist, that list describes what a GRC tool has to hold.
- The Digital Omnibus pushed the Annex III high-risk deadline to 2 December 2027. The deadline moved. The time needed to build a documented management system and a credible evidence trail did not.
- Judge tooling on whether its output would survive a notified body or a market surveillance authority, not on how many modules it ships.
What a governance risk and compliance tool actually does
A governance risk and compliance tool is a single system of record that holds an organisation’s policies, the risks it has accepted or refused, the controls that treat those risks, the obligations those controls answer to, and the evidence that each control actually operated. The three letters describe three disciplines that grew up in different departments. The tool is what forces them into one structure. That structure is the product. Governance without risk data is a set of documents nobody reads. Risk without control mapping is a register that never changes anything. Compliance without evidence is an assertion. When the three sit in separate spreadsheets, every audit becomes a reconciliation exercise, and every regulatory question becomes a project. When they share one data model, a question like “which controls treat this risk, who owns them, when were they last tested, and where is the proof” has an answer that takes minutes rather than weeks. This is also why the category resists simple definition. Two products can both be described as a GRC platform and share almost no functionality, because one is built around policy distribution and attestation while another is built around control testing and audit workflow. The useful question is never “is this a GRC tool” but “what does its data model make cheap, and what does it make expensive”.
Why the data model matters more than the dashboard
Buyers are shown dashboards during demonstrations, because dashboards demonstrate well. Dashboards are downstream. A heat map is trivial to produce once risks, controls and test results are related correctly, and impossible to produce honestly when they are not. The questions worth asking in an evaluation are structural. Can one control satisfy several frameworks at once, or does the tool force a duplicate control per framework? Can an obligation be traced to the specific evidence artefact that discharges it? Can a risk be attached to an asset rather than only to a business process? Those answers determine whether the tool reduces work or simply relocates it. Our guide to AI governance covers the operating model this structure has to support.
The OCEG capability model, and where a tool actually sits
Most vendor explainers of this category eventually reach the OCEG GRC Capability Model, published as the Red Book. It organises the discipline into four components: Learn, Align, Perform and Review, under the heading of Principled Performance. Learn is understanding context, culture and stakeholders. Align is connecting objectives, strategy and risk appetite. Perform is executing controls and operations. Review is measuring whether any of it worked. The model is available from OCEG. The honest reading, and the one most explainers avoid, is that software instruments Perform and Review well and cannot manufacture Align at all. A tool can record a risk appetite statement. It cannot tell you whether the organisation genuinely holds that appetite, or whether senior management would override it under commercial pressure. Buying a governance risk and compliance tool before deciding what the organisation is actually willing to accept produces a very well-documented version of an unresolved argument. That distinction matters more with AI than it did with financial controls, because AI decisions are made much further down the organisation. A product manager can put a model into a customer-facing workflow in an afternoon. If Align has not happened, the tool records the consequences rather than shaping them. It also explains why the category boundary is blurry in practice. A governance risk and compliance tool is one component of a wider control stack that includes identity, logging, model registries and security monitoring, a split we set out in compliance platform versus the stack around it.
What AI changes: the system becomes the regulated asset
Until recently the scope of a GRC programme was processes, vendors, controls and financial reporting. AI adds something the model was not built for: an asset that is probabilistic rather than deterministic, that degrades quietly as the world moves away from its training data, and that is regulated per system rather than per process. Three consequences follow. First, inventory becomes the binding constraint. You cannot classify, control or evidence a system you do not know exists, and unsanctioned adoption is the normal state rather than the exception. Anything you cannot see is outside every control you have written, which is the practical problem behind shadow AI. Second, classification becomes a legal act rather than an internal convenience. Under the EU AI Act, whether a system is prohibited, high-risk, subject only to transparency duties, or effectively unregulated determines which obligations attach. That classification has to be recorded, justified and revisited when the system changes. Third, the risk register stops being periodic. A control tested annually is a reasonable answer for a procurement process. It is a poor answer for a model whose behaviour can shift after a vendor update nobody told you about. The lifecycle view in our AI risk management guide sets out what continuous looks like in practice.
From AI-powered GRC to GRC over AI
Almost every product in this market now advertises AI features: summarising policies, drafting control descriptions, suggesting risk ratings, triaging questionnaires. Some of it genuinely removes work. It is also a different subject entirely from what regulators are asking about. AI-powered GRC means the vendor uses a model to make their software faster. GRC over AI means your organisation can demonstrate control over the AI systems it deploys. A tool can be excellent at the first and useless at the second. The preposition is the whole distinction, and it is worth being blunt in vendor conversations about which one is being demonstrated. There is a second-order point. If a model helps produce your control evidence, that model is itself in scope. Evidence generated by an unvalidated system is not stronger than the system that produced it.
The EU AI Act writes the functional specification
The most useful thing about the EU AI Act, for anyone evaluating tooling, is that it is unusually specific about what has to exist on paper. Articles 8 to 15 set the requirements for high-risk systems: a risk management system (Article 9), data and data governance (Article 10), technical documentation (Article 11), record-keeping (Article 12), transparency and user information (Article 13), human oversight (Article 14), and accuracy, robustness and cybersecurity (Article 15). Article 16 then lists what a provider must do: comply with those requirements, identify itself on the system, operate a quality management system, keep documentation, keep automatically generated logs, undergo conformity assessment, draw up an EU declaration of conformity, affix CE marking, register the system, take corrective action, cooperate with national competent authorities, and meet accessibility requirements. Article 17 is where a procurement checklist appears almost verbatim. A provider’s quality management system must be documented and must include at least: a strategy for regulatory compliance including conformity assessment procedures; techniques for design, development and quality control; examination and testing procedures; technical specifications; data management systems; a risk management system; a post-market monitoring system under Article 72; procedures for reporting serious incidents under Article 73; a process for handling communications with authorities; a system for record-keeping; resource management; and an accountability framework setting out management and staff responsibilities. Twelve elements, each of which has to live somewhere and be producible on request. That is a specification for a system of record, whether or not anyone calls it one. Article 9 adds the shape of the risk work. Risk management is a continuous iterative process across the whole lifecycle: identify and analyse risks to health, safety and fundamental rights, evaluate risks arising in use, evaluate risks surfaced by post-market monitoring data, and adopt measures accordingly. The goals are set out too: eliminate or reduce risk as far as technically feasible, mitigate what cannot be eliminated, supply transparency information, and train deployers where appropriate. Risk itself is defined as the combination of the probability of harm and its severity. One nuance defuses the usual objection that this is only for large organisations. Article 17(2) requires the quality management system to be proportionate to the size of the provider’s organisation, and Recital 146 explicitly contemplates a simplified version for microenterprises. Proportionality applies to how much process, not to whether the obligations exist. Our EU AI Act resources go through the classification questions in detail.
The deadline moved, the build time did not
Timelines shifted in 2026. The Digital Omnibus on AI deferred obligations for standalone Annex III high-risk systems to 2 December 2027, and for AI embedded in products already covered by EU product-safety law to 2 August 2028. Several dates did not move: Article 50 transparency and content-labelling duties applied from 2 August 2026, general-purpose AI model obligations from 2 August 2025, and the Article 5 prohibitions from 2 February 2025. The analysis from the Cloud Security Alliance and from Gibson Dunn agree on the dates. Reading a deferral as breathing room is a mistake for one practical reason. Post-market monitoring and record-keeping are historical obligations. When an authority asks in 2028 how a system behaved, the answer is assembled from logs that had to be captured while the system was running. An organisation that starts collecting in late 2027 has a compliant management system and no history to put in it. The deadline is when you must be able to show the trail, which means the collection decision comes considerably earlier.
ISO 42001 and NIST AI RMF: the control layer
Regulation says what must be true. It does not hand you a control set. Two references fill that gap, and any serious governance risk and compliance tool needs to carry both without duplicating work. ISO/IEC 42001 specifies an AI management system, structured like other management-system standards, and it is certifiable. That matters commercially as well as internally, because a certificate is portable evidence in a procurement conversation. It maps well onto the Article 17 elements, which is why so many providers use it as the backbone of their quality management system. We cover the standard in ISO 42001 explained. The NIST AI Risk Management Framework is voluntary and differently shaped: four functions, Govern, Map, Measure and Manage, that give teams a vocabulary for talking about AI risk without arguing about terminology first. It is strongest as an analytical scaffold and weakest as an audit artefact, which is the opposite of a certifiable standard. Our NIST AI RMF guide walks through the four functions. The tooling consequence is concrete. Most organisations end up answering to a regulation, a certifiable standard and a voluntary framework at the same time, often alongside existing security certifications. A tool that models a control as belonging to one framework forces the same evidence to be gathered several times. A tool that models a control once and maps it to many obligations turns a multiplication into an addition. This single question separates tools that scale across frameworks from tools that quietly triple the workload.
A capability checklist for AI-era tooling
The following is what to test when assessing a governance risk and compliance tool, with the obligation each capability answers to. It is deliberately about capabilities rather than modules, because module names differ across products while obligations do not.
| Capability | What it must actually do | Obligation anchor |
|---|---|---|
| AI system inventory | Register every system and material component, including bought and embedded ones, with an owner and a lifecycle state | Art. 16, Art. 49 registration |
| Risk classification | Record the classification, the reasoning behind it, and force re-evaluation when the system changes | Art. 6, Annex III |
| Multi-framework control library | Map one control to several obligations at once, without duplicate records | Art. 17, ISO/IEC 42001 |
| Evidence capture | Attach a dated, versioned artefact to the control and the obligation it discharges | Art. 17, Art. 18 |
| Automatic logging | Retain machine-generated logs over the retention period, not just human sign-offs | Art. 12, Art. 19 |
| Incident workflow | Detect, triage and report serious incidents against a regulatory clock | Art. 73 |
| Post-market monitoring | Collect performance and behaviour data continuously and feed it back into the risk process | Art. 9(2), Art. 72 |
| Supply chain records | Hold model provenance, vendor terms, version history and change notifications | Art. 25, Art. 16 |
| Roles and accountability | Name responsible people per system and per control, with escalation paths | Art. 17 accountability framework |
Two rows carry most of the weight in practice. Automatic logging is where tools designed for process compliance tend to fail, because they were built for periodic human attestation rather than for machine-generated event streams. Supply chain records are where most organisations discover they cannot answer basic questions about a model they did not train, which is the same gap covered in our work on auditability.
Evidence that survives an audit
Most evidence problems are not gaps. They are artefacts that exist but do not hold up when examined, and there are four recurring failure modes. Our guide to auditing AI systems covers what assessors actually look for. Timing is the first. A screenshot proves a state existed when someone took it, not that a control operated throughout a period. Attribution is the second: an export with no author, no system version and no timestamp cannot be tied to anything. Mutability is the third, because a spreadsheet that anyone can edit after the fact proves considerably less than its contents suggest. Traceability is the fourth and most common: an artefact that cannot be connected back to the specific obligation it discharges leaves an assessor to guess, and assessors do not guess in your favour. COSO’s work on internal control over generative AI is useful here, and it introduces a distinction worth borrowing. When management relies on an AI output as part of the evidence supporting a control, the standard applied to that evidence rises. Re-performing a check yourself is not the same as accepting a model’s conclusion, and the documentation burden differs accordingly: the prompt, the configuration and the model version all become part of the record. The same publication makes a related point that tends to surprise teams, which is that models, configurations, fine-tuning artefacts, embeddings and retrieval indexes should be treated as configuration items under access control and change management, rather than as content. The practical test for any governance risk and compliance tool is simple to run. Pick one control, follow it to the obligation it answers, and then to the artefact that proves it operated last quarter. If that path takes more than a couple of clicks, or if any step relies on somebody’s memory, the tool is a filing cabinet rather than a system of record.
Buy, extend, or both
There are three honest options for acquiring a governance risk and compliance tool that covers AI, and the right one depends on what already exists. Extending an incumbent platform makes sense when a mature programme is already running, the vendor has a credible AI module rather than a renamed risk register, and the existing control library is genuinely reusable. The advantage is one system and one set of habits. The risk is an AI module that models AI systems as ordinary assets, which fails on classification, logging and model provenance. A dedicated AI governance system makes sense when AI is central to the product, when obligations are specific enough that generic control structures do not fit, or when nothing mature exists to extend. The advantage is a data model built for the problem. The cost is a second system, and integration work nobody enjoys. The hybrid is the most common outcome and the least discussed. The incumbent platform stays the enterprise register of record, and a specialist system handles AI-specific obligations, pushing summarised state upward. This works when the boundary is decided deliberately, and produces two competing registers when it is not. Whichever path you take, decide the boundary before the procurement conversation rather than during it. Our AI compliance software page sets out how we approach the specialist side of that split.
FAQ
What is an example of a governance risk and compliance tool? The category covers several distinct product shapes. Enterprise GRC platforms centralise risk registers, control testing and audit workflow for large regulated organisations. Compliance automation tools focus on continuous evidence collection against security certifications. Policy management systems handle authoring, distribution and attestation. Dedicated AI governance systems model AI systems, their classification and their regulatory obligations. Most organisations end up running more than one, so the useful comparison is which system holds the register of record and which ones feed it. Is GRC the same as IT audit? No, though they are often confused because they look at the same controls. GRC is the ongoing operating discipline: setting policy, maintaining the risk register, running controls and collecting evidence continuously. IT audit is a periodic independent assessment of whether that discipline works. A well-run GRC programme makes audits cheaper because the evidence already exists in a structured form. Audit findings then feed back into the risk register. The relationship is cyclical, but the roles are deliberately separate, and independence is the reason. Is Jira a GRC tool? Not on its own. Jira tracks work, and a great deal of GRC involves work: remediation tasks, control testing, evidence requests. Many teams start by running compliance activity through it. What it lacks is the underlying data model, meaning first-class objects for risks, controls, obligations and evidence with the relationships between them. Issues with labels approximate this until an assessor asks which controls treat a given risk and where the proof sits. Jira works well alongside a system of record, and poorly as one. Does GRC require coding? Generally not for the day-to-day work. Modern tools are configured through interfaces, and the demanding parts of the job are analytical rather than technical: classifying systems correctly, writing controls that are actually testable, deciding what counts as sufficient evidence. Coding becomes relevant at the edges, mainly integrations that pull evidence automatically from cloud platforms, model registries or logging systems. That automation is what makes continuous monitoring feasible at scale, so some technical capacity on the team is a practical advantage even where it is not a requirement. Which is better, SOC or GRC? They answer different questions and are not alternatives. A security operations centre detects and responds to threats in close to real time. GRC establishes what should be controlled, why, and whether the controls worked over a period. A SOC generates evidence and incidents that a GRC programme consumes; a GRC programme sets the policies and risk appetite a SOC operates within. Organisations that treat them as competing budget lines usually end up with detection that nobody has mapped to an obligation, or obligations that nothing actually monitors. Do GRC tools cover the EU AI Act? Increasingly they claim to, and the claims deserve testing. Ask to see an AI system inventory with per-system risk classification and recorded reasoning, evidence linked to specific articles rather than to a generic control family, retained machine-generated logs rather than human attestations, and a serious-incident workflow that runs against a regulatory clock. Many products satisfy the first and struggle with the rest. A vendor claiming coverage should be able to walk one system from registration through to a document pack an assessor could read.
Conclusion
The category did not change its name. It changed its scope. A governance risk and compliance tool used to be judged on how well it handled processes, vendors and financial controls, and it is now judged on whether it can also treat an AI system as a first-class governed object, with a classification, a control set, a log trail and an owner. The regulation has made the requirements unusually legible. Article 17 lists what has to be documented, Article 12 says the logs must exist, Article 72 says monitoring continues after deployment, and the deferred deadlines mean the evidence trail has to start well before the date anyone is measuring against. Evaluate a governance risk and compliance tool accordingly: not on module count, but on whether the trail from obligation to control to dated artefact holds together when someone with authority follows it. If you are working through that evaluation for AI systems specifically, our AI compliance platform is built around the article-level obligations described above.