Your logs record what happened. Can an independent reviewer trust them?
Article 12 requires high-risk AI systems to support automatic event logging. It does not prescribe Secoya or require cryptographic sealing. The practical evidence question is what an organisation can later establish about a particular decision without asking the originating system to validate its own history.
When the high-risk obligations apply
The EU’s AI Omnibus entered into force on 27 July 2026 and changed the implementation timetable. Earlier summaries that give 2 August 2026 as the general Article 12 deadline are now out of date.
| Date | Position |
|---|---|
| 2 Aug 2026 | Article 50 transparency obligations begin applying; this is not the general high-risk Article 12 date. |
| 2 Dec 2027 | High-risk rules apply to the Annex III categories, including biometrics, critical infrastructure, education, employment and access to essential services. |
| 2 Aug 2028 | High-risk rules apply to AI systems embedded in regulated Annex I products. |
Article 19 requires providers to keep automatically generated logs under their control for a period appropriate to the system’s intended purpose and for at least six months, unless applicable EU or national law provides otherwise. Article 26(6) imposes the corresponding minimum on deployers for logs under their control.
Primary sources: European Commission — AI Omnibus enters into force and Regulation (EU) 2024/1689.
Logging and evidential integrity are different controls.
Article 12 requires technical logging capabilities that support traceability, post-market monitoring and operational monitoring. An ordinary application log may satisfy important parts of that requirement. But its evidential weight can still depend on the surrounding access controls, retention system, administrators and vendor platform.
- Observability systems are designed to collect, search and correlate events; they do not automatically bind a business decision to the authority and policy in force.
- Write-once storage can provide strong retention controls, but independent review still depends on the storage platform and its configuration.
- A signature proves control of a signing key, not the truth of the signed statement or the completeness of the surrounding event history.
Secoya is designed to complement required logs by sealing selected high-consequence decisions into portable records that can be checked outside the originating application. It does not, by itself, establish AI Act compliance.
Change the payload and watch its digest stop matching.
This small browser exercise demonstrates one integrity layer: a SHA-384 digest over a deterministic representation of five fields. It is not a complete Secoya Trust Record verification and it does not verify Ed25519 or ML-DSA-65 signatures. The full demonstration is available on the verification demo.
——The initial digest is established when this page loads. Edit a field to demonstrate detection; reload the page to reset it.
What the current Secoya build establishes.
Established by the implementation
- Changes to protected payload or metadata are detected.
- Signatures bind algorithm, key, authority and declared signing time.
- A relying party can enforce its own acceptance policy.
- The `/3` conformance suite has been exercised in TypeScript, Python and Rust.
- RC5’s TypeScript suite passes 118 assertions on Node 24.18.
Not established yet
- That the signed statement is factually true.
- Trusted external time or production protection against record deletion.
- Production key custody, durable replay protection or registry operation.
- Independent cryptographic audit, legal admissibility or regulatory compliance.
- Production assurance from a completed customer pilot.
The transparency demonstration shows how independently retained signed tree heads can expose deletion, rollback and rewritten observed history. It is an in-browser model, not a production transparency service.
Start with one consequential approval.
One controlled workflow, one decision boundary and verification by your own team. The pilot determines the KMS, replay scope, retention period, timestamp jurisdiction and registry arrangement required for the real deployment.