EU AI Act Position Statement
Regulation (EU) 2024/1689 — the Artificial Intelligence Act
Operator TUARA KURI LIMITED, trading as AgenticRail
Jurisdiction New Zealand, serving users globally including the European Union
Contact hello@agenticrail.nz
1. AgenticRail is not an AI system
Not in any sense, and not under the Regulation's definition either. There is no model, no inference, no training data and no adaptiveness anywhere in the enforcement path. This is the first thing to establish, because everything else follows from it.
The operative word is infers. AgenticRail infers nothing. It receives a payload, applies a fixed set of rules to it, and returns ALLOW, DENY or HALT. The verdict is a function of the request and the sequence's own recorded position — nothing is sampled, weighted or learned, so the same request against the same sequence state always yields the same verdict and the same reason code. It is deterministic, not stateless: replay protection and step order mean a request that was permitted once is correctly refused the second time.
So it falls outside Article 3(1), and holds no obligations of its own under the Regulation. That is a consequence of what the software is, not an exemption it qualified for: the obligations belong to the AI system it sits alongside, and to the parties who provide or deploy that system.
AgenticRail enforces structure. It does not determine meaning, purpose, or correctness.
2. Where the obligations currently stand
Under the Digital Omnibus on AI — proposed by the European Commission on 19 November 2025, with political agreement reached between the Council and Parliament on 7 May 2026 — the high-risk obligations moved:
- Stand-alone Annex III high-risk systems: from 2 August 2026 to 2 December 2027
- High-risk AI embedded in products regulated under Annex I: to 2 August 2028
- The Article 50 transparency rules and the Article 4 AI literacy duty were not deferred
The substance of the obligations did not change. The deferral was granted because the harmonised technical standards defining how to satisfy them were unfinished. That is now changing: ISO/IEC 24970 on AI system logging reached Final Draft International Standard stage on 18 May 2026, and its European counterpart prEN 18229-1 is at Enquiry with public comment open until 20 August 2026.
3. Role under the Regulation
Article 3(3) defines a provider as a party that develops an AI system and places it on the market or puts it into service under its own name. Article 3(4) defines a deployer as a party using an AI system under its own authority.
AgenticRail is neither. It does not develop, place on the market, or operate any AI system. It does not determine the purpose of your system, define its outputs or decision logic, or establish its risk classification. It is a component used by whichever party holds those roles.
| AgenticRail | The customer |
|---|---|
| Validates the structure of a submitted payload | Defines the purpose of the AI system |
| Enforces declared step order, replay protection and sealing | Determines whether that system is high-risk |
| Applies the policy constraints configured for the sequence | Configures those constraints to reflect its own obligations |
| Refuses invalid or out-of-order execution and records the refusal | Implements human oversight, risk management and data governance |
| Produces signed, chained, independently checkable enforcement records | Retains those records and answers to authorities for them |
4. Article 12 in detail
Article 12 is the obligation this product is closest to, so it is worth being exact about what it says rather than what it is usually summarised as saying.
12(1). "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system."
12(2). "In order to ensure a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose of the system, logging capabilities shall enable the recording of events relevant for: (a) identifying situations that may result in the high-risk AI system presenting a risk within the meaning of Article 79(1) or in a substantial modification; (b) facilitating the post-market monitoring referred to in Article 72; and (c) monitoring the operation of high-risk AI systems referred to in Article 26(5)."
Regulation (EU) 2024/1689, Article 12(1) and 12(2)For a non-biometric high-risk system, that is the entire requirement. Article 12 specifies what logs must be good for, not what they must contain — no field list, no format, and no retention period. Retention lives in Article 26(6) for deployers and Article 19 for providers, both on a floor of at least six months, with Article 19 qualified to logs that are under the provider's control.
Article 12(3) applies to remote biometric identification only
Article 12(3) contains the one concrete minimum content list in the article — period of use, reference database, matching input data, and identification of the natural persons involved in verification. It opens with the words "For high-risk AI systems referred to in point 1(a) of Annex III", and Annex III point 1(a) is remote biometric identification, expressly excluding biometric verification whose sole purpose is confirming a person is who they claim to be.
That list does not apply to credit scoring, employment, education, healthcare triage, or any other Annex III category. AgenticRail does not record the identity of natural persons, and for a non-biometric system that is not a gap, because the Regulation does not ask for it.
What the enforcement record contributes, under 12(2)(a)
Of the three purposes in Article 12(2), (b) and (c) are continuous-observation duties that a competent application log serves. (a) is structurally different. It concerns situations that may result in the system presenting a risk within the meaning of Article 79(1) — risks to the health, safety or fundamental rights of persons.
A situation in which an agent attempted a harmful action and was refused before it ran produces no action, therefore no output, therefore nothing for a record written after the fact to describe. A refusal can only be recorded by whatever performed the refusal, at the moment it performed it.
AgenticRail produces such a record on every evaluated step, permitted or refused. Each carries the step and function presented, the action type, the position in the declared sequence, the decision, and on a refusal a machine-readable reason code. The record is constructed and signed with Ed25519 at the moment of the decision, before the gate returns a verdict to the caller; the durable write is dispatched at the same moment and completes independently, so storage latency can never delay or block enforcement.
5. Article by article
| Provision | Position |
|---|---|
| Art. 9 Risk management | Not addressed. A record can evidence that a process ran. It cannot conduct a risk assessment or construct a safety case. That judgement is about your specific system and remains yours. |
| Art. 10 Data and data governance | Not addressed. The gate does not see, evaluate or govern training data or model outputs. It records that a step ran in the declared order and says nothing about whether the underlying decision was accurate, fair or free of bias. |
| Art. 11 & Annex IV — Technical documentation | Contributes. A per-sequence report can be produced on demand as a documentation artefact. It is one input to the technical file, not the file. |
| Art. 12 Record-keeping | Contributes, and most directly under 12(2)(a). Records generated automatically at infrastructure level rather than by the application, including records of refused actions that produce no output of their own. See section 4. |
| Art. 13 Transparency and provision of information to deployers | Not addressed. Article 13 obliges the provider to supply deployers with instructions for use covering the system's capabilities, limitations and intended purpose. That is a documentation obligation about your system, which no enforcement layer can author on your behalf. Disclosure to the people an AI system interacts with is a separate duty under Article 50. |
| Art. 14 Human oversight | Not addressed. The gate can require that a human-gated step was passed and can bind whatever token you supply as evidence that it occurred. It cannot establish that a person read, understood or meaningfully considered anything. Effective oversight remains the deployer's obligation. |
| Art. 15 Accuracy, robustness, cybersecurity | Not addressed. Testing a model's accuracy and robustness is a separate discipline with separate evidence. Determinism in the enforcement layer says nothing about the behaviour of the system being enforced. |
| Art. 19 Provider log retention | Contributes. Records remain independently checkable across the six-month floor and beyond, for logs under the provider's control. |
| Art. 26(5) Deployer monitoring | Contributes. Refusals form a structured signal rather than anomalies inferred from unstructured output. |
| Art. 26(6) Deployer log retention | Contributes. Signed, chained records held for the retention period, verifiable without the operator's cooperation. |
| Art. 72 Post-market monitoring | Contributes. Enforcement records are monitoring evidence, recorded automatically rather than assembled later. |
Four contributions and five explicit absences is the honest shape of a component. No product satisfies the EU AI Act, because the Regulation places obligations on providers and deployers rather than on the tools they use. Any vendor claiming otherwise is describing something the Regulation does not contain.
6. Limits worth stating plainly
Sealing is detectable, not impossible. A sealed sequence cannot be reopened or rewritten without leaving a detectable break in the hash chain. A single altered record is caught immediately. A full downstream rewrite by a holder of the signing keys is not caught by the chain alone — only an independently held copy catches that, which is why a second archive exists under a separate credential.
Timestamps are signed, not attested. The signature covers the timestamp, so the value cannot be altered after signing without breaking verification. It does not establish that the value is true, because we generate it. A record of when something ran is accurate; proof of when, in the sense a timestamping authority provides, is a different thing and is not claimed.
A record establishes sequence, not correctness. It shows that the required steps occurred in the declared order. It does not show that any of them reached the right answer.
No certification is held or claimed. AgenticRail is not SOC 2 audited and not ISO 27001 or ISO/IEC 42001 certified, and this statement is not a conformity assessment. Conformity assessment for Annex III systems involves a notified body where the Regulation requires one, and no supplier can perform it on your behalf.
7. Data protection
The enforcement path operates on structural metadata — step names, function names, action types, sequence identifiers, nonces and timestamps — and is designed so that personal data need not be submitted to it. Request inputs are hashed rather than stored in the record.
One field behaves differently and is worth knowing about: the optional attestation object is published verbatim in the sequence report rather than hashed, because evidence nobody can read proves nothing. On a public demo sequence that report requires no key, so anything placed in attestation on a demo sequence is world-readable. Treat it as a publication surface, not a private field.
Processing terms are in the Data Processing Agreement; handling is described in the Privacy Policy.
8. How to check every claim on this page
The regulatory statements are quoted from Regulation (EU) 2024/1689 and can be read at source. The claims about the mechanism can be checked directly, without contacting us:
- Run a real multi-step sequence against the production gate on the demo page. It returns a sequence identifier.
- Paste that identifier into the verification tool, or request the report as JSON. No key is required for a demo sequence.
- The report is self-contained. Each record carries its raw signature and
signed_canonical, the byte-exact preimage that was signed, and the report carries the public keys inline underverification.public_keysin both SPKI and JWK form. Run Ed25519 verification in your own code, offline, with no second request and no call back to us.
The verifier answers any client, with or without a browser. That is deliberate: an off-ramp only a browser can reach is not an off-ramp.
If anything on this page does not match the live system, the live system is the authority and this page is wrong. Tell us and it will be corrected.
Changes in this version. States the Article 3(1) position that AgenticRail is not an AI system, and the Article 3(3)/3(4) position that it is neither provider nor deployer. Sets out the Digital Omnibus deferral to 2 December 2027 and 2 August 2028. Rewrites the Article 12 section against the text: 12(2)(a) identified as the operative purpose, 12(3) confined to remote biometric identification under Annex III point 1(a), and retention attributed to Articles 26(6) and 19 rather than to Article 12. Adds Articles 13 and 15 to the not-addressed list alongside Articles 9, 10 and 14. Adds the limits section covering seal detectability, timestamp attestation, and the absence of certification. Adds the
attestation field's publication behaviour. The document fingerprint block carried by v2.5 and earlier is not continued, in line with the other versioned documents on this domain.Status. Informational. Not legal advice, not a certification, and not a conformity assessment.