Skip to content
SimpleAct Logo

Industry · SaaS & software

Status: 6 October 2026

EU AI Act for SaaS: What Software Vendors with AI Features Must Do

A chatbot in the product, a writing assistant, a ranking for job applications: every AI feature in your software has its own classification. This page shows when you are the provider, what integrating a language model means, which duties Art. 50 has brought since August 2026 and when a feature becomes high-risk.

Start the duty checkSee typical systems
  • Provider or deployer – per feature
  • Building on GPAI models via API
  • Chatbots and generated content (Art. 50)
  • When a feature becomes high-risk
app.simpleact.de

AI register

Demo Organisation GmbH · product and internal

A
SystemClassification
  • Support chatbot in the productLanguage model from a GPAI provider via APITransparency
  • Applicant ranking in the HR moduleBuilt in-house, shipped to customersHigh-risk
  • Churn forecast in the admin areaB2B metrics, no decisions about peopleMinimal
  • Coding assistant for the dev teamPurchased, internal useMinimal

Sample data · simplified classification, check the actual use

In short

Under the EU AI Act, SaaS companies are usually providers of their AI features and deployers of tools they buy. Duties depend on purpose: chatbots and generated content fall under Art. 50 (since 2 August 2026), features for Annex III purposes such as candidate selection are high-risk (from 2 December 2027). Integrating a language model makes you a downstream provider.

Context

Why the EU AI Act hits software companies twice

The AI Act (Regulation (EU) 2024/1689) does not attach its obligations to industries but to roles and purposes. For software companies this creates a particular situation: they build AI features into a product that many customers use for very different purposes – and they use AI themselves, from coding assistants to support tools. As a rule, they wear two hats at the same time.

Under Art. 3(3), a provider is anyone who develops an AI system or has it developed and places it on the market or puts it into service under their own name or trademark. For a SaaS solution with an AI feature, that is typically the software vendor, even if the underlying model comes from a third party. Under Art. 3(4), a deployer is anyone using an AI system under their own authority – your customers when they use your feature, and you yourself for every tool you buy.

The territorial scope is wide: the regulation applies to providers placing AI systems on the market or putting them into service in the Union, wherever they are established, and also to providers and deployers in third countries where the output of the system is used in the Union (Art. 2(1)). A US or UK vendor with European customers cannot avoid it.

Which obligations arise depends on the purpose of each feature. Most AI features in business software – search, summaries, recommendations, forecasts on company metrics – are low-risk and trigger no specific requirements beyond the general duty to promote AI literacy (Art. 4). Features that talk to people or generate content are different: they fall under the transparency obligations in Art. 50, which have applied since 2 August 2026.

A feature becomes high-risk when it is intended for one of the purposes listed in Annex III – for example screening and evaluating job applications (point 4(a)), decisions on promotion or evaluating the performance and behaviour of workers (point 4(b)), creditworthiness assessment of natural persons (point 5(b)) or evaluating learning outcomes (point 3(b)). HR, learning and finance software therefore reaches the high-risk zone quickly. After the Digital Omnibus (Regulation (EU) 2026/1744), those obligations apply from 2 December 2027.

Then there is the value chain: most SaaS vendors do not train their own language models but integrate a general-purpose AI model (GPAI) via API. That makes them a downstream provider (Art. 3(68)), relying on information the model provider has to supply under Art. 53(1)(b). Conversely, your customers can become providers themselves if they resell your feature under their own brand or repurpose it for a high-risk use (Art. 25(1)).

This page sorts out the typical situations, shows common AI features with their usual classification and leads, via a short check, to the obligations that are likely relevant for your product. It is a simplified overview and not legal advice.

Art. 50 transparency duties for chatbots and generated content apply
2 Aug 2026
Art. 50 transparency duties for chatbots and generated content apply
Obligations for high-risk AI under Annex III apply (Digital Omnibus)
2 Dec 2027
Obligations for high-risk AI under Annex III apply (Digital Omnibus)
or 3% of turnover: fine ceiling for breaches of Art. 16, 26 and 50, among others (Art. 99(4))
€15m
or 3% of turnover: fine ceiling for breaches of Art. 16, 26 and 50, among others (Art. 99(4))

