EU AI Act Application Playbook: Classify, Control and Evidence Regulation 2024/1689

This is the Governance article for applying the EU AI Act on live work. Use it as a working playbook: define the system, map roles, screen prohibitions, classify risk, build the control and evidence pack, then calendar the dates that bind you.

Source: Regulation (EU) 2024/1689 (Artificial Intelligence Act), OJ L 12.7.2024 — official ELI text. This playbook is an operational guide, not legal advice. Verify current guidelines, standards and national enforcement before publishing a compliance roadmap.

---

How to use this playbook​

Work top to bottom. Do not skip to high-risk documentation if you have not finished the prohibition screen. Do not treat GPAI provider duties as a substitute for deployer duties on the finished application.

Mode	What you do
New use case	Complete Steps 0–10 before production data or personal data reaches a model
Existing system	Re-run Steps 0–4; gap-assess Steps 5–9 against current state; calendar Step 10
Procurement	Require the vendor to complete the provider pack; you still own deployer Steps 6–8
Material change	Re-open from Step 1 whenever purpose, population, model, automation or geography changes

---

Step 0 — Open the intake pack​

Do not classify a slogan (“an intelligent HR platform”). Capture enough context to answer legal and design questions.

Required fields​

Field	Why it matters
Business sponsor	Who accepts residual risk
Problem statement	What decision or outcome AI supports
Intended users	Who operates the system
Affected persons	Whose rights, health or opportunities are impacted
Intended purpose (draft)	Classification hinges on purpose, not model sophistication
Deployment markets	EU / UK / other; where output is used
Data categories	Personal, special category, biometric, children’s data
Candidate models / vendors	Value-chain roles and GPAI exposure
Automation level	Suggest / decide / act
Human involvement	Where a person can override or stop
Non-AI baseline	Alternative if AI is stopped

---

Step 1 — Define the AI system boundary​

The Act regulates the system in its context of use, not only a model API.

1.1 Bound the socio-technical system​

List every component that can influence the output or an automated action:

• UI / channels
• Orchestration and agents
• Prompts, policies, guardrails
• Foundation / fine-tuned models
• Retrieval, embeddings, vector stores
• Tools and write-back integrations (CRM, HRIS, payments)
• Training, evaluation and logging stores
• Human review interfaces
• Vendors and hosting regions

1.2 Confirm it is an AI system (Article 3(1))​

Ask:

1. Is it machine-based?
2. Does it operate with some autonomy?
3. Does it infer outputs (predictions, content, recommendations, decisions) from inputs?
4. Can those outputs influence a physical or virtual environment?

Hard-coded rules that only execute human-defined logic without inference are usually not AI systems under the Act. If uncertain, treat as in-scope until legal confirms otherwise.

1.3 Separate model vs system​

Object	Question
GPAI model	Is a general-purpose model being placed on the market / integrated?
AI system	Is an application with an intended purpose being placed on the market or put into service?
Both	Common: you deploy a GPAI-based system and may owe deployer + (sometimes) provider duties

---

Step 2 — Confirm scope and jurisdiction (Article 2)​

2.1 In-scope triggers​

Treat the use case as in scope if any of these are true:

Trigger	Example
Provider places system/model on EU market	SaaS sold to EU customers
Deployer established/located in the EU	EU bank using a vendor model
Output used in the EU	Non-EU processor returns scores used by EU staff
Product manufacturer embeds AI under own brand	Device with AI safety component

2.2 Work the carve-outs carefully​

Carve-out	Apply only if…	Common mistake
Military / defence / national security	Exclusive use for those purposes	Dual-use civilian deployment still in scope
Scientific R&D only	Sole purpose is scientific R&D	Productisation after research re-enters scope
Pre-market research/testing	Before placing on market / putting into service	Real-world testing is not excluded
Personal non-professional use	Natural person, purely personal	Employee workplace use is professional
Open-source	Free/open licence and not high-risk / Art. 5 / Art. 50	Open weights do not erase high-risk duties

---

Step 3 — Map organisational roles​

Roles determine which obligations you own. One organisation often holds several roles.

3.1 Role definitions (apply literally)​

Role	You are this when…
Provider	You develop (or have developed) the system/model and place it on the market / put the system into service under your name or trademark
Deployer	You use the system under your authority in a professional context
Importer	You first place a third-country provider’s system on the Union market
Distributor	You make it available in the supply chain without being provider/importer
Authorised representative	Non-EU provider appoints you in writing
Product manufacturer	AI is placed with your product under your name/trademark
Downstream provider	You integrate a model into an AI system you provide

3.2 Role-shift traps (Article 25)​

You may become the provider if you:

