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
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.
| Marking | Means |
|---|---|
| COVERED | The obligation is met and there is linked evidence for it. |
| PARTIALLY COVERED | Some of the obligation is met; the gap is named rather than glossed. |
| CUSTOMER ACTION | Yours 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:
| Verdict | How it is graded |
|---|---|
ANCHORED_VALID | Earns anchored, compliance-grade language. |
SIGNED_PENDING | Reads "readiness — not yet anchored". Sealed is not anchored. |
| Tampered bundle | Refused. The report is never rendered. |
| Incomplete bundle | Returns INSUFFICIENT_PROOF. |
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
- "Show the article-by-article EU AI Act readiness board for our CV screening agent (demo)."
- "Generate the Evidence & Readiness Report from our sealed Witness trail (customer mode)."
- "Which EU AI Act articles are covered, partial, or customer-action for our credit-decision agent?"
- "Generate an evidence-backed EU AI Act report from my Witness chain-proof bundle without sharing my key (attested mode)."
See a generated example
EU AI Act conformance summary (Northwind Bank — demo data) · GDPR Art. 35 DPIA (demo data)