An audit trail for AI data, built for the EU AI Act era.
Article 12 of the EU AI Act asks high-risk AI systems for automatic record-keeping — traceability across the system's lifetime. The hard half is proving what data the system saw at decision time. Every Dynamic Feed response is signed and timestamped, and any decision input can be notarized into a public, Bitcoin-anchored log. Evidence, not assertions.
The call
Signed data in, witnessed records out. Each step is independently verifiable against the published key — your auditor doesn't have to trust you, or us.
# 1) ground the decision in signed data (every response is Ed25519-signed)
curl -X POST https://dynamicfeed.ai/v1/batch -H "Content-Type: application/json" \
-d '{"calls":[{"tool":"sanctions_screen","args":{"name":"ACME GMBH"}}]}'
# 2) notarize the exact input your AI acted on (hash-only — nothing sensitive leaves)
curl -X POST https://dynamicfeed.ai/v1/notarize -H "X-API-Key: $KEY" \
-d '{"payload_sha256": "", "subject": "acme-claims-bot"}'
# 3) later, for the auditor: an inclusion proof up to the Bitcoin-anchored head
curl https://dynamicfeed.ai/v1/notary/log/123/proof Sample response
{ "schema": "notary/v1", "mode": "hash_only",
"witnessed_at": "2026-06-12T03:14:09+00:00",
"payload_sha256": "1f4c…", "subject": "acme-claims-bot",
"log": { "idx": 124, "prev_hash": "9b2e…" },
"signature": { "alg": "Ed25519", "key_id": "df-ed25519-…" } }Why live data
When a regulator, auditor or claimant asks what your AI system knew at decision time, a row in your own database is a weak answer — you control that database, so it proves intent at best. A tamper-evident trail needs three properties: the data itself carries provenance and a signature (every Dynamic Feed response does), the record of what your system consumed is witnessed by a neutral party (one POST to /v1/notarize, hash-only mode keeps the content private), and the timeline can't be rewritten (an append-only public log, head anchored to Bitcoin daily). To be plain: this is not legal advice and not a conformity assessment — compliance is a process you run with your counsel. This is the verifiable logging substrate underneath it.
Use it for
- High-risk AI deployers building Article-12-style record-keeping
- Fintech and insurance AI recording decision inputs for disputes
- AI vendors answering enterprise procurement's 'how would we audit it?'
- Post-incident reconstruction: what did the system know, and when
FAQ
Does using this make my AI system EU AI Act compliant?
No — nobody's API can make you compliant, and you should distrust anyone who claims otherwise. Compliance is a process: risk management, documentation, oversight, conformity assessment. What this provides is one verifiable component — tamper-evident records of the data side — that your compliance process can build on. Talk to your counsel.
Why isn't logging to my own database enough?
Because you administer it. Self-kept logs can be edited after the fact, and an auditor knows that. A neutral witness record in a public, append-only, Bitcoin-anchored log is evidence that doesn't depend on trusting you — or us.
What exactly gets recorded?
Whatever you choose: in hash-only mode just a sha256 and a timestamp — the content never leaves your infrastructure. The grounded data itself (sanctions screens, market data, weather, any of the 67 tools) is signed and provenance-stamped at the source.
Does this matter outside the EU?
Yes — the same record-keeping pattern answers auditors, insurers and courts anywhere. The EU AI Act is simply the loudest current driver.
What does it cost?
Signed data is keyless to try; notarizations run on any plan's quota, and the dedicated Notary plan is US$49/month for 10,000 — see /notary.