The evidence file

19 artefacts appear across EU AI Act. 0 of them are demanded by more than one obligation, which makes them the ones worth building first: the same document, properly made, discharges several duties at once. An artefact that is merely present does not discharge anything, so each entry records what makes it sufficient — that sentence is the part an assessor is testing.

What you will be asked for

• A dated residual-risk acceptance decision

  One obligation

  • Article 9 — Risk management system

    Article 9(5) requires a judgement that residual risk is acceptable. A judgement has an author and a date. A risk register with a column shaded green records a rating, not an acceptance, and cannot show who would answer for it.

• A named oversight assignment, with the competence behind it

  One obligation

  • Article 26 — Obligations of deployers of high-risk AI systems

    Article 26(2) asks for competence, training and authority, and the necessary support. A rota naming who is on duty is not the artefact; the artefact is what qualifies them to override the system and what authority they hold to do it without escalating.

• A risk management plan tied to a named system and release

  One obligation

  • Article 9 — Risk management system

    It should name the process owner and the review cadence, and be versioned against the system rather than against the organisation. A plan that cannot be tied to a specific system and a specific release is a corporate policy, and Article 9 does not ask for a policy.

• A suspension decision, or a recorded decision not to suspend

  One obligation

  • Article 26 — Obligations of deployers of high-risk AI systems

    The clearest evidence that 26(5) is operating is an occasion when it fired. Where it never has, the record should show the threshold being applied and a reasoned conclusion that it was not crossed — which is the only version of this an assessor can test.

• Cybersecurity measures addressing AI-specific attack surfaces

  One obligation

  • Article 15 — Accuracy, robustness and cybersecurity

    The four categories Article 15(5) names: data poisoning of the training set, model poisoning of pre-trained components, adversarial examples or model evasion, and confidentiality attacks or model flaws. Surfaces the Act does not enumerate — model extraction, prompt injection — belong here too where the architecture admits them.

• Declared accuracy levels and metrics in the instructions for use

  One obligation

  • Article 15 — Accuracy, robustness and cybersecurity

    The declaration has to name the metric, not only the score. Precision at what threshold, over what population, against what ground truth. A figure without its definition cannot be checked by a deployer and does not discharge Article 15(3).

• Evidence that post-market data re-entered the process

  One obligation

  • Article 9 — Risk management system

    Article 9 and Article 72 are one loop. Field data that never changes a risk rating is a monitoring function running in parallel to the risk management system rather than inside it — the two artefacts exist, and nothing connects them.

• Feedback-loop mitigation records for systems that continue to learn

  One obligation

  • Article 15 — Accuracy, robustness and cybersecurity

    Article 15(4) requires mitigation of feedback loops in continually learning systems. The evidence is a control that detects when the system’s own outputs have re-entered its training data, and a record of it having been checked.

• Governance that visibly moved after the assessment

  One obligation

  • Article 27 — Fundamental rights impact assessment for high-risk AI systems

    A tightened escalation route, a narrowed set of affected persons, a new redress path — or a recorded decision that no change was warranted, and on what basis. Findings that reach nothing leave the assessment reading as a formality, which is how an authority receiving it under Article 27(3) will treat it.

• Input-data controls where the deployer supplies the data

  One obligation

  • Article 26 — Obligations of deployers of high-risk AI systems

    Article 26(4) attaches only to the extent the deployer exercises control. The artefact is the boundary: which fields the deployer supplies, what checks run on them, and where responsibility passes back to the provider.

• Notification to the market surveillance authority

  One obligation

  • Article 27 — Fundamental rights impact assessment for high-risk AI systems

    Article 27(3) requires the deployer to notify the authority of the results, submitting the filled-out template referred to in Article 27(5) — the AI Office questionnaire. The evidence is that submission and its acknowledgement, not the internal assessment sitting complete on a shared drive.

• Review records from more than one point in the lifecycle

  One obligation

  • Article 9 — Risk management system

    The Act calls the process "continuous" and "iterative". Two or more review entries across releases, with risks that visibly changed status between them, is what distinguishes a process that ran from an assessment that happened.

• Robustness testing against the conditions the system will actually meet

  One obligation

  • Article 15 — Accuracy, robustness and cybersecurity

    Distribution shift, degraded inputs, adversarial inputs where relevant. Robustness is a claim about behaviour outside the happy path, so evidence drawn only from the happy path does not support it.

• The completed assessment, dated before first use

  One obligation

  • Article 27 — Fundamental rights impact assessment for high-risk AI systems

    The date is the control. Article 27 says "prior to deploying", so an assessment dated after go-live does not cure the breach, however good its content. Where a system was already in use before the obligation applied, the record should show when it was brought into scope.

• The contractual right of access to logs

  One obligation

  • Article 26 — Obligations of deployers of high-risk AI systems

    Because 26(6) is qualified by control, the deployer’s real exposure sits in the vendor agreement. The evidence is the clause, and a retrieval that was actually performed against it rather than assumed to be available.

• The in-scope determination, with reasons

  One obligation

  • Article 27 — Fundamental rights impact assessment for high-risk AI systems

    A deployer that concluded it is out of scope needs that conclusion written down against the Article 27(1) categories. The absence of an assessment and the absence of a reasoned decision not to make one look identical from outside, and only one of them is defensible.

• The notice given to affected people, and its date

  One obligation

  • Article 26 — Obligations of deployers of high-risk AI systems

    Under 26(11) a deployer of an Annex III system that makes or assists decisions about people must tell them so. Where the deployer is an employer, 26(7) separately requires workers and their representatives to be informed before the system is put into service.

• The test methodology and dataset description behind each declared figure

  One obligation

  • Article 15 — Accuracy, robustness and cybersecurity

    An assessor reconciles the declared number to the test that produced it. Where the evaluation population differs from the deployment population, that difference is itself a disclosure — the common failure is a figure measured on curated data and declared as though it were operational.

• Traceability from each significant risk to the test that measured it

  One obligation

  • Article 9 — Risk management system

    Each identified risk should reach a mitigation and a test result. Testing that cannot be mapped back to a risk demonstrates diligence but not conformity, and mitigations with no test behind them are intentions.