1. Put your name/trademark on a high-risk system already on the market
2. Make a substantial modification to a high-risk system
3. Change the intended purpose of a non-high-risk (including GPAI-based) system so it becomes high-risk

3.3 Build the value-chain map​

For each party, record:

Party	Role(s)	Contractual duty	Evidence they must supply
Foundation-model vendor	GPAI provider	Docs, copyright policy, incident notice	Annex XI/XII pack
Your product team	Provider of the app	Conformity, QMS, CE, registration	Technical file
Business unit	Deployer	Instructions, oversight, FRIA, worker notice	Oversight SOP, FRIA
Integrator	Distributor / deployer	Verify CE / stop if non-compliant	Intake checklist

---

Step 4 — Screen prohibited practices (Article 5)​

If any prohibition hits, stop. Controls do not legalise a prohibited intended purpose.

Prohibitions apply from 2 February 2025. Upper penalty band for undertakings: €35M or 7% worldwide annual turnover (whichever is higher).

4.1 Prohibition screen (work line by line)​

ID	Practice	Screen questions	If “yes / unsure”
5(a)	Subliminal / manipulative / deceptive techniques	Does the system distort behaviour so people take decisions they would not otherwise take, causing (or reasonably likely to cause) significant harm?	Legal review → redesign or stop
5(b)	Exploitation of vulnerabilities	Does it target age, disability, or social/economic vulnerability to distort behaviour with significant harm?	Stop / redesign
5(c)	Social scoring	Does it score people over time from behaviour/traits and produce detrimental treatment in unrelated contexts or disproportionate treatment?	Stop
5(d)	Crime prediction from profiling alone	Does it assess/predict criminal-offence risk solely from profiling or personality traits?	Stop (human assessment of objective facts may still be supported)
5(e)	Untargeted facial scraping	Does it create/expand facial-recognition DBs by scraping internet/CCTV without targeting?	Stop
5(f)	Emotion inference at work/education	Does it infer emotions in workplace or education (outside medical/safety intent)?	Stop
5(g)	Sensitive biometric categorisation	Does it infer race, politics, trade-union membership, religion/beliefs, sex life/orientation from biometrics?	Stop
5(h)	Real-time RBI in public spaces for LE	Is real-time remote biometric ID used in publicly accessible spaces for law enforcement?	Default stop — narrow statutory exceptions only

4.2 Real-time RBI — do not DIY the exceptions​

Even for the listed LE exceptions (victim/missing-person search; imminent threat to life/terror; Annex II serious offences ≥ 4 years), you still need:

• Strict necessity and proportionality
• Prior judicial / independent authorisation (urgency rules)
• Fundamental-rights impact assessment
• EU database registration
• Temporal, geographic and personal limits
• No adverse legal decision based solely on the system output
• Enabling national law (Member States may forbid these uses entirely)

---

Step 5 — Classify the risk tier​

Classification follows intended purpose and context, not model size.

5.1 Decision tree​

5.2 Annex III quick map (high-risk candidates)​

Area	Treat as high-risk candidate when used for…
1 Biometrics	Remote biometric identification; sensitive categorisation; emotion recognition (where permitted)
2 Critical infrastructure	Safety components in critical digital infrastructure, road traffic, water/gas/heating/electricity
3 Education	Admission/assignment; evaluating learning outcomes; education-level decisions; exam proctoring
4 Employment	Recruitment/selection; terms/promotion/termination; task allocation from behaviour/traits; performance monitoring
5 Essential services	Public benefits eligibility; credit scoring (fraud detection excepted); life/health insurance risk & pricing; emergency triage/dispatch
6 Law enforcement	Victim risk; polygraphs; evidence reliability; certain reoffending tools; investigative profiling (where permitted)
7 Migration / border	Polygraphs; entry/migration/health risk; asylum/visa eligibility support; detection/ID (travel-doc check excepted)
8 Justice / democracy	Assisting courts applying law to facts; influencing election/referendum outcomes or voting behaviour

5.3 Applying Article 6(3) derogation (only with evidence)​

You may argue “not high-risk” only if there is no significant risk of harm to health, safety or fundamental rights (including no material influence on decisions) and one of:

1. Narrow procedural task
2. Improves a previously completed human activity
3. Detects deviations from prior human decision patterns (with proper human review; does not replace the assessment)
4. Purely preparatory to an Annex III assessment

Always high-risk if profiling natural persons.

Provider duties when claiming derogation:

• Document the assessment before placing on the market / putting into service
• Register in the EU database (Art. 49(2))
• Produce the assessment to authorities on request

5.4 GPAI track (Chapter V) — run in parallel when relevant​

