The evidence file

68 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 bias examination that reached the risk register

  One obligation

  • Article 10 — Data and data governance

    The examination is required; its use is what makes it evidence. An assessor traces a finding from the bias work to a risk entry, a mitigation, and a measurement.

• A dataset defect register, with treatment

  One obligation

  • Article 10 — Data and data governance

    The duty to identify relevant gaps and shortcomings and how they can be addressed is unqualified, unlike the error-freedom language around it. A register naming known limitations and what was done about each is the strongest single artefact under this article.

• A dated classification determination per system

  One obligation

  • Article 6 — Classification rules for high-risk AI systems

    Naming the route considered, the conditions tested, and the conclusion. This is required by the Regulation only where the conclusion is "not high-risk", but an assessor asks for it either way — it is the record that shows the question was asked before the answer was needed.

• 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 filed initial report that was later completed

  One obligation

  • Article 73 — Reporting of serious incidents

    Paragraph 5 exists to stop timeliness being traded for completeness. A file where every submission was final and several were late shows a process that has never used the provision it needed.

• A finding that came out of the monitoring, and what it changed

  One obligation

  • Article 72 — Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems

    Field data that never alters a risk rating or a declared figure indicates a system running alongside the compliance process rather than inside it. One traced example is worth more than the dashboard.

• A logging specification traced to the three downstream uses

  One obligation

  • Article 12 — Record-keeping

    Each recorded event class should map to what it exists to enable: risk identification, post-market monitoring, or deployer monitoring. Events that map to none of the three are operational telemetry, which is fine but is not what this provision is asking for.

• 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 re-review trigger tied to change

  One obligation

  • Article 6 — Classification rules for high-risk AI systems

    Classification is a determination about an intended purpose, and intended purpose moves. The artefact is what causes the question to be re-asked — a new market, a new customer segment, a retrained model, a changed interface.

• A recorded assessment against each listed practice

  One obligation

  • Article 5 — Prohibited AI practices

    Because there is no classification gateway, the only way to show Article 5 was considered is to have considered it. A short reasoned conclusion per limb, dated, is the artefact — and the emotion-inference and social-scoring limbs are the two that need real analysis rather than a dismissal.

• A recorded obviousness assessment for 50(1)

  One obligation

  • Article 50 — Transparency obligations for providers and deployers of certain AI systems

    The exemption applies where the AI nature is obvious to a reasonably well-informed, observant and circumspect person in context. That is a judgement someone has to have made and written down; relying on it silently leaves nothing to show.

• 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 signal-to-requirement map

  One obligation

  • Article 72 — Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems

    Each monitored signal tied to the Section 2 requirement it bears on, with the threshold at which it becomes a compliance question rather than an engineering one. This is what separates conformity monitoring from product monitoring.

• 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.

• A version history tying the file to system releases

  One obligation

  • Article 11 — Technical documentation

    Currency is a continuing duty, so the artefact is a change log showing which release each revision belongs to — and a revision that followed the last material change rather than preceding it by a year.

• An awareness timestamp per incident, naming the person

  One obligation

  • Article 73 — Reporting of serious incidents

    The clocks run from when someone knew, which is rarely when a ticket was opened. The record shows who first held the information and at what hour, on the provider side and on the customer side.

• An index mapping each Annex IV point to an artefact

  One obligation

  • Article 11 — Technical documentation

    Nine rows, each naming the document that answers the point and the version it stands at. This is the cheapest thing on this page to produce, and its absence is the most reliable predictor that two or three of the points are not answered at all.

• Automation-bias treatment that someone maintains

  One obligation

  • Article 14 — Human oversight

    Not a slide in induction. Periodic calibration, seeded disagreement cases, or measured agreement against an independent standard — something that keeps awareness current, because the duty is to remain aware.

• Configuration evidence where an exception is relied on

  One obligation

  • Article 5 — Prohibited AI practices

    Emotion inference for medical or safety reasons, biometric categorisation confined to lawful dataset filtering. The exception has to be visible in how the system is deployed, not only in the justification written for it.

• 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 machine-readable marking actually survives

  One obligation

  • Article 50 — Transparency obligations for providers and deployers of certain AI systems

    Provenance metadata is routinely stripped by resizing, re-encoding or upload to a third-party platform. The artefact is a test showing the marking is still detectable at the point content reaches an audience, not a statement that it was applied at generation.

• 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.

