The EU AI Act for SaaS builders: what applies now, and what moved to 2027 and 2028

What changed since this article first ran

When I first wrote this in March 2026, the headline date was 2 August 2026, and the delay everyone was talking about was only a proposal. It is not a proposal any more. The Digital Omnibus on AI, Regulation (EU) 2026/1744, was adopted on 8 July 2026, published in the Official Journal on 24 July 2026 and entered into force three days later, on 27 July 2026.¹

It moved the big one. The rules for high risk AI systems listed in Annex III now apply from 2 December 2027. The rules for AI built into products already covered by EU safety law apply from 2 August 2028.¹ Everything else in this article is written to the law as it stands on 8 November 2026, with every date taken from the text of the regulations in the Official Journal.

So 2 August 2026 did happen. It just turned out to be a smaller day than the old headline promised. The transparency rules arrived, the high risk rules did not.

What the EU AI Act is, and why an Irish business is in scope

The EU AI Act is Regulation (EU) 2024/1689. It entered into force on 1 August 2024 and applies in stages.² Think of it as the GDPR's cousin for AI: it reaches beyond the EU's borders, it sorts things by risk, and the fines are large. But instead of regulating personal data, it regulates AI systems by how much risk they pose to people's health, safety and fundamental rights.

For an Irish SaaS founder the reach question is short. The Act applies to providers who place AI systems on the EU market, wherever those providers are based, and to providers and deployers outside the EU where the output of the system is used in the EU.² A SaaS product built in Galway and sold to a customer in Cork, or in Lyon, is placed on the EU market. You are in scope the day it goes live, and so is every competitor from outside the EU selling into Ireland.

What counts as an AI system is wide. The Act's definition is a machine based system that, for explicit or implicit objectives, infers from the input it receives how to generate outputs such as predictions, content, recommendations or decisions.² A recommendation engine qualifies. So does a chatbot. A fixed rule that says "free delivery over €50" does not, because it infers nothing.

There is no separate Irish AI Act to wait for. The AI Act is an EU regulation with direct legal effect in Ireland, as in every member state. What Irish law still has to settle is who supervises and enforces it. The General Scheme of the Regulation of Artificial Intelligence Bill 2026, published by the Department of Enterprise, Tourism and Employment on 4 February 2026, does that with a distributed model: established sectoral regulators act as the competent authorities, and a new statutory body, Oifig Intleachta Shaorga na hÉireann, the AI Office of Ireland, coordinates them as the single point of contact.³ For personal data, the regulator that matters is the Data Protection Commission (DPC), and its guidance on AI, large language models and data protection is the place to start.⁴ I go through the Irish side in AI in business: the options, the dangers and how to get it right.

The dates, as the law stands on 8 November 2026

Here is the whole timetable, after the Omnibus. The left column is the date, the right what applies from it.

Date	What applies
1 August 2024	The Act enters into force
2 February 2025	The prohibited practices and the AI literacy duty (Chapters I and II)
2 August 2025	Rules for general purpose AI models, governance and penalties, except the fines for model providers
27 July 2026	The Digital Omnibus on AI enters into force
2 August 2026	The general date: transparency duties in Article 50, fines for general purpose AI model providers, and the rest of the Act not dated otherwise
2 December 2026	Two new prohibitions (sexual deepfakes of real people without consent, and child sexual abuse material). Generative systems already on the market before 2 August 2026 must mark their output by now
2 August 2027	General purpose AI models placed on the market before 2 August 2025 must comply. Every Member State must have a working AI regulatory sandbox
2 December 2027	High risk rules for the systems listed in Annex III
2 August 2028	High risk rules for AI that is a safety component of, or is itself, a product under the EU safety laws in Annex I

The original dates are in Article 113 of the Act.² The Omnibus replaced the high risk dates, added the two prohibitions from 2 December 2026, gave older generative systems until 2 December 2026 to mark their output, and moved the sandbox deadline to 2 August 2027.¹

One more change matters to anyone with a product already live. A high risk system placed on the market before the high risk rules apply is caught only if its design changes significantly after that date.¹ That is not a loophole to plan around. It is a reason to know which version of your product was on the market when.

The four levels of risk, and where your product sits

