The compliance officer at a healthcare provider opens the GRC suite for the annual control round. The control "AI tools are only used after assessment by the privacy officer" is marked implemented. Attached as evidence: last year's policy document and the attendance list of the training. Everything is in order, and still 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 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) keeps four things together. The policies, with versions, owners and approvals. The risk register, with an owner, a score and the measures per risk. The controls, per framework such as ISO 27001, the GDPR or the NIS2 transposition, with their status, their test frequency and the evidence uploaded alongside. 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 a GRC suite fine.
What the suite lacks is a view of reality of its own. 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 delivers 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 in the suite with what exists, rather than with what was requested. Why the second list is always shorter than the first is in what is shadow AI.
The second is the moment of work. 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 condition or the alternative attached. That is the difference between a policy that exists and a policy that is followed.
From those two follow the figures that make a control say something: what share of AI use runs through allowed tools, how many tools with real use have no decision, and how often someone chose the alternative after a notice. Counts per tool, without a user id, so that the measurement itself creates no processing of personal data that would need to go into the suite's own register.
How do they relate?
| 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 |
| Moment | Planning cycle, control round, audit | The moment 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 happens and whether it matches the agreement |
| Role in an audit | The system of record | The source of the figures held in that record |
The rows complement each other in one direction: the observation feeds the record. The other way round does not work. A GRC suite cannot bring the agreement to the moment of work, 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 implemented, with the policy and the attendance list as evidence. Copilot is the allowed tool. Then the organisation looks for the first time at which AI services are opened from the browser.
Next to Copilot, ChatGPT and Perplexity turn out to be in use, plus three specialised tools: a transcription tool for meetings, a translation tool and a service that summarises reports. Two of the three appear in no register. Nobody did anything wrong, and the control was not wrong either. The evidence was just thin: a document and an attendance list say what was agreed, not what happens.
What the compliance officer does next is describe the control differently. Not "policy exists and training was given", but "tools with use and 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 lags the moment the next tool shows up. What else can go wrong with evidence that comes only from a dashboard is in a dashboard is not evidence.