• For a claimed Annex III derogation, the filing that goes with it

  One obligation

  • Article 6 — Classification rules for high-risk AI systems

    Which of the four conditions is relied on, a record that profiling is not performed, and the registration in the public database. The reasoning no longer has to be published, which raises rather than lowers the value of holding it.

• For biometric identification, the four minimum fields

  One obligation

  • Article 12 — Record-keeping

    Start and end of each use, the reference database checked against, the input data that produced a match, and the identity of the people who verified the result. The last of these makes the two-person verification rule auditable.

• For biometric identification, the two-person verification record

  One obligation

  • Article 14 — Human oversight

    Article 12(3)(d) requires the logs to capture who performed the verification, which exists precisely so 14(5) can be audited. The two people may include the operator, and the log entry may be the whole of the evidence.

• For edited text, both limbs of the exception

  One obligation

  • Article 50 — Transparency obligations for providers and deployers of certain AI systems

    A named person holding editorial responsibility, and evidence that human review actually occurred. The exception is conjunctive, so a newsroom with a sub-editor but no accountable person fails it, as does a named person who never reads the output.

• For generative systems, safeguard efficacy and misuse response

  One obligation

  • Article 5 — Prohibited AI practices

    The qualifying provisions turn on whether adequate technical safeguards prevent the prohibited generation and correct observed or reported misuse. Evidence is red-team results against those specific categories and a record of reports acted on.

• For the product route, evidence on both conditions separately

  One obligation

  • Article 6 — Classification rules for high-risk AI systems

    Which Annex I instrument covers the product, and whether that instrument requires third-party conformity assessment for it. A determination that addresses only the first condition has answered half the test.

• 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.

• Override rate, measured and trended

  One obligation

  • Article 14 — Human oversight

    The single most diagnostic number available. A rate at or near zero over a meaningful period is the automation-bias condition made visible, and it is measurable without any access to the model.

• Proof the instructions reached the operating team

  One obligation

  • Article 13 — Transparency and provision of information to deployers

    Article 13(2) requires an appropriate digital format or otherwise, and information that is concise, complete, correct, clear, relevant, accessible and comprehensible. A file behind a partner login that operations has never opened fails the last three adjectives.

• Provenance and original collection purpose for personal data

  One obligation

  • Article 10 — Data and data governance

    Governance practices must cover data origin and, for personal data, the purpose it was originally collected for. This is where the article overlaps with data-protection law and where reuse of historical operational data usually fails.

• 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.

• Something downstream that came out of the logs

  One obligation

  • Article 12 — Record-keeping

    A monitoring finding, a substantial-modification determination, a suspension decision. This is the only evidence that distinguishes capability from volume, and its absence over a long operating period is itself the finding.

• Subgroup performance where intended use makes it material

  One obligation

  • Article 13 — Transparency and provision of information to deployers

    Point (b)(v) asks, when appropriate, for performance regarding specific persons or groups the system is intended to be used on. Where a system is pointed at people, the qualifier is doing very little work.

• Test reports dated and signed by named individuals

  One obligation

  • Article 11 — Technical documentation

    Point 2(g) asks for reports signed by the responsible persons. A build artefact identified by a commit hash attributes nothing to anybody, and the signature is what makes someone answerable when a figure is later questioned.

• The appropriateness argument for the chosen metrics

  One obligation

  • Article 11 — Technical documentation

    Point 4 asks why these measures suit this particular system. Reporting scores answers a different question; this one asks why those were the right things to score, given the intended purpose.

• The Article 3(49) classification note, limb by limb

  One obligation

  • Article 73 — Reporting of serious incidents

    Which of the four limbs is engaged and on what reasoning, including an explicit answer on limb (c). A severity rating produced by an operations matrix does not address the fundamental-rights question at all.

• 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 customer notification clause, with an hour figure in it

  One obligation

  • Article 73 — Reporting of serious incidents

    Because the deadline can run from the deployer’s knowledge, the contractual escalation window is a reporting control. An obligation to notify "promptly" leaves the provider unable to show its own clock ever started on time.

• The disclosure itself, with its position and timing

  One obligation

  • Article 50 — Transparency obligations for providers and deployers of certain AI systems

    Article 50(5) requires the information at the latest at the time of first interaction or exposure, clearly and distinguishably, and conforming to accessibility requirements. A disclosure discoverable only in a policy page has already missed the moment the provision names.

• 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 instructions for use, indexed against Article 13(3)

  One obligation

  • Article 13 — Transparency and provision of information to deployers

    Six points, one of them carrying seven sub-headings. An index showing where each is answered turns a product manual into a compliance artefact, and it exposes the sub-headings that were never written at all.