A feature might be high-risk?

We cover classification and the full list of obligations on dedicated pages.

Typical AI features

Which AI systems are typical in SaaS – and how are they classified?

The table shows common AI features in software products and in your own operations, the role you usually take and the classification that often applies. What counts is always the specific intended purpose – the same technology can be classified very differently depending on its use.

  • Support chatbot or in-app assistant

    Transparency

    Provider · Art. 50(1)

    Users must be told they are interacting with an AI unless that is obvious. The notice belongs in the product, not just the terms of service.

  • Generating text, images, audio or video

    Transparency

    Provider · Art. 50(2)

    Mark outputs as artificially generated in a machine-readable way, as far as technically feasible. Exception for purely assistive standard editing. Systems on the market before 2 August 2026: by 2 December 2026.

  • Applicant tracking with ranking, filtering or matching

    High-risk

    Provider · Annex III 4(a)

    Screening, filtering and evaluating applications is named explicitly. The Art. 6(3) exemption is ruled out as soon as profiling takes place.

  • Performance evaluation, task allocation, shift planning based on behaviour

    Depends on use

    Provider · Annex III 4(b)

    High-risk where the feature influences decisions on promotion, termination or task allocation based on individual behaviour, or evaluates performance and behaviour.

  • Learning platform with automated assessment

    Depends on use

    Provider · Annex III 3

    High-risk, among others, when evaluating learning outcomes or deciding on access to education. Pure learning recommendations without assessment usually not.

  • Credit scoring in embedded finance or buy-now-pay-later

    High-risk

    Provider · Annex III 5(b)

    Creditworthiness assessment of natural persons is high-risk; systems for detecting financial fraud are excluded. More on the fintech page.

  • Sentiment analysis of staff, e.g. in a contact centre

    May be prohibited

    Provider / deployer · Art. 5(1)(f)

    Inferring emotions in the workplace is prohibited, except for medical or safety reasons. Get a legal review before building such a feature.

  • Search, summaries, ticket routing, recommendations

    Minimal

    Provider · Art. 4

    Usually no specific duties. Still check whether outputs go directly to end users (then possibly Art. 50) and what customers use the feature for.

  • Forecasts on company data (churn, revenue, stock)

    Minimal

    Provider · Art. 4

    Without decisions about natural persons in Annex III areas, usually low risk.

  • Integrated GPAI model (LLM via API)

    GPAI chain

    Downstream provider · Art. 3(68), Art. 53

    The model provider carries the duties for the model. You remain the provider of your system and need its documentation to meet your own duties.

  • Third-party AI under your own brand (white label)

    Depends on use

    Provider · Art. 25(1)(a)

    If the system is high-risk, your name or trademark makes you the provider with all provider obligations.

  • Coding assistant, meeting notes, translation in your own team

    Minimal

    Deployer · Art. 4, Art. 26

    In your own operations you are a deployer. AI literacy, usage rules and data protection for entered data matter most.

Simplified, non-exhaustive overview. "Common classification" means: this is often the case, but not always. The intended purpose in the individual case is decisive; document your classification per feature.

Focus areas for SaaS

Four questions every software company has to settle

Role, value chain, integrated models and transparency – these four points decide which obligations sit on your product.

01Art. 3(3) and (4)

Provider or deployer – per feature, not per company

The role is not fixed once for the whole company but for each AI system. For the AI features in your product you are usually the provider: you developed them or had them developed and place them on the market under your brand. That applies even when an external language model does the actual work.

Your customers are deployers as soon as they use the feature under their own authority. For high-risk systems they have their own obligations under Art. 26 – such as human oversight, keeping logs and informing workers. They can only meet them if you, as the provider, deliver usable instructions for use (Art. 13) and make logging technically possible (Art. 12).

For tools you buy yourself, you are a deployer. Obligations there are usually manageable as long as no Annex III purpose is involved. An exception is HR software you use for your own hiring: here the deployer obligations for high-risk AI apply to you.

02Art. 25

The value chain: when others become the provider

