Guides
EU AI Act evidence for deployers
A clause-level map of the deployer obligations in Articles 12, 14, 26 and 27 to the Immiscible records that evidence them, what Immiscible does not cover, and the evidence pack an auditor can take away.
If your company deploys an AI agent that is part of a high-risk system, the EU AI Act asks you, as the deployer, to keep its logs, to put people in charge of overseeing it, and to be able to stop it. This page maps each of those obligations to the Immiscible record that evidences it, and says plainly what Immiscible does not cover. The evidence pack at the end assembles the records in one download.
This is not legal advice, and the pack does not make anyone compliant. Whether an agent is part of a high-risk system depends on what it is used for (Annex III), and that is your determination. Under Regulation (EU) 2026/1744, which amended the AI Act, the deployer obligations for high-risk systems in Annex III apply from 2 December 2027. Check the current position with whoever owns your compliance.
#The obligations
| Article | Obligation | Status | What evidences it | What Immiscible does not cover |
|---|---|---|---|---|
| Art. 12 | Automatic recording of events (logs) over the lifetime of the system | Partly | Every decision, approval, freeze and change of authority is appended to a hash-chained ledger; the pack verifies the chain. | Immiscible records what passes through it. Events inside the agent or the model that never reach Immiscible are not recorded, and Art. 12 is in the first place a design duty of the provider. |
| Art. 14 | Human oversight: people who can understand, monitor, intervene and stop | Partly | Rules that ask a person or refuse, the people who decide, and a kill switch that stops one agent or every agent. | Art. 14 is built in by the provider. Immiscible adds oversight at the actions it sees; it does not explain the model’s output or train the people who oversee. |
| Art. 26(1) | Use the system in accordance with the provider’s instructions for use | Partly | Signed rules limit each agent to the payments, data and actions the deployer allows, which can mirror the instructions for use. | Immiscible does not hold or check the provider’s instructions for use. |
| Art. 26(2) | Assign human oversight to people with the competence, training, authority and support | Partly | Named overseers per rule, with the authority each holds, the agent’s sponsor and who may stop it. | Competence and training are the deployer’s records; Immiscible lists who holds the authority, not whether they are trained. |
| Art. 26(3) | Other obligations and the deployer’s freedom to organise oversight are unaffected | Not covered | A statement of law, with nothing to record. | |
| Art. 26(4) | Input data under the deployer’s control is relevant and sufficiently representative | Not covered | Immiscible does not assess input data. Data releases are limited to named fields, recipients and purposes, which is not the same thing. | |
| Art. 26(5) | Monitor operation; inform the provider and authorities of risks and serious incidents; suspend use | Partly | Every decision is monitored and recorded; the kill switch suspends an agent or the whole fleet, and its history and drills are in the pack. | Reporting to the provider, the distributor or a market surveillance authority is the deployer’s to do. |
| Art. 26(6) | Keep automatically generated logs under the deployer’s control for at least six months | Evidenced | Ledger records are never purged by retention; the pack shows the oldest record, the export window and whether it reaches six months. | Logs kept by the provider or the model vendor are outside Immiscible. A plan whose export window is under six months does not meet this on its own. |
| Art. 26(11) | Inform natural persons that they are subject to the use of a high-risk system | Not covered | Notices to the people affected are the deployer’s; Immiscible does not send or record them. | |
| Art. 27 | Fundamental rights impact assessment (FRIA), where it applies | Partly | Inputs for the assessment: the agents and their purpose and risk class (Art. 27(1)(a)), the human oversight measures (27(1)(e)) and the measures taken when risks materialise, including stopping an agent (27(1)(f)). | The assessment itself, the categories of people affected, the specific risks of harm and the notice to the market surveillance authority are the deployer’s. |
The records behind these rows are described in Evidence and the kill switch. For what Article 12 logging means for agents in general, see EU AI Act logging for agents.
#The evidence pack
Owners, admins, security admins and auditors can download the pack; other roles are refused. It is GET /api/w/:wid/evidence/ai-act for a signed-in session, which answers JSON (schema: immiscible.ai-act-deployer.v1), or a zip with ?format=zip. From the command line:
immiscible evidence ai-act --out pack.zipThe CLI command is from CLI 0.3.0, which is not yet published on npm. The zip holds:
| File | What it is |
|---|---|
pack.json | The pack as data |
SUMMARY.md | The same facts in words, with the obligations table above |
README.txt | What the files are, and whether the ledger verified when the pack was made |
What the pack holds:
- Integrity: the ledger’s chain checked end to end when the pack is made, with its head and record count. If any record was changed, the pack says the chain does not verify and names the first record that breaks it.
- Agents: each agent with its purpose, autonomy tier, sponsor, who answers for stopping it, and a risk class. The risk class comes from the agent inventory and reflects the permissions the agent holds; it is not an AI Act classification.
- Oversight: for every active rule, the people who decide what it holds for a person and with what authority (owners, admins, approvers, or the named approvers where the workspace names them), any approval chain for payments, and the separation of duties that applies.
- Intervention triggers: each clause of each rule that asks a person or refuses, and the checks that apply whatever the rules say.
- Retention: the oldest and newest ledger record, how far back records can be exported on your plan, the call log and prompt metadata settings, any legal hold, and whether the export window reaches the six months of Art. 26(6).
- Kill switch: agents stopped now, the history of stops and restarts, and the last drill.
- Gateway: model calls counted by model and by where they were served, as in the evidence pack for the gateway, without the records themselves.
The pack carries no prompts, no request summaries and no personal data released from the vault: only counts, settings, rule clauses, the names of the people who oversee, and the ledger’s verification. Making it is recorded in the audit log, which is chained into the ledger.