Inside the Vault: AI in GRC, and the gates that make it trustworthy

Most of the Vault is drafted with AI. I think that is a reason to trust it, not a reason to doubt it. The debate about AI in GRC content keeps asking whether a model wrote the words. That's the wrong question. What decides whether you can rely on a page is the system around the model: who checks what, who signs it off, and what the model is never allowed to do. If you're a compliance lead weighing up whether AI-built guidance is safe to act on, or whether your own team should use AI this way, that system is what you should be asking about.

An earlier version of this page said every Vault article starts in a real engagement. That isn't how the Vault is built, so here is how it is.

Why "a practitioner wrote it" is the wrong test

The usual view is simple. Good GRC content comes from experienced people writing by hand, and anything a model touched is suspect. It's a fair instinct. Plenty of AI-generated compliance content is fluent, confident and wrong, and in this field a confident wrong answer costs more than no answer.

But the instinct tests the wrong thing. A practitioner writing alone can still misquote a regulation, cite a date that has moved, or pass off a guess as experience. What protects the reader isn't the author's species. It's whether claims trace to primary sources, whether a separate pass checks them, and whether someone accountable puts their name to the result.

That's the standard I hold the Vault to, and it doesn't depend on who or what produced the first draft.

How the Vault is actually built

GRCMANA is AI native, which means delivery is engineered around AI from the ground up, not bolted on. The Vault is the most visible example of it.

It runs on a simple division of labour. Models handle judgement: drafting, editing, reasoning about what a reader needs. Deterministic workflows handle state: moving a page from one stage to the next, validating outputs, retrying when something fails. The two don't get confused.

In practice, a page goes through five steps:

1. A knowledge layer. Control pages draw on our GRC Wiki, which explains each control in GRCMANA's own words. A model writes those entries. Licensed standard text stays in a separate control library.
2. A draft. A model writes the first version against a written editorial standard.
3. A separate edit. A second model run, working as Chief Editor to a written runbook, re-checks every source, traces every first-person claim and edits the draft. It is not the drafter marking its own work, and it is not the human check. That comes next.
4. My approval. This is the human check. No page leaves the pipeline until I approve it, and the publishing workflow reads nothing else.
5. Publishing by workflow. Once approved, a deterministic workflow publishes the page. No model takes part in publishing.

The workflow itself is the subject of other pages: compliance as code and a unified control library explain the engineering. Here, what matters is where the gates sit.

What the AI is never allowed to do

The boundaries matter more than the model, so here they are:

• It never approves or publishes. In the automated pipeline, a model step returns a result and the workflow checks it before anything changes. Approval is mine, and only a workflow publishes.
• It never invents experience. No first-person claim or client story appears unless it traces to something I have actually said or written. Every number traces to a primary source.
• It never treats competitor pages as sources. They can be read to check coverage. They are never cited or linked.
• The drafting models never see licensed ISO text. The standard's own text stays in our control library. One step reads it: a model session that rewrites each control in our own words for the GRC Wiki, and a verbatim check stops any entry that copies the standard's wording from being saved. The control pages in our ISO 27001 Annex A controls list are drafted from the wiki, never from the standard.

None of these relies on the drafting model policing itself. The verbatim check and the publishing rule are built into the workflows. The rest are checked by the separate edit, and then by me.

What the EU AI Act says about publishing AI-drafted text

Article 50(4) of the EU AI Act requires a deployer of an AI system that generates text published "with the purpose of informing the public on matters of public interest" to disclose that the text was AI-generated. Article 50 has applied since 2 August 2026.

The same paragraph sets out an exception. The duty does not apply where the content "has undergone a process of human review or editorial control" and a person "holds editorial responsibility for the publication of the content". My approval on every page is that control, and GRCMANA holds that responsibility. That is why the approval gate on pieces like this one is never sampled.

Does the Act reach a UK firm at all? Partly. Article 2 covers deployers outside the EU "where the output produced by the AI system is used in the Union". Whether a UK blog read in Dublin counts is not settled, and I wouldn't build a policy on the answer being no. I'd rather the process meets the exception anyway, and say openly how the pages are made, as this one does.

The AI management system standard, ISO/IEC 42001, points the same way: know what AI you run, and govern it. So our AI system inventory records the drafting pipeline and the step that writes the GRC Wiki, each with its inputs, an accountable owner and the controls that bound it.

The strongest objection: AI content is generic, and Google buries it

Here is the case against all of this, put fairly. Models produce the average of what they've read. A library drafted by AI will read like every other library drafted by AI, and search engines are getting better at spotting it and pushing it down. Why build your reference library on that?

The first half has real force. Unchecked, a model does drift towards the generic. That's exactly why the gates exist: the editorial standard, the source checks, the separate edit and my sign-off are there to strip out filler and keep only what the evidence supports.

The second half doesn't match what Google says. Its published guidance on AI-generated content says its systems aim to reward "original, high-quality content" showing experience, expertise, authoritativeness and trustworthiness, with a focus "on the quality of content, rather than how content is produced". What it treats as spam is using automation "with the primary purpose of manipulating ranking". Its own FAQ is blunt: "Using AI doesn't give content any special gains. It's just content." It also suggests AI disclosures where a reader might reasonably ask how a page was made.

So the penalty attaches to low quality and to manipulation, not to the tool. A page that is sourced, checked and signed off is held to the same bar as one typed by hand.

What to do about AI in your own GRC work

If your team is using AI in GRC work, or about to, five moves matter more than which model you pick:

1. Write down what the model may never do. Before choosing a tool, list the boundaries: no unsourced numbers, no invented experience, no final decisions. Rules you can check beat assurances you can't.
2. Keep the model away from state. Let it draft and recommend. Let a deterministic process, or a person, change the record. A model that can update your risk register directly is a control you haven't designed.
3. Separate drafting from review. The step that checks the work should not be the step that produced it. Two passes catch what one pass talks itself out of.
4. Name the person who approves. One accountable human, every time. It's good governance, and under Article 50(4) it may be the difference between needing a disclosure and not.
5. Decide which text each model may see. Standards text under licence, client data and anything confidential need a rule: which models may read them, on what terms, and never the ones drafting public content. Give those models your own summaries instead.

Then put each AI system you use into an inventory, with an owner. That's where governing AI starts, as I argued in who answers when the AI gets it wrong.

Why the Vault is free

Because the economics allow it. Engineering delivery around AI is what lets a lean firm work at mid-market economics, and that makes a reference library cheap enough to give away. The gates above are what stop low-cost production turning into low-quality content. The Vault is the method in public, so you can judge it by the pages.

The model drafts. The gates, and finally a named person, decide what stands. If you want to see the result, start with the ISO 27001 hub and read it as critically as you like.