01
Obtain the receipt
The receipt identifies one governed interaction. Today it is obtained from the customer whose deployment placed or answered the call; they can export it without asking us.
Regulators and DPOs
What a receipt establishes, and what it does not.
This page is written for someone who has to form a view, not buy something. It sets out how a compliance receipt is checked, which parts of it depend on trusting Audact and which do not, and what our contact with authorities actually amounts to.
Nothing on this page has been reviewed, adopted or endorsed by any authority, and we say so where it matters rather than at the bottom.
Checking a receipt
Four steps, and none of them requires an Audact account.
A receipt is one object per governed interaction. The arithmetic below runs on the object in your hand; the Merkle roots are published at api.audact.ai/v1/metachain.
- 02No key needed
Recompute the hashes
The input hash, the output hash and the link to the receipt before it are recomputable from the receipt itself. A recomputation either matches or it does not.
- 03
Check inclusion in the Merkle root
The receipt carries a Merkle path and an index. Walking the path against the root establishes that this receipt sits in that batch and has not been substituted for another. The roots are published at api.audact.ai/v1/metachain; the call's Article 50 report carries the inclusion proof to verify against the root.
- 04On request
Request the surrounding record
Policy version is exportable per tenant, in JSON and in a form a data protection officer can read.
Receipt explorer Walk a sample chain field by field. No account, no API key.
Sample receipt (JSON) The machine-readable shape, with synthetic values.
Sample receipt (PDF) The same record in a form a DPO can read.
Scope
Which parts do not depend on trusting us, and which do.
This is the part of the evidence model most worth your time. It is stated here exactly as it is stated on the proof page, and it does not get stronger for this audience.
Anyone can check
Three values, recomputable without a key
The input hash, the output hash and the link to the receipt before it. A fourth, inclusion in the Merkle root, is checked against the published root with the inclusion proof from the call's Article 50 report. For the three that stand there is no key, no account and no access to our database: the arithmetic runs on the receipt in your hand.
Key needed
What the key is for
The authentication code is HMAC-SHA256 over the canonical receipt, under a symmetric key held by Audact. Whoever can check the code can also produce it. It evidences that the record is intact, not who wrote it.
What it records
What a receipt is about, and what it is not
A receipt is a faithful record of what the system received, decided and released. That is what it establishes — not whether the world matched it. If a caller gave a wrong name, the receipt records the wrong name faithfully.
One further point, because it is the one most often assumed the other way round. The timestamp on the root is an RFC 3161 timestamp from freeTSA.org, a free public service. It fixes an ordering against our own chain; freeTSA.org is not an eIDAS-qualified trust service, so this is not a qualified timestamp and we do not present it as one.
A later change or reordering of the chain is detectable by recomputation against a retained commitment. That is the property we claim, and we claim nothing stronger than it.
Engagement
Where our contact with authorities actually stands.
Each line says what it is and what it is not. None of it confers status, and none of it should be read as an assessment of Audact by anyone.
Status, August 2026
EU AI Office: response to the Article 50 consultation
3 June 2026
EU AI Pact: voluntary Pillar II commitments
Listed
Article 57 regulatory sandboxes (NL, DE)
Exploratory dialogue
Not a participant
National supervisory authorities
Seeking dialogue
No adoption
Public verification service
In development
No date committed
Acknowledgement of a consultation response is not an endorsement and confers no special status. The AI Pact is a voluntary public commitment; the Commission states the pledges are not legally binding, so signing them is not a certification, not an approval, and creates no legal presumption that a system conforms to the AI Act. No authority has adopted or endorsed this page.
The wider record
What sits around a receipt.
A single interaction is rarely the whole question. The documents below are the ones a supervisory authority or a data protection officer normally asks for next, and they are public.
Trust Center Sub-processors, hosting, retention, and what we hold no certification for.
Security and compliance architecture DPA, sub-processor matrix, liability allocation, and what a DPIA would have to cover (no template published).
Data Processing Agreement Article 28 terms, in full.
Article 50, article by article What the law requires, with the article numbers.
Our Article 50 consultation submission Five positions, published unedited.
Report a vulnerability Coordinated disclosure policy and safe harbour.
Ask directly
A technical briefing, with an engineer in the room.
We make ourselves available for an hour with supervisory authority staff, data protection officers and counsel. Bring the questions this page did not answer; the ones about what the artefact does not establish are the most useful.
- regulators@audact.ai
Please include your role and organisation.
- security@audact.ai
Security disclosures and coordinated vulnerability reports.