Verified Digital Agents → C2MD → EU AI Act Evidence & Readiness Report

EU AI Act Evidence & Readiness Report

An article-by-article readiness board for a specific agent: every relevant obligation marked COVERED, PARTIALLY COVERED or CUSTOMER ACTION, with linked evidence where it exists and concrete, article-anchored steps where it does not.

Live · free tier

This is an evidence-and-readiness map, not a compliance report. Documented is not evidenced, and evidenced is not compliant. Final Compliance-Officer attestation is a human act — the report is built to be reviewed and signed off, not to substitute for that review.

What it covers

Annex III classification plus Articles 5, 9, 10, 11, 12, 13, 14, 15, 27 and 50 — assessed against the agent you describe, not against a generic template.

MarkingMeans
COVEREDThe obligation is met and there is linked evidence for it.
PARTIALLY COVEREDSome of the obligation is met; the gap is named rather than glossed.
CUSTOMER ACTIONYours to do. The report gives the concrete, article-anchored step — not "seek legal advice".

Article 12 is the one that needs a real trail

Article 12 requires record-keeping — automatic logging of events over the system's lifetime. That is the obligation you cannot satisfy with a document, because the evidence is the operational record. This is where the report reads a genuine sealed trail rather than asserting coverage.

Three modes, and what each one proves

demo (default)

Runs on synthetic input with no external calls. Output is labelled SAMPLE — DEMO DATA. Useful for seeing the shape of the board before you connect anything. It proves nothing about your system, and says so on its face.

customer

Reads your real, account-isolated decision trail through VDA Witness's authorised read, and evidences Article 12 live. Requires a Witness API key passed as witness_api_key; that Bearer key is the sole account binding, and account isolation is inherited from Witness rather than chosen by a parameter.

With no key, or an invalid one, the call fails closed. There is deliberately no fall-back to demo data — a report that silently degraded to synthetic input would be worse than no report at all.

attested (key-safe)

You supply your own Witness chain-proof bundle — records, predecessor chain, anchor and DID document, from GET /api/witness/chains/{chainKey}/proof — together with the Article 12 report, and no key at all. A witness_api_key sent to this mode is rejected loudly: never accepted, never logged, never forwarded.

C2MD then verifies that evidence offline, against pinned public infrastructure (did:web plus Sigstore Rekor and RFC-3161 timestamp authorities), making zero calls back to Witness. Article 12 is graded strictly off the verified verdict:

VerdictHow it is graded
ANCHORED_VALIDEarns anchored, compliance-grade language.
SIGNED_PENDINGReads "readiness — not yet anchored". Sealed is not anchored.
Tampered bundleRefused. The report is never rendered.
Incomplete bundleReturns INSUFFICIENT_PROOF.
Why attested mode matters commercially. Your auditor can be handed a report whose Article 12 evidence was verified without anyone — including us — holding your key, and which they can re-verify themselves against public transparency logs. The verification does not depend on trusting VDA.

Where it sits in the governance cycle

C2MD turns standards into governance an agent can follow; ACP holds that governance in git and signs it before agents receive it; HITL captures the human decisions; Witness seals every governed decision. This report is the read-back: it turns the sealed trail into something a compliance officer can review, article by article.

Ask for it in plain language

See a generated example

EU AI Act conformance summary (Northwind Bank — demo data) · GDPR Art. 35 DPIA (demo data)