The Act is easiest to read as four levels: practices that are banned, systems that are high risk, systems with transparency duties, and everything else. Each level has its own duties.

Banned: the prohibited practices

These have been prohibited since 2 February 2025.² You cannot place them on the EU market, put them into service or use them. In plain words, Article 5 bans AI systems that:

• use subliminal, manipulative or deceptive techniques that materially distort someone's behaviour and cause, or are reasonably likely to cause, significant harm
• exploit a person's vulnerability due to age, disability or a specific social or economic situation, with the same harmful effect
• score people on their social behaviour or personal characteristics in ways that lead to unjustified or unrelated unfavourable treatment
• predict a person's risk of committing a crime based solely on profiling or personality traits
• build or expand facial recognition databases by untargeted scraping of faces from the internet or CCTV
• infer emotions in the workplace or in education, except for medical or safety reasons
• categorise people by biometric data to infer race, political opinions, trade union membership, religious beliefs, sex life or sexual orientation
• run real time remote biometric identification in public spaces for law enforcement, outside a few narrow exceptions²

From 2 December 2026 the Omnibus adds two more: systems that generate realistic sexual images or video of an identifiable person without that person's explicit consent, and systems that generate child sexual abuse material. A general tool is caught when that output is its purpose, or a foreseeable and reproducible result without adequate safeguards.¹

The fine for breaking a prohibition is up to €35 million or 7% of worldwide annual turnover, whichever is higher.²

What it means for a SaaS builder: most products are nowhere near this list. The edge cases are a marketing tool that relies on manipulative techniques, an HR tool that reads emotions in interviews, and an image generator with no guard against fake intimate images. If any of those describes you, this is not a compliance project. Stop.

High risk: allowed, with heavy duties

High risk systems are allowed, but they carry the bulk of the Act's obligations. There are two routes in.

Route one: products under EU safety law. An AI system is high risk if it is a safety component of a product covered by the EU laws listed in Annex I, or is itself such a product, and that product needs a third party conformity assessment.² Machinery, toys, lifts and medical devices are the familiar examples. These rules now apply from 2 August 2028.¹ The Omnibus also clarified that AI used only for convenience, efficiency or performance optimisation, with no safety function, is not a safety component.¹

Route two: the uses listed in Annex III. This is the route most SaaS builders need to check. It now applies from 2 December 2027.¹ Annex III has eight areas:²

1. Biometrics: remote biometric identification, biometric categorisation by sensitive attributes, and emotion recognition.
2. Critical infrastructure: safety components in the management of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity.
3. Education and vocational training: deciding admission, evaluating learning outcomes, assessing the level of education someone gets, and monitoring students for cheating in tests.
4. Employment: recruitment and selection, including placing targeted job adverts, filtering applications and evaluating candidates, and decisions on promotion, termination, task allocation and monitoring performance.
5. Essential services: public benefits eligibility, creditworthiness and credit scores (fraud detection excepted), risk assessment and pricing for life and health insurance, and the triage of emergency calls.
6. Law enforcement: victim risk, polygraphs, evidence reliability, reoffending risk and profiling in criminal investigations.
7. Migration, asylum and border control: risk assessments, examining applications and identifying people.
8. Justice and democratic processes: helping courts research and apply the law, and systems meant to influence how people vote.

Two rules sit on top of that list, both in Article 6.²

The first is an exit. A system in Annex III is not high risk if it poses no significant risk of harm, including by not materially influencing the outcome of a decision. That applies where the system only performs a narrow procedural task, improves the result of work a person has already finished, detects patterns in past decisions without replacing human review, or does a preparatory task for an assessment. A provider who relies on this exit must document the assessment before the system goes on the market.

The second closes the exit. A system in Annex III that performs profiling of natural persons is always high risk, whatever else is true.

Translated for common products:

• Lending or fintech SaaS scoring creditworthiness: high risk.
• HR or recruitment SaaS screening CVs or ranking candidates: high risk.
• EdTech SaaS grading assessments or deciding admissions: high risk.
• Insurance SaaS pricing life or health cover: high risk.
• Marketing SaaS optimising ad campaigns and audiences: almost certainly not, with one caveat I come to below.
• An eCommerce shop with recommendations, pricing rules and cart recovery: almost certainly not.