Art. 25(1) names three cases in which a deployer, distributor, importer or other third party is considered the provider of a high-risk system: when they put their name or trademark on a high-risk system already on the market (point (a)), when they make a substantial modification and it remains high-risk (point (b)) or when they change the intended purpose so that a system that was not high-risk becomes high-risk (point (c)).

For SaaS vendors this works in two directions. If you sell a third-party high-risk solution as white label, you become the provider. And a customer who simply uses your general text analysis to pre-select job applicants may become a provider under point (c). The original provider must then cooperate closely and provide information – unless it has clearly specified that its system is not to be changed into a high-risk system (Art. 25(2)).

In practice: define in product descriptions, terms of use and instructions what your feature is intended for and what it is not. Anyone supplying tools, services or components for a high-risk system must also agree in writing with the provider which information, capabilities and technical access are needed (Art. 25(4)); this does not apply to components under a free and open-source licence.

03Art. 3(68), Art. 53(1)(b)

Integrating GPAI models: you become a downstream provider

Most AI features in SaaS products are built on a general-purpose AI model integrated via API. The obligations for the model itself – technical documentation, copyright policy, a summary of training content – lie with the model provider under Chapter V; they have applied since 2 August 2025, and from 2 August 2027 for models already on the market before then.

As the integrator, you are a downstream provider (Art. 3(68)). The model provider must give you information and documentation that lets you understand the model’s capabilities and limitations and meet your own obligations (Art. 53(1)(b), minimum content in Annex XII). Request these documents actively and file them with the relevant feature.

Your own obligations still follow the purpose of your system: a GPAI-based chatbot falls under Art. 50, a GPAI-based applicant ranking under the high-risk obligations. Switching models – new provider, new version – is therefore not just a technical decision. Recommendation: treat it as a change that can affect classification, testing and documentation, and recheck data protection and processor agreements.

04Art. 50(1), (2) and (4)

Chatbots and generated content: Art. 50 has applied since August 2026

Since 2 August 2026, providers must design AI systems that interact directly with people so that those people are informed they are interacting with an AI – unless this is obvious to a reasonably well-informed person from the context (para. 1). For a support chat this means a clear notice in the chat window, at the latest at the first interaction.

Providers of systems generating audio, image, video or text must mark the outputs in a machine-readable format so that they are detectable as artificially generated or manipulated (para. 2). For systems placed on the market before 2 August 2026, the deadline for this marking runs until 2 December 2026. A voluntary Commission code of practice on marking has been available in its final version since 10 June 2026.

Disclosing deepfakes and certain published texts, by contrast, is a duty of deployers (para. 4) – that is, your customers. Recommendation: support them with settings and text snippets, such as an option to label generated images visibly. This is not a provider obligation of your own, but it makes it easier for your customers to meet theirs.

Interactive check

Duty check for your SaaS product

Answer five questions about your product. The list then shows the obligations and recommendations that are likely to apply – with the legal reference. Tick off what is done and copy the open points as a task list. Your answers stay in your browser.

Your product
  • Do users talk directly to an AI feature?Chatbot, voice assistant, AI agent in the product
  • Does your product generate text, images, audio or video?e.g. email drafts, product images, speech output
  • Do you integrate a third-party GPAI model?e.g. a large language model via API
  • Does a feature serve an Annex III purpose?e.g. candidate selection, performance evaluation, credit checks, assessing learning
  • Do you sell third-party AI under your brand or supply components for others’ high-risk systems?White label, OEM, model or data supply
For every product with AI
app.simpleact.de

Your status

0 of 5 done

A
0 of 5 done0%

Nothing ticked yet. Answer the questions and start with the first item.

Simplified overview, not legal advice. Items marked "Recommendation" are not legal obligations. The high-risk list is shortened – see the full high-risk checklist.

Deadlines

The dates that matter for SaaS vendors

The AI Act applies in stages. For software companies the transparency duties, the GPAI rules and the high-risk dates after the Digital Omnibus matter most.

Scroll the table sideways →