Question	If yes
Are you placing a GPAI model on the Union market?	Article 53 duties
Training compute > 10²⁵ FLOP, or Commission designation / equivalent impact?	Systemic-risk model → Articles 53 and 55
Free/open weights + public architecture/usage?	Limited documentation relief — not for systemic-risk; copyright policy + training summary still required
Are you only a deployer of a GPAI-based app?	You still own deployer duties; require Annex XII information from the model provider

5.5 Transparency track (Article 50) — often stacks with other tiers​

Trigger	Obligation
System interacts directly with people	Inform them it is AI (unless obvious)
Synthetic audio/image/video/text generation	Machine-readable marking of artificial origin
Emotion recognition / biometric categorisation	Inform exposed persons
Deepfake image/audio/video	Clear disclosure of artificial generation/manipulation
AI text informing the public on public-interest matters	Disclose unless human editorial responsibility applies

---

Step 6 — Implement the control baseline for your class​

6.1 High-risk — Chapter III Section 2 (must-build controls)​

Article	Control you implement	Practical evidence
9 Risk management	Lifecycle risk process covering intended use + reasonably foreseeable misuse	Risk register, residual-risk acceptance, update log
10 Data governance	Relevant, representative training/validation/test data; bias examination; gap handling	Data sheets, lineage, bias tests, retention rules
11 Technical documentation	Annex IV file before market/service; keep updated	Technical file / design history file
12 Logging	Automatic event logs for traceability, post-market monitoring, deployer monitoring	Log schema, retention (≥ 6 months unless other law)
13 Transparency to deployers	Instructions for use: purpose, limits, accuracy, oversight, compute, maintenance	Deployer guide in accessible language
14 Human oversight	Competent humans can understand, override, stop; two-person rule for certain biometric ID	Oversight SOP, training records, stop-button design
15 Accuracy, robustness, cybersecurity	Declared metrics; fail-safe; poisoning/adversarial defences	Eval reports, red-team results, security controls

6.2 Provider operating system (Articles 16–22)​

If you are the provider of a high-risk system, also establish:

Duty	How to apply
Quality management system (Art. 17)	Written policies covering design control, testing, data management, risk, post-market, incidents, accountability
Documentation keeping (Art. 18)	Keep tech file, QMS docs, notified-body decisions, EU DoC for 10 years after market/service
Logs under your control (Art. 19)	Retain appropriately, ≥ 6 months default
Conformity assessment (Art. 43)	Annex VI internal control and/or Annex VII notified body (biometrics stricter)
EU declaration of conformity (Art. 47)	Written DoC; assume responsibility
CE marking (Art. 48)	Physical and/or digital as applicable
Registration (Art. 49)	EU database before market/service (Annex III; critical infrastructure often national)
Corrective action (Art. 20)	Fix, withdraw, disable, recall; inform chain
Authorised representative (Art. 22)	Mandatory for third-country providers before EU availability

6.3 Deployer operating system (Articles 26–27)​

If you are the deployer of a high-risk system:

Duty	How to apply
Use per instructions	Technical + organisational measures; no silent purpose creep
Assign oversight	People with competence, training, authority and support
Input-data quality	Where you control inputs: relevant and sufficiently representative
Monitor & escalate	Suspend if use presents a risk; report serious incidents
Keep logs	Under your control, ≥ 6 months default
Workplace notice	Inform workers’ representatives and affected workers before use
Inform affected persons	When Annex III systems decide or assist decisions about them
FRIA (Art. 27)	Before certain public-body / public-service / credit / insurance uses
Public-authority registration	Register use in EU database; do not use unregistered systems

6.4 GPAI provider baseline​

All GPAI (Art. 53)	Systemic-risk add-ons (Art. 55)
Technical documentation (Annex XI)	Adversarial evaluation / red-teaming
Downstream info (Annex XII)	Union-level systemic-risk assessment & mitigation
Copyright / TDM opt-out policy	Serious-incident tracking & reporting
Public training-content summary	Cybersecurity of model + infrastructure

Use codes of practice (Art. 56) until harmonised standards exist; keep alternative compliance evidence if you do not adhere.

6.5 Transparency-only / minimal class​

Still implement enterprise controls proportionate to harm (security, privacy, evaluation, incident response). The Act’s lighter touch is not permission to skip organisational risk management — see the NIST companion article.

---

Step 7 — Assemble the evidence pack​

Authorities and auditors ask for artefacts, not intentions.

7.1 Core pack by class​

