EU AI Act readiness: signed evidence for logging, human oversight and transparency

SURADAR now produces signed evidence for three parts of an EU AI Act programme: automatic event logs, human oversight, and transparency notices. This post maps that evidence to 23 articles of the Act, in 22 rows. SURADAR produces direct evidence for 2 of them. It supplies partial evidence or structured inputs for 17. It does not cover the other 4.

SURADAR does not make an AI system compliant. The provider and the deployer of the AI system decide how they meet the Act. Providers carry out the conformity assessment that applies, with a notified body only where the procedure requires one. Competent authorities supervise and enforce the Act. SURADAR gives those people records they can verify.

Read this first. Glyphzero, Inc. does not certify compliance with the EU AI Act. SURADAR evidence is not a conformity assessment or a certification. This post is an engineering mapping. It is not legal advice. Ask your own counsel how the Act applies to your systems.

What applies now, and what comes next

The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and changed the dates for high-risk systems [2] [3]. Among the parts of the Act that apply today are the Article 5 prohibited practices, which apply from 2 February 2025, and the Article 50 transparency duties, which apply from 2 August 2026 [1] [3]. On 2 December 2026, two new Article 5 bans apply. They cover specified practices that generate or manipulate intimate material of an identifiable person without consent, and child sexual abuse material (CSAM), subject to the scope conditions and exclusions in Article 5(1a) and (1b) [2].

The Omnibus moved Chapter III, Sections 1 to 3 of the Act (Articles 6 to 27, except Article 6(5)) to 2 December 2027 for Annex III high-risk systems and to 2 August 2028 for Annex I high-risk systems [2]. That is 14 months from the date of this post for Annex III. Other articles that concern high-risk systems sit outside those sections, for example Article 49 (registration), Article 72 (post-market monitoring) and Article 73 (serious incidents). The Omnibus did not give them a new date, so the general application date of 2 August 2026 in Article 113 is the date in the text [1] [2]. Ask your counsel how those articles apply to a system before its Chapter III date.

These are general application dates. Transitional rules in Article 111 also apply. A high-risk system placed on the market or put into service before its Chapter III date falls under the Act only if its design changes significantly from that date, but systems for public authorities must comply by 2 August 2030 [2]. Providers of general-purpose AI models placed on the market before 2 August 2025 have until 2 August 2027 [1]. For Annex I products in Section B, Article 2(2) limits which articles apply [2].

Figure 1. EU AI Act application dates after the Digital Omnibus. Spacing is to scale. General application dates; the transitional rules in Article 111 also apply. Sources: Article 113 of the Act as amended, Article 111 as amended [1] [2] [3].

Article 12 record-keeping sits in Chapter III, Section 2. For Annex III systems its date is 2 December 2027, not 2 August 2026 [2]. If you saw “August 2026” for high-risk logging in older material, that date no longer holds for Annex III systems.

Where SURADAR sits in the action path

SURADAR runs one permission check for each agent tool call that your host service routes through it. The check uses five layers: L1 Core Auth, L2 Identity, L3 Transaction Binding, L4 Agent Registry and L5 Governance. The L1 to L8 layers are Glyphzero’s own grouping of SURADAR components. They are not categories from the Act. It returns one of three results: allow, ask a named person, or deny.

SURADAR signs each decision it records. If it cannot build or store that record, it refuses the call. A second signed log records what happened next: not dispatched, refused by a later step, dispatched, and the result. SURADAR reports gaps in that evidence, such as a dispatch with no recorded result. You can export the records as a package and check its public-key signatures offline. Parts signed with shared HMAC-SHA256 keys stay attested by the deployment, not by a public key.

Figure 2. From agent action to auditor. The left column is what SURADAR records. The right column is what the provider and deployer still own.

Coverage by article

The matrix maps each article to the SURADAR layers that produce evidence for it. The layers are Glyphzero’s own grouping of SURADAR components. The last column gives one overall status per article.

Evidence: SURADAR writes signed records that map to the runtime part of the article.
Partial or inputs: SURADAR covers part of the article, or supplies structured records that your own process must complete.
Not covered: the obligation is an organisational process. SURADAR does not do it.

L7 Decision Plane is in development and makes no claim here. L8 Assurance Lab has its first parts merged: statistics for evaluation results and a regression gate.

Figure 3. SURADAR evidence coverage by EU AI Act article. The table below holds the same data in text form.