The dates that matter for SaaS vendors
TopicApplies fromReference
AI Act enters into force1 August 2024Reg. (EU) 2024/1689
Prohibited practices and AI literacy2 February 2025Art. 4, 5
Obligations for GPAI model providers2 August 2025 (existing models by 2 August 2027)Art. 53, 111(3)
Transparency duties for chatbots and generated content; general application2 August 2026Art. 50, 113
Art. 50(2) marking for systems on the market before 2 August 2026by 2 December 2026Reg. (EU) 2026/1744
New prohibitions: non-consensual intimate deepfakes, child sexual abuse material2 December 2026Art. 5 as amended
High-risk AI under Annex III (e.g. HR, learning, scoring features)2 December 2027 (previously 2 August 2026)Reg. (EU) 2026/1744
High-risk AI in products under Annex I2 August 2028 (previously 2 August 2027)Reg. (EU) 2026/1744
All AI Act deadlines with calendar export

Interfaces

Think EU AI Act, GDPR and customer contracts together

The AI Act does not replace other law. For SaaS vendors, data protection, processing agreements and contracts with customers and model providers overlap most.

Processing on behalf (Art. 28 GDPR)
If your AI feature processes your customers’ personal data, you are often a processor. An integrated model provider is then often a sub-processor – with consequences for your DPA, your list of sub-processors and how you inform customers.
Third-country transfers
If the model provider is outside the EEA or accesses data from there, you need a basis under Art. 44 ff. GDPR. Also check regions, retention and whether inputs are used for training.
Automated decisions (Art. 22 GDPR)
If a feature makes decisions with legal or similarly significant effects for people, additional GDPR requirements apply – regardless of the AI Act classification.
Data protection impact assessment
Your customers as controllers need a DPIA for high-risk processing (Art. 35 GDPR). For high-risk AI they are to use the information from your instructions for use (Art. 26(9) AI Act) – one more reason to write them carefully.
Customer contracts and terms of use
Intended purpose, excluded uses, customers’ duties as deployers and access to logs belong in contracts and docs. This protects both sides from an unplanned role change under Art. 25.

Not legal advice: have contracts with customers and model providers reviewed by a lawyer.

Approach

Six steps to an EU AI Act roadmap for your product

A sequence that works well for software teams. It is a recommendation; scope and pace depend on whether high-risk features are involved.

  1. 1

    Inventory features

    Record all AI features in the product and all AI tools in your own operations – with model, data flows and owning team.

  2. 2

    Define purpose and role

    Describe the intended purpose per feature and document the role. This decides whether you are provider, deployer or downstream provider.

  3. 3

    Classify

    Rule out prohibitions, check Annex III, flag transparency cases. File the result with reasons in the AI register.

  4. 4

    Quick wins first

    AI notices in chat, marking generated content and training already apply. These come before the high-risk work with its end-2027 deadline.

  5. 5

    Plan high-risk features

    For every high-risk feature, set up a plan for risk management, documentation, QMS and conformity assessment – with owners and dates.

  6. 6

    Build it into releases

    Briefly check new features, model switches and new target groups against the classification before release. That keeps the register current.

Common mistakes

Where SaaS teams get stuck with the AI Act

"We only use an API"

Anyone integrating a model and offering the feature under their own brand is the provider of the AI system. The model provider’s duties do not replace your own.

Classifying only the whole product

A product can contain a minimal search feature and a high-risk ranking at the same time. Classification happens per feature and purpose.

Ignoring customer use

What customers do with a general feature can make it high-risk. Clear intended purpose and exclusions in contracts and docs help.

AI notice only in the terms

Art. 50 requires people to be informed. A sentence in the terms of use is not enough; the notice belongs in the interface.

Switching models without review

A new model can change behaviour, data flows and risks. Without a review, classification, DPA and documentation quietly go out of date.

Postponing high-risk to 2027

Technical documentation and quality management are not built in a few weeks. Vendors of HR, learning or scoring features should plan now.

With SimpleAct

One AI register for your product and your own operations

In SimpleAct you record AI features and purchased tools in the AI inventory, set role and purpose, classify each system by risk class and work through a matching compliance checklist per system. A library of 19 controls along the EU AI Act holds status and evidence links per system. The Professional plan includes unlimited AI systems and users.

In a pilot project, six AI systems – one of them high-risk – were recorded and assessed in around four hours.

  • AI inventory with role, purpose and vendor
  • Risk classification per feature
  • Compliance checklist per risk class
  • 19 controls with status and evidence links
  • AI Discovery and GDPR module from Professional
