Here, AI is a governance question before it is a feature
Every GRC platform now says it is AI-powered. If you are a government entity, a bank or anyone holding citizen data, that claim raises questions before it raises interest — where does the data go, does it leave the Kingdom, and can you explain an AI-assisted decision to an assessor.
Eight questions to ask any GRC vendor about AI
From the compliance programmes we build and run in Saudi Arabia: the AI conversation in a vendor assessment goes badly when the buyer asks what the feature does and well when they ask what happens to their data. These are the questions we would ask — and the ones we expect you to ask us.
Which region processes the request. If the answer is vague, or the vendor has not asked themselves, that is the answer. For a government entity this determines whether the feature is usable at all.
And if it does, under what transfer mechanism. This is a PDPL question with a specific answer, not a matter of general assurance — and your regulator will treat it that way.
Ours, or anyone's. Ask for it in the contract rather than on a webpage, because a policy can change and a contractual term cannot without you.
Most vendors describe a reminder engine as artificial intelligence. Knowing which is which tells you where the risk is and where the reliability is, and they are usually different places.
If an AI suggestion can become a compliance status without a person approving it, the platform is making assertions on your behalf that you will have to defend.
When an assessor asks how a control was assessed or a document produced, "the system suggested it" is only an acceptable answer if there is a record of who reviewed and approved it.
Per feature, or entirely. Some organisations cannot use AI features for certain data classifications, and a platform that cannot be operated without them is not usable by those organisations.
The question almost nobody asks. Using an AI feature makes you an AI user, with governance obligations of your own — see below.
If a vendor cannot answer these in a first call, the issue is not that they are hiding something. It is usually that nobody has asked them, which tells you how the feature was built and how the security review will go.
Automation and AI are not the same thing
They get marketed as one capability. They behave completely differently, and conflating them oversells the AI while hiding where the value actually is.
- Evidence expiry surfacing before it lapses
- Review cycles recurring on schedule
- Requests routed to the named owner
- Reminders escalating when overdue
- Status changing when a condition is met
- Findings reopening if verification fails
- Drafting a policy from your context
- Proposing mappings between frameworks
- Summarising a long assessment response
- Suggesting where coverage looks thin
- Answering a questionnaire from existing records
- Explaining what a requirement is asking for
The left column is unglamorous and carries most of a compliance programme. It is predictable, auditable, and fails in obvious ways. The right column is genuinely useful on judgement-adjacent work and fails plausibly, which is why everything in it needs a person between the output and the record.
A useful way to decide which belongs where: if the task has one correct answer, it is automation. If it requires judgement you would accept from a competent junior colleague — subject to review — it is a candidate for AI. Anything requiring judgement you would not delegate is neither.
What AI should not do in a compliance programme
The boundary matters more than the capability, because crossing it produces confident records nobody can defend.
| Task | Appropriate | Why |
|---|---|---|
| Drafting a policy | Yes, with review | A draft is a starting point. The reviewer remains the author in every sense that matters. |
| Proposing framework mappings | Yes, with review | Mapping is pattern work with a knowledgeable check. A wrong mapping is visible to someone who knows the framework. |
| Summarising evidence | Yes, alongside the original | The summary is a convenience. The artefact remains the evidence, and the assessor reads the artefact. |
| Deciding compliance status | No | A status is an assertion you make to a regulator. It needs a person who is accountable for it. |
| Approving evidence | No | Approval is a judgement about sufficiency. If nobody approved it, you cannot say it was reviewed. |
| Assessing risk | Suggest only | Risk acceptance carries personal accountability. A suggestion is useful; an unreviewed rating is not defensible. |
| Answering a regulator | Draft only | A submission is a formal statement by your organisation. Nothing goes out unread. |
The pattern across the "no" rows is consistent: AI should not produce anything you would be personally accountable for without having read it. That is not a limitation of the technology — it is what accountability means, and a platform that blurs it is creating a problem you inherit.
Using AI makes you an AI user
The question almost nobody asks a vendor, and the one that lands hardest when an assessor raises it first.
Under ISO/IEC 42001, control A.9 covers the responsible use of AI systems within an organisation — including AI you did not build. An AI feature in your compliance platform, processing your organisational data, sits squarely inside that. And if the data being processed includes personal data, the PDPL applies to that processing like any other.
This is not an argument against using AI. It is an argument for knowing that you are, and recording it. An organisation that has adopted AI features across a dozen tools without an inventory has an AI governance gap regardless of how good any individual tool is.
Record it as an AI system
An AI feature in a platform you use belongs in your AI system register, with its purpose, its data and its owner — the same treatment as any other AI you have adopted.
What data does it touch
Which classifications the feature processes determines whether it may be used at all. This is an asset governance question before it is an AI one.
A vendor obligation too
Where personal data is involved, the AI service is a processor with the obligations of one — recorded in your vendor register alongside the rest of the processor chain.
Evidenced, not asserted
Whatever review sits between AI output and a record should leave a trace, because "a person reviewed it" is only credible when there is a record of which person and when.
How we approach it in Govrly
Stated as principles rather than a feature list, because the specifics belong in a written answer to your security review rather than on a marketing page.
A person between output and record
AI output is a draft or a suggestion. It becomes a compliance record when someone with the authority to do so accepts it — never before, and never silently.
Automation is not sold as AI
Evidence expiry, review cycles, routing and escalation are deterministic and behave predictably. We describe them as what they are, because a buyer assessing AI risk needs to know which is which.
The platform works without it
Organisations that cannot use AI features for certain data — or at all — should still be able to run their programme. A platform whose core function depends on AI is unusable for a meaningful share of this market.
Involvement is visible
Where AI contributed to a record, that should be apparent — so that when an assessor asks how something was produced, the answer is available rather than reconstructed.
Data handling in writing
Processing location, data handling and training use are questions we answer specifically and put in the contract. If a vendor will only answer them on a webpage, that is a signal.
No compliance without people
No platform makes an organisation compliant, and adding AI does not change that. The work is still decisions, ownership and evidence — AI shortens the drafting, not the accountability.
Adopting AI in a compliance programme
The sequence that keeps you able to answer for it afterwards.
- Decide what data may touch an AI featureBy classification, before you enable anything. This is an asset governance decision and it constrains everything after it.
- Get the data handling answers in writingProcessing location, transfer mechanism, training use. In the contract, not on a webpage, and from every vendor including us.
- Start where being wrong is cheapDrafting, summarising, mapping proposals. Not status decisions, not risk ratings, not regulatory submissions.
- Keep a person between output and recordAnd make sure that review leaves a trace. An unreviewable AI contribution is an audit finding waiting to be written.
- Add it to your AI inventoryPurpose, data, owner, classification. You are an AI user now, and control A.9 applies whether or not anyone has mentioned it.
- Record it as a processor where personal data is involvedIn your vendor register, with the rest of the processor chain. This is a PDPL question, not an AI one.
- Tell your own assessors before they find outA disclosed and governed AI use is a non-issue. A discovered one is a finding, and the difference is entirely in the sequencing.
- Review what it is actually doing for youSome AI features save real time and some create review work that exceeds what they saved. The second kind should be switched off rather than tolerated.
Deterministic automation carries the routine — evidence expiry, review cycles, routing and escalation — while AI assists on drafting and mapping with a person between every output and every record. Ask us the eight questions above and we will answer them in writing.
See it in a demo →AI and automation — FAQs
Does our data leave the Kingdom?
Ask us directly and we will answer specifically and put it in the contract. We deliberately do not answer this on a marketing page, because the answer depends on your deployment and because a webpage is not where a data residency commitment belongs. We would give any vendor the same treatment.
Is our data used to train models?
This is a contractual question, and you should treat it as one with every vendor. A published policy can change without you; a contractual term cannot. Ask for it in writing before enabling anything.
What is the difference between automation and AI here?
Automation is deterministic — evidence expiry, recurring reviews, routing, escalation. It behaves predictably and fails visibly. AI assists with judgement-adjacent work like drafting and mapping, and fails plausibly, which is why everything it produces needs a person before it becomes a record. Most vendors market both as AI; knowing which is which tells you where the risk sits.
Can AI decide whether a control is compliant?
It should not, and we do not think any platform should allow it. A compliance status is an assertion your organisation makes to a regulator, and it needs a person who is accountable for having made it. AI can suggest; the acceptance is a human act with a name attached.
Can we use the platform without AI features?
Yes, and that matters. Some organisations cannot use AI features for certain data classifications, and some cannot at all. A platform whose core function depends on AI is unusable for a meaningful share of this market, which is why the programme has to work without it.
Does using AI create obligations for us?
Yes, and this is the question almost nobody asks. Under ISO 42001, control A.9 covers responsible use of AI systems including ones you did not build. An AI feature processing your organisational data belongs in your AI inventory with a purpose, an owner and a classification — and where personal data is involved, the service is a processor under the PDPL.
How do we explain AI-assisted work to an assessor?
By showing who reviewed it and when. "The system suggested it" is an acceptable answer only when paired with a record of the person who accepted it. This is why review needs to leave a trace — an unreviewable AI contribution is a finding waiting to be written.
Where should we start with AI in compliance?
Where being wrong is cheap — drafting, summarising, mapping proposals. Not status decisions, risk ratings or regulatory submissions. And decide by data classification what may touch an AI feature before enabling anything, because that decision constrains everything afterwards.
Will AI reduce our compliance workload?
Some of it, and not the part most people hope. Drafting gets faster. Decisions, ownership and evidence do not, because those are the parts that require accountability. We would be cautious of any vendor promising more than that, including on the question of headcount.
What if an AI feature creates more work than it saves?
Switch it off. Some AI features generate review work exceeding the time they saved, and tolerating those is how a programme ends up slower with better marketing. This is worth reviewing deliberately rather than assuming the feature is helping because it exists.
Ask us the eight questions
We will answer them specifically, in writing, and we suggest you hold every vendor to the same standard.