AI can make GRC decisions safely when the decision is repeatable, grounded in evidence and easy to reverse, and when a named person approves every decision that accepts risk, changes a control or will be relied on by someone else. The question to ask of any AI feature in a GRC tool is therefore narrower than “can it decide”. It is which decisions it makes alone, which it only proposes, and whether the record shows the difference.
I lead AI at DigitalXForce, so I have a stake in this answer, and I would rather give a precise one than an enthusiastic one. Governance, risk and compliance exist to show that someone was accountable for a decision. An AI that makes the decision invisibly removes the thing the function is there to prove.
The setting I have in mind is Continuous Control Assurance. Continuous Control Assurance (CCA) uses evidence, monitoring and validation to determine whether controls continue to operate as expected. Most of that work repeats every day, which is exactly where AI earns its place, and a small part of it is judgment, which is where it should not decide alone.
What can AI do safely in GRC today?
AI does well at the work that is large in volume, grounded in documents or data, and checkable by a person afterwards. In a GRC program, that means 5 kinds of work.
- It reads documents, such as a policy, a supplier’s audit report or a contract clause, and says which controls they address.
- It maps evidence to controls and controls to framework requirements, which is slow and repetitive work for a person.
- It scores and ranks risks and failed controls, so a team starts the day with the most important item.
- It recommends remediation steps that match the requirement the control serves.
- It drafts narratives, policies and reports for a person to edit and sign.
In each case the output is a proposal that a person or a rule can check against the evidence. That is the property that makes it safe. A rule-based test that reads a setting and compares it with an expected value is not really an AI decision at all, and it can run on its own, because anyone can re-perform it. Evidence Collection vs Control Validation explains where AI fits in validating a control.
Where should AI not make autonomous GRC decisions?
AI should not decide alone wherever the decision accepts risk, changes what a control means, changes a production system or produces something another party will rely on. Those are the decisions that carry accountability, and accountability has to sit with a person who can be named. The table shows how I would divide the work.
| GRC activity | What AI or automation does | What a named person decides | What the record keeps |
|---|---|---|---|
| Evidence collection | It reads the evidence from the source system on schedule. | A person decides which system holds the evidence for each control. | The record keeps the source, the time read and the population. |
| A rule-based control test | It compares the evidence with the expected state and records the result. | A person approves the expected state and any change to it. | The record keeps the result and the version of the rule. |
| A control conclusion that needs judgment, such as whether a policy covers a control | It proposes the conclusion and links it to the passages it read. | A reviewer accepts or rejects the conclusion before anyone relies on it. | The record keeps the proposal, the evidence, the reviewer and the decision. |
| Framework mapping | It proposes which requirements a control satisfies. | The compliance owner approves the mapping. | The record keeps who approved each mapping and when. |
| Risk scoring and prioritization | It scores and ranks risks from the evidence. | The risk owner confirms the priority of the risks that go to leadership. | The record keeps the score, its inputs and any override with its reason. |
| Risk acceptance or an exception | It can prepare the facts, and it never approves. | A named person accepts the risk with a reason and an expiry date. | The record keeps the approver, the reason and the expiry. |
| A change to a production system | It recommends the fix and opens the task. | The system owner makes the change through the normal change process. | The record keeps the task, the change and the retest. |
| A policy, standard or plan | It drafts the text against the chosen frameworks. | The policy owner edits and approves it. | The record keeps the approved version and its approver. |
| A board or regulator report | It drafts the narrative from the analysis. | An executive checks the facts and signs it. | The record keeps the evidence behind each statement. |
| An audit opinion | It plays no part beyond preparing evidence. | The auditor forms the opinion. | The auditor’s own working papers keep it. |
The middle rows are where programs slip. An AI that scores a risk is useful, and an AI whose score silently decides that a risk no longer needs treatment has accepted the risk without anyone signing for it. What is agentic TPRM, and what should people still decide? applies the same division to supplier assessments.
What do the NIST AI RMF and the EU AI Act say about human oversight?
Both put the decision about oversight on the organization, and both expect it to be written down. The NIST AI Risk Management Framework 1.0, NIST AI 100-1, published in January 2023, asks in GOVERN 3.2 for policies and procedures that define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems. MAP 3.5 asks that processes for human oversight are defined, assessed and documented. MANAGE 2.4 asks for mechanisms, with assigned responsibilities, to supersede, disengage or deactivate an AI system whose performance or outcomes are inconsistent with its intended use.
The framework’s Appendix C is the most practical part for GRC. It says human-AI configurations can span from fully autonomous to fully manual, and that some AI systems may not require human oversight while others specifically require it. That is the same division the table above makes. NIST’s page for the framework says AI RMF 1.0 is being revised as part of the White House AI Action Plan, so I would check it again before relying on the numbering.
The EU AI Act sets its human oversight rule in Article 14, which applies to AI systems the Act classifies as high-risk. Whether a given GRC tool falls into that class depends on the Act’s own classification rules, so I would not assume it does. Its wording is still the clearest description I know of what an oversight role needs. Article 14(4) expects the people assigned to oversight to be able, as appropriate and proportionate, to do 5 things.
- They can understand the system’s capacities and limitations and monitor its operation.
- They remain aware of automation bias, the tendency to rely too much on the system’s output.
- They can correctly interpret the system’s output.
- They can decide not to use the output, or disregard, override or reverse it.
- They can intervene in the system or interrupt it.
I use that list as a test for any AI feature in a GRC tool, whether or not the Act applies to it.
How should human review work in AI-assisted GRC?
Human review should sit at the point of reliance, which is the moment an AI output starts to count toward a result, a report or a decision. Reviewing every intermediate step wastes the reviewer’s attention, and reviewing nothing turns a proposal into a decision. In my experience, 4 rules keep review honest.
- The reviewer sees the evidence the AI used, next to the conclusion, so the check is quick and does not mean redoing the work.
- The reviewer can reject or change the conclusion, and a rejection is recorded as carefully as an approval.
- The reviewer has the competence and the authority to disagree, which rules out approving your own area’s exceptions.
- The program tracks how often reviewers override the AI, because a reviewer who never disagrees may no longer be reviewing.
The last rule is about automation bias. NIST AI 600-1, the Generative AI Profile published in July 2024, describes automation bias as excessive deference to automated systems, and it notes that this can make the risk of confabulation worse. A review step that has turned into a click is still an AI decision, only with a person’s name attached to it.
How do you explain an AI-assisted GRC decision to an auditor?
You explain it with the record, not with the model. An auditor does not need to understand how the model works in order to test a conclusion, in the same way they do not need to understand a database engine to test a report. They need to see what went in, what came out, who reviewed it and what happened next.
For every AI-assisted conclusion that counts toward a result, the record should keep 6 things: the evidence the AI read, the instruction or rule it applied, the engine and version that produced the conclusion, the conclusion itself, the person who reviewed it and their decision, and the time of each step. With that record, an auditor can re-perform a sample of conclusions by hand and compare the answers. Is Automated Evidence Trustworthy? covers provenance and audit trails for automated evidence in general, and Will auditors accept automated control test results as audit evidence? covers the auditor’s side.
How do you prevent hallucinations in AI-assisted compliance workflows?
You cannot remove them entirely, so you make them visible and keep them away from any decision. NIST AI 600-1 calls the problem confabulation, the production of confidently stated but erroneous or false content, and it says confabulation is a natural result of how generative models are designed. It also warns that outputs can include confabulated logic or citations that appear to justify the answer, which is the version that worries me most in compliance work.
These controls do most of the work in a GRC setting.
- The AI works from the organization’s own evidence and frameworks, and it is asked to answer from them, not from general knowledge.
- Every statement it makes about a control cites a record that exists, such as a control identifier, an evidence item or a passage in a document.
- A check confirms that each cited record exists and says what the output claims before a person sees it.
- Outcomes are chosen from a fixed set, such as pass, fail or undecided, instead of free text.
- The program tests the AI on known cases, including controls broken on purpose, and records how often it gets them right.
- A person reviews every output that will be relied on, as the section above describes.
A narrative that XForce GPT drafts for a board is the easiest place to check this. Every sentence in it should trace to a figure, a control or a finding in the record, and a sentence that traces to nothing comes out.
How do you preserve human accountability in Continuous Control Assurance (CCA)?
Every decision that matters has a named owner, and the AI is never the approver of record. In a Continuous Control Assurance program that means a person owns each control, each expected state, each accepted exception and each report that leaves the team. The AI can prepare all of them, and none of them is final until the owner approves it.
It also means someone can switch the AI off. MANAGE 2.4 in the NIST framework asks for exactly that, and the program should know in advance how it would run without the AI for a sustained period. If the answer is that it cannot, the AI has become a dependency nobody governs, which is a risk the GRC function should be the first to record. The Continuous Control Monitoring page lists what is automated and what stays with people in day-to-day monitoring.
What should you check before you trust an AI feature in a GRC platform?
These are the 5 checks I run before I rely on one.
- I check that the vendor can say, decision by decision, what the AI does alone and what it only proposes.
- I check that every AI conclusion links to the evidence it read, and that the link opens the real record.
- I check that a reviewer can reject a conclusion, and that the rejection is kept in the record.
- I check that no AI output can accept a risk, change a control or change a production system without a person.
- I check that the program still works, more slowly, with the AI switched off.
If a vendor cannot answer the first question, the rest do not matter. What Proof Should a GRC Vendor Provide? covers the wider set of questions to ask, and Will AI Replace Cybersecurity Teams? covers what AI changes for the people doing the work.
How AI JedAI and XForce GPT divide the work at DigitalXForce
We built DigitalXForce with 2 engines that do different jobs, so that analysis and writing stay separate. AI JedAI is the DigitalXForce AI engine that analyzes: it reasons over control evidence and live telemetry, maps documents to controls and frameworks, scores and prioritizes risk, and recommends remediation mapped to framework requirements. XForce GPT is the DigitalXForce generative AI engine that writes: it produces the plain-language risk narratives and board-ready reports, generates policies, standards and plans, and runs the embedded assistant. In DigitalXForce, an analyst reviews AI output, both AI JedAI’s conclusions and XForce GPT’s drafts, before anyone relies on it, and every conclusion links back to the evidence it used. The article on how AI JedAI and XForce GPT enable automation describes both engines.
A risk operations center is an operating model for continuously measuring, prioritizing and reducing risk, in the way a security operations center handles threats; DigitalXForce’s implementation is X-ROC, the XForce Risk Operations Center. X-ROC never changes a customer’s systems on its own, so the customer’s own team makes each change, as the FAQ answer on system changes says. Both engines run across every module, including AI-Powered Risk Management and Automated GRC, which holds the control library, and the AI TRiSCM and AI Risk Governance module applies the same governance to a customer’s own AI systems, mapped to the NIST AI RMF, ISO/IEC 42001 and the EU AI Act. What Is AI Governance, and How Do You Run It Continuously? covers that side.
Where DigitalXForce is not the answer
If you are preparing a first SOC 2, you can start with DigitalXForce Lite, which is the full platform hosted in the cloud with the same functionality and a faster deployment, open to any organization that prefers cloud hosting.
Questions about AI and GRC decisions
Can AI make GRC decisions safely?
It can make the decisions that are repeatable, grounded in evidence and easy to reverse, such as reading documents, mapping evidence and ranking risks. A named person should approve every decision that accepts risk, changes a control or a production system, or will be relied on by someone else.
Where should AI not make autonomous GRC decisions?
AI should not decide alone on risk acceptance and exceptions, changes to a control’s expected state, changes to production systems, approval of policies, reports that leave the team or anything that forms an audit opinion. It can prepare each of them for a person to approve.
How can AI assist with control assessments?
AI can read policies, audit reports and contracts and say which controls they address, map evidence to controls and frameworks, propose conclusions where a simple rule cannot decide, and rank failures by risk. Each conclusion should link to the evidence it read, and a person should review it before anyone relies on it.
How should human review work in AI-assisted GRC?
Review should happen at the point where an AI output starts to count, with the evidence shown next to the conclusion. The reviewer needs the competence and authority to disagree, rejections should be recorded as carefully as approvals, and the program should track how often reviewers override the AI.
How do organizations explain AI-assisted GRC decisions to auditors?
They show the record: the evidence the AI read, the instruction it applied, the engine and version, the conclusion, the reviewer and their decision, and the time of each step. With that record, an auditor can re-perform a sample of conclusions and compare the answers.
How do organizations prevent hallucinations in AI-assisted compliance workflows?
They ground the AI in the organization’s own evidence, require every statement to cite a record that exists, check those citations automatically, limit outcomes to a fixed set such as pass, fail or undecided, and have a person review every output that will be relied on. NIST AI 600-1 calls the problem confabulation.
How do organizations preserve human accountability in Continuous Control Assurance (CCA)?
Every control, expected state, accepted exception and outgoing report has a named owner, and the AI is never the approver of record. The program also keeps a way to supersede or switch off the AI, which the NIST AI RMF asks for in MANAGE 2.4.
Sources
- NIST published the Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, in January 2023, at https://doi.org/10.6028/NIST.AI.100-1. GOVERN 3.2, MAP 3.5 and MANAGE 2.4 are in its Core, and Appendix C covers human-AI interaction. NIST’s page at https://www.nist.gov/itl/ai-risk-management-framework says AI RMF 1.0 is being revised.
- NIST published the Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, in July 2024, at https://doi.org/10.6028/NIST.AI.600-1. Confabulation is described in section 2.2, and automation bias in section 2.7, Human-AI Configuration.
- Article 14 of Regulation (EU) 2024/1689, the EU AI Act, on human oversight of high-risk AI systems, was read on the European Commission’s AI Act Service Desk at https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-14.
- Every source above was read on 26 September 2026.
What this looks like in practice.
Reading about continuous evidence is one thing. Watching a control get tested against live data from your own stack is another. A 30 minute walkthrough on your frameworks shows the difference.