View the AI inventory software

PDF: EU AI Act for SaaS & software

Our guide for software vendors with AI features, to share with your team.

Open-Source Framework

simpleact-ai-act-for-saas

Open guidance for SaaS providers: when a deployer becomes a provider, and what follows from it.

View on GitHub

FAQ

Frequently asked questions about the EU AI Act for SaaS

Yes, as soon as the product contains AI systems and is offered in the Union. The regulation applies to providers placing AI systems on the market or putting them into service in the Union, wherever they are established, and also where the output of a system from a third country is used in the Union (Art. 2(1)). Which duties apply depends on the purpose of each individual feature.
Usually yes – for the AI system you build from it and offer under your brand. The model provider is the provider of the GPAI model; you are a downstream provider (Art. 3(68)). Your duties follow the purpose of your feature, such as Art. 50 for a chatbot or the high-risk obligations for an applicant ranking.
Both, in different roles. As provider you carry the duties on how the system is designed, such as transparency, documentation and, for high-risk AI, the conformity assessment. Your customers are deployers with their own duties – for high-risk AI under Art. 26, for example human oversight and keeping logs. They depend on your instructions for use to do so.
Yes. Since 2 August 2026, providers must design AI systems that interact directly with people so that those people are informed they are interacting with an AI – unless it is obvious from the context (Art. 50(1)). A clearly visible notice in the chat window is the usual way.
When it is intended for a purpose listed in Annex III, such as screening and evaluating applications, decisions on promotion or termination, evaluating learning outcomes or assessing the creditworthiness of natural persons. An exemption is possible where there is no significant risk (Art. 6(3)) – but not for profiling. The obligations apply from 2 December 2027.
Yes. Under Art. 25(1), anyone who puts their name or trademark on a high-risk system, substantially modifies it or uses a system that was not high-risk in a way that makes it high-risk is considered the provider. A customer using a general text analysis to pre-select applicants could become a provider that way. So define the intended purpose of your features clearly.
GPAI model providers must give downstream providers information and documentation that lets them understand the model’s capabilities and limitations and meet their own obligations (Art. 53(1)(b), minimum content in Annex XII). This duty has applied since 2 August 2025; for models already on the market before then, from 2 August 2027.
In most cases, no. For high-risk systems under Annex III points 2 to 8 – which include HR, education and scoring features – Art. 43 provides for conformity assessment by internal control under Annex VI. Only biometric systems under point 1 may need a notified body.
Yes. After the Digital Omnibus, SMEs and small mid-caps can provide technical documentation in simplified form and implement proportionate quality management. For fines, SMEs, including start-ups, face the lower of the two amounts (Art. 99(6)). Since the Digital Omnibus, this also applies to small mid-caps (Art. 3(14b)), but only for fines under paragraphs 4 and 5 (Art. 99(6a)). The obligations themselves remain.
For prohibited practices up to €35m or 7% of worldwide annual turnover, for breaches of provider obligations under Art. 16 and transparency duties under Art. 50, among others, up to €15m or 3%, and for supplying incorrect information to authorities up to €7.5m or 1% (Art. 99). For SMEs, including start-ups, the lower amount applies (Art. 99(6)). Since the Digital Omnibus, this also applies to small mid-caps (Art. 3(14b)), but only for fines under paragraphs 4 and 5 (Art. 99(6a)).

More questions? We're happy to help. Send email · Get started

Sources and status

Last reviewed on · SimpleAct editorial team

This page and the duty check are a simplified overview and not legal advice. The wording of Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744 is authoritative. Examples, classifications in the table and items marked as recommendations are not a binding assessment.

Changes to this page

  • 6 October 2026 – Rebuilt: table of typical AI features with classification, roles and Art. 25, GPAI integration, Art. 50, interactive duty check, deadlines after the Digital Omnibus, sources.
  • 8 July 2026 – Short version with typical SaaS situations and FAQ.

Related topics

Every AI feature in your product in view

AI inventory, role, classification and evidence in one place – for the product and your own operations.

Book a demoTry 7 days free