AI Act (EU Regulation 2024/1689)
European regulation applicable to any AI system marketed, put into service or used in the EU. Classifies systems into four risk categories (unacceptable, high, limited, minimal) with different obligations for providers, distributors, importers and deployers. Entered into force 2 August 2024 and applies in stages until 2027. Sanctions up to €35M or 7% of global revenue.
What the AI Act is and who it applies to
The AI Act (EU Regulation 2024/1689) is the world's first comprehensive AI regulation. It applies to any AI system marketed, put into service or used in the European Union, regardless of where the provider is established. That is: if your company is in Spain and uses an OpenAI model (US company) to process data of a German client, the AI Act applies to you.
The regulation's logic is simple: classify systems by risk level and assign proportional obligations. Minimum risk systems have practically no obligations beyond good practices. High risk have extensive obligations for documentation, risk management, transparency, human oversight and cybersecurity.
Obligations split between providers (whoever puts the system on the market or develops it) and deployers (whoever uses it professionally). Critical to identify your role before anything — many companies think they're "just users" when in reality they're providers because they customise or market AI systems.
Applies also to companies outside the EU if their systems are used inside. And applies to the deployer even if the provider is outside. This means if you contract an AI SaaS from an American startup, you (as Spanish deployer) have obligations even if the provider doesn't comply.
The 4 roles: provider, deployer, importer, distributor
A single company can have multiple simultaneous roles per specific AI system. Example: an AI consultancy (us) is a provider when we develop and integrate a proprietary agent for a client, and we're deployer when we use ChatGPT Enterprise to draft internal proposals.
| Role | Definition | Typical example | Obligations |
|---|---|---|---|
| Provider | Person/company that develops an AI system and markets/puts into service under its name | Spanish startup selling AI chatbot to hotels | Maximum · technical, documentation, conformity assessment |
| Deployer | Person/company using an AI system in professional activity | Insurer using third-party AI for claims triage | Compliant use, human oversight, information to affected |
| Importer | EU-established that imports to EU an AI system from extra-EU provider | European distributor of American AI systems | Verifies provider complied; documentation |
| Distributor | Any person in supply chain making AI system available without being provider/importer | Reseller selling third-party AI system | Verifies labelling and documentation |
If you're "just deployer" but substantially modify a provider's AI system (fine-tuning with your data, purpose change, output adjustment), you become provider in AI Act's eyes. With maximum obligations. This point gets ignored in many internal fine-tuning projects.
The 4 risk categories
- Unacceptable risk · PROHIBITED — Subliminal manipulation systems, social scoring by public authorities, biometric categorisation by race/orientation, emotion recognition in work/education (with exceptions), mass scraping of facial images from internet for databases. Maximum sanction €35M / 7%.
- High risk · EXTENSIVE OBLIGATIONS — Systems used in: education access, employment (selection, evaluation), essential services (credit, life/health insurance), law enforcement, migration/asylum/borders, justice administration, democratic processes. Requires technical file, conformity assessment, risk management system, transparency, human oversight, cybersecurity, EU database registration. Sanction up to €15M / 3%.
- Limited risk · TRANSPARENCY — Chatbots, deepfakes, systems generating synthetic content. Basic obligation: inform user they interact with AI or that content is artificially generated. Applies to most commercial chatbots and generative systems.
- Minimal risk · GOOD PRACTICES — Everything else. Spam filters, content recommenders, video games with AI, purely internal systems. No legal obligations — just suggested good practices.
GPAI (General Purpose AI Models) systems — such as Claude, GPT, Gemini, Llama — have their specific regime within AI Act. Providers of these models (Anthropic, OpenAI, Google, Meta) have their obligations. If you use their API, you're not a GPAI provider — you're a deployer of the system you've built on top.
Concrete obligations for a Spanish company
For a Spanish company using AI in internal or commercial processes, obligations depend on role (provider/deployer) and system risk category. This is the executive summary:
- AI systems inventory · All · Keep register of all AI systems used or developed: purpose, risk category, provider, data processed, automated decisions.
- Category analysis · All · For each system, evaluate risk category with regulation annex III criteria. If high risk, move to next obligations level.
- Risk management system · High risk provider · Documented process for identifying, evaluating and mitigating system risks throughout its lifecycle.
- Technical file · High risk provider · Detailed documentation: architecture, training data, performance metrics, known limitations, foreseen and unforeseen use cases.
- Log registration · Provider + Deployer high risk · System must generate automatic logs allowing subsequent audit.
- Transparency with user · All limited risk+ · Inform when user interacts with AI (chatbots) or when content is synthetic (deepfakes, commercial generative AI).
- Human oversight · High risk · Design allowing a human to supervise the system, understand its output and intervene/stop if problem detected.
- Conformity assessment · High risk provider · Before marketing, assess system meets requirements. Can be self-assessment or notified body certification per case.
- CE marking + EU registration · High risk provider · System bears CE marking and registers in EU's high-risk AI systems database.
- Fundamental rights impact analysis (FRIA) · High risk deployer public/essential services · Specific evaluation on impact to affected people.
Application calendar 2024-2027
| Date | What enters application |
|---|---|
| 1 August 2024 | Regulation enters into force |
| 2 February 2025 | Prohibitions (unacceptable risk) + AI literacy obligation for staff |
| 2 August 2025 | Obligations for GPAI providers (Claude, GPT, Gemini). Models already on market have until 2 Aug 2027 to fully comply |
| 2 August 2026 | GENERAL APPLICATION ENTRY · rest of obligations for limited and high risk AI systems (with exceptions) |
| 2 August 2027 | Full application to high risk AI systems that are part of regulated products (annex I) — medical devices, toys, lifts, etc. |
Critical date for most Spanish companies is 2 August 2026. From that date, if you deploy AI in high-risk processes without obligations met, you're exposed to sanction. Minimum preparation: 6 months. If you haven't started, start now.
Real sanctions and Spanish authority regime (AESIA)
The competent authority in Spain is AESIA (Spanish Agency for AI Supervision), headquartered in A Coruña. It's the first national agency in the EU dedicated specifically to AI supervision — created in August 2023 in anticipation of AI Act.
AESIA has investigation, information request and sanction proposal powers. In 2025-2026 its main focus is preparation of guides, collaboration with providers and awareness. From August 2026 active sanctioning regime is expected, though probably starting with serious cases and prohibition systems (unacceptable category) before scaling to high risk.
Complementary Spanish sanctioning regime (Digital Services Law + AI Governance Law in progress) may add specific obligations and civil liability regimes for damages caused by AI.
- Up to €35M or 7% global revenue · Prohibitions breach (unacceptable risk)
- Up to €15M or 3% global revenue · Breach of high risk, GPAI or transparency obligations
- Up to €7.5M or 1% global revenue · Providing incorrect information to authorities
Checklist for the DPO / AI responsible
- 1. Create inventory of AI systems used or developed by the company (including API integrations with third-party LLMs).
- 2. Classify each system by role (provider / deployer / importer / distributor) and by risk category.
- 3. Identify high risk systems — maximum priority if you work in HR, credit, insurance, health, biometrics, critical infrastructure.
- 4. Train staff on AI Act — obligation already in force since February 2025 (art. 4 AI literacy).
- 5. For high risk systems where you're provider: start risk management system + technical file + conformity assessment.
- 6. For systems where you're deployer: review contract with provider, verify compliance, document use purpose, activate human oversight.
- 7. For chatbots and generative systems: implement transparency (user notice) before 2 Aug 2026.
- 8. Review contracts with AI providers (Anthropic, OpenAI, Google) — must comply with GPAI obligations. Confirm in writing.
- 9. Integrate AI Act into impact analysis (DPIA) of AI projects with personal data (GDPR art. 35).
- 10. Prepare serious incident management procedure — obligation to notify AESIA within 15 days if system causes material damage or rights violation.
Frequently asked questions
We're an SME using ChatGPT and Claude for internal tasks. Does AI Act apply to us?
Yes, you're deployers of those systems. Obligations depend on use purpose. If you use them for purely low-risk internal tasks (drafting emails, summarising reports, generating marketing copy), obligations are minimal: basically inform staff these systems exist and ensure the provider (Anthropic, OpenAI) complies with GPAI obligations.
If you use them for processes significantly affecting people (personnel selection, employee evaluation, decisions on clients in essential services), they enter high risk and obligations are extensive — risk management system, transparency, human oversight, impact analysis.
Rule of thumb: internal productivity use = minimal obligations. Use impacting decisions on external people = careful evaluation and likely high risk.
If we fine-tune an open-source model (Llama, Mistral), are we providers?
Depends on whether you'll market or put into service the modified model, or if it's purely internal. If internal for own processes, you're advanced deployers with reinforced responsibility for the modification. If you market or distribute the fine-tuned model, you become providers with maximum obligations.
Substantial modification (purpose change, significant behaviour adjustment, expansion to new capabilities) is what triggers reclassification as provider. Light fine-tuning with own data to specialise the model in your domain is usually considered substantial modification.
Recommendation: if fine-tuning is internal, clearly document purpose and limitations. If commercial, prepare for all provider obligations.
What if my AI provider (Anthropic, OpenAI) doesn't comply with AI Act?
As deployer, you have obligation to verify the system you deploy meets applicable requirements. If your provider doesn't comply with GPAI obligations (e.g., doesn't publish model technical sheet or doesn't inform of systemic risks), you're deploying a non-compliant system.
In practice large providers (Anthropic, OpenAI, Google, Meta) are adapting progressively and publish technical documentation in their trust centres. You must review their terms, model cards and confirm in writing they comply with applicable GPAI obligations for models you use.
If a small provider or startup doesn't comply, consider migrating or requiring compliance by contract. Your deployer responsibility doesn't disappear because the provider is small.
When must impact analysis on fundamental rights (FRIA) be done?
FRIA (Fundamental Rights Impact Assessment) is mandatory for high risk AI system deployers in three cases: (1) public authorities and bodies acting on their behalf, (2) providers of essential public services, (3) private companies when the system is used to evaluate creditworthiness (art. 27 AI Act).
The analysis must identify: process where system is used, estimated period and frequency, category of affected persons, specific harm risks, human oversight measures and risk mitigation.
FRIA is different from GDPR DPIA — though can be done jointly. DPIA analyses data protection impact; FRIA analyses impact on the set of fundamental rights (dignity, non-discrimination, freedom of expression, effective judicial protection).
Is AESIA already sanctioning or in support phase?
AESIA is in support and preparation phase for full AI Act application in August 2026. In 2025-2026 its focus is publishing interpretive guides, training the ecosystem, collaborating with providers and awareness on obligations.
From August 2026 active sanctioning regime expected, though foreseeably starting with serious cases (unacceptable risk prohibitions, high risk systems deployed without any documentation) before scaling to systematic inspection.
Recommendation: don't wait for AESIA to investigate. Minimum preparation to comply with high risk obligations is 6-12 months, and serious AI providers know it — they're proactively aligning their contracts and documentation with AI Act.