EU AI Act mapping
How the controls around Anlyon's execution boundary map to the EU AI Act's logging (Article 12) and human-oversight (Article 14) obligations for high-risk AI systems.
The EU AI Act’s obligations for high-risk AI systems apply later than the Act’s general application date, which is set in the regulation’s own text. As of 2026-09-07, the European Commission’s implementation page gives December 2, 2027 for the Annex III categories (Article 6(2): biometrics, critical infrastructure, education, employment, migration and border control), and August 2, 2028 for high-risk systems embedded in regulated products under Annex I (Article 6(1)). The same page says the AI Omnibus entered into force on July 27, 2026.
Anlyon provides mechanisms relevant to record-keeping (Article 12) and human oversight (Article 14). The table below is an engineering mapping, not a finding that a deployment satisfies those articles. The dates are the regulation’s and its amendments’. They are not a sales deadline and they can change. Confirm them against the European Commission’s implementation page and the regulation, and assess the requirements for your system and role.
Article 12: Record-keeping and logging
The Act requires high-risk systems to automatically record events over their lifetime, to a degree that enables traceability of the system’s functioning.
| Obligation | Anlyon mechanism |
|---|---|
| Recording relevant events | Hosted invocation and approval records cover the Anlyon execution path. Instrument external model and tool activity in your application. Using Anlyon does not automatically record every outside operation. |
| Traceability of functioning | Each run is a tree of spans on one timeline. X-Request-Id correlates the API request into run metadata and span attributes. |
| Decision attribution | Approval records retain the decider and policy information. Action versions are appended and never rewritten. |
| Retention & export | Configure retention and export for your obligations. Early Beta Access has 14-day trace retention. Paid plans with longer retention arrive after the beta. Check current terms and analytics. |
Traces, spans, and approvals are never metered on any plan. Logging you are obligated to keep is not something we bill you to keep.
Article 14: Human oversight
The Act requires that high-risk systems can be effectively overseen by humans, including, under Article 14(4), the ability to intervene, interrupt, or halt the system.
| Obligation | Anlyon mechanism |
|---|---|
| Review consequential actions | Hosted actions can require a decision before Anlyon dispatches. Local gates depend on your code using the wrapper and do not establish what outside code executed. |
| Separate decision authority | The requesting credential cannot decide its own approval. API-key quorum counts credentials, not necessarily distinct people. Use authenticated human reviewers when the workflow requires people. |
| Ability to halt / interrupt | Environment halt stops new dispatch after the halt check. A request already accepted by an external provider is not recalled. |
| Correct future behavior | Rollback repoints subsequent invocations to pinned action definitions. It does not reverse an external effect already dispatched. Recovery or compensation is separate work. |
| Oversight is recorded | An approval decision records the decider, a timestamp and the note when one is given. An environment halt records its reason and a timestamp. |
A concrete oversight loop
- A policy routes a risky action to
require_approval(optionally N-of-M). See Approvals & policies. - A human approves or denies in the dashboard. The decision, decider, and policy version are recorded.
- If something looks wrong, an operator halts the environment to stop new dispatch. Investigate already dispatched work separately. See Environments & the kill switch.
- A bad version is rolled back by pointer. See Immutable versions & rollback.
- When the calls carry a
runId, the approval wait, the decision and the invocation are on one exportable trace.