Artefact	High-risk provider	High-risk deployer	GPAI provider	Transparency
Classification memo	✓	✓	✓	✓
Role map	✓	✓	✓	✓
Risk-management file (Art. 9)	✓	use provider instructions + local risks	systemic risk file if Art. 55	proportionate
Data governance pack (Art. 10)	✓	input-data controls	training-data summary	as needed
Technical documentation (Annex IV / XI)	Annex IV	—	Annex XI	—
Instructions for use / Annex XII	✓	received & version-controlled	Annex XII to downstream	UX copy
Human-oversight SOP	design + guide	operating SOP + staffing	—	escalation path
Evaluation / robustness / security reports	✓	acceptance tests	model eval + red team	smoke tests
QMS / policies	✓	local operating procedures	policies + codes of practice	—
EU DoC + CE	✓	verify before use	—	—
Database registration proof	✓	public bodies: use registration	notify AI Office if systemic	—
FRIA / DPIA	support deployers	Art. 27 + GDPR DPIA as applicable	—	DPIA if personal data
Post-market / monitoring plan	✓	monitoring per instructions	incident reporting	feedback loop
Incident procedure	✓	✓	✓	✓

7.2 Annex IV technical documentation — minimum outline​

1. General description (purpose, versions, hardware/software, UI, instructions)
2. Development process (methods, design choices, architecture, data, oversight design, pre-determined changes, validation/tests, cybersecurity)
3. Monitoring, capabilities, limitations, discrimination risks
4. Performance metrics appropriateness
5. Risk-management system description
6. Lifecycle changes
7. Harmonised standards / common specs applied
8. Copy of EU declaration of conformity
9. Post-market monitoring system and plan

SMEs may use the Commission’s simplified form when available; notified bodies must accept it.

7.3 Logging fields (practical minimum)​

Event field	Why
Timestamp, system/version IDs	Traceability
User / deployer organisation	Accountability
Input reference (not raw secrets if avoidable)	Replay / audit
Output / decision reference	Challenge rights
Human override / stop	Oversight proof
Confidence / policy / guardrail hits	Safety analysis
Serious-incident flag	Art. 73 reporting

---

Step 8 — Human oversight, transparency and impact assessments​

8.1 Human oversight design (Article 14)​

Design so assigned people can, as appropriate:

1. Understand capacities and limits; detect anomalies
2. Resist automation bias
3. Interpret outputs correctly
4. Decide not to use / disregard / override outputs
5. Stop the system safely

For certain remote biometric identification systems: no action/decision based on an ID match unless separately verified by at least two competent persons (with limited LE/migration exceptions where law finds this disproportionate).

8.2 Fundamental rights impact assessment (Article 27)​

Who: public-law bodies; private entities providing public services; deployers of Annex III credit-scoring and life/health-insurance pricing systems (critical-infrastructure safety components in Annex III point 2 are excepted from this FRIA duty).

When: before first use; update when relevant factors change.

Minimum content:

Element	Fill in
Processes where the system will be used
Period and frequency of use
Categories of persons/groups affected
Specific risks of harm (use Art. 13 info from provider)
Human-oversight measures
Measures if risks materialise (governance, complaints, redress)

Notify the market surveillance authority with the completed template (AI Office questionnaire when available). Complement — do not replace — the GDPR/LED DPIA.

8.3 Transparency UX checklist (Article 50)​

Surface	Required disclosure
Chat / voice agent	“You are interacting with an AI system” (unless obvious)
Generated media pipeline	Machine-readable provenance / watermarking where technically feasible
Deepfake publish path	Clear human-visible label
Public-interest AI text	Label unless editorial responsibility applies
Emotion / biometric categorisation	Notice to exposed persons

Meet accessibility requirements for notices.

---

Step 9 — Governance decision gate​

Record an explicit decision. Do not imply approval from silence.

Decision	When to use	Conditions
Stop	Art. 5 hit; unjustified residual risk; missing critical evidence	Archive decision; block tooling access
Hold	Classification or FRIA incomplete; vendor evidence missing	Time-boxed actions; no production data
Redesign	Purpose drives high-risk/prohibited outcomes unnecessarily	Change purpose, automation, or population; re-enter Step 1
Go (conditional)	Class clear; controls and evidence accepted	Named conditions, owners, review date
Go	All mandatory artefacts approved for this class	Enter monitoring calendar

Decision record template​

Field	Entry
System / version
Classification
Roles (our org)
Residual risks accepted
Conditions / exemptions
Kill criteria
Next review date
Approver name / date

---

Step 10 — Timeline, registration and post-market duties​

10.1 Application calendar (plan programmes against this)​

