Placing AI in the middle of the obligation-to-evidence chain

Most security and risk functions are using AI somewhere. Few are using it where it matters most. The interesting place for AI in GRC is not the help-desk chatbot or the policy summariser, it is the long, brittle chain that runs from a regulatory obligation landing on the desk to a tested control producing audit-ready evidence in production. That chain is where compliance programmes age, where assurance debt accumulates, and where most teams quietly run out of headcount. It is also the part of the work that lends itself most cleanly to retrieval, structured extraction and agentic execution.

The chain is the product

Strip GRC back to first principles and the value chain is short: an obligation (regulation, contract, framework, internal policy) is decomposed into requirements; requirements are translated into controls; controls are operated; operation produces evidence; evidence is tested; tested evidence becomes assurance to a board, a regulator or a customer. Every step in that chain is a translation problem with a clear input and output schema. Translation problems are exactly where modern language models perform well, provided you treat them as translators and not as oracles.

The mistake teams make is reaching for AI at the ends of the chain, at intake ("summarise this 400-page rule for me") or at output ("draft an audit response"). Both are useful. Neither moves the needle. The middle of the chain, obligation to control, control to evidence, is where time is actually spent, and where the same translation runs thousands of times a year across overlapping frameworks (ISO 27001, ISO 42001, NIST CSF, NIST AI RMF, PCI-DSS, SOC 2, NIS2, DORA, the EU AI Act). Solve it once with structured retrieval and you compound returns every cycle.

Obligation → control: structured extraction, not summarisation

The starting move is to stop asking the model to "read" regulation and start asking it to extract. A small, well-scoped pipeline, clause-level chunking, retrieval against an internal control taxonomy, schema-constrained output, and an SME reviewer, will produce a draft control set that maps to a regulator's language with traceability you can defend in an audit. The output is not "an answer." It is a structured artefact: requirement ID, requirement text, candidate control IDs, proposed delta to existing controls, confidence, and the source spans the model used. The SME's job is to approve, amend or reject, not to read 400 pages from cold.

This is also where ISO 42001 starts paying for itself. Treat each model-assisted pipeline as an AI system with a documented purpose, risk classification, data inputs, intended outputs and human oversight pattern. The same governance you would apply to a vendor-supplied AI service applies to the one your GRC team is running in-house. The framework is the friend, not the bureaucracy.

Control → evidence: where the time actually goes

The single biggest time-sink in modern compliance programmes is evidence collection. Screenshots, ticket exports, configuration dumps, access reviews, the same artefacts gathered manually, every quarter, for every framework. The right pattern here is agentic: small, narrow agents that connect to the source system (the IdP, the ticketing platform, the cloud control plane), pull the evidence on a schedule, hash it, store it with provenance, and post a structured payload into the GRC platform against the relevant control. The model isn't deciding whether the control is effective, it is doing the boring, deterministic plumbing that humans were doing badly.

Continuous control monitoring is the natural endpoint. Once evidence is flowing on a schedule, the question shifts from "do we have evidence?" to "is the control operating within tolerance?" That is a far more useful question for a board, and a far less painful conversation with an auditor.

Where human judgement has to stay

Three places. First, risk acceptance, a model can quantify, contextualise and recommend, but the residual risk owner is a named human accountable to the board. Second, novel obligations, the first time a new regulation lands, an SME has to read it properly; the pipeline is for the next thousand cycles, not the first. Third, anything where the failure mode is asymmetric: privacy decisions, lawful basis, regulator-facing attestations, breach notification thresholds. The cost of a wrong answer dwarfs the cost of a slow one.

The risks are well-rehearsed and real: hallucination, drift, prompt injection from ingested documents, over-reliance, loss of institutional memory if the model becomes the only place a rationale lives. The mitigations are well-rehearsed too, with retrieval-grounded outputs, schema constraints, provenance on every artefact, explicit reviewer steps, evaluation harnesses that re-run on every prompt or model change. None of this is exotic. It is the same engineering rigour any other critical pipeline gets.

What to do on Monday morning

• Pick one framework crosswalk you are currently maintaining by hand. Build the obligation-to-control extractor against it. Measure SME minutes saved per requirement.
• Pick one control with high evidence volume (access review, change management, vulnerability remediation). Stand up a single evidence agent. Make it boring and reliable before you make it clever.
• Put every model-assisted pipeline into your AI inventory under ISO 42001. Risk-classify it. Name an owner. Define the human oversight step in writing.
• Set an evaluation cadence. Re-run a frozen test set on every model upgrade. Treat regression as a Sev-2 incident, not a research finding.

Closing

AI in GRC is not a vision exercise and it is not a productivity slogan. It is a pipeline engineering problem with a regulatory backdrop. Put it in the middle of the chain, give it structure, keep the human in the loop where the failure mode is asymmetric, and the programme starts to move at the speed of the business it protects rather than the speed of the audit cycle it serves.