On August 2, 2026, the EU AI Act's full obligations kicked in. Article 12 requires high-risk AI systems to maintain logs that are sufficient to ensure the traceability of the system's output throughout its lifecycle. Article 13 requires transparency documentation explaining how the system arrived at its decisions.
If you're building an AI agent that makes compliance decisions — onboarding a counterparty, screening a name against sanctions, approving a transaction — those decisions are now subject to Art.12/13 logging requirements if your system operates in or for EU-connected entities.
The problem: most x402 compliance services return a JSON blob with a verdict. That blob is ephemeral. Your agent receives it, acts on it, and it's gone. If an auditor asks "why did your agent approve this counterparty?" you have nothing.
What VeraData ships in every response
Every paid VeraData call returns an audit_aat block:
{
"audit_aat": {
"chain_hash": "sha256:...",
"query_normalized": "bancolombia s a",
"list_snapshots": {
"OFAC_SDN": {
"sha256": "sha256:...",
"fetch_timestamp_utc": "2026-07-08T20:00:00Z",
"entry_count": 19089,
"source_url": "https://www.treasury.gov/ofac/downloads/sdn.csv"
}
},
"screening_threshold": 0.75,
"source_class": "independently_reproducible",
"no_match_claim": {
"claim": "NO_MATCH",
"total_entries_screened": 59454,
"statement": "The name was compared against 59,454 entries. No entry exceeded threshold 0.75. This is an explicit NO_MATCH claim, not a default empty result."
},
"reproducibility_instructions": {
"step_1": "Fetch source_url in list_snapshots[list].source_url",
"step_2": "SHA-256 hash the response body",
"step_3": "Compare against list_snapshots[list].sha256",
"step_4": "Run query_normalized against same dataset at threshold 0.75",
"step_5": "Verdict should reproduce exactly"
}
}
}
source_class: independently_reproducible means exactly what it says. A third party can fetch the same list files, hash them, run the same query at the same threshold, and verify the verdict — including matches: [] for CLEAN results — without asking VeraData anything.
This design was validated in public by an independent verifier (babyblueviper1) on GitHub and refined through a 7-round technical exchange with ANP2 Network on dev.to this week. The current audit_aat schema is the result of that process.
Why this matters specifically for LATAM
SARLAFT (Colombia), CNBV (Mexico), COAF (Brazil), and UAF (Chile) all have AML screening mandates that predate the EU AI Act. An agent transacting in LATAM was already operating in a high-compliance environment. The EU AI Act adds a second layer of logging obligation on top of existing local requirements.
VeraData covers both:
- Local AML: OFAC+UN+EU+UK sanctions, RUES/CNPJ/RFC business registry, PEP screening
- EU AI Act: Art.12 audit trail with SHA-256 chain hash and independently reproducible source snapshots
The practical question
If your agent makes compliance decisions today — even informally, even without calling it "high-risk AI" — do you have an audit trail that satisfies Art.12? Can you show an auditor exactly which version of the OFAC list your agent screened against, at what threshold, and what the explicit claim was for a CLEAN result?
If the answer is no, that's the gap VeraData was built to close.
Trial: X-TRIAL: true header — no wallet, no account, no API key.
https://api.veradata.dev/demo
Top comments (0)