Date	What binds you
2 Feb 2025	Chapters I–II: definitions, literacy (Art. 4), prohibitions
2 Aug 2025	Governance machinery, GPAI obligations, penalties framework, notified bodies
2 Aug 2026	General application of the Regulation
2 Aug 2027	Art. 6(1) product high-risk path fully applicable; GPAI models already on market must complete compliance steps
2 Aug 2030 / 31 Dec 2030	Extra transition for certain public-authority high-risk uses and Annex X large-scale FSJ systems

Legacy high-risk systems on the market before 2 Aug 2026 generally need full new compliance when subject to significant design changes thereafter — with stricter public-authority timelines.

10.2 Registration (Article 49)​

Who	What
Provider of Annex III high-risk (except point 2)	Register self + system before market/service
Provider claiming Art. 6(3) not-high-risk	Register self + system
Public-authority deployers of Annex III (except point 2)	Register self, select system, register use
Law enforcement / migration / justice biometrics etc.	Secure non-public database section
Critical infrastructure (point 2)	National registration

10.3 Post-market and incidents​

Duty	Apply by
Post-market monitoring system + plan (Art. 72)	Providers of high-risk systems
Serious-incident reporting (Art. 73)	Report to market surveillance where the incident occurred — timelines as short as 2–15 days depending on severity
Corrective action / recall	Providers; deployers suspend and escalate
Material-change reassessment	New conformity assessment if substantial modification

10.4 AI literacy (Article 4)​

Providers and deployers must ensure staff and operators have sufficient AI literacy for the context. Record training by role (oversight staff need more than end users).

---

Worked examples (apply the steps)​

Example A — Internal coding assistant (EU employees)​

Step	Result
Boundary	IDE plugin + LLM API + prompt filters + logging
Roles	You = deployer of vendor GPAI system; vendor = GPAI provider
Art. 5	Clear (no manipulation/scoring/biometrics)
Class	Not Annex III; Art. 50 may apply if users might think a person is answering — usually obvious in IDE
Controls	Secure SDLC, secret scanning, data-loss controls, vendor Annex XII pack, literacy
Decision	Go conditional — no customer personal data in prompts

Example B — CV ranking for EU hiring​

Step	Result
Boundary	ATS integration + ranking model + recruiter UI
Roles	Likely provider if you brand/supply the tool; hiring company is deployer
Art. 5	Screen emotion inference / manipulative dark patterns
Class	High-risk — Annex III point 4(a) recruitment/selection
Controls	Full Section 2 + QMS + conformity + CE + registration; deployer oversight, worker notice, bias testing
Decision	Go only with complete provider file and deployer SOP

Example C — Chatbot that grants/denies public benefits​

Step	Result
Art. 5	Clear only if no prohibited scoring/manipulation
Class	High-risk — Annex III point 5(a)
Extra	Deployer FRIA (Art. 27) + DPIA; no adverse decision without meaningful human involvement design
Decision	Hold until FRIA, oversight staffing and appeal path exist

---

Penalty bands (why the gate is real)​

Breach	Undertaking ceiling (higher of)
Art. 5 prohibited practices	€35M or 7% turnover
Most operator / Art. 50 / notified-body breaches	€15M or 3% turnover
Misleading information to authorities	€7.5M or 1% turnover
GPAI provider breaches (Commission)	€15M or 3% turnover

SMEs/start-ups: use the lower of the percentage or fixed amount. Always apply procedural fairness and national rules.

---

Material-change triggers (re-enter the playbook)​

Re-run from Step 1 when any of these change:

• Intended purpose or prohibited-action list
• User or affected population
• Geographic market / output-use location
• Automation level or oversight model
• Model provider, model version, fine-tune data
• Retrieval corpus or tool permissions
• Data categories or retention
• Branding / substantial modification / new high-risk purpose

---

Common failure modes​

Failure	Correction
Classifying the model, not the use	Fix intended purpose and Annex III mapping
“We’re only a deployer” while branding the app	Re-run Article 25 role analysis
Skipping Art. 5 because “we’re high-risk compliant”	Prohibitions override control frameworks
Art. 6(3) without documentation/registration	Treat as high-risk until pack exists
FRIA after go-live	Complete before first use where required
Vendor PDF as sole evidence	Demand Annex XI/XII + contractual audit rights
No kill criteria	Add stop conditions to the decision record

---

Master checklist (print this)​

---

How this fits the Governance series​

Article	Use for
This playbook	Apply Regulation 2024/1689 step by step on a live use case
NIST AI RMF and the EU AI Act	Enterprise Step-5 gate; Govern/Map/Measure/Manage operating model
ISO/IEC 42001	Artificial Intelligence Management System (AIMS) backbone
Responsible AI and Governance	Delivery-layer principles, artefacts and traceability

---