Strictly, the EU AI Act (Regulation 2024/1689) does not use the word 'tamper-proof'; it requires automatic logging under Article 12 and traceability under Article 13 whose integrity can be relied on for post-market monitoring, conformity assessment, and supervisory investigation. In practice this means tamper-evident: any modification to a log record must be detectable. The accepted technical control is cryptographic sealing of each record and independent attestation. NexArt Certified Execution Records implement exactly that: SHA-256 certificateHash over protected fields, Ed25519 signature from the NexArt attestation node, offline verification with no vendor dependency.
Terminology: tamper-evident, not tamper-proof
No practical system is truly tamper-proof; any file can be deleted or overwritten. Tamper-evident is the correct term: modification is detectable, so a third party can distinguish an intact record from an altered one. Some sources use 'tamper-proof' colloquially. The EU AI Act text itself does not use either phrase, but supervisory authorities and standards bodies converge on tamper-evident cryptographic sealing as the concrete control.
What the Act actually says
Article 12 requires high-risk AI systems to automatically record events over their lifetime. Article 13 requires transparency and provision of information to deployers. Article 20 requires providers to keep the logs for at least six months. Article 72 requires a post-market monitoring system able to analyse those records. Across these obligations, the operational assumption is that the records can be relied on: an operator who cannot demonstrate integrity of their logs is exposed on investigation.
The technical control that satisfies it
Each AI execution produces a Certified Execution Record: input, output, model identity, parameters, and context, sealed with a SHA-256 certificateHash over protected fields. The bundle is signed with Ed25519 by the NexArt attestation node. When present, an external timestamp provides additional third-party time evidence. Any later modification to a protected field invalidates the hash; any modification to the signed bundle invalidates the signature. Verification uses only the record and the published public key, offline, with no vendor dependency.
How this maps to compliance workflow
You attach CERs to your Article 11 technical documentation. You retain them under Article 20 wherever you already retain logs. On a supervisory request, you hand over the relevant CERs; the authority verifies them independently. This gives your Article 12 logs an integrity property they do not have on their own, and lets a supervisory authority proceed without having to trust your infrastructure.
Related questions
Is cryptographic sealing mandatory under the EU AI Act?
The Act does not mandate a specific cryptographic scheme. It requires automatic logging that can support post-market monitoring and conformity assessment. Cryptographic sealing is the accepted technical control that makes those logs reliable enough for that purpose.
Do I need to seal every event or only high-risk decisions?
Article 12 covers events relevant to identifying risk situations and substantial modifications. In practice, sealing every AI decision keeps you well inside the requirement and avoids arguments about which events qualified.
How does NexArt handle sensitive content in sealed logs?
Confidential execution replaces sensitive input and output fields with keyed hashes before it is written into the confidential proof record. The record is still fully verifiable; the permanent proof record contains only commitments (raw content is processed transiently at the node and is excluded from the persisted record).