Article	Topic	Status	What SURADAR produces	What stays with you
4	AI literacy	Partial	Signed training-completion records per person; can be checked at approval time when the host configures a literacy service and training criteria	The measures that support AI literacy of your staff (Article 4 as amended by the Omnibus [2])
5	Prohibited practices	Partial	Signed purpose codes on tools and grants; calls with a prohibited purpose are denied; scoped, expiring exceptions	Deciding which uses are prohibited; practices that never pass through SURADAR
6	High-risk classification	Partial	Signed classification record per system version, from a named reviewer’s answers	The classification decision itself
9	Risk management	Partial	Signed risk register linked to test runs	The risk management system and residual-risk acceptance
10	Data governance	Partial	Signed dataset manifests you import (L5); L6 export of retrieval provenance	Training, validation and test data quality
11	Technical documentation	Partial	Annex IV dossier builder; missing evidence shows as “unknown” and blocks a “complete” result	Dossier content and sign-off
12	Record-keeping	Evidence	Durable signed decision and outcome logs; gap reconciliation; scheduled anchoring	Events outside SURADAR; log storage
13	Instructions for use	Partial	Instructions-for-use generator from registry and evidence records	The text you give deployers
14	Human oversight	Evidence	Signed approvals attributed to rostered people; N-of-M quorum; halt; override requests; a minimum delay after the request; required rationale	Oversight design; choosing and training overseers
15	Accuracy, robustness, cybersecurity	Partial	Signed authentication, replay refusal, tool-call guard, memory poisoning checks, signed evaluation results, imported model test results	Model accuracy and its metrics
17	Quality management	Not covered	Digest references only	The quality management system
18	Documentation keeping	Partial	Ten-year minimum age on deletion requests for technical documentation routed through SURADAR	Keeping all Article 18 documents for 10 years after the system is placed on the market or put into service; storage
19	Automatically generated logs	Partial	Six-month minimum age on deletion requests for decision and audit logs routed through SURADAR; legal hold; signed deletion authorisations; write-once export interface	Setting the retention period the Act and other law require (at least six months, longer if the intended purpose needs it); preserving the logs; storage
26	Deployer duties	Partial	Overseer roster, six-month retention, worker and affected-person notice records, suspend-on-risk records	Most deployer duties
27	Fundamental rights impact assessment (FRIA)	Partial	FRIA status record and reopen flag	The assessment and its conclusions
43	Conformity assessment	Not covered	Nothing	The full assessment
47-48	EU declaration, CE marking	Not covered	Placeholders only; SURADAR never generates them	Drawing up the EU declaration and affixing the CE marking
49	EU database registration	Partial	Export of registration fields; record of your manual submission	Submitting the registration
50	Transparency	Partial	Signed records of the host’s statement that a notice was shown; signed output manifests bound to L6 provenance	Machine-readable marking of AI outputs; deciding which exceptions apply
72	Post-market monitoring	Partial	Monitoring plan object; signed metrics reports; agent interaction summary from host-supplied data; drift per agent	The monitoring plan content
73	Serious incidents	Partial	Incident cases with the 15, 10 and 2 day maximum windows from awareness; corrective-action log	Qualifying the incident; earlier reporting where the Act requires it; sending the report
86	Right to explanation	Partial	Explanations built from signed decision records; durable contest records	Answering the affected person

Totals by row: 2 evidence, 17 partial, 3 not covered (the 47-48 row holds two articles, so 4 articles are not covered).

What the evidence covers, in more detail

Logging (Articles 12, 18, 19 and 26(6)). The Act requires high-risk systems to allow automatic recording of events over their lifetime. Providers and deployers keep logs under their control for a period that suits the intended purpose, at least six months, unless other Union or national law provides otherwise. Providers keep the Article 18 documents for 10 years after the system is placed on the market or put into service [1]. SURADAR writes each recorded permission decision to disk as a signed record. On restart, it rejects records with invalid signatures, broken sequences, or a different log key. Detecting a cut-off tail or a rollback to an older copy needs an external checkpoint and protected storage. Retention rules refuse deletion requests routed through SURADAR before six calendar months for decision and audit logs, and before ten years for technical documentation. A legal hold stops those deletions. Each deletion needs a signed authorisation. A document’s age in SURADAR is not the Article 18 period. Setting the right retention periods and preserving the files stay with you.

Human oversight (Articles 14 and 26(2)). Article 14(4) lists abilities that overseers need, including to disregard, override or reverse an output and to interrupt the system with a stop button or similar procedure that brings it to a halt in a safe state. Article 26(2) requires deployers to assign oversight to people with the necessary competence, training, authority and support [1]. Whether a deployment gives overseers those conditions is for the provider and deployer to judge. Each approver is a named person on a roster, and each approval carries a signature attributed to that person. In the reference deployment profile, the server holds these person keys; a production deployment decides key custody. A policy can require several distinct people to approve. A key rotation does not let one person count twice. An approval binds to one exact action, so changed arguments need a new approval. A halt blocks matching new actions and asks matching running actions to cancel. Downstream services must honour the cancel. If a running action does not confirm the cancel in time, SURADAR records an unknown outcome. It never records that action as reversed.

