EU AI Act for Frontend and Product Teams
This page explains what frontend and product teams MUST do under Regulation (EU) 2024/1689 (the EU AI Act), in practical delivery terms.
This page is not legal advice. It is an engineering-focused interpretation of the regulation text. Always validate decisions with legal and compliance teams before launch.
- Prohibited practice (Art 5): up to €35,000,000 or 7% of worldwide annual turnover.
- Other operator / notified-body breaches: up to €15,000,000 or 3%.
- Supplying incorrect, incomplete, or misleading info: up to €7,500,000 or 1%.
Whichever is higher (for SMEs, whichever is lower).
Official source and scope
- Regulation text: Regulation (EU) 2024/1689
- This regulation uses risk-based obligations:
- Prohibited practices: feature cannot be placed on the market or used.
- High-risk AI systems: feature is allowed only with strict controls and evidence.
- Transparency-triggered cases: feature is allowed, but user-facing disclosures are mandatory.
Which page should I open?
Open the use-case page closest to your real feature behavior:
| If your feature does this | Open this page | Initial likely path |
|---|---|---|
| Filters, ranks, or scores job applicants | Hiring screening and ranking | High-risk |
| Scores exams or flags suspicious exam behavior | Exam scoring and proctoring | High-risk |
| Supports decisions about credit, insurance, benefits, or similar access | Access to essential services | High-risk |
| Lets users chat with an AI assistant for support | Customer support chatbot | Transparency-triggered |
| Generates or manipulates text, image, audio, or video | Content generation and synthetic media | Transparency-triggered (sometimes prohibited depending on intent/use) |
| Uses face or biometric signals for identification/categorization/inference | Biometric and face-related features | Prohibited or high-risk or transparency-triggered (depends on exact use) |
Timeline milestones teams should track
| Milestone | Practical meaning for teams |
|---|---|
| 1 August 2024 | Regulation entered into force (Art 113). Teams MUST classify AI features and map provider/deployer responsibilities in delivery workflows. |
| 2 February 2025 | Chapters I–II apply: Art 5 prohibitions bind (MUST NOT launch banned use cases) and Art 4 AI literacy applies (MUST complete role-appropriate training and keep records). |
| 2 May 2025 | GPAI codes of practice due (Art 56). Teams relying on general-purpose models MUST track their model provider's code-of-practice adherence. |
| 2 August 2025 | GPAI obligations + governance (Chapter VII) + penalties (Art 99) + notified bodies apply. Teams using external models MUST collect supplier compliance documentation and model/version traceability. |
| 2 August 2026 | General application (Art 113). High-risk and transparency duties in scope. Teams MUST run release gates so in-scope features have completed classification, required controls, required disclosures, and stored evidence before release. |
| 2 August 2027 | Art 6(1) Annex I product-embedded high-risk systems, and GPAI models already on the market before 2 Aug 2025, MUST comply. Re-check deployed features and supplier dependencies. |
| 2 August 2030 / 31 December 2030 | Legacy public-authority high-risk systems must comply by 2 Aug 2030; large-scale EU IT systems in Annex X by 31 Dec 2030 (Art 111). |
AI Act role terms in plain language (with web examples)
The same company can hold different roles for different features.
- Provider: you build an AI system (or put it on market) under your name.
Example: your company ships its own CV-screening feature as part of a hiring SaaS. - Deployer: you use an AI system in your business operations.
Example: your support team uses a third-party AI assistant inside your customer portal. - Importer: you bring an AI system from outside the EU into the EU market.
- Distributor: you supply an AI system in the EU market without being the provider/importer.
- Authorised representative: a non-EU provider MUST appoint one established in the EU (Art 22 for AI systems, Art 54 for GPAI models).
- Product manufacturer: treated as a provider when the high-risk system ships under their product or trademark (Art 25(3)).
A deployer, distributor, importer, or third party becomes a provider with full provider obligations if they (a) put their name/trademark on a high-risk system, (b) substantially modify it, or (c) change its intended purpose so it becomes high-risk. Rebranding or repurposing a vendor's model is not a shortcut around provider duties.
How to classify a feature (decision path)
Run this sequence for each AI feature version.
Step 0: Is it in scope?
WHEN: Before any classification work.
MUST confirm the feature is an AI system (Art 3(1)): "a machine-based system designed to operate with varying levels of autonomy, that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers from the input it receives how to generate outputs such as predictions, content, recommendations, or decisions."
Scope exclusions (Art 2) — the Act does not apply to:
- Systems used purely for scientific R&D (Art 2(6)) or pre-market R&D/testing (Art 2(8)).
- Purely personal, non-professional use (Art 2(10)).
- Military, defence, or national-security purposes (Art 2(3)).
- Free & open-source AI systems (Art 2(12)) — except when they are high-risk, prohibited (Art 5), or fall under Art 50 transparency duties.
The Commission issues guidelines clarifying the AI-system definition and scope (Art 96). If a feature clears Step 0 as in-scope, continue to Step 1.
Step 1: Define what the feature actually does
WHEN: A new AI feature, major model change, or major use change is planned.
MUST:
- Document the feature purpose in one sentence.
- Document who is affected and what outcome is influenced.
- Document whether output is advisory only or used in a decision.
WHY this matters: AI Act classification is based on real use and impact, not team labels like “assistant” or “copilot.”
Step 2: Screen for prohibited practices first
WHEN: Step 1 is complete.
MUST ask:
- Does it use manipulative/deceptive techniques or exploit vulnerability in ways likely to cause harm?
- Does it implement prohibited social scoring logic causing unjustified detrimental treatment?
- Does it match other banned biometric-related practices in the regulation text for your context?
WHY prohibited if yes: These uses are treated as unacceptable risk to fundamental rights. They are not conditionally allowed.
MUST if yes: Stop work, block release, escalate to legal/compliance, and keep the prohibition record.
Step 3: Screen for high-risk scope
WHEN: Feature is not prohibited.
MUST ask:
- Is the feature used in employment (hiring, promotion, worker management)?
- Is it used in education/vocational assessment (exam scoring, proctoring)?
- Is it used for access decisions in essential services (credit, insurance, benefits, similar)?
- Is it biometric identification/categorization use that is not prohibited but regulated?
- Is it a safety component or product-linked case in regulated product scope?
WHY high-risk if yes: These domains can strongly affect legal rights, opportunities, safety, and access to essential life outcomes.
MUST if yes: Treat as high-risk candidate, require formal classification, and do not launch before required controls/evidence are approved for your role.
An Annex III system is not high-risk if it only (a) performs a narrow procedural task, (b) improves the result of prior human activity, (c) detects decision patterns/deviations without replacing human review, or (d) does a preparatory task. But it is ALWAYS high-risk if it performs profiling of natural persons. A provider that self-classifies as not-high-risk MUST still document the assessment (Art 6(4)) and register in the EU database (Art 49(2)).
Step 4: Screen for transparency duties
WHEN: Feature is not prohibited, and high-risk scope is not confirmed (or additional transparency duties still apply).
MUST ask:
- Are users interacting with an AI system when people cannot reasonably tell they are interacting with AI?
- Is content AI-generated or AI-manipulated and presented to users?
- Is there emotion recognition or biometric categorization where notice duties apply?
WHY transparency-triggered if yes: People must be informed when they cannot reasonably tell they are interacting with AI, or when they consume synthetic/manipulated content in covered scenarios.
MUST if yes: Implement required disclosures before release and verify them in all supported locales. Split the duty by role:
- Provider — design AI that interacts with people so users know it is AI (Art 50(1)), and mark generative-AI output (audio/image/video/text) as artificially generated in a machine-readable format — watermark/metadata (Art 50(2)).
- Deployer — notify people exposed to emotion recognition or biometric categorisation (Art 50(3)); disclose deep fakes and AI-generated text published to inform the public on matters of public interest (Art 50(4)).
Step 5: Confirm supplier and literacy obligations
WHEN: Any third-party model/provider is used, or staff build/use AI systems.
MUST:
- Request and store supplier attestations/documentation relevant to EU AI Act obligations, and keep model/provider identity plus version traceability.
- Re-run checks when provider/model versions or feature purpose changes.
- Keep AI literacy completion records for relevant roles.
WHY: Duties apply across the supply chain and operating teams, not only to model vendors.
What high-risk actually requires
Once a feature is confirmed high-risk, obligations depend on your role.
Seven system requirements (Art 9\u201315):
- Risk management system (Art 9).
- Data & data governance (Art 10).
- Technical documentation (Art 11).
- Record-keeping / automatic logs (Art 12).
- Transparency & instructions for use (Art 13).
- Human oversight (Art 14).
- Accuracy, robustness & cybersecurity (Art 15).
Provider duties (Art 16):
- Quality management system (Art 17); keep documentation (Art 18).
- Conformity assessment before market (Art 43); EU declaration of conformity (Art 47); CE marking (Art 48); register in EU database (Art 49).
- Post-market monitoring (Art 72); serious-incident reporting (Art 73); corrective actions (Art 20).
Deployer duties (Art 26):
- Use per instructions; assign competent human oversight; ensure input-data relevance where controlled; monitor and keep logs \u2265 6 months.
- Inform workers' reps and affected workers before workplace deployment (Art 26(7)); inform affected persons for Annex III decision systems (Art 26(11)); run a DPIA where required (Art 26(9)).
- Complete a Fundamental Rights Impact Assessment before deployment (Art 27) if you are a public body / provide public services, or you are a creditworthiness / insurance-pricing deployer \u2014 then notify the market surveillance authority.
- Support the affected person's right to explanation (Art 86) for decisions based on an Annex III system's output with legal or similarly significant effect.
Report without undue delay after establishing a causal link, and at most: 15 days normally; 2 days for widespread infringement or serious/irreversible critical-infrastructure disruption; 10 days where a death is involved. An initial incomplete report is allowed.
The European Commission lists illustrative high-risk cases such as exam scoring, CV-sorting recruitment software, and credit scoring that denies a loan. It has also published guidance on prohibited practices and on the AI-system definition (Feb 2025). Always check the latest Commission AI Act guidance for current examples, as further guidance is still being issued.
Use-case playbooks
- Hiring screening and ranking: high-risk path for employment-impacting workflows.
- Exam scoring and proctoring: high-risk path for education and certification outcomes.
- Access to essential services: high-risk path for credit, insurance, benefits, and similar decisions.
- Customer support chatbot: transparency duties for AI interaction disclosure.
- Content generation and synthetic media: labeling and prohibited-use escalation path.
- Biometric and face-related features: prohibited-first screening, then high-risk/transparency assessment.
Required release checklist
- Role identified for this feature (provider/deployer/importer/distributor).
- Prohibited-practice screening completed and stored.
- If prohibited: release blocked and escalation recorded.
- If high-risk candidate: formal determination and required controls approved before release.
- If transparency-triggered: required disclosures/labels implemented and validated.
- If third-party GPAI/model is used: supplier documentation and model-version traceability stored.
- AI literacy obligations recorded for relevant team roles.
- Reclassification trigger defined for changes in model, purpose, data, or decision impact.