AI Agents for GRC: What Actually Works (and What's Just a Chatbot)

Category: AI & Automation Author: Cody Swidler Tags: AI agents, GRC, MCP, automation, risk management, agentic AI

Every GRC vendor now has "AI." Open the demo and it's almost always the same thing: a chat box that answers questions about your policy documents. Useful, occasionally. But it's not an agent, and it's certainly not running your risk program. It's search with better manners.

There's a real version of AI in GRC coming, and it looks nothing like a policy chatbot. To understand the difference — and to not get sold the wrong thing — you need to be clear about what an agent actually requires to be useful in risk and compliance work.

The Chatbot Ceiling

A document chatbot retrieves text and summarizes it. Ask it "what's our policy on vendor access" and it finds the paragraph. That's retrieval-augmented generation, and it has a hard ceiling: it can only tell you what's already written down. It cannot tell you your residual risk, because residual risk isn't written in a document — it's computed from your controls, your incidents, and your open findings. The chatbot has no model of any of that. It has prose.

This is why most "AI GRC" demos feel impressive for ninety seconds and useless by the second real question. The moment you ask something that requires reasoning over the actual state of the program — "which risks got worse this quarter," "what happens to our exposure if this control fails" — the chatbot has nothing to reason over. There's no there there.

What an Agent Actually Needs

An agent that can operate a GRC program — not just talk about it — needs three things the chatbot doesn't have.

1. A connected data model. Risks, controls, issues, and incidents have to exist as structured, linked data — not as paragraphs in a Word file. The agent needs to know that this incident is evidence for that risk, and that this audit finding degrades that control. That's the entire premise of the connected GRC model: four entities, joined by their relationships. Without it, there is nothing for an agent to act on.

2. A deterministic engine. This is the part everyone skips, and it's the most important. The agent must not be the thing that decides your risk scores. An LLM that "judges" residual risk is a liability — it will be confidently wrong, and you can't defend a board rating that came from a model's vibe. Instead, the ratings come from a deterministic engine: fixed rules that turn evidence into numbers (incident count drives likelihood, control effectiveness drives residual, open issues drag control effectiveness down). The engine computes; the agent reads, explains, and acts. Every number is traceable to evidence. This separation is what makes AI in GRC trustworthy.

3. Tools, not just text. The agent needs to be able to do things — query the model, simulate a change, generate a report — through defined tools, not by free-associating. This is what the Model Context Protocol (MCP) is for: it exposes your risk program's engine as a set of capabilities an agent can call. "Re-rate every risk against this quarter's incidents" becomes a real operation with a real, auditable result — not a paragraph of plausible-sounding text.

What the Real Agents Do

Once you have a model, an engine, and tools, the agent work that matters comes into focus. None of it is "summarize this PDF." All of it is the analysis a GRC team currently does by hand, slowly:

Re-rating. A new incident lands. An agent recomputes the affected risks against the engine and tells you exactly which ratings changed and why — in minutes, not at the next quarterly cycle. The numbers come from the engine; the agent does the legwork of figuring out what moved.

Audit-finding triage. A new finding comes in from an exam. The agent maps it to the control it affects, shows the downstream residual-risk impact, and drafts the remediation — turning a finding from a line in a log into a propagated, understood change.

Coverage analysis. "Which risks have weak or no control coverage?" is a question every risk leader should be able to answer instantly and almost never can. An agent over a connected model answers it on demand.

Board reporting. The quarterly board narrative — top risks, what moved, what's driving exposure — generated from live data instead of assembled by hand from stale spreadsheets. This is exactly the decision-driving reporting I argued for in board risk reporting that actually drives decisions, now produced from the real state of the program.

How to Tell the Difference When You're Being Sold

When a vendor shows you "AI for GRC," ask one question: where does the risk number come from? If the answer is "the model assesses it," walk away — you're being sold a confident guesser. If the answer is "the model computes it from your controls and incidents using defined rules, and the AI explains and acts on that," you're looking at something real. The chatbot judges; the engine computes. That distinction is the whole game.

And ask the second question: does it have a model of my program, or just my documents? Documents are the chatbot ceiling. A connected data model is the floor a real agent stands on.

Where to Start

You don't get the agent first. You get the model first — risks, controls, issues, and incidents as connected, computable data, the way I laid out in the connected GRC model and how to build a risk register that calculates residual risk. Build that, even in a spreadsheet, and you've built the thing every real GRC agent will need to stand on. The agents come to the programs whose data is ready for them. Most programs' data isn't. That's the work to do now.

The hype says AI will transform GRC. It will — but not as a chatbot reading your policies. As an agent operating a model you have to build first.

Cody Swidler is the founder of PivotRisk and a Principal Program Manager, Enterprise Resiliency at Apex Clearing. He has built and scaled GRC, resilience, and risk programs across Microsoft, Twilio, Box, Zayo, and Miro.