From Paperwork to AI Workflows
Traditional GRC was built on paperwork. Policies as documents, controls as screenshots, assurance as a folder of artefacts assembled by hand and rebuilt every cycle. That model is now being dismantled — not gradually, but at the speed at which AI agents and bots can be pointed at the work. Risk triage, control testing, evidence collection and questionnaire response are all being handed to systems that never tire of repetition. The practitioner’s role shifts accordingly: from doing the work to specifying it, governing it, and knowing when its output can be trusted. Staying on top of that shift means understanding what has genuinely been automated, what has quietly been assumed, and where a human still has to sign.
Most GRC functions spend the majority of their effort re-collecting information the organisation already has. Screenshots of access lists that a directory service could return through an API. Quarterly attestations about configurations a monitoring stack already observes continuously. Evidence packs rebuilt from scratch for each of four overlapping frameworks.
GRC engineering applies software engineering discipline to risk and compliance: APIs instead of GUIs, version control instead of shared drives, continuous telemetry instead of periodic inspection. Policies become executable rules. Evidence becomes a query. Audits become a report generated from live data rather than a fire drill.
The point is not to eliminate judgement — judgement is the part that matters. The point is to stop spending judgement on data collection so it can be spent on risk.
Traditional GRC
- Evidence gathered manually before each audit
- Controls tested on a quarterly or annual cycle
- Policies written as documents nobody executes
- Same evidence recollected per framework
- Risk registers updated in workshops
- Assurance is a point-in-time snapshot
AI GRC Engineering
- Evidence collected automatically and continuously
- Controls tested on every change, in the pipeline
- Policies expressed as code that enforces itself
- Collected once, mapped to many frameworks
- Risk signals streamed from production systems
- Assurance is a live state you can query
Manual Work Worth Killing First
Not everything should be automated, and not everything can be. These are the processes where the ratio of effort to judgement is worst — which makes them the highest-value automation targets in most compliance functions.
Control Assurance & Testing
Very high effortSampling, screenshotting, and re-testing controls that already emit telemetry. Most control tests are questions a system can answer directly, asked instead of a human who then asks the system.
What to automate
- Configuration checks against a defined baseline
- Access reviews pulled from identity provider APIs
- Continuous control monitoring with drift alerts
- Exception tracking with automatic expiry
- Test results written to an immutable evidence store
Evidence Collection
Very high effortThe single largest consumer of GRC hours. Evidence is usually re-gathered per audit, per framework, per year — despite being the same underlying facts each time.
What to automate
- Scheduled API pulls into a central evidence lake
- Timestamped, hash-verified artefact storage
- One control test mapped to many frameworks
- Auditor-facing read-only access to live evidence
- Automatic gap flagging when a pull fails
Internal & External Audit Prep
High effortThe pre-audit scramble is a symptom, not a process. If evidence is continuous, preparation collapses from weeks of chasing to generating a report.
What to automate
- Request-list matching against existing evidence
- Population and sample generation with rationale
- Walkthrough narratives drafted from system data
- Prior-year finding status tracked automatically
- Auditor request tracker with SLA visibility
Framework Mapping
High effortOrganisations subject to ISO 27001, SOC 2, ISO 42001, and the EU AI Act simultaneously usually maintain four parallel control sets describing the same underlying controls.
What to automate
- Single control library with framework crosswalks
- Machine-readable control definitions (e.g. OSCAL)
- Gap analysis when a new framework is adopted
- Change propagation across all mapped frameworks
- Coverage reporting by framework and by control
Third-Party & Vendor Risk
High effortQuestionnaire cycles that take weeks and produce assertions nobody verifies. The effort is real; the assurance is largely theatrical.
What to automate
- Certificate and report expiry monitoring
- Questionnaire triage and response summarisation
- Risk tiering from contract and data-flow attributes
- Continuous monitoring of critical vendors
- Reassessment triggered by change, not calendar
Policy & Regulatory Change
Moderate effortTracking what changed in a regulation, deciding whether it touches you, and updating the affected artefacts is slow, repetitive, and easy to fall behind on.
What to automate
- Monitoring of regulator and standards-body sources
- Impact triage against your control library
- Draft redlines routed to a human owner
- Policy version control with review scheduling
- Attestation and training assignment on change
Designing a Compliance Agent From Scratch
An agent that runs a compliance process on its own is achievable today — but only if you build it as a system with boundaries, not as a prompt with ambition. This is the sequence that tends to work, and the failure mode at each stage.
Pick a process narrow enough to fully specify
The first agent should do one thing whose correct output you can define precisely. Quarterly user access review for a single system beats "automate compliance". If you cannot write down what a correct result looks like, you cannot evaluate the agent, and you cannot defend it to an auditor.
Do this
- Choose a high-volume, low-ambiguity process
- Write the acceptance criteria before any code
- Collect 20–30 historical cases as a test set
Failure mode
- Scope so broad no output can be verified
- Starting with the process nobody understands
- No baseline to measure improvement against
Give it deterministic tools, not free rein
The model should decide which tool to call and with what arguments. It should not be the thing that computes the answer. Wrap each data source in an explicit function — fetch access list, retrieve control definition, write finding — and let the deterministic code do the deterministic work.
Do this
- Expose narrow, typed, well-documented tools
- Keep calculations in code, not in the model
- Return structured data the agent can reason over
Failure mode
- Asking the model to do arithmetic or counting
- Giving raw database or shell access
- Tools so broad their blast radius is unbounded
Separate read from write, and gate the writes
Let the agent gather, analyse, and draft freely. Require a human decision before anything leaves the system — a finding raised, a ticket closed, an exception approved. This is the control that would have prevented most documented agent failures, and it is the one auditors will ask about first.
Do this
- Read access broad; write access explicitly granted
- Approval gate on every externally visible action
- A kill switch that a named person can trigger
Failure mode
- Treating a prompt instruction as a permission
- Production write access "just for convenience"
- Approval so high-volume it becomes a rubber stamp
Make the reasoning auditable by default
Log the prompt, the retrieved context, every tool call and its result, the model version, and the final output — together, as one replayable record. If you cannot reconstruct why the agent reached a conclusion six months later, the output is not evidence and cannot be relied upon in an audit.
Do this
- Store inputs, intermediate steps, and outputs
- Pin and record the model version per run
- Align retention to your limitation periods
Failure mode
- Logging only the final answer
- Silent model upgrades changing behaviour
- Evidence that cannot be independently replayed
Evaluate before you trust, and keep evaluating
Run the agent against your historical test set and measure it. Precision matters more than recall in most compliance contexts — a false finding wastes an engineer's afternoon and erodes trust in the whole programme. Re-run the evaluation on every model or prompt change.
Do this
- Measure against known-correct historical outcomes
- Track false positives and false negatives separately
- Re-run evaluations as a release gate
Failure mode
- Judging quality by whether output "looks right"
- No regression testing after prompt changes
- Deploying on demo performance alone
Run it shadow, then assisted, then autonomous
Deploy alongside the existing manual process first and compare outputs without acting on them. Then let it draft for human approval. Only then, and only for the lowest-consequence actions, consider letting it act unattended. Most GRC agents should stop permanently at stage two — and that is still a large win.
Do this
- Shadow-run for at least one full process cycle
- Compare against human output and investigate gaps
- Expand autonomy per action type, not wholesale
Failure mode
- Going straight to autonomous because the demo worked
- Retiring the manual process before validation
- Treating autonomy as the goal rather than a means
AI & LLM Capabilities for GRC
Language models are not a compliance product. They are a set of capabilities that happen to map unusually well onto the parts of GRC work that are text-heavy, repetitive, and judgement-light. Understanding which capability you are using — and its failure mode — matters more than which vendor you buy.
Document Comprehension
Reading long, dense regulatory text, contracts, audit reports, and vendor documentation, then extracting specific structured facts from them.
Semantic Mapping
Recognising that two differently worded requirements describe the same underlying control — the task that makes multi-framework compliance so expensive.
Structured Extraction
Turning unstructured input — emails, tickets, meeting notes, questionnaire responses — into consistent, machine-readable records.
Retrieval-Grounded Answering
Answering questions against your own document corpus, with citations back to source, rather than from the model's general knowledge.
Drafting & Summarisation
Producing a competent first draft of a repetitive artefact, which a practitioner then corrects — far faster than authoring from blank.
Tool Use & Orchestration
Deciding which system to query and in what order, then chaining the results — the capability that turns a chatbot into an agent.
Where these tools genuinely earn their place
- High-volume text work with a human reviewing output
- First drafts of repetitive, structured artefacts
- Mapping and crosswalk generation across frameworks
- Triage — deciding what a human should look at first
- Making your own documentation searchable in plain language
- Summarising long regulatory or audit material
Where they will let you down
- Anything requiring exact arithmetic or counting
- Being the sole determinant of a compliance conclusion
- Legal interpretation presented as settled advice
- Deterministic evidence handling that must reproduce exactly
- Processing untrusted external content with broad access
- Tasks where a plausible wrong answer is worse than none
A Realistic Maturity Path
Nobody jumps from spreadsheets to autonomous agents. Each stage makes the next one cheaper, and most organisations get the majority of the benefit by stage three.
Consolidate
One control library, one evidence store, one source of truth. Stop duplicating per framework before automating anything.
Integrate
Replace manual collection with API pulls from the systems that already hold the facts. Evidence becomes a query.
Continuous
Controls tested on change rather than on schedule. Drift alerts replace quarterly discovery. Audit prep collapses.
Agentic
Narrow agents run defined processes end to end, gated by human approval on anything consequential.