Start with the evidence file, not the law library
Plain-English use: pick one AI system, identify the missing records, then generate a first-pass evidence route. The output tells you which records to create, which EU AI Compass pages to use next, and which teams may need to review the issue.
Current-law planning note
Use current law as the baseline until adopted legal text changes it. Digital Omnibus material may change parts of the high-risk timeline if formally adopted, but it should not stop evidence work. Keep the assumption, date, owner, and source visible in the file.
Choose your evidence problem
Start with the situation closest to your current problem. Use the full router below only after you know which evidence gap you are trying to close.
No inventory exists
Create the controlled list of AI systems before debating obligations.
Open inventory fields →Vendor evidence is weak
Ask for instructions, limitations, logs, oversight, security, and change records.
Build vendor request →Article 50 may apply
Check AI interaction, synthetic content, deepfake, biometric, or emotion triggers.
Run disclosure tree →Audit questions are coming
Prepare the records a buyer, auditor, regulator, or board may ask to see.
Open audit questions →Build your first evidence route
Local-only router
Build a first-pass evidence route
This form runs in the browser. Use working names only. Do not enter personal data, customer-confidential data, trade secrets, employee records, production credentials, or incident details.
Your evidence route appears here
Select the evidence gaps, then generate a first-pass route to records, EU AI Compass pages, and review owners.
Deployer evidence stack
A deployer evidence stack is the basic file that makes AI use reviewable. It should not depend on one vendor PDF or one policy paragraph.
| Evidence layer | Record to retain | Owner question |
|---|---|---|
| AI inventory | System name, purpose, owner, vendor, data category, deployment stage, users, geography. | Who owns the system and when was the record last reviewed? |
| Role and risk route | Provider/deployer assumption, Article 6/Annex III signals, high-risk rationale, uncertainty log. | Who approved the classification basis? |
| Vendor evidence | Instructions for use, limitations, oversight guidance, logging support, security and change notes. | Can the deployer explain reliance on provider information? |
| Oversight and monitoring | Human oversight assignment, training, intervention path, monitoring notes, review cadence. | Who can stop, escalate, or override the workflow? |
| Logs and incidents | Logs under deployer control, event review, suspected risk, serious-incident route, closure record. | Who checks the log or incident trail? |
| Article 50 transparency | Notice text, placement screenshot, first-exposure context, provider marking evidence, approval record. | Who approved what people see? |
| FRIA / DPIA route | FRIA screening note, DPIA linkage, affected groups, risks, oversight and mitigation evidence. | Who decides whether formal legal/privacy review is required? |
| Audit response file | Summary pack, evidence index, open gaps, accepted risks, unresolved legal questions. | Who can answer review questions without rebuilding the file? |
Article 26 evidence map
Article 26 evidence should turn deployer duties into records someone can check. This table is an operational map, not a legal conclusion.
| Article 26 area | Evidence artifact | Common gap |
|---|---|---|
| Use according to instructions | Provider instructions, approved operating procedure, version record. | Vendor instructions exist but are not connected to the actual deployment. |
| Human oversight | Named human oversight owner, competence record, intervention and stop path. | Oversight named in policy but not assigned to a trained person. |
| Input data under deployer control | Input-data relevance and representativeness check where the deployer controls input data. | Data owner assumes the provider handles all data-quality questions. |
| Monitoring and risk escalation | Monitoring cadence, trigger criteria, provider/distributor/authority escalation path. | Team has logs but no review rule or escalation owner. |
| Logs under deployer control | Log-retention decision, minimum retention basis, privacy review where needed. | Logs are available technically but not retained as evidence. |
| Workplace use | Worker and representative information record where workplace rules apply. | HR or works-council review is started too late. |
| Public-authority registration checks | Registration verification or provider escalation where database entry is missing. | Use begins before registration status is checked. |
| DPIA linkage | DPIA cross-reference using provider information under Article 13 where applicable. | DPIA and AI Act evidence files are maintained separately with inconsistent assumptions. |
Where to go next
| If the evidence gap is... | Use this EU AI Compass route | Expected output |
|---|---|---|
| No inventory | AI system inventory fields | Inventory structure and field-level evidence logic. |
| Evidence plan unclear | 30-day evidence planner | Week-by-week action path. |
| Audit response needed | Audit and regulator questions hub | Likely review questions and evidence prompts. |
| Evidence checklist needed | EU AI Act evidence checklist | Evidence areas to create, assign, and retain. |
| Vendor evidence missing | Vendor evidence request builder | Structured request language for provider/vendor evidence. |
| Article 50 trigger possible | Article 50 disclosure decision tree | Notice draft, evidence list, and escalation notes. |
| Article 50 implementation needed | Article 50 implementation pack | Implementation path for notice operations and evidence retention. |
| AI agent runtime involved | AI agent deployer evidence checklist | Agent boundary, runtime, tool-use, oversight, and evidence checks. |
30-day evidence path
Week 1: Inventory
Name systems, owners, vendors, users, purposes, and deployment stage.
Week 2: Role and risk
Record provider/deployer assumptions, high-risk signals, and uncertainty.
Week 3: Evidence requests
Collect vendor instructions, oversight, logs, limitation, and security evidence.
Week 4: Review file
Route Article 50, FRIA/DPIA, incident, legal, privacy, and audit questions.
When to escalate
| Trigger | Escalate to | Evidence to retain |
|---|---|---|
| High-risk classification is plausible or disputed. | Legal, compliance, product owner. | Classification rationale, assumptions, and unresolved questions. |
| Personal data, biometric data, employment data, or sensitive groups are involved. | DPO, privacy counsel, HR where relevant. | DPIA/FRIA screening note, data map, affected group analysis. |
| Deepfake, synthetic media, or public-interest text is published. | Legal, communications, content owner. | Article 50 notice, screenshot, approval and publication context. |
| Vendor cannot explain limitations, logs, oversight, or security controls. | Procurement, security, risk owner. | Vendor evidence request, response, residual-risk decision. |
| Operational monitoring finds risk, complaint, or incident signals. | Security, legal, product, competent authority path where relevant. | Incident intake, log extract, containment note, escalation timeline. |
Common evidence mistakes
- Starting with a vendor PDF instead of an AI system inventory.
- Keeping classification logic in email instead of a retained record.
- Assigning human oversight to a role, not a named accountable owner.
- Assuming logs exist without checking who controls and retains them.
- Publishing Article 50 notices without screenshots or version dates.
- Treating FRIA and DPIA as the same artifact.
- Using provisional-agreement deadlines as if adopted law.
- Waiting for audit questions before building the evidence index.
Frequently asked questions
Use these answers to check scope, evidence depth, escalation points, and limits before relying on the evidence hub.
EU AI Act deployer evidence should usually start with an AI system inventory. The inventory should name the system, owner, vendor, purpose, user group, deployment stage, data categories, role assumption, risk route, Article 50 trigger, and evidence status. Without the inventory, later vendor review, Article 26 mapping, FRIA/DPIA routing, and audit preparation become guesswork.
An AI inventory is necessary but not enough for EU AI Act readiness. The inventory tells the team what exists; the evidence file should also show instructions for use, human oversight assignment, input-data checks where controlled by the deployer, log retention where available, monitoring, vendor evidence, Article 50 notice records, and escalation decisions.
Article 26 deployer evidence commonly maps to use according to instructions, competent human oversight, input-data relevance where the deployer controls inputs, monitoring, risk or incident escalation, log retention where logs are under deployer control, workplace notification where applicable, registration checks for public authorities, DPIA linkage, and cooperation with authorities.
Yes. A deployer usually needs vendor evidence because provider instructions, technical documentation extracts, model limitations, log availability, human oversight guidance, cybersecurity information, and Article 50 marking support affect the deployer evidence file. A vendor PDF is not enough if it does not answer the deployment-specific review questions.
Article 50 disclosure evidence should sit beside the AI system inventory and publication record. Keep the notice text, version date, screen placement, first-exposure timing, audience, workflow owner, provider marking evidence where relevant, editorial-control record where relied upon, and legal or communications review note.
FRIA or DPIA review should be escalated when the system may be high-risk, affects people in a sensitive context, processes personal data, supports consequential decisions, involves employment or public-service use, or creates rights-impact questions. Use the evidence route builder as triage only; the final FRIA, DPIA, legal, and privacy positions need qualified review.
No. The EU AI Act Deployer Evidence Route Builder does not prove compliance, certify an AI system, or provide legal advice. It helps structure evidence preparation and routes users to free EU AI Compass tools. Compliance depends on system facts, implementation, legal interpretation, governance operation, and continuing review.
Use the current-law deadline as the planning baseline until adopted amendments change it. The Digital Omnibus process may affect high-risk timing, but provisional-agreement material should not replace operational readiness work. Keep a change log, record assumptions, and update the evidence plan when the legal position becomes final.
Source and review note
This page provides operational guidance, not legal advice. It was last reviewed on 3 May 2026 against the AI Act Service Desk text for Article 113, Article 26, Article 50, Article 27, and the European Parliament Legislative Train page for the Digital Omnibus on AI. Validate final legal, privacy, employment, procurement, security, tax, and sector-specific decisions with qualified professionals.
Build the evidence file before someone asks for it
Start with the route, then use the planner or inventory fields to turn the result into a retained record.