EU AI Act High-Risk Evidence Pack: HR, Finance and Healthcare Playbooks for 2027
A role-based evidence checklist for Annex III AI systems, with practical HR, finance and healthcare workflows and a reusable GDPR, DORA and ISO control map.

The most useful EU AI Act deliverable for 2027 is not another policy. It is a system-level evidence pack that lets a reviewer answer five questions quickly: what the system does, why it is or is not high-risk, which legal entity holds each role, how people remain in control, and where the supporting evidence lives.
Regulation (EU) 2026/1744 moved the main Chapter III requirements for Article 6(2) and Annex III systems to 2 December 2027. It did not pause the rest of the EU AI Act. Article 50 transparency duties have applied since 2 August 2026, while prohibited-practice, AI-literacy and applicable general-purpose AI duties follow their own dates.
This playbook turns the amended timeline into an evidence-building workflow for HR, finance and healthcare teams. For the full legal timeline, start with our EU AI Act 2026 update.
The 60-Second Scope Test
| Question | Evidence to keep | Why it matters |
|---|---|---|
| Is it an AI system under Article 3? | Architecture summary and documented scope analysis | Avoids treating every rules engine or spreadsheet as AI—or excluding a system merely because a vendor uses another label |
| What is the intended purpose? | Approved purpose statement, users, affected people, inputs, outputs and decisions | High-risk classification depends heavily on intended use |
| Does an Annex III use case match? | Clause-by-clause classification memo | “Used in HR” or “used in healthcare” is not precise enough |
| Does Article 6(3) affect classification? | Reasoned assessment and provider documentation | A narrow exception may apply in some cases, but it is not a blanket sector exemption |
| Who is provider, deployer, importer or distributor? | Contract and value-chain role map | Obligations attach to legal roles, not internal labels such as vendor and customer |
| Are other live rules triggered? | Article 5, Article 50, GDPR and sector-law screen | A system that is not high-risk can still be prohibited, transparent-risk, privacy-regulated or sector-regulated |
Approve the classification at a named governance forum. Reassess it when the intended purpose, model, input data, decision weight, user population or deployment geography changes.
Industry Playbooks
HR and recruitment
Annex III expressly covers specified employment uses, including recruitment or selection, targeted job advertising, filtering applications, evaluating candidates, decisions affecting work relationships, task allocation based on individual behaviour or traits, and monitoring or evaluating performance.
Before deploying, an HR team should be able to produce:
- the exact stage of the employment process influenced by the system;
- the attributes, signals and inferred characteristics used;
- evidence that prohibited emotion-recognition uses in the workplace are blocked unless a narrow legal exception applies;
- validation by job family, language, geography and relevant affected group;
- the human reviewer's authority to disagree, obtain more evidence and reverse a result;
- worker, candidate and representative notices required by applicable law;
- an accommodation and challenge route; and
- retention, deletion and logging rules for applications, scores and reviewer actions.
US obligations do not collapse into the EU program. New York City's Local Law 144, for example, requires an in-scope automated employment decision tool to have a recent independent bias audit, a published summary and required notices. Illinois' Artificial Intelligence Video Interview Act requires notice, an explanation, consent and deletion handling for covered video interviews. Use one inventory, but preserve jurisdiction-specific tests and evidence.
Credit, insurance and financial services
Certain systems used to evaluate creditworthiness or establish a credit score, and specified risk assessment and pricing uses in life and health insurance, can fall within Annex III. Financial institutions should connect the AI evidence pack to model-risk management, customer communications, complaints, outsourcing and—where the entity is in scope—Digital Operational Resilience Act (DORA) controls.
The review should distinguish:
- eligibility, pricing, fraud, collections and service-prioritization uses;
- a model recommendation from the final consequential decision;
- training data from live customer data;
- performance drift from discriminatory outcome risk;
- model error from ICT availability or integrity incidents; and
- an AI provider from an ICT third-party service provider under DORA.
DORA evidence can support resilience, incident and supplier controls. It does not replace the AI Act's classification, data-governance, human-oversight, conformity or registration work.
Healthcare and medical products
Healthcare AI can reach the high-risk regime through two different paths. A use may match Annex III, or the AI may be a safety component of—or itself be—a regulated product under Article 6(1) and Annex I. The latter main Chapter III requirements apply from 2 August 2028, not December 2027.
Document whether the system is clinical, administrative, research-only or patient-facing; whether it is part of a medical device; and which entity controls the intended medical purpose. Link AI evidence to the product risk file, clinical or performance evaluation, cybersecurity, change control, vigilance and post-market processes without pretending those files are interchangeable.
Marketing and customer engagement
Ordinary segmentation or content optimization is not automatically Annex III high-risk. Marketing systems may still trigger the GDPR, consumer law and Article 50. They may also cross into a different category when used for credit access, insurance pricing, biometric categorisation or another listed consequential use.
The safe operating rule is simple: classify the decision and intended purpose, not the department buying the tool.
The Provider Evidence Pack
| Evidence object | Minimum useful content | Accountable owner |
|---|---|---|
| Classification and role memo | AI-system analysis, Article 6 route, intended purpose, exclusions, operator roles and change triggers | Legal plus product owner |
| Risk-management file | Foreseeable risks, testing, mitigations, residual risk, acceptance authority and review cadence | Risk owner |
| Data-governance record | Sources, provenance, relevance, representativeness, preparation, bias checks, gaps and access controls | Data owner |
| Technical documentation | Annex IV-indexed system description, development, capabilities, limitations, validation and lifecycle controls | Provider engineering and compliance |
| Instructions for use | Intended use, prohibited or unsupported uses, input requirements, accuracy, oversight, maintenance and logging | Product owner |
| Performance dossier | Metrics by relevant population and context, robustness, cybersecurity, thresholds and known failure modes | Validation lead |
| Human-oversight design | Required competence, interface cues, override, escalation and automation-bias safeguards | Product and deployer operations |
| Logging design | Events captured, clock and identity controls, export format, retention assumptions and access | Engineering and security |
| Quality-management evidence | Change control, supplier controls, issue management, competence, records and release approval | Quality owner |
| Conformity and registration file | Assessment route, declaration, marking where applicable, EU database fields and approvals | Regulatory owner |
| Post-market file | Monitoring plan, feedback, drift thresholds, serious-incident workflow and corrective action | Operations and safety owner |
Do not wait for a conformity assessment to discover that production logs cannot reconstruct a decision or that the contract prevents access to validation evidence.
The Deployer Evidence Pack
Deployers need their own records rather than a copy of the vendor's folder:
- Approved use case and local configuration.
- Provider instructions and proof that operating controls follow them.
- Input-data suitability checks for the deployed context.
- Named, trained human overseers with real authority.
- Monitoring, log-retention and escalation procedures.
- Worker, customer or affected-person notices where required.
- A GDPR lawful-basis, transparency, rights and data-protection impact assessment analysis when personal data is involved.
- An Article 27 fundamental-rights impact assessment where the deployer and use meet that provision's trigger.
- Vendor incident, change-notification and evidence-access commitments.
- Suspension and exit criteria if performance, safety or rights controls fail.
The Commission's consolidated Article 26 text describes deployer duties including following instructions, assigning competent human oversight, monitoring operation, managing relevant input data and retaining automatically generated logs under specified conditions. Translate each applicable duty into an owner, control, record and test frequency.
One Control, Several Frameworks—But Separate Conclusions
| Shared control area | AI Act use | GDPR use | DORA / ISO / SOC 2 reuse boundary |
|---|---|---|---|
| System and data inventory | Role, classification, registration and technical file | Records, purpose, data categories and recipients | Asset and service inventory can seed the record but usually lacks AI purpose detail |
| Risk assessment | Health, safety and fundamental-rights risks | Risks to data subjects and DPIA | Enterprise risk formats can be reused; scoring and legal tests remain framework-specific |
| Access and change control | Quality management, robustness and traceability | Integrity, confidentiality and accountability | ISO/IEC 27001 and SOC 2 evidence can support operation, not AI legality |
| Supplier governance | Provider/deployer information and monitoring | Processor/controller and transfer controls | DORA adds financial-sector ICT contract and oversight requirements |
| Logging and monitoring | Traceability, deployer retention and post-market monitoring | Accountability, security and rights handling | Central logging can support all, but retention and access rules may conflict |
| Incident handling | Serious-incident and corrective-action workflow | Personal-data breach analysis | DORA and security incidents use different thresholds, recipients and clocks |
| Impact assessment | AI risk and qualifying fundamental-rights assessment | DPIA | Reuse facts; issue separate approved conclusions |
ISO/IEC 42001 is useful for governance cadence, policy, objectives, impact assessment and continual improvement. ISO/IEC 27001 and SOC 2 can support security and assurance evidence. None provides a presumption that every product, use or operator complies with the AI Act.
A 90-Day Build Plan
Days 1–30: inventory and classify
- Freeze a list of production, pilot and procured AI systems.
- Record intended purpose, geography, affected people, operator roles and vendor chain.
- Screen Article 5, Article 50, Annex III and Annex I.
- Escalate uncertain and high-impact cases.
Days 31–60: test the evidence
- Select one likely high-risk system per business line.
- Request the provider evidence pack.
- Run a GDPR/DPIA and sector-law gap review.
- Test whether a reviewer can reconstruct a real decision from retained evidence.
Days 61–90: remediate the operating model
- Amend contracts for documentation, logs, changes and incidents.
- Train human overseers by role and failure scenario.
- Approve thresholds for monitoring, suspension and reassessment.
- Put evidence owners and due dates into the governance calendar.
Frequently Asked Questions
When do the main EU AI Act rules for Annex III high-risk systems apply?
The main Chapter III requirements for systems classified as high-risk under Article 6(2) and Annex III apply from 2 December 2027. Article 50 transparency, AI-literacy, prohibited-practice and applicable GPAI duties already operate on separate earlier dates.
Is every AI tool used by an HR team automatically high-risk?
No. Annex III targets specified intended uses such as recruitment, selection, targeted job advertising, decisions affecting work relationships, task allocation based on individual behaviour or traits, and performance monitoring. The intended purpose and Article 6 conditions must be documented for each system.
Can one DPIA replace the EU AI Act technical documentation or fundamental-rights impact assessment?
No. A GDPR DPIA, AI Act technical documentation and an Article 27 fundamental-rights impact assessment have different legal triggers and required content. Teams can reuse validated facts and controls, but must preserve each instrument's scope and accountable owner.
Does ISO/IEC 42001 or ISO/IEC 27001 certification prove EU AI Act compliance?
No. Those standards can organize governance, security and audit evidence, but they do not decide whether a system is prohibited or high-risk, establish an operator's legal role, or replace AI Act conformity, registration, transparency and post-market duties.
What should an EU buyer obtain from an AI vendor now?
At minimum, obtain the intended-purpose and role statement, version and change history, data and performance documentation, known limitations, human-oversight instructions, logging and export capability, incident cooperation terms, security evidence, subcontractor information and a plan for the provider evidence required before the applicable deadline.
Research and Review
This guide was researched against the consolidated AI Act and the adopted Digital Omnibus amendment, Commission AI Act Service Desk material, final Article 50 guidance, official US employment-AI sources and the related EU data-protection and financial-resilience instruments. Sources and legal status were reviewed on 13 October 2026.
The control map is an implementation aid, not a legal conclusion. It distinguishes shared operational evidence from framework-specific assessments and does not assume that a sector label alone determines high-risk status. See our editorial policy.
Official Sources
- Regulation (EU) 2024/1689 — Artificial Intelligence Act — controlling base regulation
- Regulation (EU) 2026/1744 — Digital Omnibus on AI — adopted amended dates and provisions
- Annex III — AI Act Service Desk — official consolidated high-risk use cases
- Article 26 — deployer obligations — official consolidated article and summary
- Article 50 transparency guidelines — final Commission guidance applying from August 2026
- NYC automated employment decision tools — Local Law 144 enforcement guidance
- Illinois Artificial Intelligence Video Interview Act — official state statute
- Colorado automated decision-making technology rulemaking — official 2027 state-law status and implementation page
- Regulation (EU) 2022/2554 — DORA — financial-sector digital operational resilience requirements
Related Topics
Related Standards
Related Articles
EU AI Act 2026 Update: What Is Live, What Was Delayed, and What to Do
The EU AI Act is applying, but its high-risk deadlines changed. Separate live transparency and GPAI duties from the December 2027 and August 2028 requirements.
MiCA in 2026: Stablecoin Issuer and CASP Compliance Checklist
A role-based MiCA guide for stablecoin issuers and crypto-asset service providers after the EU transitional period, with practical evidence and DORA links.
NIS2 vs DORA: Which EU Digital Resilience Rule Applies to You in 2026?
NIS2 and DORA are both EU cybersecurity regulations that took effect in 2024-2025. They overlap, they conflict, and they probably both apply to you. Here's how to tell them apart.
ISO 42001: What Every Company Building AI Products Needs to Know About AI Governance
ISO 42001 is the first international standard for AI management systems. Here's what it covers, why it matters now, and how to get started.