EU AI Act · Control protocol

Build an EU AI Act matrix that withstands examination

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.

Dr Youssef Trardi·Updated 5 September 2026

Unit of conclusion

A control counts only when its result is demonstrated

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.

Applicability: Provision, condition, role and date
Control: Objective, mechanism, owner and frequency
Examination: Population, procedure, threshold and result
Conclusion: Status, limitation, decision and approver

Traceability chain

Keep one thread from the legal text to the decision

Each field answers a different question. Merging them creates a record that cannot be reviewed; connecting them lets a second examiner reconstruct the conclusion.

Source — Article, paragraph, annex, consolidated text and consultation date.
Applicability — Triggering fact, relevant role, deadline and rationale.
Expected outcome — Precise assertion the arrangement must satisfy.
Control — Technical or organisational mechanism, owner and frequency.
Test — Population, sample, procedure, threshold and failure criterion defined before execution.
Evidence — Inputs, raw results, version, provenance, integrity and limitation.
Decision — Row status, action, decision authority and reopening condition.

Provider · high-risk systems

Examine requirements across the lifecycle

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

Risk

Basis: Art. 9
Expected control: Continuous process connected to hazards, intended use, foreseeable misuse and residual risk
Test and evidence: Replay a scenario, verify metrics and thresholds, retain results and acceptance

Data

Basis: Art. 10
Expected control: Governance of data used for training, validation or testing, as applicable
Test and evidence: Examine lineage, quality criteria, relevance, representativeness and relevant bias

Documentation

Basis: Art. 11 · Annex IV
Expected control: Technical file consistent with the system presented for examination
Test and evidence: Reconcile architecture, versions, performance, limitations and cited records

Logs

Basis: Art. 12
Expected control: Recording capabilities suited to system traceability
Test and evidence: Trigger events; verify integrity, timestamps and retrieval

Information

Basis: Art. 13
Expected control: Accurate instructions that a deployer can actually use
Test and evidence: Perform a task, limitation and incident response from the instructions alone

Human oversight

Basis: Art. 14
Expected control: Measures designed to understand, monitor, disregard, override or stop as applicable
Test and evidence: Test permissions, response time, degraded modes and intervention record

Performance and security

Basis: Art. 15
Expected control: Declared accuracy, robustness and cybersecurity levels maintained
Test and evidence: Run relevant nominal, boundary, error, attack and drift scenarios

Quality system

Basis: Arts. 16–21 · 72–73
Expected control: Ownership, change, retention, correction, monitoring and incidents organised
Test and evidence: Sample one change and one incident end to end through the decision

Deployer · high-risk systems

Verify actual operating conditions

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

Use as instructed

Basis: Art. 26(1)
Expected control: Configuration and procedure aligned with instructions for use
Test and evidence: Compare active settings, procedure and instruction version

Oversight

Basis: Art. 26(2)
Expected control: Competent, trained, authorised and supported people
Test and evidence: Role-based exercise, access matrix, training and decision log

Input data

Basis: Art. 26(4)
Expected control: Relevance and sufficient representativeness where controlled by the deployer
Test and evidence: Sample production inputs, exclusions and relevant sub-populations

Monitoring and suspension

Basis: Art. 26(5)
Expected control: Detected signal, named escalation and genuinely available stop
Test and evidence: Simulate a risk and incident; measure detection, notification and suspension

Logs

Basis: Art. 26(6)
Expected control: Logs under the deployer’s control retained for the applicable period
Test and evidence: Extract a period; verify completeness, access, integrity and retention rule

Information

Basis: Art. 26(7) and (11)
Expected control: Workers or persons informed when conditions are met
Test and evidence: Check content, recipients, timing and proof of delivery

Registration and DPIA

Basis: Art. 26(8) and (9)
Expected control: Context-dependent duties examined before use
Test and evidence: Verify entity status, EU registration and GDPR interaction

Test protocol

Write the test before requesting evidence

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.

Baseline — Freeze the system, configuration, data and period under examination.
Assertion — State an observable outcome without relying on vague verbs such as “manage” or “ensure”.
Population — Define covered cases, exclusions and the sampling strategy.
Procedure — Describe actions, tools, inputs and calculation rules so the test can be repeated.
Criterion — Set success threshold, tolerance, severity and expected response before seeing the result.
Record — Retain raw outputs, anomalies, protocol deviations, conclusion and signatory.

Evidential strength

Retain what a third party must be able to verify

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.

Provenance: Author, source system and collection path
Time: Date, covered period and timestamp
Version: Model, code, rules, data and configuration
Integrity: Original, hash or preservation mechanism
Result: Raw data, calculation, exception and observation
Scope: Covered population, exclusion and conclusion limit

Row status

Separate result, evidence and decision

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

Effective

Condition: Procedure performed, criterion met and sufficient evidence
Consequence: Conclusion valid for the tested version and scope

Failed

Condition: Criterion missed or mechanism unavailable
Consequence: Finding, severity, owner, due date and closure test

Not demonstrated

Condition: Missing evidence, unperformed procedure or non-reproducible result
Consequence: Limitation or finding; no assumed compliance

Not applicable

Condition: Applicability condition tested and rationale retained
Consequence: Validated exclusion with a reopening trigger

For determination

Condition: Disputed interpretation, fact or threshold
Consequence: Isolated question, named authority and expected decision

Replayable case · human oversight

Move from a stated policy to a supported conclusion

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

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

Reopen the conclusion whenever its object changes

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.

Version — Re-examine after a model, data, rule, interface or supplier change.
Use — Re-examine after a change in purpose, population, influenced decision or context.
Role — Re-examine after rebranding, integration, substantial modification or transfer of responsibility.
Result — Re-examine after drift, incident, complaint, threshold breach or control failure.
Law — Re-examine after a change to the text, deadline, guidance or sector rule.

Sources and references

Regulation (EU) 2024/1689 — consolidated text (new tab)
Roles, requirements, post-deployment monitoring and current timeline.
Regulation (EU) 2026/1744 — amendment to the EU AI Act (new tab)
Official text setting, among other changes, the 2 December 2027 Annex III and 2 August 2028 Annex I deadlines.
AI Act Service Desk — Article 16, provider obligations (new tab)
Provider obligations for high-risk AI systems before and after placing them on the market.
AI Act Service Desk — Article 26, deployer obligations (new tab)
Instructions for use, human oversight, input data, monitoring, logs and information duties.

Frequently asked questions

Is an internal policy sufficient evidence?

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.

Can providers and deployers use the same matrix?

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.

How should unavailable evidence be handled?

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.

Does one “effective” row prove that the system is compliant?

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

Does your file distinguish what exists from what has actually worked?

We start from the qualification, the version in service and actual responsibilities to build and examine the evidence chain.

Present the system