The receipt problem with AI

Imagine an AI assistant preparing a payment for review. A week later, a finance lead needs to understand why a particular account was selected. A screenshot of the assistant's answer might help, but the reviewer also needs the source instruction, the approved details and the payment system's result.

This is a hypothetical workflow. The useful question is concrete: can another person inspect the same evidence without depending on the operator's dashboard or memory?

Keep the logs. Make the handover checkable.

Logs, approvals and transaction records can all be valuable evidence. Their quality depends on what they capture, who can change them, how they are retained and whether a reviewer can interpret them. A signed receipt adds a portable integrity check for a specific assertion.

Aqta's published v1 format records the gateway's enforcement decision for an LLM request, including a request hash, model identifier and policy identifiers. Verification checks the signed bytes against the expected public key^[1]. It does not turn that gateway record into a complete account of the wider workflow.

The public key is public. The signing key is private.

The issuer signs with a private key. Reviewers use the public verification key. They must establish which public key they trust independently of the receipt they are checking; an attacker could otherwise supply their own signed record and key.

A successful check establishes that the signed content verifies under that key. Assess the assertion's accuracy, coverage of events, external execution and independent time evidence separately: signature verification alone establishes none of them.

One decision, five review questions

1. What was recorded? Identify the exact assertion and the system making it.
2. What does it refer to? Retain the authorised source material and the canonicalisation needed to check any hash.
3. Who approved the action? Keep the approval and its precise scope where the workflow requires one.
4. What actually happened? Join the record to the executing system's acknowledgement or failure.
5. What could be missing? Reconcile against an independent inventory or expected sequence, and record gaps.

These questions define a review pack, not fields all supplied by a v1 receipt. A hash can help compare retained content with a commitment; it cannot recover missing content. Sensitive source material still needs appropriate access and retention controls.

What the rules do and do not say

For financial entities within its scope, DORA addresses documented ICT risk management, with proportionality and specific exceptions. Article 6 does not prescribe Aqta receipts^[2]. Bank model-risk guidance separately addresses model validation and monitoring; the Federal Reserve expressly describes its current guidance as non-prescriptive and not enforceable standards^[3].

The EU AI Act's Article 12 concerns automatic event recording for high-risk AI systems. That is a scoped record-keeping provision, not a universal requirement to sign every AI decision^[4]. A receipt format alone cannot establish that an organisation meets any of these frameworks.

Start with the reviewer's question

Before adding another dashboard, take one real review question and list the artefacts needed to answer it. Then test whether a colleague can follow the record, verify its integrity and identify its limits without a guided tour. That is where a signed receipt earns its place: one checkable part of a useful evidence pack.

Correction, 8 November 2026: Clarified the public verification key, narrowed legal claims, and separated record integrity from truth, completeness, timing and execution.