The EU AI Act is the EU’s risk-based regulation for AI systems and general-purpose AI models. For product, security, and GRC teams, the practical question is not only “does this law apply?” but “which AI systems do we actually have, what role do we play, what risk category might apply, and what evidence would show we are managing the system properly?”
Regulation (EU) 2024/1689 lays down harmonised rules for AI systems and general-purpose AI models, with the stated aim of supporting trustworthy, human-centric AI while protecting health, safety, and fundamental rights (Regulation (EU) 2024/1689). It can affect organisations that build, provide, import, distribute, or deploy AI systems connected to the EU market, including certain non-EU actors where AI system outputs are used in the Union. Exact scope and role classification need legal review.
What is the EU AI Act?
The EU AI Act regulates AI through a risk-based model. Some AI practices are prohibited, some AI systems are subject to detailed high-risk requirements, some systems trigger transparency duties, and general-purpose AI model providers have separate obligations.
That structure matters operationally because an AI feature is not assessed only by the technology it uses. Not just the model itself. Classification depends on intended purpose, deployment context, affected users, organisational role, and whether the system falls into a defined category under the Regulation.
For product and security teams, this turns the Act into a governance problem:
- inventory AI systems and AI-enabled features
- identify EU exposure
- document whether the organisation is a provider, deployer, importer, distributor, or GPAI model provider
- classify likely risk
- assign control and evidence owners
- retain documentation, logs, oversight records, vendor evidence, and review history where relevant
This article is a practical starting point, not legal advice or a substitute for formal classification.
How the EU AI Act risk tiers work
The Act is often described using “unacceptable,” “high,” “limited,” and “minimal” risk, product and security teams should know that “limited risk” and “minimal risk” are explanatory shorthand. The Regulation formally addresses prohibited AI practices, high-risk AI systems, transparency obligations for certain systems, and general-purpose AI models (Articles 5–6 and Annex III).
| Category | What it means | Practical examples to review | Operational consequence |
|---|---|---|---|
| Prohibited AI practices | The Act bans specified AI practices. | Systems resembling Article 5 practices, such as certain manipulative, exploitative, social-scoring, or biometric-identification use cases, need immediate legal review. | Treat as a stop-or-redesign category until legal and compliance teams confirm the position. |
| High-risk AI systems | Systems that fall within statutory high-risk categories or specified regulated-product contexts. Classification depends on intended use, not a general “AI” label. | Certain employment, worker management, education, credit, law-enforcement, migration, critical-infrastructure, or regulated-product safety use cases may require high-risk analysis. | Expect the most demanding operational requirements: risk management, documentation, data governance where applicable, logging, oversight, robustness, and cybersecurity. |
| Transparency cases, often called “limited risk” | Certain AI systems trigger transparency duties because of how users interact with them or the type of output produced. | Chatbots, AI-generated content, deepfake-style outputs, or systems where users should know they are interacting with AI may fall into this area depending on context. | Product teams may need disclosures, user information, labelling, or interface changes. |
| Other systems, often called “minimal risk” | Systems that do not fall into prohibited, high-risk, transparency, or GPAI-specific categories may have fewer AI Act-specific duties. | Internal productivity assistants, search helpers, or low-impact recommendation tools may be lower risk, subject to use-case review. | Still inventory and monitor them, because purpose, users, data, or vendor dependencies can change. |
| General-purpose AI models | GPAI rules apply to providers placing general-purpose AI models on the EU market, with additional duties for systemic-risk models. | Foundation models or broadly reusable models made available downstream may be relevant. A product using a GPAI model is not automatically the GPAI model provider. | Model-provider obligations differ from downstream AI-system obligations, so document the dependency and role clearly. |
For GPAI, providers placing general-purpose AI models on the EU market must maintain technical documentation, provide specified information to downstream providers, implement a copyright-compliance policy, and publish a training-content summary. Models trained above 10^25 FLOP are presumed to present systemic risk, subject to designation and rebuttal mechanisms; systemic-risk model providers have additional evaluation, incident-reporting, and cybersecurity duties (European Commission GPAI Q&A).
Who has obligations under the EU AI Act?
Obligations depend on the organisation’s role as well as the system’s risk category. The Act defines providers, deployers, importers, and distributors separately, and in specified circumstances an importer, distributor, deployer, or other third party can assume provider obligations for a high-risk system (Articles 2, 3 and 25).
| Role | Plain-language meaning | Why product and security teams should document it |
|---|---|---|
| Provider | An organisation that develops, or has developed, an AI system or GPAI model and places it on the market or puts it into service under its name or trademark. | Provider duties can include lifecycle controls, documentation, conformity-related steps, logging, corrective action, and information duties, depending on the system. |
| Deployer | An organisation using an AI system under its authority, except for purely personal non-professional activity. | Deployers may have use, monitoring, human oversight, and context-specific duties. Security and GRC teams need to know where AI is actually used. |
| Importer | An organisation established in the EU that places on the market an AI system bearing the name or trademark of a third-country provider. | Importer status can create value-chain obligations and evidence needs around supplier documentation and product information. |
| Distributor | An organisation in the supply chain, other than the provider or importer, that makes an AI system available on the EU market. | Distribution activity may create verification, information, and escalation obligations. |
| GPAI model provider | An organisation that places a general-purpose AI model on the EU market. | GPAI model duties are different from ordinary downstream deployment duties and should be tracked separately. |
A company can have different roles for different systems or activities. That sounds simpler than it usually is. For example, it might deploy a third-party AI support tool, provide its own AI-enabled product feature, and distribute another vendor’s AI-enabled product. Branding changes, intended-purpose changes, substantial modifications, and contractual arrangements can affect role analysis, so teams should record assumptions and route them for legal review.
What obligations matter most for product and security teams?
For high-risk systems, the Act’s requirements include risk management, data quality and governance where applicable, documentation and traceability, transparency, human oversight, accuracy, robustness, and cybersecurity. Providers have lifecycle, conformity-assessment, quality-management, documentation, logging, registration, and corrective-action duties; deployers have use, monitoring, and oversight duties that depend on the system and context (European Commission, “Navigating the AI Act”).
Product and security teams should translate those themes into implementation questions:
- Risk management: What harms could result from the system’s intended use or foreseeable misuse? Who reviews changes before release?
- Technical documentation: Can the team explain the system’s intended purpose, design, model dependency, data inputs, limitations, and operating conditions?
- Data governance and data quality: Where applicable, what data is used, how is it sourced, and what quality or suitability checks exist?
- Logging and traceability: What events, decisions, model outputs, user actions, or system changes are logged? Who can access logs during investigation?
- Transparency and user information: Do users need to know they are interacting with AI or receiving AI-generated content?
- Human oversight: Where oversight is required or chosen as a control, who can intervene, override, escalate, or stop use?
- Accuracy, robustness, and cybersecurity: How is the system tested, monitored, protected from misuse, and reviewed after incidents or material changes?
- Post-market monitoring and corrective action: How are issues, complaints, incidents, degradation, and vendor changes captured and acted on?
- Vendor and model dependency review: What documentation, contractual terms, model information, security assurances, and change notifications are available from suppliers?
Existing governance, privacy, security, or audit evidence may be reusable, but teams should map it to the applicable AI Act requirement rather than assume equivalence and leave it there.
Key EU AI Act dates, penalties, and legal-status caveats
The Act entered into force on 1 August 2024. The European Commission states that prohibited-practice and AI-literacy provisions began applying on 2 February 2025, and GPAI obligations on 2 August 2025 (European Commission AI Act page).
The original Regulation text states general application from 2 August 2026 and Article 6(1) high-risk rules from 2 August 2027. The Commission’s current page also reports a May 2026 political agreement on a proposed AI omnibus and states that certain Annex III high-risk rules will apply from 2 December 2027, while high-risk systems embedded in regulated products are scheduled for 2 August 2028. Treat those later dates as current Commission-reported implementation status and verify the finally adopted legal text before relying on them.
Penalty ceilings vary by infringement. The Act sets maximum administrative fines of up to €35 million or 7% of worldwide annual turnover, whichever is higher, for prohibited practices; up to €15 million or 3% for many other operator obligations; and up to €7.5 million or 1% for supplying incorrect, incomplete, or misleading information. Separate provisions address GPAI model provider fines (Articles 99 and 101). These are basically statutory maximums, not expected penalties.
First readiness steps: inventory, classify, assign owners, collect evidence
The following workflow is editorial readiness guidance. It is a triage method for product, security, legal, and GRC teams, not a complete legal compliance programme.
- Build an AI system inventory. Include AI-enabled product features, internal tools, vendor systems, pilots, and model dependencies.
- Identify EU exposure and business context. Record whether the system is placed on the EU market, used in the EU, or produces outputs used in the Union.
- Determine organisational role. Document whether the organisation may be acting as provider, deployer, importer, distributor, GPAI model provider, or more than one role.
- Classify likely risk. Flag prohibited-practice concerns, high-risk indicators, transparency duties, GPAI relevance, or lower-risk assumptions.
- Assign owners. Name product, engineering, security, legal, compliance, vendor-management, and business owners where relevant.
- Map controls. Link risk management, documentation, logging, oversight, testing, cybersecurity, monitoring, and vendor controls to the system.
- Identify evidence to retain. Decide what records will prove the control exists and is operating.
- Review vendors and model dependencies. Capture supplier documentation, contractual terms, model information, security review status, and change-notification paths.
- Schedule periodic review. Revisit classification when the system’s purpose, users, data, model, vendor, geography, or risk profile changes.
AI Act readiness matrix
This matrix is a starting point for internal triage. It is not an exhaustive statutory checklist.
| Risk area | What it means | Likely obligations or review focus | Product/security controls to consider | Evidence to retain |
|---|---|---|---|---|
| Prohibited-practice concern | The system may resemble a banned AI practice. | Stop, redesign, or obtain legal clearance before launch or continued use. | Release gate, legal escalation, use-case restriction, procurement block. | Classification memo, legal decision record, product change record, approval or rejection history. |
| High-risk indicator | The system may fall within a defined high-risk category or regulated-product context. | Risk management, documentation, traceability, transparency, human oversight, accuracy, robustness, cybersecurity, and role-specific duties. | Risk assessment, model and data review, logging, validation testing, oversight workflow, incident process, change control, access control. | Technical documentation, test results, logs, oversight design, monitoring records, corrective-action records, vendor documentation. |
| Transparency case | Users may need to know they are interacting with AI or receiving AI-generated content. | Disclosure, labelling, user information, or interface controls depending on system type and context. | UI notices, content labels, user guidance, disclosure review, release checklist. | Screenshots, copy approvals, design records, user notice versions, review sign-off. |
| GPAI dependency | The product depends on a third-party general-purpose AI model. | Clarify whether the organisation is a downstream provider/deployer or a GPAI model provider; collect downstream information where relevant. | Model dependency register, vendor review, acceptable-use constraints, change monitoring, security review. | Supplier documentation, model cards or technical information where available, contract terms, security review, change notices. |
| GPAI model provider | The organisation places a GPAI model on the EU market. | Technical documentation, downstream information, copyright policy, training-content summary; additional duties if systemic risk applies. | Documentation process, release governance, evaluation, incident reporting, cybersecurity controls. | Model documentation, downstream information package, policy records, training-content summary, evaluation and incident records. |
| Other lower-risk system | The system does not currently appear prohibited, high-risk, transparency-triggering, or GPAI-specific. | Maintain classification rationale and monitor changes. Other laws or internal controls may still apply. | Inventory review, change management, access control, acceptable-use policy, vendor review if third-party. | Inventory record, classification rationale, owner approval, vendor record, periodic review history. |
AI system inventory starter table
Use this as a first-pass inventory schema. Add fields for your sector, product lifecycle, and legal review process.
| Field | What to record |
|---|---|
| System name | Product feature, internal tool, vendor system, model, or pilot name. |
| Owner | Business, product, engineering, or operational owner accountable for the system. |
| Business purpose | What the system is intended to do and which decision or workflow it supports. |
| Internal/external users | Employees, customers, consumers, partners, public users, or affected individuals. |
| EU exposure | Whether the system is marketed, deployed, used, or produces outputs used in the EU. |
| Organisation role | Provider, deployer, importer, distributor, GPAI model provider, or role uncertain. |
| Data inputs | Main data categories, sources, sensitive data indicators, and update frequency. |
| Model or vendor dependency | Internal model, third-party model, GPAI dependency, SaaS vendor, or embedded product. |
| Likely risk tier | Prohibited concern, high-risk indicator, transparency case, GPAI relevance, other, or unknown. |
| Human oversight | Who reviews outputs, approves use, intervenes, overrides, or escalates issues. |
| Logging/monitoring | Logs captured, monitoring owner, alerting, retention, and investigation process. |
| Vendor review status | Security, legal, procurement, contractual, and documentation review status. |
| Review date | Next classification, control, or vendor review date. |
What evidence should teams retain?
Readiness depends on being able to explain decisions later. The exact evidence needed depends on the system, role, and risk category, but teams may need to retain:
- AI system inventory records
- risk classification rationale
- role classification rationale
- intended-purpose descriptions
- technical documentation
- data source and data governance records where applicable
- control ownership records
- human oversight design and review notes
- logging and monitoring evidence
- testing, validation, accuracy, robustness, and cybersecurity records
- transparency notices, user information, or labelling approvals
- vendor documentation, contracts, security reviews, and model information
- issue, incident, complaint, or corrective-action records
- change-management and release-approval history
- periodic review records
The important discipline is continuity. Evidence should be collected as systems are designed, changed, procured, and monitored, not reconstructed only when a regulator, auditor, customer, or internal risk committee asks for it.
How to use this guide internally
Start with the inventory. For each AI system or AI-enabled feature, record the business purpose, EU exposure, organisational role, likely risk category, owner, controls, vendors, and evidence location. Then route uncertain role and classification questions to legal or compliance for review.
Product and security teams do not need to resolve every legal question on day one. They do need a repeatable operating model: know where AI is used, understand why the use case matters, assign accountable owners, map controls to obligations, retain evidence, and revisit the analysis when systems, vendors, models, users, or EU exposure change.