For Compliance and audit
AI compliance and audit readiness
The gap that will hurt you is not a missing policy. It is a policy that asserts controls you cannot evidence — because an unverifiable claim in front of an auditor is worse than a documented gap.
What you are actually accountable for
You own the difference between what the organisation asserts and what it can demonstrate. That is a narrower and more useful job than owning the policy itself, and in AI it is unusually exposed: most AI policies were written quickly, describe controls nobody instrumented, and have not been tested against a request for evidence. Your value is finding those before an auditor or an enterprise customer does, and converting them into either instrumentation or an honest register entry.
What is landing on you right now
- Customer questionnaires with new AI sections
Enterprise buyers now ask about data handling, subprocessors, model training and agent access to their data. These answers are contractual, and a vague one slows or loses a deal.
- Frameworks arriving faster than practice
NIST's AI RMF, ISO/IEC 42001 and the EU AI Act are all in play, and their requirements land on organisations whose AI usage is largely undocumented. Confirm current text with counsel — this area moves.
- Policies written to look right
Clauses like 'all AI-generated code is reviewed' are common and unverifiable, because you cannot identify which code was AI-generated. They fail on first contact with an evidence request.
- Third-party terms that vary by plan and by account
Retention and training opt-out differ by vendor, by tier, and by whether an employee used a personal account. One vendor answer does not cover one vendor.
Questions you are being asked and cannot answer
the gap
- Can we produce a current inventory of AI systems in use, including tools bought on expense cards?
- Can we evidence — not assert — that a given artefact was reviewed before it was deployed?
- For a specific date, can we show which AI components were in use on which systems?
- Can we demonstrate that AI connectors hold least-privilege access to customer data?
- For each clause in our AI policy, can we name the mechanism that verifies it?
The analysis, from where you are standing
Every AI governance framework, whatever its origin, converges on four demands: know what you are using, know what it can reach, review it before you rely on it, and be able to show all three after the fact. Those are inventory, access control, change review and evidence — the same four things every other control framework wants. That is genuinely good news, because it means your existing programme structure transfers. What does not transfer is the instrumentation, and that is where the audit findings will be.
The specific problem is that AI artefacts are outside every system of record you currently rely on. Change review works because changes go through version control and a pipeline. Skills, rules files, hooks and MCP configurations are copied into per-user locations with no manifest, no version metadata and no diff on update — so 'this was reviewed before deployment' has no evidence trail by default, and neither does 'this is the version that was reviewed'. That single gap undermines the change-review claim for the components most likely to matter.
The most valuable thing you can do this quarter is a claims audit rather than a policy rewrite. Take your AI policy clause by clause and, for each, name the artefact that proves it. Where none exists you have three honest options: build the mechanism, weaken the clause to something checkable, or move it to the risk register as an accepted gap. All three are defensible. Leaving an unevidenced assertion in place is the only option that is not, and it is the current default.
One framing worth carrying into conversations with security and engineering: a documented gap with an owner and a date is a stronger audit position than an asserted control with no evidence. Auditors are experienced at distinguishing the two, and the second reads as a control failure plus a documentation failure. This is also the argument that gets instrumentation funded, because it converts an abstract maturity discussion into a specific, costed list.
What to do — the end state
- Build an AI system inventory that includes card purchases
Procurement records are not an inventory. Reconcile against egress logs, OAuth grants, extension inventories and expense data, and record how each entry was discovered.
- Capture data terms per surface, per plan, in writing
Retention, training opt-out, subprocessors, region. These differ by tier and by whether a personal account was used, so one answer per vendor is not enough. Store it where questionnaires get drafted.
- Run a clause-by-clause claims audit
For each policy requirement, name the evidence artefact. No artefact means build it, weaken the clause, or register the gap. This is the single highest-value exercise on the list.
- Establish an evidence trail for artefact review
Reviewer, date, version reviewed, and what was deployed. Without a version pin, 'we reviewed it' and 'this is what ran' are separate claims and only the first has evidence.
- Document connector access against customer data
Which connectors reach customer data, with which credential and scope, approved by whom. This is the question enterprise questionnaires are converging on and it is answerable today.
- Extend your bill of materials to models and artefacts
CycloneDX has a published ML-BOM capability for models and datasets. The artefact and connector layers have no standard, so document your fields as an explicit extension rather than implying a standard exists.
- Define retention for AI session data deliberately
It contains whatever the agent read, so it inherits your most sensitive context's classification. Set retention against your realistic detection lag, and record the reasoning.
- Test one evidence request end to end
Pick a date and ask for the AI components in use on a system then. The dry run tells you what an audit will find, months earlier and with no consequences.
- Register what you cannot yet evidence
Named gap, named owner, dated remediation, stated interim compensating control. This converts a finding into a plan, which is the difference between a weakness and a failure.
- Delete unverifiable clauses from the policy
Particularly anything requiring detection of AI-generated content. A shorter policy that is entirely true is more defensible than a thorough one that is partly aspirational.
What to do first — the order
- Weeks 1–3 · Inventory
AI system inventory reconciled from discovery sources rather than procurement, plus data terms per surface and plan. Everything downstream needs this denominator.
- Weeks 3–5 · Claims audit
Walk the policy clause by clause naming evidence. Expect the artefact-review and least-privilege clauses to fail first; they are the ones with no system of record.
- Weeks 5–7 · Dry run
Issue yourself an evidence request for a specific past date. This is the cheapest possible simulation of the finding you would otherwise receive live.
- Weeks 7–10 · Close or register
Fix the clauses that are cheap to evidence, weaken the ones that were aspirational, and register the rest with owners and dates. Then align the policy to what is now true.
What to report upward, and the trap in each
- Share of policy clauses with a named verification mechanism
The core readiness number. Track it openly — a rising figure driven by deleting unverifiable clauses is real progress, not gaming.
- AI system inventory completeness and freshness
Report both. A complete inventory from last quarter is a document, not a control, and freshness is what an auditor probes.
- Artefacts with a reviewer, date and pinned version
Evidence coverage for the change-review claim. Without the pin, the review evidence and the deployment evidence do not join up.
- Connectors with documented scope against customer data
Directly answers the fastest-growing questionnaire section, and it is achievable with configuration data you already have.
- Evidence request turnaround
Measured by dry run rather than by whether logging is on. Time-to-evidence is what an audit actually experiences.
Where we fit, in your order
- Vincosha Registry
Gives artefact review an evidence trail that joins up: reviewer, date, pinned version, and which machines received it — which is what the change-review claim needs to be provable.
- Vincosha Assay
Produces a dated scan record per artefact version, turning 'we review artefacts' from an assertion into an artefact you can hand over.
- Vincosha Ledger
Answers the retrospective question — which AI components were in use, where, on a given date — which is the form most evidence requests actually take.
Frequently asked
- Which AI framework should we align to?
- Start with whichever your customers and regulators already reference, and note that the underlying demands converge — inventory, access control, change review, evidence. Building those four well makes alignment to any specific framework mostly a mapping exercise. Confirm current requirements with counsel, since this area is changing quickly.
- Is a documented gap really better than asserting the control?
- Yes, reliably. An asserted control with no evidence reads to an auditor as a control failure and a documentation failure, and it damages the credibility of everything else you claimed. A named gap with an owner, a date and an interim compensating control reads as a functioning risk programme.
- How do we answer questionnaires about AI subprocessors?
- Per surface and per plan, in writing, and include tools that arrived on expense cards — those are frequently the ones with consumer terms. The reconciliation between what procurement approved and what is running is usually where the inaccurate answer originates.
- Can we evidence that AI-generated code was reviewed?
- Generally not, because you cannot reliably identify which code was AI-generated, and any clause premised on that will fail an evidence request. The workable claim is that changes to defined risk classes get defined review regardless of origin — that is verifiable from your existing pipeline and achieves the same control objective.
Sources
Written 2026-07-25. Nothing on this page asserts a statistic we did not gather ourselves, and where a regulatory or standards obligation is mentioned it is described in prose and left to your counsel to confirm against the current text rather than paraphrased as fact.