Providers of high risk systems must, among other things, run a risk management system, govern their training data, keep technical documentation, build in automatic logging, give deployers clear instructions, design for human oversight, meet standards of accuracy, robustness and cybersecurity, pass a conformity assessment, register the system and monitor it once it is on the market.² The Omnibus lets SMEs and small mid cap companies file the technical documentation on a simplified form the Commission will publish.¹

The fine for breaking these duties is up to €15 million or 3% of worldwide annual turnover.²

Transparency: the duties that apply now

This is where most SaaS products with AI features land, and these duties have applied since 2 August 2026.² Article 50 sets four of them:

• Providers of systems that talk directly to people must design them so people know they are dealing with an AI, unless that is obvious from the context.
• Providers of systems that generate synthetic audio, images, video or text must mark the output in a machine readable format, so it can be detected as artificially generated. Systems on the market before 2 August 2026 have until 2 December 2026.¹
• Deployers of emotion recognition or biometric categorisation must tell the people exposed to it.
• Deployers who publish deepfakes must disclose that the content is artificial. So must deployers who publish AI generated text to inform the public on matters of public interest, unless a person has reviewed it and someone holds editorial responsibility.²

The information has to be given clearly, at the latest at the first interaction, and it has to meet accessibility requirements.² Breaking these duties falls in the same fine band as the high risk duties: up to €15 million or 3%.²

Everything else: minimal risk

Spam filters, stock forecasting, search ranking, most recommendation engines. The Act places no specific duties on them beyond AI literacy, and it encourages voluntary codes of conduct. The rest of the law still applies: the GDPR, the Cyber Resilience Act and, where relevant, the NIS2 Directive.

How to classify a system, one question at a time

The classification is a sequence of questions, and the order matters. A profiling check comes before the exit, a prohibition comes before everything.

Read it from the top. Each diamond is a question about the system's intended purpose, and the boxes after it are the answers. The point to take away is the order. A system that profiles people inside an Annex III area never reaches the exit, and a system that is not in Annex III never needs it.

Worked example: where GrowCentric.ai falls

This is how I classified my own product, because it is the exercise every SaaS builder needs to do.

GrowCentric.ai is a marketing optimisation SaaS. It analyses campaign performance, reallocates budget across channels, segments audiences, detects conflicts between competing clients and adjusts campaign settings. As I described in my AI marketing automation post, it uses specialised agents that coordinate through a shared event bus.

Step 1: is anything prohibited? No. Nothing on the banned list: no subliminal techniques, no social scoring, no biometrics, no emotion recognition. It optimises campaigns. It does not manipulate individuals without their awareness.

Step 2: is it a safety component of a regulated product? No.

Step 3: is its use in Annex III? Area by area: no biometrics, no critical infrastructure, no education. The closest is essential services. GrowCentric segments audiences for advertising. It does not decide whether someone gets a loan, insurance, healthcare or a public benefit. It decides which people see which adverts and how much to bid for their attention. That is marketing, not gatekeeping.

There is one caveat the first version of this article missed. Annex III point 4 covers AI used for recruitment, and it names placing targeted job adverts.² A marketing tool used by an employer to target job adverts is doing exactly that. If a client turned GrowCentric to that purpose, the client would be changing the intended purpose of a system that is not high risk into one that is, and the Act then treats that client as the provider of a high risk system.² Since the Omnibus, an original provider who clearly specifies that its system is not to be changed into a high risk system does not have to hand over documentation and technical access to that new provider.¹ So the intended purpose, and the uses I exclude, go into the terms.

Step 4: transparency. Yes. GrowCentric's agents produce reports for client dashboards and generate synthetic content such as ad copy variations. Those reports should say they are AI generated, and the generated text needs machine readable marking under Article 50.

Step 5: profiling. GrowCentric profiles behaviour for advertising segmentation. Under the GDPR that is profiling and is regulated already. Under the AI Act, profiling only forces the high risk label inside an Annex III area, and advertising is not one.

My classification: GrowCentric.ai is not high risk. It has transparency duties.

