The compliance officer at a healthcare provider opens the GRC suite for the annual control testing. The control "AI tools are only used after assessment by the privacy officer" is marked as implemented. Attached as evidence: last year's policy document and the attendance list from the training session. Everything is in order, yet she cannot answer the auditor's question: which AI tools were actually used this year?
That is not a shortcoming of the GRC suite. The suite only knows what was put into it.
GRC software manages what an organisation has agreed: policies, risks, controls and the evidence that goes with them. Software for the governance of AI use supplies what the suite cannot know by itself: which AI tools are actually opened, what was decided about them and whether that decision holds up during the working day. One is the system of record, the other the source of observation. Mix them up and you get a control that is green on paper and says nothing in practice.
What does GRC software do?
A GRC suite (governance, risk and compliance) brings four things together. The policies, with versions, owners and approvals. The risk register, with an owner, a score and the measures for each risk. The controls for each framework, such as ISO 27001, the GDPR or the NIS2 transposition, with their status, their test frequency and the evidence uploaded alongside them. And the audits themselves, with findings and follow-up.
The suite is good at that, and for many organisations it is rightly where an auditor starts. One register for all frameworks, one workflow for all controls, one place where the evidence lives. It works for AI as well as it does for access management: an AI register with owner, purpose, data, risk and decision fits comfortably in a GRC suite.
What the suite lacks is its own view of what actually happens. Every status was set by a person, every piece of evidence uploaded by a person. For a control like "backups are tested daily" that is no problem, because the test report comes out of the backup system. For "AI tools are only used after assessment" there is no system that produces the report, unless you set one up.
What does governance of AI use supply?
Two things a GRC suite cannot produce on its own. The first is the observation: which AI tools are opened in the organisation, how often and which of them still have no decision. That is what you need to fill the register with what actually exists, rather than with what someone requested. Our article on shadow AI explains why the list of requested tools is always shorter than the list of tools actually in use.
The second is the moment of use. A decision in a GRC suite is visible to the compliance officer and the auditor. An employee opening a new summarising tool at ten in the morning does not see that decision, because he is not in the suite. Governance of AI use brings the decision to the browser, at the moment the tool is opened, with the conditions or the alternative alongside. That is the difference between a policy that exists and a policy that is followed.
Those two produce the figures that give a control real meaning: what share of AI use goes through allowed tools, how many tools in real use have no decision and how often someone chose the alternative after a notice. These are counts per tool, without a user ID, so the measurement itself says as little as possible about people.
How do the two fit together?
| GRC software | Governance of AI use | |
|---|---|---|
| What it manages | Policies, risks, controls, evidence, audits | Which AI tools are in use and the decision per tool |
| Where the content comes from | Entered by people | Observed in the browser, aggregated |
| Who works with it | Compliance, risk, internal audit, control owners | Admins and the privacy officer; the employee sees the decision |
| When it is used | Planning cycle, control testing, audit | When someone opens a tool |
| Scope | Every framework the organisation works under | One subject: everyday AI use |
| What it says about AI use | What was agreed and who confirmed it | What actually happens and whether it matches what was agreed |
| Role in an audit | The system of record | The source of the figures held in that record |
The two complement each other in one direction: the observation feeds the record. It does not work the other way round. A GRC suite cannot put the decision in front of someone at the moment they open a tool, and software for AI use does not manage your ISO controls.
What does this look like in practice?
Back to the healthcare provider. The control is marked as implemented, with the policy and the attendance list as evidence. Copilot is the allowed tool. Then, for the first time, the organisation looks at which AI services are being opened in the browser.
It turns out that ChatGPT and Perplexity are in use alongside Copilot, plus three specialised tools: a transcription tool for meetings, a translation tool and a service that summarises reports. Two of those three are not in any register. Nobody did anything wrong, and the control was not wrong either. The evidence was simply thin: a document and an attendance list show what was agreed, not what happens.
The compliance officer then rewrites the control description. Not "policy exists and training was given", but "tools in use without a decision: two, last quarter five", with the source attached. That is a control an auditor can test, and a register that no longer falls behind as soon as the next tool appears. What else can go wrong when your evidence comes only from a dashboard is covered in our article on dashboards as evidence.
