AI & ML Advanced By Samson Tanimawo, PhD Published Dec 22, 2026 5 min read

Regulatory Landscape: EU AI Act Post-2026

The EU AI Act took full effect through 2025-2026. Here is what it actually requires for general-purpose AI providers and the companies building on them.

What it covers

The EU AI Act applies to any AI system used in the EU, regardless of where the developer is located. The "Brussels effect" is in full play: if your product reaches EU users, you're in scope. The Act creates a tiered risk framework with different obligations per tier; the highest-risk uses are restricted or banned outright.

The territorial reach. Developers based in the US, UK, or anywhere else fall under the Act if they place AI systems on the EU market or if their outputs are used in the EU. The compliance perimeter is global for any company with EU customers; ignoring the Act means abandoning EU market access.

The covered systems. "AI systems" defined broadly: ML, rule-based systems with optimisation, statistical approaches with adaptive components. Most modern software with intelligent behaviour is in scope. Narrow exemptions exist for purely scientific research and personal-use systems; commercial deployment usually isn't exempt.

The implementation timeline. The Act passed in 2024. Most provisions apply through 2025-2027 in phased rollouts. By 2026, the foundation-model and high-risk provisions are largely in effect; full enforcement matures through 2027. Compliance work that started in 2024 is now table stakes.

The penalty structure. Up to 7% of global annual revenue or €35M (whichever is higher) for the most serious violations. Lower tiers for less serious. The penalties are real; companies that ignored GDPR's similar penalty structure paid eight-figure fines. The AI Act's penalties are larger.

The risk tiers

The Act categorises AI uses into four risk tiers, each with different obligations:

The unacceptable-risk reality. Outright bans on specific use cases. Social scoring (government use), exploitation of children/disabled, real-time biometric identification in public (with narrow law-enforcement exceptions), manipulative behaviour-influencing systems. Companies operating in the EU must verify their products don't fall into these categories.

The high-risk reality. Annex III lists specific high-risk uses. If your system is in any listed category, full compliance applies. The compliance burden is significant, risk management framework, technical documentation, conformity assessment, human oversight design, post-market monitoring. Estimated cost: 6-12 engineer-months per high-risk system, plus ongoing operating cost.

The limited-risk reality. Transparency obligations are practical and cheap. Add "I'm an AI" disclosure; label deepfakes; inform users of emotion-recognition. Most chatbots are in this tier.

The minimal-risk reality. The vast majority of consumer AI products. No specific obligations beyond GDPR-style baseline. The Act's main effect on minimal-risk systems is the indirect influence, the foundation models powering them have their own obligations.

Foundation-model rules

Separate rules for "general-purpose AI models" (foundation models like GPT, Claude, Gemini, Llama). Tighter rules for "GPAI models with systemic risk" (the largest, most capable). Obligations include training data documentation, copyright compliance, evaluation against systemic risks, cybersecurity, and incident reporting.

The GPAI obligations. Document training methodology, training data summaries, energy consumption, evaluation processes. Make documentation available to downstream developers. Comply with EU copyright law, including respecting opt-outs from text-and-data-mining exceptions.

The systemic-risk threshold. GPAI models trained with more than 10^25 floating-point operations are presumed to have systemic risk. The threshold is below current frontier models (GPT-4, Claude 3.5+, Gemini Ultra). The Commission can adjust the threshold over time.

The systemic-risk obligations (additional). Conduct adversarial testing. Track and mitigate systemic risks. Ensure cybersecurity measures. Report serious incidents. Energy efficiency reporting. The compliance is heavier than baseline GPAI obligations; the actual ongoing cost runs into millions of dollars per year.

The downstream-developer flow. Developers building on top of GPAI models inherit some compliance work. They must rely on accurate documentation from the model provider; they must add their own risk management for the deployed system. The supply chain of compliance is real and is being navigated for the first time in 2026.

The open-source carve-out. Certain open-source models have lighter obligations, recognising that the developer doesn't control downstream deployment. The carve-out is narrower than open-source advocates wanted; legitimate open weights still face documentation obligations.

Practical compliance

For a typical SaaS deploying generative AI:

  1. Audit your AI uses, categorise by risk tier. Most are minimal or limited risk; a few hiring/credit/medical features may be high risk.
  2. Add transparency disclosures, chatbot identity, AI-generated content labels. Cheap; required for limited-risk.
  3. Document your foundation-model dependencies, which models, providers, intended uses. Foundation in your risk register.
  4. If high-risk: conformity assessment, human oversight design, post-market monitoring. Significant work; engage specialists.
  5. Incident response plan, for serious incidents, reporting timelines apply. Build the playbook before you need it.

The audit step. Start with a list of every AI feature in your product. For each, ask: is it Annex III high-risk? Is it banned? If neither, is it limited-risk (transparency only)? Most teams find 80%+ of their AI uses are minimal or limited risk; high-risk ones need focused work.

The transparency step. Most disclosures are 1-2 sentence additions to UI. "Hi, I'm Nova AI." "This image was AI-generated." "We use AI to assist with X." Cheap to implement; visible to users; compliant.

The high-risk pathway. For a single high-risk system, plan for 4-8 engineer-months of compliance work plus 2-4 months of conformity assessment. Most companies engage specialised AI compliance consultants; the cost is justified by the penalty avoidance.

The ongoing operations. Compliance isn't a one-time project. Post-market monitoring requires logs, analysis, periodic reviews. Incident reporting requires detection mechanisms. Some teams stand up a dedicated AI compliance role; others fold it into existing legal/risk teams.

The vendor question. Foundation-model providers (OpenAI, Anthropic, Google) provide compliance documentation. Use it; reference it in your own documentation; verify it covers your specific use case. The vendor's compliance is necessary but not sufficient.

Common antipatterns

Assuming the Act doesn't apply because you're not based in the EU. Brussels effect. If you have any EU customers, the Act applies.

Treating compliance as one-time. The Act requires ongoing operations: monitoring, incident response, periodic reviews. Build it as a process.

Ignoring foundation-model documentation. Even if you only use OpenAI's API, you need to document this dependency. The Act creates supply-chain compliance obligations.

Confusing "limited risk" with "no obligations". Transparency disclosures ARE obligations. Don't skip them because they sound informal.

What to do this week

Three moves. (1) List every AI feature in your product; classify by risk tier. The classification surfaces where compliance work is needed. (2) Add chatbot/AI-generated-content disclosures if missing. The compliance-to-cost ratio is excellent; you check off limited-risk obligations cheaply. (3) For any high-risk feature, consult specialised counsel. The compliance cost is significant; doing it right the first time is much cheaper than retrofitting after a regulator inquiry.