Prohibited practices (Article 5). Tools carry purpose codes from signed registry entries. Each call takes its purpose from the signed grant, never from the request. SURADAR denies a call when its purpose is on the prohibited list. Exceptions to these software rules are scoped, expire, and come only from a configured policy owner. They are not legal permissions. A policy owner cannot waive Article 5; the operator must establish any exception the law allows and get any authorisation it requires. The rule set already includes the two bans that apply from 2 December 2026 [2]. An operator who enables them now denies those purposes before the legal date.

Transparency (Articles 50, 26(7) and 26(11)). SURADAR signs the host’s statement that a notice was shown, with the reported time and the session, content or subject it applies to. The record does not prove that a person saw or read the notice. Notice kinds cover AI interaction, emotion recognition, biometric categorisation, deepfakes, AI-generated public text, worker notices and affected-person notices. Output manifests bind an output to its L6 memory provenance. When an output has no grounding, the manifest says so. SURADAR does not mark or watermark outputs. Article 50(2) machine-readable marking stays with the provider of the generating AI system [1]. For systems placed on the market before 2 August 2026, that marking duty applies from 2 December 2026 [2].

Monitoring and incidents (Articles 72 and 73). Each monitoring report signs which logs, keys and record counts it used. An interaction report summarises agent-to-agent calls from the chains and events the host supplies. Its signature does not prove those calls took place. Article 73 sets three reporting rules [1]. In general, the provider reports immediately after it establishes a causal link or its reasonable likelihood, and no later than 15 days after awareness. For a widespread infringement or a serious incident under Article 3(49)(b), the report is due immediately and no later than 2 days after awareness, with no wait for a causal link. For a death, the report is due immediately once a causal relationship is established or suspected, and no later than 10 days after awareness. All day counts are outer limits. Incident cases show those maximum windows from the earliest awareness. Your incident process must also meet the earlier reporting the Act requires. SURADAR does not send reports to authorities. Your team sends them and records the receipt.

Documentation and registration (Articles 11, 13 and 49). The dossier builder marks each Annex IV item as evidenced or unknown. “Evidenced” means present and signed, not “satisfactory”. Failed test results stay visible. Registration export fills the database fields that SURADAR knows and leaves the rest as “unknown”.

What SURADAR does not cover

These obligations are organisational. They stay with the provider or the deployer:

The risk management system as a process (Article 9).
Governance of training, validation and test data (Article 10).
The quality management system (Article 17).
Conformity assessment, the EU declaration of conformity and CE marking (Articles 43, 47 and 48).
The conclusions of a fundamental rights impact assessment (Article 27).
Submitting registrations and incident reports to authorities (Articles 49 and 73).
Machine-readable marking of AI-generated content (Article 50(2)).
The decision that a system meets the Act.

Limits we state up front

No single installer yet. The EU features ship as Go packages in the SURADAR module. Your engineers compose them in your host service. A reference EU deployment profile wires classification, Article 5 purpose rules, human approval, durable logs and offline export. Transparency, retention, incident and monitoring records are separate calls.
Scope is the routed path. SURADAR records only the actions that your host routes through it.
Fail-closed start. The EU server profile refuses to start without the purpose rules and, when it serves memory, erasure hooks.
Engineering checks, not legal status. The deployment profile reports which engineering checks its verifier demonstrated. Everything else is “Unknown” or listed as an operator duty. These statuses do not mean a legal obligation is met.
Open items. Rotation and revocation for evidence signing keys are open. The incident workflow keeps cases in memory and restores them from signed snapshots.

Talk to us

If you run AI agents in the EU and want to see the evidence package, write to [email protected].

Glyphzero, Inc. does not certify compliance with the EU AI Act, and this post is not legal advice. Article references are to Regulation (EU) 2024/1689 as amended by the Digital Omnibus on AI.

Sources

Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act), Official Journal of the European Union, English text, Publications Office of the European Union. https://publications.europa.eu/resource/cellar/dc8116a1-3fe6-11ef-865a-01aa75ed71a1.0006.03/DOC_1
Regulation (EU) 2026/1744 of the European Parliament and of the Council of 8 July 2026 (Digital Omnibus on AI), Official Journal of the European Union, L series, 24 July 2026, English text, Publications Office of the European Union. https://publications.europa.eu/resource/cellar/b459c07f-86fb-11f1-bf5e-01aa75ed71a1.0006.03/DOC_1
European Commission, “AI Act” (Shaping Europe’s digital future, regulatory framework for AI). https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai