Every time your AI touches sensitive data, it hands you a receipt.
AYA Receipts consolidates three proofs your agent already produces (what it redacted, that consent existed for the purpose, and that the guardrail actually ran) into one bound, signed bundle for every data-handling turn. Not a policy PDF you wrote once, a receipt tied to the exact moment the data was processed.
See a sample receipt bundle How the three surfaces work
THE PROBLEM
Your agent reads someone's record, redacts the obvious identifiers, checks (you hope) that you had consent, runs a guardrail, and answers. Each of those steps might leave a log, in three different places, in three different shapes. Then a regulator asks what happened to a specific person's data on a specific day, and you are stapling a redaction report to a consent database to a pipeline log, reconstructing after the fact a story you should have captured at the time. The reconstruction is where audits go badly, because a log assembled under pressure looks like exactly what it is. As of August 2, 2026, the EU AI Act turns "prove what your AI did" into a board-level obligation for high-risk systems, so this stops being good hygiene and becomes a requirement with a date on it.
HOW IT WORKS
Receipts does not add a new logging system, it binds together three proofs AYA already emits. For each data-handling turn it classifies the data lane (is this open or locked, does it need consent, does it need de-identification), verifies GDPR consent for the declared purpose and fails closed if there is none, records the consent event into a GDPR Article 12 processing log, runs the de-identification valve, and captures the execution-liveness heartbeat that proves the guardrail ran. Then it consolidates all of it into one bundle (counts, verdicts, and ids only, never the underlying data) and seals it. If a surface is missing, the bundle says so, it does not fake a green check.
WHAT YOU GET (one signed bundle)
For every turn that handled sensitive data, one auditable artifact with three surfaces: - the privacy surface, how many spans were redacted, which categories, how many were restored on the return path, and a loud corruption count if any markers broke, - the consent surface, the consent verdict (consented, denied, or absent, never dressed up), the consent id, the declared purpose and legal basis, and the Article 12 processing-log event, - the execution-liveness surface, a reference to the HMAC heartbeat proving the guardrail actually executed, and whether it is fresh, - a binding hash over all three, and an HMAC signature so the bundle is tamper-evident, not a document anyone could edit later.
Counts and ids, never content. A receipt you can hand to a regulator or a customer without handing over the data it is about.
WHO IT'S FOR
Teams shipping AI agents into regulated or privacy-sensitive workflows, healthcare, fintech, legal, HR, anywhere you owe a data-processing record. And RegTech and compliance platforms who want a per-decision trust surface they can hand to their own customers (that is design partner zero). If your agent processes data a regulator or a court could ask about, this is for you. If it does not touch anything sensitive, you do not need it.
PRICING (the ladder)
We price the ladder, not a single number, and every number below is a hypothesis we validate with you, not a commitment. - Free receipts, on by default for any AYA agent handling sensitive data. The trust surface is the wedge, not the meter. - Compliance, per seat, when you need the durable, queryable Article 12 log, signed-bundle export, and retention controls that an audit actually leans on. - Platform, license the receipt surface into your own product so you can hand per-decision receipts to your customers.
IP is licensed, never assigned. The surface stays ours, the receipts are yours. Any step that takes your money is gated and confirmed before it runs, nothing charges silently.
THE PROOF (dogfood)
We run this discipline on ourselves, and I am going to be precise about how much. Two of the three surfaces are already live on AYA itself, every capability AYA ships terminates as a verification receipt on disk, and every guardrail writes an HMAC heartbeat, which is the same execution-liveness proof this product sells, and the redaction receipt already rides on AYA's own outbound responses today. The build of this very product left a receipt too, the deliverable composes six consent and privacy atoms that were each verified on disk before this page existed.
HONEST NOTE
Here is the part most launch pages leave out. The third surface, the GDPR Article 12 consent log, is built but not yet wired, so AYA does not yet eat all three surfaces end to end, it eats two. No single bundle has been HMAC-signed by our security agent on a live turn yet, that wiring plus one live signed bundle is the first real test, and a partner batch is the one after that. So the honest status is blocked on that last piece of security plumbing, not shippable this afternoon, and I would rather tell you that than imply a proof we have not run. Where a real check exists we give you the receipt, where a surface is missing we say so on the bundle itself, we never manufacture a seal. That refusal to fake certainty is the whole product.
See a sample receipt bundle
*This page is a specification. The capability it describes is not built yet, and nothing here is a claim that it runs today.*