The first version of this article said Article 6(4) required me to document that. Strictly, it does not: Article 6(4) applies to a system listed in Annex III whose provider relies on the exit.² GrowCentric is not listed at all. I document the assessment anyway. I'd rather have the documentation and not need it than need it and not have it.

Worked example: a Solidus shop and an HR tool

Two invented businesses, to show the line from both sides.

Gracedieu Cycles is a bike shop in Waterford selling online at gracedieucycles.example, built on Ruby on Rails and Solidus. It uses five AI features. Each one, classified:

1. Product recommendations ("riders who bought this saddle also bought"): not in Annex III. Minimal risk.
2. Pricing rules that move prices with stock and demand: not creditworthiness, not insurance. Minimal risk. If prices were set per person from their behaviour, that would be profiling under the GDPR, which defines profiling as automated processing of personal data to analyse or predict things such as a person's economic situation, preferences or behaviour.⁵ That is a data protection question, not an AI Act one.
3. Churn prediction that flags customers for a win back email: not access to an essential service. Minimal risk.
4. Cart recovery emails timed by a model: marketing automation. Minimal risk.
5. A chat assistant on the product pages: talks directly to people. Transparency duty under Article 50, in force since 2 August 2026. The assistant has to say it is an AI at the first message.

Gracedieu's whole AI Act job is one disclosure line and a short written classification.

Shortlist is an invented HR SaaS in Limerick, at shortlist.example. It ranks CVs against a job description for its customers, recruiters across Ireland and the rest of the EU. Ranking candidates is in Annex III point 4, and ranking people by their characteristics is profiling, so the exit is closed.² Shortlist is a provider of a high risk system from 2 December 2027, with the full set of duties: risk management, data governance, documentation, logging, human oversight, conformity assessment and registration. Its customers, as deployers, must use it as instructed, assign trained people to oversee it, keep its logs for at least six months and tell candidates that a high risk system is being used on them.²

A little over a year sounds like a long time. For a conformity assessment, a quality management system and a data governance review, it is not.

Worked example: what the fine ceiling means for a small company

The fine bands are the same shape everywhere in the Act: a fixed amount or a share of turnover. For most companies the higher of the two applies. For SMEs, and since the Omnibus for small mid cap companies too, the lower of the two applies.²¹

$$\text{cap}_{\text{large}} = \max(F,\; p \times T) \qquad \text{cap}_{\text{SME}} = \min(F,\; p \times T)$$

Here $F$ is the fixed amount in euros for the type of breach, $p$ is the percentage for that band written as a decimal, $T$ is the company's total worldwide annual turnover for the preceding financial year, $\max$ takes the larger of the two and $\min$ the smaller. Percentages written as decimals are explained in Foundations: percentages.

