The EU AI Act Explained: Risk Tiers, Deadlines and Compliance

Most enterprises already have more artificial intelligence in use than any single team can see from end to end. A customer support workflow may call a third-party model, a fraud system may score transactions, a recruiting tool may rank applicants, and a productivity assistant may summarize documents that contain regulated data. Each system quite possibly has an owner, a vendor record and a security review somewhere, but those records often sit in different places and answer different questions.

The EU AI Act raises a specific question regarding AI systems: Can the organization show what each system does, which role the company plays, what risk tier applies and what controls are required for each?

EU AI Act readiness starts with AI governance and an evidence trail. The Act is legal in form, but operational in practice. It asks enterprises to connect AI systems to the data, models, documentation, logs, human oversight and incident processes that prove they are being used responsibly — especially when those systems affect employment, credit, education, critical infrastructure, law enforcement or other high-impact decisions.

The EU AI Act is the world’s first comprehensive legal AI framework. It entered into force on Aug. 1, 2024, and applies in phases. Prohibited practices, AI literacy, and general-purpose AI obligations are already applicable. Based on current timelines, most high-risk AI obligations are expected to apply starting in 2026, with some extended transition periods into 2027–2028. The policy goal is human-centric AI: systems that can be used productively, but with safeguards around safety, fundamental rights, transparency and accountability. 

The scope is wider than many organizations initially assume. The Act can apply to providers, deployers, importers and distributors outside the EU when an AI system is placed on the EU market or when the output produced by the system is used in the EU. A U.S.-based company that sells an AI-enabled product into Europe, uses an AI system to evaluate EU residents, or depends on a non-EU model whose outputs affect people in the EU may still need to assess its obligations.

The Act uses a risk-based framework. Some AI practices are banned outright, some high-risk AI systems face detailed obligations and many lower-risk uses remain largely available, subject to transparency rules or voluntary codes of conduct. It also distinguishes between providers and deployers. A provider develops an AI system or general-purpose AI model and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its own authority except for personal nonprofessional use.

For most enterprises, a key practical takeaway is to understand what AI systems are in use, classify them by risk, document how they work, preserve the evidence needed for oversight and make sure high-risk systems can pass the required conformity assessment before they are placed on the EU market or put into service.

The EU AI Act organizes AI systems into four main risk categories: unacceptable risk, high risk, limited risk and minimal risk. The category matters because it determines whether the system is prohibited, subject to high-risk obligations, covered by transparency obligations or largely outside mandatory controls.

The EU AI Act adds a separate regime for general-purpose AI (GPAI) models, including foundation models that can perform a wide range of downstream tasks. This regime sits on top of the risk tiers because a general-purpose model can be integrated into many different AI systems, some low-risk and some high-risk.

Baseline GPAI obligations include:

• Maintaining technical documentation

• Providing downstream providers with information needed to integrate the model responsibly

• Implementing a policy to comply with EU copyright law

• Publishing a summary of the content used to train the model

For GPAI models with systemic risk, the obligations go further. The Act uses a compute threshold — currently 10^25 floating-point operations — as one indicator that a model may present systemic risk. Providers of these models are expected to perform model evaluations, conduct and document adversarial testing, assess and mitigate systemic risks, track and report serious incidents, and maintain adequate cybersecurity protections for the model and its physical infrastructure.

Enterprise deployers should treat GPAI documentation as a procurement and governance requirement. A company that licenses or integrates a third-party model may not become the model provider by default, but it still needs enough downstream documentation to understand acceptable use, limitations, integration constraints, risk controls and incident-reporting expectations. For high-risk use cases, that documentation becomes part of the evidence chain for the AI system built around the model.

In practice, this means model evaluation and red teaming are no longer only research or security exercises. They are essential supply chain controls. Procurement, legal, security, data governance and AI platform teams need to know what the model provider will disclose, what the enterprise will test itself and how model-related risks will be tracked after deployment.

The EU AI Act applies in phases. The current statutory timeline is the baseline for enterprise planning, even as policymakers continue to debate possible implementation adjustments.

• Aug. 1, 2024: The EU AI Act entered into force.

• Feb. 2, 2025: Prohibited AI practices and AI literacy obligations began to apply.

• Aug. 2, 2025: Governance rules and GPAI model obligations began to apply.

• Aug. 2, 2026: Most obligations are scheduled to apply, including high-risk AI rules for Annex III systems.

• Aug. 2, 2027: High-risk AI systems embedded in regulated products under Annex I are scheduled to come fully into scope.

The timeline remains politically active. Industry groups have called for a delay, arguing that companies need more guidance and more time to comply. Snowflake Principal Data Strategist Jennifer Belissent notes that “industry calls for a delay in the EU AI Act’s implementation have been strong,” but also argues that enterprises should not wait because “the true driver of AI and data governance is already in place. Customers require it.”

This is a common planning approach for most enterprises. Even if some implementation details shift, customers, regulators, boards and business partners are already asking for AI inventories, risk classifications, model documentation, data lineage, incident processes and evidence that high-impact AI systems are governed.

The EU AI Act uses severity tiers for administrative fines. Member states are responsible for penalty rules and enforcement measures, but the Act sets maximum fine levels tied to the type of infringement.

