EUROPE · RIGHTS · RESPONSIBILITY
Practical EU AI Act guide: risk, GDPR, explainability, authorities, advanced models and evidence.
Independent educational guide, reviewed 26 October 2026. Not individual legal advice or certification. Classification and duties depend on purpose and context. Check consolidated legislation and changes before deployment.
Summary of the Commission timeline incorporating the AI Omnibus. Transitional provisions and exceptions require case-specific checking.
Not every framework applies to every project. This is a scoping map, not an exhaustive obligation list.
| Marco / Framework | When to assess it | Link |
|---|---|---|
| RGPD + LOPDGDD | Personal data, lawful basis, rights, DPIA, processors and transfers. | Source |
| AI Act | System/model, role, prohibitions, risk, transparency and conformity. | Source |
| MDR / IVDR | Medical-device intended purpose: qualification and clinical/sector duties. | Source |
| NIS2 / CRA | Assess entity, product and national implementation; not all AI is in scope. CRA reporting starts September 2026; main duties December 2027. | Source |
| DORA / finanzas | Financial entities and ICT resilience; add the specific financial-service regime. | Source |
| Propiedad intelectual | Copyright, databases, licences and rights reservations; accessible data is not automatically freely reusable. | Source |
| Data Act / DGA | Data access and reuse within scope; neither replaces GDPR nor authorises all training. | Source |
| Trabajo, consumo, igualdad y sector público | Assess labour information, non-discrimination, accessibility, procurement and safety in context. In Spain assess ENS where the public-system context requires it. | Source |
The AI Act regulates AI systems and models according to function, risk and value-chain role; it does not grant universal permission to use data. Identify intended purpose, users, affected people, geography, provider, deployer and changes. The same model may carry different duties in different uses. Internal prototypes and free systems are not automatically exempt.
A model is a component; a system also includes interfaces, rules, data, integration and use. Providers and deployers have different duties. Rebranding, substantial modification or a changed intended purpose can shift provider responsibilities. Supplier contracts should allocate tasks, evidence access and cooperation, but cannot remove statutory duties.
Check Article 5: specified harmful manipulation, exploitation of vulnerabilities, social scoring, crime prediction based solely on profiles, indiscriminate facial-image scraping and certain biometric uses are prohibited. Emotion inference in workplaces and education has a specific prohibition with medical or safety exceptions. Biometrics and surveillance are not ordinary use cases: conditions and exceptions require exact analysis.
Main routes concern specified regulated products or safety components under Annex I and uses listed in Annex III, including employment, education, essential services and certain public functions. Article 6(3) exceptions require conditions and documentation: calling a tool advisory is insufficient. An Annex III system profiling natural persons cannot use that exception to downgrade its classification.
An industrial predictor is not automatically high-risk because it uses neural networks. Data protection, product safety, contracts and sector rules may still apply. Article 50 transparency duties are triggered by specific functions, not marketing labels. Record why categories do or do not apply and reassess changes in purpose or integration.
For high-risk systems, risk management is continuous: identify foreseeable hazards, assess impacts, implement controls and evaluate residual risk. Connect each risk to verifiable evidence: test, owner, acceptance threshold and release decision. Compliance is not a final folder; reassess data, model, user and environment changes.
Document provenance, licences, purpose, representativeness, cleaning, labelling, dataset separation and potential bias. Examine actual use and affected groups. Prevent training–evaluation leakage, including temporal leakage. Synthetic data does not guarantee anonymity or fairness. Special-category processing requires its specific legal conditions and safeguards; do not collect sensitive attributes by default just to complete an audit.
Maintain system description, intended purpose, architecture, versions, data, metrics, validation, limits, risks and controls. Map requirements to evidence and record changes. A model card is useful but does not replace required technical documentation. Reconstruct the released version and its evaluation without retaining unnecessary personal data.
Design logs supporting investigation: version, time, minimal input or reference, output, intervention and relevant event. Retention must follow applicable duties, purpose and security requirements. Do not indiscriminately store conversations, secrets, health data or internal reasoning chains. Restrict access and protect integrity.
Article 13 requires sufficient transparency for high-risk deployers to interpret outputs and use them appropriately, with comprehensible instructions about purpose, performance, limits and oversight. This is not a blanket requirement to publish all source code or weights. Explanations must support a real person and task, rather than merely present an attractive chart.
Article 86 concerns clear, meaningful explanations of AI’s role and the main elements of specified decisions based on Annex III high-risk systems, excluding point 2. Its effects and conditions must be met, and legal restrictions and other EU rights matter. It is not a universal entitlement to a technical explanation of every prediction.
As technical practice, compare interpretable models, feature importance, local explanations and counterfactuals. SHAP and LIME may help, but are not prescribed by the Act and do not establish causality or compliance. Test stability, faithfulness and comprehension. A plausible LLM narrative does not establish why another model decided. Explaining an output differs from justifying a decision.
High-risk oversight requires competence, authority and means to interpret, detect anomalies, intervene or stop use. Automatic sign-off or review without time does not provide substantive oversight. Test disagreement scenarios and automation bias. Specify escalation conditions and who owns decisions.
Choose harm-relevant metrics: false positives and negatives, calibration, uncertainty, subgroup performance, degradation and availability. Thresholds are not universal. Test distribution shifts, attacks, tampering, poisoning and dependencies. Generative models also need hallucination, leakage, prompt-injection and tool-abuse evaluations. High average accuracy can conceal serious failures.
High-risk deployers must follow instructions, assign oversight, manage data under their control and handle monitoring and incidents as applicable. Using an API does not automatically make a customer the base-model provider. Changes in purpose or substantial modification may change the analysis. Obtain adequate supplier documentation and reporting channels.
A GDPR DPIA and Article 27 AI Act fundamental-rights assessment are not identical documents and have different scopes. Article 27 concerns specified deployers, including public-related cases and certain services, not every model. Examine affected groups, impacts, mitigations and relevant participation. Coordinate assessments without losing their distinct requirements.
For identifiable people’s data, establish lawful basis, purpose, minimisation, information, retention, processors and transfers. GDPR Article 22 concerns specified solely automated decisions with legal or similarly significant effects, not every prediction. Examine exceptions and safeguards. Decorative human involvement does not change the process. Pseudonymisation is not anonymisation.
Do not assume parameters cannot contain personal information merely because they are parameters. The ORGANIZATION-009 calls for case-specific anonymity assessment and examination of legitimate interest where relied upon. Consider memorisation, extraction, expectations and mitigations; public sources do not erase individual rights. Training and downstream use may require separate lawful-basis analysis.
A model estimating corporate demand, solvency or risk is not automatically high-risk because it concerns an entity. Its data may nevertheless identify sole traders, directors, employees or customers. Check trade secrets, licences, accuracy and sector use: corporate analysis feeding employment or personal-credit decisions changes context. Investment-related services also need financial-regulatory analysis.
Before predicting performance, health, behaviour or vulnerability, ask whether the purpose is lawful, necessary and proportionate and what errors could do. Do not infer sensitive traits out of curiosity or repurpose scores beyond context. Provide understandable information, correction, review and complaints. Medical or employment systems need specialist sector analysis, not merely neural-network tuning.
Separate GPAI model-provider duties from those of integrating systems. Article 53 addresses documentation, downstream information, copyright policy and a public training-content summary under its conditions. Open-source exceptions have limits; publishing weights does not exempt every development. Fine-tuning requires analysis of actual role and modifications.
GPAI models with systemic risk have additional duties involving evaluation, adversarial testing, risk mitigation, incidents and cybersecurity. Do not equate systemic risk with every large model or one isolated metric; check current criteria and procedures. Integrators must still assess their use case and cannot transfer all responsibility to the base model.
Assess AI-interaction notices and marking or disclosure duties applicable to providers or deployers, including exceptions. Technical marking differs from audience-facing disclosure. A generic footer does not solve every case. Transparency does not authorise defamation, personal-data disclosure or copyright infringement.
For high risk, determine the applicable conformity route, documentation, EU declaration, marking and registration. Not all systems require the same external body. A notified body is not just any commercial auditor. Harmonised standards have specified legal effects only under relevant conditions; logos or voluntary audits do not replace required conformity.
ISO/IEC 42001 structures an AI management system. Certification is voluntary and performed by certification bodies, not ISO. It can evidence in-scope processes but does not certify that every model, decision or processing operation meets all law. Check scope, issuer and validity; it is not blanket AESIA or EU approval.
Prepare post-market monitoring and incident channels. Track drift, complaints, misuse and real harm, not just lab accuracy. Define investigation ownership, rollback and corrective communications. Deadlines depend on regime and severity: one incident may trigger the AI Act, GDPR and sector rules simultaneously.
RAG does not remove responsibility for sources, data or outputs. For agents, restrict tools and permissions, separate environments, validate irreversible actions and log authorisations without storing secrets. Evaluate retrieval, citations, document exposure and prompt injection. These are proposed technical controls; adequacy is system-dependent. Agents accessing payments, records or infrastructure need particularly clear boundaries.
Editorial diagram; each duty has its own legal scope.
Illustrative editorial examples, not classification opinions. The last column combines potential duties and technical recommendations.
| System | Initial scoping | Evidence and controls |
|---|---|---|
| Energy-demand forecast | Not necessarily high-risk; reassess safety-component use in critical infrastructure. | Temporal validation, uncertainty, use limits and safe failure. |
| Job-applicant ranking | Typical Annex III use; assess purpose, classification and GDPR. | Relevant data, bias tests, meaningful oversight, information and review. |
| Natural-person creditworthiness | Generally high-risk within the Annex III case; exceptions are specific. | Calibration, traceability, decision reasons, review and financial rules. |
| Corporate solvency | Not inherently the same as assessing a natural person’s creditworthiness. | Provenance, incidental personal data, uncertainty and advice limits. |
| Public-document assistant | Assess interaction, sources, licences and data processing. | AI notice where required, verifiable references, error evaluation and access control. |
| Clinical diagnostic support | May engage medical-device and high-risk rules; intended medical purpose matters. | Clinical evidence, risk management, sector assessment and professional oversight. |
| Employee emotion inference | Generally prohibited in the workplace, subject to specific exceptions. | Do not deploy merely on consent; examine prohibition and exceptions. |
| Moderation or fraud detection | The label does not determine risk; assess people, effects and the exact legal case. | False positives, intervention, appeal, security and applicable sector rules. |
| Invoice-processing agent | Not automatically high-risk; data and actions may trigger other duties. | Least privilege, payment approval, limits, auditability and recovery. |
Check current designations and sector competence before filing documentation or complaints. Not every authority certifies models.
| Comisión Europea / Oficina de IA | EU supervision and coordination; specific role for GPAI models. |
| Comité Europeo de IA | Member-State coordination and advice; not a desk approving every model. |
| AESIA | Spanish AI supervision and resources reference. Verify specific competence and current designation. |
| AEPD / autoridades de protección de datos | Personal-data protection; AI oversight does not replace it. |
| Supervisores sectoriales | Finance, health, product safety and other fields: competence depends on the system and current framework. |
| Autoridades notificantes y organismos notificados | Authorities designate and supervise; bodies assess conformity in routes requiring their involvement. |
Preparation checklist, not a compliance test or certificate. Ticking boxes does not establish adequate evidence. Selection lasts only while this page remains open.
Download evidence template · JSONThis is a proposed implementation sequence, not an alternative legal route or a promise of zero risk.
No: classify the integrated system and your own duties.
No: it is an analysis technique; validate usefulness and address legal requirements separately.
No: meaningful understanding, disagreement and intervention are needed.
Not necessarily: identifiable people’s data may be involved.
No: it is a regulated testing environment, not immunity.
Reglamento / Regulation (EU) 2024/1689 · Regulation (EU) 2026/1744 · AI Act Service Desk · AESIA · AEPD · ORGANIZATION-009
Chapter links support further reading. Guides and codes do not replace law. Review amendments, published harmonised standards and national competence before applying this guide. Photographs are AI-generated conceptual illustrations, not authority photographs or conformity seals.