From Spreadsheet to Agent: Making Your Risk Data Computable

Category: AI & Automation Author: Cody Swidler Tags: computable risk, GRC data model, AI, automation, risk register, MCP

There's a quiet prerequisite buried under all the excitement about AI in risk and compliance, and almost nobody is naming it: your data has to be computable before any of it works. Not digitized — computable. Those are different things, and the gap between them is where most GRC programs are stuck.

A risk register in a spreadsheet is digitized. A risk register where likelihood is derived from incident counts, residual is derived from control effectiveness, and every rating traces to evidence — that's computable. The first one an AI can read. The second one an AI can operate. The whole future of AI in GRC depends on which one you have.

Digitized vs Computable

Most risk data is digitized prose. A risk has a title, a description, and two numbers somebody typed in a workshop. The numbers aren't connected to anything — they're opinions stored in cells. You can search this data, sort it, put it in a chart. But you can't reason over it, because there's no logic underneath it. Change a control and nothing recalculates. Log an incident and no rating moves. The spreadsheet is a filing cabinet, not a model.

Computable data is different in one specific way: the numbers are outputs of rules over linked inputs, not standalone entries. This is the discipline behind the data-driven risk assessment — every score traces to evidence — extended into structure: the evidence is itself linked data, and the rules run automatically. Once that's true, the data can answer questions nobody typed the answers to. "What's our residual exposure if this control degrades?" has an answer, because residual is computed, not stored.

The Three Properties of Computable GRC Data

Structured. Risks, controls, issues, and incidents exist as defined records with defined fields — not as free text in a document. An agent can't reason over a paragraph; it can reason over a record.

Linked. The records reference each other by ID. This incident belongs to that risk. This issue affects that control. This risk is mitigated by these controls. The links are the relationships from the connected GRC model, and they're what let a change in one place propagate to the right places everywhere else.

Rule-driven. The ratings come from explicit, deterministic rules over the structured, linked data — not from human judgment re-entered each cycle. Incident count maps to a likelihood. Average control effectiveness maps to a reduction factor. The rules are fixed and documented, so the output is reproducible and defensible.

Hit all three and your data stops being a record of what people decided and becomes a model of what's actually true. That model is the thing an AI agent stands on.

Why This Is the Real AI Prerequisite

The reason "AI for GRC" demos disappoint is almost never the AI. It's that the AI is pointed at digitized prose. Ask the smartest model in the world "which of my risks got worse this quarter" and if the underlying data is just typed-in numbers with no link to incidents, the model has nothing to compute from — it can only guess or summarize. The intelligence isn't the bottleneck. The computability of the data is.

This is also why the order of operations matters. You don't buy an AI agent and then get value. You make your data computable, and then an agent becomes useful — because now there's a model for it to operate. Programs that invest in the data model first will get enormous leverage from agents. Programs that skip it will keep buying chatbots and wondering why they don't help.

How an Agent Reaches Computable Data

Once the data is computable, the last piece is exposure: the agent needs a defined way to query and act on the model. In the emerging standard, that's the Model Context Protocol — the engine that computes your ratings is wrapped as a set of tools (list the risks, rank by residual, simulate a control change), and any AI client can call them. The agent doesn't get raw spreadsheet access and a prayer; it gets defined operations with auditable results. The computable model is the substance; the protocol is the doorway.

You don't need any of that infrastructure to start, though. The substance comes first, and it's buildable in a spreadsheet today.

Where to Start

Make one thing computable. Take your risk register and connect residual to control effectiveness instead of guessing it twice — the build is in how to build a risk register that calculates residual risk. Then link your incidents to risks and let the count inform likelihood. You've now turned a filing cabinet into a model — and you've done the single highest-leverage thing you can do to get ready for AI, without buying any AI at all.

The agents are coming to the programs whose data is computable. Everyone else will be watching demos. Make your data computable now, and you'll be on the right side of that line.

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.