The Act also instructs member states to consider the interests of small and midsize enterprises (SMEs) and startups, and lower fine ceilings apply to these smaller businesses. Fine severity can depend on factors such as the nature, gravity and duration of the infringement, the size of the organization, prior infringements and the degree of cooperation with authorities.

For enterprise teams, the penalty table is only one part of the risk calculation. Poorly governed AI can also trigger customer trust issues, contract friction, privacy exposure, security concerns and delays in launching AI-enabled products in the EU market.

One effective approach to AI compliance is to convert the Act’s requirements into operational artifacts. A policy that says AI must be governed is not enough — teams need records, controls and review paths that show how each system was classified, tested, approved and monitored.

Start with an AI inventory

Capture every AI system in use or development, including internally built models, third-party AI services, embedded AI features in SaaS applications and general-purpose AI models used through APIs. Each inventory record should identify the system owner, provider, deployer, intended purpose, affected users, data inputs, EU market exposure, model dependencies, integration points and whether the system affects people in the EU.

Classify each system against the risk tiers

An AI chatbot used for internal knowledge retrieval may have transparency and access-control concerns, while an AI system used to rank job candidates may fall into a high-risk Annex III domain. Classification should not be a one-time task, but instead should be reviewed when the system’s purpose, data, user population or deployment context changes.

Start with high risk

For high-risk candidates, build the six core evidence artifacts early:

• Risk-management system: Document known and reasonably foreseeable risks, mitigation measures, residual risk decisions and review cadence.

• Data-governance procedures: Capture data sources, data quality checks, representativeness assessments, bias controls, lineage, retention rules and access policies.

• Technical documentation: Maintain the system description, model logic, intended purpose, performance characteristics, limitations, validation results and deployment architecture.

• Event logs: Preserve logs that can support monitoring, audit, incident investigation and post-market review.

• Human-oversight design: Define where humans review, override, pause or escalate system outputs, and make sure reviewers have the information needed to act.

• Accuracy and cybersecurity measures: Document performance targets, robustness testing, adversarial testing, vulnerability management and security controls.

Require GPAI documentation

For GPAI, require the documentation package from model providers before integration. Procurement teams should ask for technical documentation, downstream integration guidance, acceptable-use policies, copyright-policy information, training-data summaries where required and incident-reporting commitments. Those materials should be attached to the AI system record, not stored separately in a contract folder no one can find during an audit.

Map EU AI Act controls to existing obligations 

Many organizations already have GDPR data protection impact assessments, DORA operational resilience controls, NIS2 cybersecurity controls, sector-specific model risk management procedures or software validation requirements. The goal is not to rebuild those processes under a new AI label, but to map where existing controls already satisfy part of the AI Act evidence need, then fill gaps around risk classification, GPAI documentation, transparency notices, conformity assessment, post-market monitoring and incident reporting.

Establish incident-reporting runbooks before Aug. 2, 2026 

Teams should know what counts as a serious incident, who investigates it, which logs and documentation are needed, how legal and compliance teams are notified, and how corrective actions are recorded. Waiting until a high-risk system fails in production leaves too much of the response dependent on informal coordination.

Hear what two top Snowflake executives, EVP of Product Christian Kleinerman and Principal Data Strategist Jennifer Belissent, have to say about generative AI and ethics. 

EU AI Act readiness depends on knowing what data and AI assets exist, how they are governed, who can access them and what evidence can be produced when a system is reviewed. Snowflake can support that foundation by helping organizations connect AI governance to the same platform where governed data, metadata, policies and logs already live.

Snowflake Horizon Catalog provides discovery and governance context for data and AI assets, including metadata such as lineage, semantic views and related usage context. For AI Act readiness, that matters because an AI inventory is only useful if teams can connect a system to the tables, views, features, models, policies and owners it depends on.

Snowflake’s Compliance Center helps teams evaluate, monitor and reduce security risks in Snowflake accounts through scanner-based findings, proactive notifications and account-level visibility. The Data Security capability in the Compliance Center can automatically classify certain categories of sensitive data across databases, identify regulated and high-risk categories such as PII, PCI data and protected health information, and show whether masking policies already protect it.

Snowflake access controls and policy features can also support AI governance evidence. Role-based access control (RBAC), masking policies, row access policies and access history help teams show who had access to sensitive data, which policies applied and how data was used. These records don’t replace legal analysis or conformity assessment, but they can support the logging, human oversight, data governance and audit-evidence workflows enterprises need around regulated AI systems.

Snowflake’s ISO/IEC 42001 certification adds another trust signal. The certification followed an independent third-party audit of its AI management system and supports transparency, accountability and trust in Snowflake’s AI practices.

The EU AI Act makes AI governance a requirement. An enterprise needs to know which AI systems it uses, which role it plays for each system, what data and models the system depends on, how risk was classified, where humans can intervene and what evidence exists when a regulator, customer or internal reviewer asks for proof.

That work is easier when it builds on governance patterns the organization already uses: inventories, access controls, lineage, documentation, monitoring, incident response and audit evidence. The Act adds AI-specific obligations, especially for high-risk systems and general-purpose AI, but it does not require teams to start from a blank page. The best path is to connect AI readiness to the controls already used to govern data, security, privacy and operational resilience, then close the gaps before enforcement reaches the systems that matter most.