• The intended purpose, stated tightly enough to bound use

  One obligation

  • Article 5 — Prohibited AI practices

    Several prohibitions attach to putting a system into service *for a specific purpose*. A loosely stated purpose widens exposure; a precise one, enforced by configuration rather than policy, narrows it.

• The interruption path, tested rather than described

  One obligation

  • Article 14 — Human oversight

    Article 14(4)(e) contemplates bringing the system to a halt in a safe state. Evidence is a test that exercised it and a record of what the safe state actually was, not a screenshot of a button.

• The known-circumstances section, written honestly

  One obligation

  • Article 13 — Transparency and provision of information to deployers

    Point (b)(iii) covers circumstances, including reasonably foreseeable misuse, which may lead to risks to health, safety or fundamental rights. A section listing none of them is a positive claim rather than an omission, and it will be read as one.

• The log-interpretation description under point (f)

  One obligation

  • Article 13 — Transparency and provision of information to deployers

    Where relevant, a description of the mechanisms allowing a deployer to collect, store and interpret the logs. A deployer that cannot read them cannot monitor, and its monitoring duty is not qualified by whether anyone explained the format.

• 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 plan itself, inside the technical documentation

  One obligation

  • Article 72 — Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems

    Not a standalone policy. The Annex IV file is where it belongs, and an assessor looking for it looks there first. Its absence is the one failure under this article with a clear route to a Union-level fine.

• The post-report investigation, with its risk assessment and corrective action

  One obligation

  • Article 73 — Reporting of serious incidents

    Paragraph 6 names three outputs, not one. An investigation closing on a fix, with no reassessment of the risk picture and no cooperation record with the authority or notified body, has delivered a third of what is required.

• The preservation record for the system as it stood

  One obligation

  • Article 73 — Reporting of serious incidents

    Version, weights, configuration and inputs held unchanged, with the date the authorities were told of any alteration. Paragraph 6 bars changes that could affect a later evaluation of causes until that notification has been made.

• The representativeness argument, tied to intended use

  One obligation

  • Article 10 — Data and data governance

    Not a demographic table. A stated deployment population, evidence the data reflects it, and where it does not, the consequence. The article permits the argument to be made across a combination of datasets rather than each one.

• The retention position, and who holds it

  One obligation

  • Article 12 — Record-keeping

    Which logs sit under the provider’s control and which under the deployer’s, with the six-month floor applied to each, and the data-protection constraint that the Act expressly preserves where logs contain personal data.

• The safety-component analysis, where an exclusion is relied on

  One obligation

  • Article 6 — Classification rules for high-risk AI systems

    The intended-purpose question and the failure-mode question are separate, and the second is not disposed of by the first. A system claimed as optimisation still needs a recorded answer to what happens when it fails.

• The statement of pre-determined changes

  One obligation

  • Article 13 — Transparency and provision of information to deployers

    Point (c) asks what the provider foresaw at the initial conformity assessment. That sentence later decides whether a modification was substantial, so precision in it repays effort that looks disproportionate at the time of writing.

• 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.

• The written record of design trade-offs

  One obligation

  • Article 11 — Technical documentation

    What was surrendered for what, and why, in choosing the technical solutions used to meet Chapter III Section 2. This is the element most often reconstructed long after the decision, which is also when it is least persuasive.

• 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.

• What the oversight person is given to work with

  One obligation

  • Article 14 — Human oversight

    Confidence scores, contributing factors, cases the system finds hard, known limitations. If the interface presents only a conclusion, the capabilities in 14(4)(a) and (c) have not been provided whatever the policy says.

• Where integration is relied on, the equivalence argument

  One obligation

  • Article 72 — Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems

    A documented case that the existing sectoral or financial-services arrangement achieves an equivalent level of protection, addressing the elements this article requires rather than asserting general coverage.

• Where special-category data was processed, the conditions record

  One obligation

  • Article 10 — Data and data governance

    The relocated derogation carries binding conditions, and it is additive to data-protection law rather than a standalone basis. The record shows which conditions were met and why the processing was strictly necessary.

• Where the simplified form is used, the eligibility record

  One obligation

  • Article 11 — Technical documentation

    The concession runs to SMEs, start-ups and small mid-cap enterprises. Head-count and turnover move as an organisation grows, so eligibility needs a date and a basis rather than a standing assumption inherited from an earlier year.