What Makes Annex IV Documentation Ingestible by Vanta/Drata (and Defensible to an Auditor)

A thread I keep seeing in GRC circles: a team finally sits down to write their Annex IV technical documentation for a high-risk AI system, produces a genuinely thorough Word doc, and then hits the same wall a few weeks later when someone tries to load it into Vanta or Drata as evidence, or hands it to an external auditor who asks "how do I verify this line is still true." The document is complete. It's just not usable as a record.

There's a GitHub Discussion on the riskline project (an open-source Go risk classifier for the EU AI Act) asking almost exactly this question: what shape does GRC evidence need to be in for Vanta, Drata, and auditors to actually accept it. Worth digging into because the answer isn't really about Annex IV's content requirements, which are well covered elsewhere. It's about the structural properties that separate a document from a record.

The document vs. record distinction

Annex IV lists what has to be described: system architecture, design specifications, risk management measures, training data characteristics, human oversight measures, and so on. Most templates get you to a complete document that covers all nine points. That's necessary but not sufficient.

A record, in the GRC-tooling sense, has three properties a static document usually doesn't:

1. Each claim traces to a source artifact (a test run, a config diff, a log line), not just prose asserting the claim is true.
2. Each claim has a timestamp and a version, so "still accurate as of when" is answerable without re-interviewing the engineering team.
3. The whole thing is machine-parseable enough that a compliance platform can diff it against the last version and flag what changed.

Vanta and Drata both work by continuously polling evidence sources (cloud configs, CI logs, ticketing systems) and mapping fresh evidence to controls. A hand-written Annex IV doc from six months ago doesn't participate in that loop at all. It's an island. The tooling has nowhere to attach it except as a static file upload, which is exactly the "trust me" artifact an auditor is trained to be suspicious of.

What "ingestible" concretely means

Practically, this comes down to structuring the documentation as discrete, dated claims with pointers, rather than narrative paragraphs. Instead of:

"The model is regularly evaluated for bias across demographic groups as part of our ongoing risk management process."

You want something closer to:

Fairness evaluation, 2026-08-15, commit a3f9e2, eval suite bias_eval_v3, results: [link to artifact], reviewed by: [name/role]

The second version is a row in a table, not a sentence. It has a date, a version reference, an artifact, and an accountable party. That's the shape both compliance platforms and human auditors want, because it's checkable in under a minute instead of requiring a follow-up conversation.

The Annex IV sections that map most cleanly to this pattern:

• Risk management measures → each mitigation gets a claim row: what was tested, when, against what threshold, with what result
• Human oversight measures → each oversight mechanism gets a claim row: who has override authority, what triggers escalation, when it was last exercised or tested
• Training/validation data characteristics → dataset version, provenance, known limitations, as dated claims rather than a one-time description that goes stale silently

The gap this leaves

None of this replaces the actual engineering work of doing risk management and oversight well. A team that runs no bias evaluations doesn't fix that by writing better-structured documentation, it just makes the absence more visible, which is arguably the point. Structuring evidence this way is really a forcing function: if you can't produce a dated claim with a linked artifact for a given Annex IV section, that's a signal the underlying control doesn't actually exist yet, not just that the paperwork is behind.

We build evidence-pipeline tooling around exactly this problem at Ventrova (disclosure: I'm posting this from the team that builds it, so take the framing with that in mind). The Annex IV generator is built to produce dated, linked claims rather than static prose from the start, and the risk classifier is a useful first step if you haven't yet confirmed whether a given system even falls under the high-risk Annex IV obligations in the first place.

Curious if anyone's actually gotten a hand-written Annex IV doc accepted by Vanta or Drata as-is, or if everyone doing this ends up restructuring it into some kind of evidence table eventually.