How to prove what your AI did with a customer's data
The short answer
Senthex records what your AI did as a metadata-first audit trail: for every call it logs the model, the shield verdicts and scores, timestamps and token counts. In the verifiable-audit pilot (v1.1.7), records are chained with SHA-256 and anchored to an RFC 3161 timestamp, so an auditor can verify the trail offline — tamper-evident, not tamper-proof.
What exactly does Senthex record on every call?
Senthex is a reverse proxy that sits between your app and the model provider, so it sees every request and response in flight. By design it logs metadata, not raw prompts and completions:
- the model and provider routed to, and the request status;
- each shield's verdict, score and rule version (what fired, and why);
- timestamps and token counts.
Raw request and response bodies are excluded from storage by default (data minimisation). That is enough to answer "what did the model see, what did it return, and which controls ran" without turning your audit log into a second copy of your customers' data.
Can an auditor verify the trail without trusting Senthex?
That is the point of the verifiable-audit pilot (v1.1.7). Records are linked into a SHA-256 hash chain, and the head of the chain is anchored to an RFC 3161 trusted timestamp. An offline verifier recomputes the chain and checks the timestamp token against the authority's public certificate — on the auditor's own machine, with no call back to Senthex. "Verify, don't trust" only holds if they don't have to take our word for it. You can run that check in your browser on a real (synthetic) bundle right now.
Is the audit trail tamper-proof?
No — and we never claim it is. Software logs cannot prevent change. A hash chain makes any change detectable: edit one byte and the recomputed chain no longer matches. An independent RFC 3161 timestamp stops silent backdating. That is the honest, defensible claim — tamper-evident, not tamper-proof — and it is exactly what an auditor needs. We wrote up the distinction in full.
How does this map to the EU AI Act?
Record-keeping maps to Article 12 (generate the logs) and Article 19 (retain them — at least six months) — not Article 15, which covers accuracy, robustness and cybersecurity. Keeping the two distinct matters in your technical documentation: no single vendor makes you compliant with Article 15, because that is a system-level duty. Senthex gives you operational evidence to cite, not a certificate to wave. The EU AI Act page maps each control line by line.
What's in the pilot versus the published release?
We are explicit about this so it never surprises you in a technical review. The published release does metadata logging — model, shield verdicts and scores, timestamps, token counts. The verifiable, tamper-evident chain (SHA-256 + RFC 3161 + offline verifier) is a pilot capability (v1.1.7), not yet the published release. The demo timestamp uses freeTSA, a public demo authority that is not eIDAS-qualified; production uses a qualified eIDAS timestamp (QTSP) with the identical RFC 3161 mechanism.
After an incident, can you answer these?
| Question a regulator or customer asks | Ordinary app / database logs | Senthex verifiable audit trail (pilot v1.1.7) |
|---|---|---|
| Prove the record wasn't edited afterward? | No — the app that writes the log can rewrite it | Yes — a SHA-256 hash chain makes any edit detectable (tamper-evident) |
| Let an auditor verify without calling you? | No | Yes — an offline verifier recomputes the chain on their own machine |
| Independent proof it wasn't backdated? | No | RFC 3161 timestamp anchors the chain head (demo: freeTSA, not eIDAS-qualified; production: qualified eIDAS QTSP, same mechanism) |
| Prove the trail is complete? | No | No — a bundle verifies what was exported, not what was never logged |
| EU AI Act record-keeping? | Ad hoc | Designed for Articles 12 & 19 — not Article 15 |
Frequently asked questions
How do I prove what my AI did with customer data?
Senthex keeps a metadata-first, per-call record — model, shield verdicts and scores, timestamps, token counts. In the pilot (v1.1.7) those records are chained with SHA-256 and anchored to an RFC 3161 timestamp, and an offline verifier lets anyone re-check the chain. The published release does the metadata logging; the verifiable, tamper-evident chain is a pilot.
Is the audit trail tamper-proof?
No. We say tamper-evident, never tamper-proof. Software logs can't prevent change; a hash chain makes any change detectable, and an independent RFC 3161 timestamp stops silent backdating. That is the honest, defensible claim — and it is what an auditor actually needs.
Can an auditor verify it without trusting Senthex?
Yes. The offline verifier recomputes the SHA-256 chain and checks the timestamp token against the authority's public certificate, on the auditor's own laptop — no Senthex servers or database required. Verify, don't trust only holds if they don't have to call us.
Which EU AI Act articles does this map to?
Record-keeping maps to Article 12 (generate the logs) and Article 19 (retain them, at least six months) — not Article 15, which covers accuracy, robustness and cybersecurity. Keep the two distinct in your technical documentation.
Is the timestamp legally recognised?
The public demo uses freeTSA, which is not eIDAS-qualified. Production uses a qualified eIDAS timestamp from a QTSP, with the identical RFC 3161 mechanism. Don't let anyone present a demo timestamp as a qualified eIDAS one.
See a real proof, then ship
Run the in-browser verification on a real (synthetic) audit bundle — change one byte and watch the chain catch it. When you're ready, the Free plan (1,000 requests/month, no card) gives you the same shields and metadata dashboard; Business adds longer log retention, higher request limits, and the OWASP LLM Top 10 report.