The questionnaire that asks how you govern AI

An AI policy in a wiki page is a statement of intent. An auditor, and increasingly a customer, wants to see what was enforced, when, and what happened when it was not.

The problem

The question usually arrives from outside. A customer security questionnaire grows an AI section, or a SOC 2 or ISO 27001 audit puts AI usage in scope, and the honest answer to "how do you govern this" turns out to be a document that nobody can evidence.

The gap is not the writing. Most organisations produce a sensible AI policy within a week of needing one. The gap is that nothing in the stack can show which tools were actually used, what was actually sent, or what happened the day the policy was breached.

Intent is not a control. A rule that cannot produce a record of its own decisions is, from the outside, indistinguishable from no rule at all.

What turns a policy into evidence

1. 01

   A written rule that runs

   A guardrail is a condition, an action and a mode, which is the machine-readable form of a sentence already in your policy. "Do not put credentials into AI tools" becomes a secret-pack detector with a mask action, running in monitor mode until you trust it.

2. 02

   A decision log

   Every evaluation leaves a record: device, user, tool, rule, action taken, timestamp. That record is the evidence, and it exists whether the rule blocked, masked, or only noted.

3. 03

   An inventory to scope against

   Discovery answers which AI tools are actually in use. It is the first question an auditor asks and the one a self-reported list reliably gets wrong.

4. 04

   Export, not screenshots

   Findings and decisions come out of the console as data, so the evidence pack for an audit window is assembled rather than reconstructed the week before.

What you get

What it does not do today

• —This produces evidence, not certification. No product makes an organisation SOC 2 or ISO 27001 compliant; this produces artefacts an auditor can accept for the controls that touch AI use.
• —Policy scoping by device group is not in this release. Policies apply org-wide today, with per-group scoping in development.
• —Enforcement is on the prompt surface of deeply captured endpoints. Other planes are recorded rather than blocked, and the log is explicit about which.
• —We are not lawyers, and none of this is advice about your obligations under any particular regime.

Frequently asked questions

Does this make us compliant?

No product does. Compliance is a set of controls plus evidence that they operated; this produces the evidence for the ones that touch AI usage. An auditor still has to accept it, and they will ask what is not covered, which is why the limits are on this page rather than in a footnote.

What does an auditor actually want to see?

Usually three things: what is in scope, what the control does, and proof that it operated during the period. An inventory answers the first, a guardrail definition the second, and the decision log the third.

Can we keep prompt content out of the system entirely?

Yes. Storing captured content is opt-in and retention is configurable, so you can keep the detections and the decision log without keeping an archive of what people typed.

Who can see what was captured?

Access is scoped to your organisation, and alert bodies carry metadata only. A webhook posting into a shared channel does not expose the thing that triggered it.

Keep reading

• Shadow AI discovery The inventory the scope question depends on.
• The platform What is captured at which fidelity, and where the data goes.
• AI DLP, defined What the term means here, and how it differs from the DLP you own.