Take Shortlist, with a turnover of €12 million, and assume it qualifies as an SME (both are the example's assumptions). A breach of the transparency duties sits in the €15 million or 3% band.

$$p \times T = 0.03 \times 12{,}000{,}000 = 360{,}000$$

Here $0.03$ is the 3% band and $12{,}000{,}000$ Shortlist's turnover in euros. As an SME, Shortlist's ceiling is the lower figure, €360,000. A larger company with the same turnover would face the higher one, €15 million. These are ceilings, not tariffs: the Act tells authorities to weigh the circumstances of each case and the economic viability of smaller firms.²¹

The duties that apply to everyone

Whatever the level, two things apply to every provider and deployer.

AI literacy. It applied from 2 February 2025, and the Omnibus rewrote it. Providers and deployers must now "take measures to support the development of AI literacy of their staff" and others operating AI on their behalf, taking into account their knowledge and the context of use, and the duty "does not require providers or deployers to guarantee any specific level of AI literacy of any individual".¹ The first version of this article said the Omnibus would shift the duty to Member States. The adopted text keeps it on you, softened. In practice: train your team on what the AI does, where it fails and how to read its outputs, and keep a note that you did.

Transparency where it applies. Chatbots disclose, generated content is marked, deepfakes are labelled. In force now.

Beyond those, I keep records for every AI feature even where the Act does not ask: what it does, what data trained it, what it is for. The classification might be challenged, the GDPR and the Cyber Resilience Act ask for similar records, and it is good engineering anyway.

What this looks like in code, on Rails

Here is what the architecture looks like if you build on Ruby on Rails, as I do. None of this is a legal requirement for a minimal risk system. All of it is what a high risk system needs, and most of it is what any system needs the day a customer asks why the AI did something.

Audit logging for every AI decision

High risk systems must log events automatically (Article 12), and deployers must keep those logs for at least six months (Article 26).² For everyone else it is strongly recommended. This is the pattern I use across all my AI agent implementations:

module AIAuditLoggable
  extend ActiveSupport::Concern

  def record_ai_decision(agent:, input:, output:, confidence:, metadata: {})
    AIAuditLog.create!(
      agent_name: agent,
      input_data: sanitise_pii(input),
      output_data: output,
      confidence_score: confidence,
      model_version: current_model_version(agent),
      decision_timestamp: Time.current,
      human_override: false,
      explainability_trace: generate_explanation(agent, input, output),
      metadata: metadata.merge(
        request_id: Current.request_id,
        user_id: Current.user&.id
      )
    )
  end

  def record_human_override(audit_log_id:, override_by:, reason:, new_output:)
    log = AIAuditLog.find(audit_log_id)
    log.update!(
      human_override: true,
      override_by: override_by,
      override_reason: reason,
      override_output: new_output,
      override_timestamp: Time.current
    )
    publish_override_event(log)
  end

  private

  def sanitise_pii(data)
    # Strip personal data before logging (data minimisation)
    PIISanitiser.sanitise(data)
  end

  def generate_explanation(agent, input, output)
    ExplainabilityService.explain(agent: agent, input_features: input, output: output)
  end
end

Every AI decision is logged with the agent that made it, the input it received, the output, the confidence, the model version and a readable explanation. Every human override is logged too.

That one table serves several laws at once. It is the traceability of Article 12, the material for the instructions of Article 13 and the oversight evidence of Article 14.² And under Article 22 of the GDPR, where a decision based solely on automated processing has legal or similarly significant effects and is allowed because it is necessary for a contract or rests on explicit consent, the controller must give the person at least the right to obtain human intervention, to express their point of view and to contest the decision. Articles 13 to 15 add the right to meaningful information about the logic involved.⁶ You cannot do any of that without a record of what the system decided and why.

Human override, in tiers

Article 14 requires high risk systems to be designed for effective human oversight.² For everything else it is good practice. This is the tiered autonomy pattern:

class TieredAutonomyController
  AUTONOMY_LEVELS = {
    observe_only: { requires_approval: true,  auto_execute: false },
    low_risk:     { requires_approval: false, auto_execute: true,
                    max_impact_euros: 100, max_affected_users: 10 },
    medium_risk:  { requires_approval: true,  auto_execute: false,
                    approval_timeout: 4.hours },
    high_risk:    { requires_approval: true,  auto_execute: false,
                    approval_roles: %w[admin compliance_officer],
                    approval_timeout: 24.hours }
  }.freeze

  def execute_decision(agent:, decision:, autonomy_level:)
    level = AUTONOMY_LEVELS.fetch(autonomy_level)

    if level[:auto_execute] && within_bounds?(decision, level)
      execute_and_log(agent, decision, autonomy_level)
    else
      queue_for_approval(agent, decision, level)
    end
  end

  def emergency_stop(agent:, reason:)
    # Any person can halt any AI agent at any time
    AgentManager.pause(agent)
    AIAuditLog.create!(agent_name: agent, event_type: "emergency_stop",
                       override_by: Current.user.id, override_reason: reason)
    AlertService.notify("AI agent #{agent} halted by #{Current.user.name}: #{reason}")
  end
end

Decisions with more impact need more senior approval, and anyone can press the emergency stop at any time. I use this pattern in GrowCentric.ai's agent architecture and in every agent I build for clients.

Technical documentation, generated from the system

High risk systems need the technical documentation set out in Annex IV, starting with a general description, the intended purpose, the provider and the version.² Even below high risk, having it ready protects you if your classification is ever questioned:

class AISystemDocumentation
  def generate_for(ai_system)
    {
      general_description: {
        intended_purpose: ai_system.intended_purpose,
        excluded_uses: ai_system.excluded_uses,
        provider: ai_system.provider_details,
        version: ai_system.current_version,
        date: Date.current
      },
      risk_classification: {
        level: ai_system.risk_level,
        annex_iii_assessment: ai_system.annex_iii_assessment,
        profiles_individuals: ai_system.profiles_individuals?,
        rationale: ai_system.classification_rationale,
        documented_by: ai_system.classification_documented_by,
        documented_at: ai_system.classification_documented_at
      },
      development: {
        training_methodology: ai_system.training_details,
        validation_methodology: ai_system.validation_details,
        data_governance: ai_system.data_governance_policy
      },
      oversight: {
        human_oversight_measures: ai_system.oversight_measures,
        monitoring_plan: ai_system.monitoring_plan,
        log_retention_policy: ai_system.log_retention_policy
      },
      accuracy_and_robustness: {
        performance_metrics: ai_system.latest_metrics,
        known_limitations: ai_system.known_limitations
      }
    }
  end
end

The excluded_uses field is new since the first version. It is where the "not for recruitment" line from the GrowCentric example lives.

Transparency disclosure

For Article 50, this is how I handle chatbot and generated content disclosure in Rails:

module AITransparency
  # Adds a machine readable marker to responses that carry generated content
  class DisclosureMiddleware
    def initialize(app)
      @app = app
    end

    def call(env)
      status, headers, response = @app.call(env)
      if env["ai.generated_content"]
        headers["X-AI-Generated"] = "true"
        headers["X-AI-Model"] = env["ai.model_identifier"]
      end
      [status, headers, response]
    end
  end

  module ViewHelpers
    def chatbot_disclosure
      tag.p(class: "chatbot-disclosure", role: "status") do
        "You are chatting with an AI assistant. A person is available if you prefer."
      end
    end
  end
end

A response header is a start, not the whole answer. The marking duty is on the output itself, and the Commission is encouraging codes of practice on how to mark and detect generated content, which it can turn into binding common rules if they fall short.¹ Watch for those before you settle on a format.

Provider or deployer, and why SaaS builders need to care

The Act separates the provider, who develops an AI system and places it on the market under its own name, from the deployer, who uses an AI system in the course of its work.² As a SaaS builder you are usually the provider. Your customers are deployers.

As a provider, your duties centre on building the system properly: risk management, data governance, documentation, conformity, transparency, logging and instructions for use. As deployers, your customers' duties centre on using it properly: following your instructions, assigning human oversight, making sure their input data is relevant, monitoring the system and keeping its logs.²

Here is the trap. A customer who puts their own name on a high risk system, makes a substantial change to one, or changes the intended purpose of an ordinary system so that it becomes high risk, is treated as the provider from then on.² The original provider then has to cooperate with them, share documentation and give technical access, unless it clearly specified that its system was not to be turned into a high risk one.¹

What that means in practice:

1. Your terms of service state the intended purpose of each AI feature, and the uses you exclude.
2. Your documentation says clearly what is and is not covered.
3. If you know customers use your product in a high risk way, you are close to being the provider of a high risk system yourself.
4. Your instructions for use let deployers meet their own duties.

How the AI Act sits next to the laws you already know

European regulation does not live in isolation, and the Omnibus did a fair bit of tidying at the joins.

The GDPR. If your AI processes personal data, and most does, the GDPR applies alongside. The Omnibus restated that the AI Act does not affect the GDPR, with two named exceptions.¹ One is new: providers and deployers may exceptionally process special category data, such as ethnicity or health, where strictly necessary to detect and correct bias, under conditions including pseudonymisation, strict access control and deletion once the bias is corrected.¹ The other is a time saver: a deployer doing a fundamental rights impact assessment can cross reference its data protection impact assessment instead of writing everything twice.¹ The GDPR's own rule on solely automated decisions with significant effects, Article 22, applies in its own right.⁶ I go deeper in building GDPR compliant AI features in your SaaS and in GDPR and AI: the right to be forgotten.

The first version of this article said the Digital Omnibus would allow legitimate interest as a legal basis for AI training. That idea belonged to a separate proposal to amend the GDPR, not to the AI Act Omnibus that was adopted, and nothing in Regulation 2026/1744 says it. I have cut it.

The Cyber Resilience Act. A SaaS product with an AI feature can fall under both. The Omnibus added a useful bridge: a high risk AI system that falls under the Cyber Resilience Act and meets its essential requirements is deemed to meet the AI Act's cybersecurity requirement in Article 15.¹ My Cyber Resilience Act post covers the rest.

The NIS2 Directive. If your SaaS serves essential or important entities, their supply chain duties under NIS2 mean their procurement team will ask about your AI governance as part of vendor checks.

The thread through all of them is the same: logging, incident reporting, risk management, documentation and human oversight. Build them once and they serve several laws. The same event bus that powers my agentic AI architecture also feeds the audit log, and the same tiered autonomy controller that gives meaningful human oversight meets the Act's oversight duty.

What to do now, about a year before the high risk date

This is not legal advice. I'm a developer, not a lawyer. It is engineering guidance from someone who builds AI SaaS for the European market.

Step 1: map your AI systems. List every AI feature, not just the obvious models: the recommendations, the scoring, the content generation, the chatbots. If it infers outputs from inputs, it is potentially an AI system under the Act.

Step 2: classify each one. Walk it down the flow above. Prohibited? Annex I? Annex III? Profiling? Transparency? Write the reasoning down, with the date and the version.

Step 3: settle your role. Provider, deployer or both? For each third party model you build on, work out whether you are building your own AI system on top of it, which usually makes you its provider.

Step 4: meet the transparency duties today. They have applied since 2 August 2026. Chatbot disclosure, machine readable marking of generated content, and for older generative systems the 2 December 2026 deadline.

Step 5: build the foundations. Audit logging, human override, disclosures, explanation traces, data governance, documentation templates. They are needed at every level of risk, and they cost far less to build now than to retrofit later.

Step 6: fix your contracts. Intended purpose and excluded uses in the terms. AI processing in the privacy notice. Clear allocation of compliance duties with every AI supplier.

Step 7: if you are high risk, start the clock. 2 December 2027 for Annex III, 2 August 2028 for Annex I. Watch for the Commission's simplified documentation form for SMEs and its guidance on the high risk rules.

The bottom line

The AI Act is not coming eventually. Parts of it have applied since February 2025, the transparency duties since August 2026, and the high risk rules are now dated for December 2027 and August 2028, in a regulation that has been adopted, not a proposal.

Most SaaS products are minimal risk or have transparency duties only. That's the good news. The classification still has to be done and written down, and the uses you exclude have to be in your terms, because a customer can move you up a level without asking.

The better news is that compliance with the AI Act overlaps heavily with good engineering. Audit logging, human oversight, data governance and documentation are what I'd build anyway. Retrofitting them is expensive. Building them in is just good architecture.

Footnotes

1. Regulation (EU) 2026/1744 of the European Parliament and of the Council of 8 July 2026 amending Regulation (EU) 2024/1689 (Digital Omnibus on AI), Article 1, points 2, 5, 6, 7, 8, 10, 12, 13, 18, 20, 22, 38, 39 and 40, and Article 4, Official Journal of the European Union, 24 July 2026, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202601744

2. Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act), Articles 2, 3, 4, 5, 6, 12, 13, 14, 25, 26, 50, 99, 111 and 113 and Annexes I, III and IV, Official Journal of the European Union, 12 July 2024, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401689

3. Department of Enterprise, Tourism and Employment, General Scheme of the Regulation of Artificial Intelligence Bill 2026, 4 February 2026, https://enterprise.gov.ie/en/legislation/general-scheme-of-the-regulation-of-artificial-intelligence-bill-2026.html

4. Data Protection Commission, AI, Large Language Models and Data Protection, 18 July 2024, https://www.dataprotection.ie/en/dpc-guidance/blogs/AI-LLMs-and-Data-Protection

5. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 4, definitions, point 4 (profiling), EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

6. Regulation (EU) 2016/679 (General Data Protection Regulation), Articles 13(2)(f), 14(2)(g), 15(1)(h) and 22, automated individual decision making, including profiling, EUR-Lex, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679