EU AI Act · Control protocol
A useful matrix does not recite the Regulation. It connects an applicable provision, an expected outcome, an owner, an observable control, a performed test, dated evidence and a decision.
The matrix is built after qualifying the system and each entity’s role. One row addresses one verifiable assertion for one identified version. It never concludes beyond the scope actually tested.
Each field answers a different question. Merging them creates a record that cannot be reviewed; connecting them lets a second examiner reconstruct the conclusion.
Article, paragraph, annex, consolidated text and consultation date.
Triggering fact, relevant role, deadline and rationale.
Precise assertion the arrangement must satisfy.
Technical or organisational mechanism, owner and frequency.
Population, sample, procedure, threshold and failure criterion defined before execution.
Inputs, raw results, version, provenance, integrity and limitation.
Row status, action, decision authority and reopening condition.
For providers, the requirements in Articles 8 to 15 and associated obligations cannot be demonstrated by one document. Each domain receives its own assertions, tests, records and decisions.
| Domain | Basis | Expected control | Test and evidence |
|---|---|---|---|
| Risk | Art. 9 | Continuous process connected to hazards, intended use, foreseeable misuse and residual risk | Replay a scenario, verify metrics and thresholds, retain results and acceptance |
| Data | Art. 10 | Governance of data used for training, validation or testing, as applicable | Examine lineage, quality criteria, relevance, representativeness and relevant bias |
| Documentation | Art. 11 · Annex IV | Technical file consistent with the system presented for examination | Reconcile architecture, versions, performance, limitations and cited records |
| Logs | Art. 12 | Recording capabilities suited to system traceability | Trigger events; verify integrity, timestamps and retrieval |
| Information | Art. 13 | Accurate instructions that a deployer can actually use | Perform a task, limitation and incident response from the instructions alone |
| Human oversight | Art. 14 | Measures designed to understand, monitor, disregard, override or stop as applicable | Test permissions, response time, degraded modes and intervention record |
| Performance and security | Art. 15 | Declared accuracy, robustness and cybersecurity levels maintained | Run relevant nominal, boundary, error, attack and drift scenarios |
| Quality system | Arts. 16–21 · 72–73 | Ownership, change, retention, correction, monitoring and incidents organised | Sample one change and one incident end to end through the decision |
The deployer does not inherit the provider’s matrix. It must demonstrate what it controls in its organisation: configuration, authorised people, input data, monitoring, suspension, logs and information where those duties apply.
| Object | Basis | Expected control | Test and evidence |
|---|---|---|---|
| Use as instructed | Art. 26(1) | Configuration and procedure aligned with instructions for use | Compare active settings, procedure and instruction version |
| Oversight | Art. 26(2) | Competent, trained, authorised and supported people | Role-based exercise, access matrix, training and decision log |
| Input data | Art. 26(4) | Relevance and sufficient representativeness where controlled by the deployer | Sample production inputs, exclusions and relevant sub-populations |
| Monitoring and suspension | Art. 26(5) | Detected signal, named escalation and genuinely available stop | Simulate a risk and incident; measure detection, notification and suspension |
| Logs | Art. 26(6) | Logs under the deployer’s control retained for the applicable period | Extract a period; verify completeness, access, integrity and retention rule |
| Information | Art. 26(7) and (11) | Workers or persons informed when conditions are met | Check content, recipients, timing and proof of delivery |
| Registration and DPIA | Art. 26(8) and (9) | Context-dependent duties examined before use | Verify entity status, EU registration and GDPR interaction |
Evidence is not selected because it is easy to obtain. The protocol starts from the assertion and states in advance what will support, fail or limit the result.
Freeze the system, configuration, data and period under examination.
State an observable outcome without relying on vague verbs such as “manage” or “ensure”.
Define covered cases, exclusions and the sampling strategy.
Describe actions, tools, inputs and calculation rules so the test can be repeated.
Set success threshold, tolerance, severity and expected response before seeing the result.
Retain raw outputs, anomalies, protocol deviations, conclusion and signatory.
A screenshot or unexercised policy may establish a limited fact; it does not by itself demonstrate operational effectiveness. The file retains both the item and the context that permits — or prevents — extrapolation.
The status qualifies one precise assertion. It does not turn one successful row into a general statement of system compliance.
| Status | Condition | Consequence |
|---|---|---|
| Effective | Procedure performed, criterion met and sufficient evidence | Conclusion valid for the tested version and scope |
| Failed | Criterion missed or mechanism unavailable | Finding, severity, owner, due date and closure test |
| Not demonstrated | Missing evidence, unperformed procedure or non-reproducible result | Limitation or finding; no assumed compliance |
| Not applicable | Applicability condition tested and rationale retained | Validated exclusion with a reopening trigger |
| For determination | Disputed interpretation, fact or threshold | Isolated question, named authority and expected decision |
Entirely synthetic example: a high-risk system assists a recruitment decision. Documentation states that the business owner can disregard the recommendation and suspend use.
| Field | Register entry |
|---|---|
| Basis | Articles 14 and 26(2), subject to the retained qualification and role |
| Assertion | The supervisor understands the output, can challenge it and suspend the system during service |
| Procedure | Exercise on the production version with business and administrator profiles, nominal, boundary and incident cases |
| Observation | The recommendation can be disregarded; suspension remains restricted to the administrator profile |
| Evidence | Permission export, exercise recording, timestamped logs and raw results |
| Conclusion | Suspension control failed; named correction and retest required before closure |
The register remains tied to the configuration in service. It distinguishes who operates the control, who produces evidence, who examines it and who accepts residual risk.
Primary sources
Last documentary review: 5 September 2026.
Roles, requirements, post-deployment monitoring and current timeline.
Official text setting, among other changes, the 2 December 2027 Annex III and 2 August 2028 Annex I deadlines.
Provider obligations for high-risk AI systems before and after placing them on the market.
Instructions for use, human oversight, input data, monitoring, logs and information duties.
Before you write to us
It shows that a rule has been stated, not that it operates. The conclusion also depends on the mechanism, owner, procedure performed, result and tested system version.
The structure may be shared, but provisions, responsibilities and evidence are assigned to the qualified role. High-risk system requirements must not be confused with operating duties.
The register states what is missing, why, the alternatives examined and the effect on the conclusion. A material absence becomes a limitation or finding, never assumed compliance.
No. It supports one assertion for the tested version, population and period. The overall conclusion depends on all applicable requirements, limitations, findings and the conformity-assessment procedure where required.
EU AI Act evidence register
We start from the qualification, the version in service and actual responsibilities to build and examine the evidence chain.
Present the system