Does adding AI features make a SaaS company a provider under the EU AI Act?
A SaaS company that adds a chatbot, summarization, content generation or scoring feature is usually a provider for that AI system. Article 3(3) treats anyone who develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark as a provider, whether the product is paid or free. Article 50 then decides the transparency duties, and Article 6(3) decides whether a scoring or decision-support feature falls outside high-risk status. Provider status does not depend on whether the model is your own; a company that builds on a third-party model and sells the feature under its brand is still the provider of the system it offers. The answer changes per feature, per customer use and per model supplier, so the classification has to be run feature by feature and documented. A summarizer used only to draft internal notes raises different questions from the same summarizer embedded in a customer's recruiting workflow. Ask your product team to list every AI-enabled function, the intended purpose stated in your documentation, and the model supplier behind each one. The organization owns these classification decisions and the records behind them. An implementation partner can prepare the inventory, technical files and evidence, but only an independent assessor or notified body issues conformity outcomes where one is required.
Two dates set the planning horizon. Article 4 on AI literacy has applied to providers and deployers of all AI systems since 2 February 2025, so training records for staff who build, sell or run these features should already exist. The high-risk rules in Chapter III apply from 2 December 2027 for Annex III systems, as amended in 2026, so a feature that could fall into an Annex III category needs its Article 6(3) assessment documented before it is placed on the market. Confirm your own release calendar against these dates and the official consolidated text at the consolidated Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744 before you commit to a launch sequence.
Which common AI features trigger which AI Act duties
Most SaaS AI features fall into a few recurring patterns, and each pattern carries a different provider or deployer role. The cards below show what each common feature may trigger, and why the intended purpose in your documentation, not the underlying model, usually decides whether high-risk status applies.
Customer-facing chatbot or assistant
A chatbot that talks directly with users is the clearest Article 50 case. If you develop the assistant or have it developed and sell it under your name, you are the provider, and the design must inform people they are talking with an AI system unless that is obvious to a reasonably well-informed, observant and circumspect person in context. Check whether your interface makes the disclosure obvious, and whether the bot is ever used to answer questions about applicants, customers' credit, or other decisions that could move the feature into Annex III. Disclosure is a design duty, so it belongs in the product backlog.
Generated text, images or audio
Features that create synthetic text, images, audio or video trigger the marking duty in Article 50(2), which applies to providers of AI systems and general-purpose AI systems alike. Your product must mark outputs in a machine-readable format so they can be detected as artificially generated or manipulated. If you wrap a third-party model, you still need to confirm that the marking survives your own pipeline, because a generic model vendor's marking does not automatically reach your customers' exported files. Marking is required even when the output is low risk.
AI summaries and drafting inside workflows
Summaries, email drafts and document rewrites inside a workflow are usually provider obligations for you and deployer obligations for the customer, but they are rarely high-risk on their own. The question to answer is what the customer does with the output. A summary of a support ticket is different from a summary of a job application that a recruiter uses to shortlist candidates. Document the intended purpose in terms your customers can read, and state which uses you prohibit. The intended purpose sentence in your documentation is the main control here.
Predictive scoring or ranking
Scores, rankings and risk ratings are where high-risk status most often depends on the customer's use. A ranking of job candidates, a creditworthiness score or a student admission score can fall under Annex III even when the vendor sells a generic scoring engine. Under Article 25(1), if you change the intended purpose of a non-high-risk system so that it becomes high-risk, you become its provider. Check whether your sales material, templates or default configurations describe a high-risk use, because that description can shift your role. A generic scoring tool can become high-risk through its documented purpose.
AI that flags or routes records
Routing tickets, flagging transactions or sorting records into queues can look like low-risk automation. The classification turns on what the flag controls. Article 6(3) can take an Annex III system out of high-risk status where it performs a narrow procedural task, improves a completed human activity, detects decision patterns without replacing human assessment, or performs a preparatory task. Document that assessment before you place the system on the market, and be ready to produce it on request. If the flag decides who gets a loan, a place, or a benefit without meaningful human review, the exemption is unlikely to hold. The exemption must be documented, not assumed.
When a feature becomes high-risk, and when Article 6(3) takes it out
A SaaS feature becomes high-risk by one of two routes. The first is the Annex I route, where the AI is a safety component of a product already covered by EU product safety law. The second is the Annex III route, where the feature falls into a listed use case such as employment, creditworthiness, education or access to essential services. Most SaaS AI features that reach high-risk status do so through Annex III, so the first task is to map each feature to its intended purpose as your documentation states it. Marketing copy and customer use cases do not decide the question on their own, but a provider that promotes a feature for hiring decisions will struggle to argue that the feature serves only a narrow purpose. Start with the intended purpose, then test it against the Annex III categories.
Article 6(3) can take an Annex III system out of high-risk status, but only if the system poses no significant risk of harm to health, safety or fundamental rights and performs one of four narrow roles: a narrow procedural task, improving the result of a completed human activity, detecting decision patterns without replacing or influencing human assessment without proper review, or a preparatory task. A ranking feature that scores applicants for a recruiter to review would not usually fit these roles, while a feature that only formats or files documents might. Profiling of natural persons is never exempt, so any feature that evaluates personal traits, behavior or characteristics stays high-risk regardless of the role it plays. Before relying on the exemption, confirm the current wording and examples against the draft Commission guidelines on classification of 19 May 2026, which are still a draft and may change.
If you rely on the exemption, you must document your assessment before placing the system on the market or putting it into service, provide that documentation to authorities on request, and register the system under Article 49(2). Treat the assessment as a dated record tied to a specific version of the feature, and repeat it when the model, data or purpose changes. Ask your legal and product teams to record the Annex III category considered, the role claimed, the risk reasoning and the decision owner. The exemption is a judgment you must be able to defend to a regulator, not a label you can apply once and forget.
Provider, deployer or both: role by SaaS scenario
This table compares five common SaaS arrangements, showing the likely AI Act role, the main duties and the evidence to keep for each. Use it to find your starting point, then confirm the role against your own product, contracts and intended purpose, since the same feature can change role when customers repurpose it.
| Scenario | Likely role | Main duties and evidence to keep |
|---|---|---|
| Vendor builds its own feature on a third-party model API and sells it under its name | Provider of the AI system (Article 3(3)); the model supplier is a separate provider of the model | Transparency duties if users interact with or receive synthetic content (Article 50). Keep the model supplier contract, feature documentation and intended purpose statement. |
| Vendor embeds a third-party AI tool and white-labels it under its own brand | Provider, because it places the system on the market under its own name or trademark (Article 25(1)) | Carries provider duties for the branded system. Keep the supplier's written terms on information, technical access and assistance (Article 25(4)). |
| Customer configures the vendor's generic AI for its own HR or credit decisions | Deployer for the customer; vendor usually stays a provider of the generic tool | Customer must follow deployer duties for the high-risk use. Vendor should keep configuration guides, instructions for use and written limits on permitted uses. |
| Vendor sells an unmodified general-purpose tool that a customer later points at a high-risk use | Customer becomes provider of the repurposed high-risk system if it changes the intended purpose (Article 25(1)); vendor remains general-purpose provider | Confirm contract terms that bar high-risk use and state the intended purpose. Keep usage policies, onboarding records and any written information the customer received. |
| Vendor gives a customer an open-source component it has not changed | Usually not the provider of a high-risk system; the party that builds the high-risk system is the provider | Article 25(4) written agreements generally do not apply to free and open-source tools other than general-purpose AI models. Keep license terms and a record of any changes made by the vendor. |
How a SaaS vendor works through its AI features before launch
The sequence turns a loose list of AI features into a documented position on each feature's role, risk tier and disclosure duties, so the vendor can show its reasoning before release and after every change. Each step closes with a record the compliance lead keeps.
Build an inventory of AI features and dependencies
Product and engineering leads list every feature that uses AI, including features that call a third-party model API, embed a vendor's AI component, or generate text, images or code for users. For each feature, record the underlying model or service, whether the vendor trains or fine-tunes it, where inference runs, and which customer data it touches. The step is done when the compliance lead holds an inventory record per feature, reviewed by engineering and signed off by the product owner. Confirm with each supplier which models sit behind each feature, since those dependencies drive later supplier clauses.
Record intended purpose and permitted customer use
For each inventoried feature, product management writes the intended purpose in plain terms, such as what the feature does, for which user group and in which business process. The team also lists the customer use cases the product allows and the uses it prohibits in its terms and documentation. Because Article 3 and Article 25 turn on purpose and on whether the vendor changes a system's intended purpose, this record is the anchor for every later decision. The step closes with an intended-purpose statement per feature, approved by the product owner and legal counsel and stored with the inventory.
Assign provider or deployer roles per feature
The compliance lead tests each feature against the definitions in Article 3(3) and Article 3(4) to decide whether the vendor develops and places the system on the market under its own name (a provider) or uses a system built by someone else under its authority (a deployer). The same product can hold both roles, for example a vendor that builds a chatbot on a third-party model and offers it under its own brand. The output is a role assignment per feature with a short rationale that cites the definitions relied on. Legal review confirms the rationale before the record is final.
Classify each feature against Article 50 and Annex III
The team checks each feature for Article 50 duties, such as direct interaction with people, synthetic content generation and emotion recognition. It then checks whether the feature falls in an Annex III use area. Where a feature is in an Annex III area, the team runs the Article 6(3) assessment to test whether it poses no significant risk and fits a narrow procedural, preparatory or pattern-detection role. Under Article 6(4), a provider that relies on that exemption must document the assessment before the system is placed on the market and register it. The output is a classification memo per feature that states the tier reached, the reasoning and the evidence reviewed. Confirm the current status of the draft Commission classification guidelines before finalizing the memo.
Design Article 50 disclosure and content marking
Where Article 50 applies, product and engineering design how users learn they are interacting with an AI system, and how generated audio, image, video or text is marked in a machine-readable form so it can be detected as artificially generated. The design covers the interface copy, the metadata or watermarking method, testing of how marks survive common export and sharing, and the cases where the obviousness exception might apply. Check the transparency guidelines and the Code of Practice on marking and labelling of AI-generated content for current expectations before fixing the design. The output is a disclosure and marking specification per feature, with test results showing the marks are present on output.
Document decisions and sign supplier agreements
Legal and procurement turn the decisions into a documented file: the inventory, intended-purpose statements, role assignments, classification memos and disclosure specifications. For each model supplier or AI component vendor, the team agrees in writing the information, technical access and assistance the vendor will provide, as Article 25(4) requires where a high-risk system depends on a third party. The team also confirms which terms apply to free and open-source tools, since Article 25(4) excludes most of them. The output is a signed supplier clause or data processing and assistance schedule per dependency, filed next to the decision records.
Assign owners for review after each release
Before launch, the compliance lead names an owner for each feature's record and sets out the triggers that reopen the sequence. Triggers include a new model or supplier, a new customer use case, a change to intended purpose, a substantial modification, and any change to user-facing disclosure or marking. Because Article 25(1) can make a party the provider of a system it repurposes or substantially modifies, release management must check each change against these triggers. The output is a review register that lists the owner, the trigger list and the date of the last review for each feature, kept with the release checklist.
What changes when your AI feature runs on someone else's model
When your feature calls a hosted general-purpose model through an API, the model company is the provider of that model. Your product is an AI system you place on the market under your own name, so under Article 3(3) you are the provider of the system your customers use. The model provider's own duties for the model sit in Chapter V of the Act, which the generative AI page covers in more depth. Your duties start where your product begins: how users meet the feature, how outputs reach them and what you tell customers about it.
- Model provider: the API company owns the general-purpose model, its technical documentation and the Chapter V duties attached to it.
- Your system role: you remain the system provider for the feature, including the chatbot disclosure under Article 50(1) when users interact with it directly.
- Output marking: if the feature generates text, images, audio or video, Article 50(2) applies to you as system provider, so confirm which marks the API returns and add any that your product still needs.
- Model changes: ask for notice of version changes, because a silent model update can change the behavior you documented.
- Data terms: confirm in writing how prompts, outputs and logs are used, retained and made available to you.
Before launch, check the API's written output and marking features against your own obligations.
When you fine-tune or build on an open-weight model, you take on more than integration work. The original publisher remains the provider of the base model, but your modifications can change your role. Whether fine-tuning makes you a provider of a general-purpose model depends on the nature and scale of the modification, so review it against the Chapter V criteria before release. A permissive license does not settle the question either, because the free and open-source treatment in Article 25(4) excludes general-purpose AI models from its exemption.
- Base model provider: the publisher keeps the duties for the original model, and its model card and license define what it has documented.
- Your modification: document the training data, the method and the intended purpose, since these decide whether you are a provider of the modified system or model.
- Intended purpose: if you change a system's purpose so that it becomes high-risk, Article 25(1) makes you its provider.
- Marking: your system still carries the Article 50(2) duty for synthetic output, so build the marking into the serving stack.
- Written terms: ask the publisher to confirm license scope, usage restrictions and any obligations it passes down to downstream modifiers.
Before you ship a fine-tuned model, record every modification and confirm in writing which duties the publisher keeps and which you assume.
When a model runs inside the client's own cloud account, the roles split by who places the system into service and who operates it. The model publisher stays responsible for the model. You remain the provider of the AI system if you develop it and place it on the market under your name, even if the client hosts it. The client usually acts as deployer when it uses the system under its authority in a professional setting, which means the client carries deployer duties over how it runs the system.
- Model publisher: the open-weight or licensed model owner keeps the duties for the model itself and supplies its documentation.
- Your system role: you still provide the feature, so you carry the Article 50 duties for chatbot disclosure and synthetic output marking.
- Client role: the client deploys the system in its own environment, so confirm which deployer duties it takes on and what it must keep for oversight.
- Operational responsibility: agree in writing who patches the runtime, rotates secrets, retains logs and handles incidents in the client's account.
- Model artifacts: keep checksums, version records and the source of each weight file so you can show which model produced which output.
Before deployment, write down who operates each layer so that the marking, logging and incident duties have a named owner.
When you embed a third-party AI product inside your platform, the provider of that product remains responsible for it, but your branding and your use case can shift the role onto you. If you put your name or trademark on a high-risk system, Article 25(1) makes you its provider. If you also change its intended purpose or make a substantial modification that keeps it high-risk, the same article applies. Article 25(4) expects providers and suppliers to agree in writing the information, technical access and assistance that the chain needs.
- Supplier role: the third-party company keeps the duties for its product, including its technical documentation and conformity evidence where required.
- Your branding: a white-label or co-branded release can make you the provider, so confirm your role before you sell the feature under your name.
- Marking: confirm whether the supplier's output carries the Article 50(2) mark and who is responsible if it does not.
- Written agreement: request the information, access and support you need for your own documentation, incident reporting and customer explanations.
- Change control: require notice before the supplier changes the model, the intended purpose or the data it uses.
Before signing, map each Article 25 trigger against your product plan and make sure the supplier's written terms cover every duty that lands on you.
What to agree in writing with model suppliers under Article 25(4)
Article 25(4) requires a provider and any third party supplying AI systems, models, tools, services, components or processes to agree in writing the information, technical access and assistance the provider needs to meet its obligations under the Act. For a SaaS vendor, the supplier is usually a foundation model provider, a hosted API, a fine-tuning service or an embedded component such as a classifier or moderation model. Your product team should list every such dependency in the AI system inventory, then ask each supplier for a written agreement covering what you will need to show an assessor or market surveillance authority later. The clause does not apply to free and open-source tools other than general-purpose AI models, so you must check each dependency individually. A permissively licensed open-source library is probably outside the clause, but an open-weight general-purpose model may not be, and the licence alone does not settle the question. Confirm the status of each dependency with your counsel before relying on it.
Ask suppliers for a defined set of items and put each one in the contract. Request model documentation sufficient to support your own technical documentation, including the intended purpose, known limitations and evaluation results your feature depends on. Require advance change notices for model versions, retraining, safety filter changes and deprecations, since a silent change can alter your risk classification or your transparency obligations. Ask for logs or traces that your post-market monitoring can use, with stated retention periods and the fields recorded. Name incident contacts with response expectations, so you can meet your own reporting duties when something goes wrong. Finally, ask whether the supplier can support Article 50 marking of synthetic outputs, such as machine-readable metadata or watermarking, and who is responsible if that marking is stripped or not applied. Treat each of these as something to confirm with the supplier's current terms and your own counsel, not something to assume from a marketing page or a general data processing addendum.
Why SaaS AI launches stall on classification and disclosure
Most delays in SaaS AI launches come from a few predictable gaps: unclear roles, unowned disclosure text, untested marking, and supplier terms signed too late. Each card below names one gap, the cost it typically creates, and the control that closes it before customers see the feature.
Treating the vendor as a neutral tool maker
A vendor may see itself as supplying software, while customers use the feature to rank job candidates or score borrowers. Under Article 3, the question is whether the vendor develops the system and places it on the market under its own name, and the customer's use decides how the system is classified. Check the intended purpose stated in your documentation and marketing, and list the regulated use cases customers are likely to adopt. Late discovery typically forces a rewrite of documentation and product claims just before release.
Leaving disclosure without an owner
When disclosure wording is left to the frontend team, chatbot notices, labels and help text often drift from what legal and compliance have approved. Article 50(1) requires that people interacting directly with an AI system are informed of it, unless this is obvious in context. Assign a named owner for disclosure text, record the approved wording by surface (chat widget, email, API docs), and review it at each release. The usual cost is a rework cycle on every interface that shipped without sign-off.
Assuming a model default covers marking
Article 50(2) requires providers of systems that generate synthetic audio, image, video or text to mark outputs in a machine-readable format. Some model suppliers offer default watermarking or metadata settings, but a default in the supplier's API does not show that your product preserves the marks through export, resizing, copy and paste, or downstream APIs. Test marking end to end on your own output paths, and confirm with the supplier which settings are on by default and which you must enable. Untested marking usually surfaces as a failed review late in the launch.
Missing when a customer makes you a provider
Under Article 25(1), a party becomes the provider of a high-risk system if it changes the intended purpose of a non-high-risk system so that it becomes high-risk, or if it puts its own name on a system. A customer who configures your general-purpose feature for hiring or credit decisions may therefore shift provider duties onto itself, or onto you if you help build that use. Define supported use cases in contracts and product terms, block or flag restricted configurations, and document what you will not support. Without this, a single customer project can turn a routine feature into an obligation you did not plan for.
Skipping the written supplier clause
Article 25(4) requires providers and third parties supplying AI systems, models, tools, services, components or processes to agree in writing the information, technical access and assistance needed to meet the Act. Teams often sign model supplier terms for speed and plan to add these terms after launch, which leaves documentation, logging and incident data unavailable when a customer or authority asks. The clause does not apply to free and open-source tools other than general-purpose AI models, so confirm which of your components fall under it. Agree the clause before the first production traffic, and list the evidence each side must provide.
Questions SaaS teams ask before adding AI features
Does the AI Act still apply if our AI feature is free?
Yes. Article 3(3) makes a provider anyone who develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark, whether for payment or free of charge. Price does not remove the obligation. What changes the analysis is the role you hold and the risk category of the feature. A free feature that ranks job applicants is still a high-risk use, and a free chatbot still falls under the transparency duties. Start by recording who builds the feature, whose name it ships under, and what it is for. Those three facts decide most of the first classification.
Does a chatbot need an AI disclosure if users can tell it is a bot?
Maybe not, but you have to test it. Article 50(1) requires providers to design systems that interact directly with people so those people are informed they are talking to an AI system, unless this is obvious to a reasonably well-informed, observant and circumspect person in the context. Obviousness is judged from the user's point of view, not the engineering team's. A support widget labelled as an assistant may pass the test, while a sales chat that mimics a human agent will not. Write down the test you applied, the interface text you reviewed and the user groups you considered, and revisit the record when the interface changes. The Commission's transparency guidelines are the natural next read for this question.
Who must mark AI-generated text, images and audio?
The provider of the generative system must mark outputs. Article 50(2) applies to providers of AI systems, including general-purpose AI systems, that generate synthetic audio, image, video or text. Outputs must be marked in a machine-readable format so they can be detected as artificially generated or manipulated. If your SaaS product calls a third-party model and presents its output under your brand, you are likely the provider of that generative feature, even though the model belongs to someone else. Check the marking approach your model supplier offers and confirm it survives your export, download and API paths. The Commission has published a Code of Practice on marking and labelling AI-generated content that you should review.
How much internal staff time does AI Act work take?
The effort depends on how many AI features you ship, how many of them touch people's rights and how well your product documentation already works. Internal time usually goes to three tasks: an inventory of AI features and their purposes, a written classification for each feature, and transparency reviews for user-facing interfaces. Engineering staff must answer technical questions about data, models and logs. Legal or compliance staff own the classification decisions and the governance record. Product owners confirm the intended purpose, which drives the risk category. Ask any partner to break its estimate into these roles so you can see which hours fall on your own team.
Can our team classify AI features without outside help?
Yes, a capable internal team can do the classification and keep a written record. The work is mostly a structured reading of Article 3 for roles, Article 6 for high-risk status, and Article 50 for transparency, applied to a clear description of each feature. Outside help becomes useful when the classification is disputed, when a feature sits near an Annex III category, or when the team must produce technical evidence such as logs, documentation, data lineage or human oversight records. A partner such as DeployOpen can prepare systems and evidence for your own review, but it does not issue legal opinions or conformity findings. Only independent assessors and notified bodies issue those results where the Act requires them.
When do the high-risk rules apply to Annex III systems?
The high-risk rules in Chapter III Sections 1 to 3 apply from 2 December 2027 for Annex III systems, as amended by Regulation (EU) 2026/1744. The original date was 2 August 2026. Annex I product systems move to 2 August 2028, instead of 2 August 2027. The transparency duties under Article 50 follow the general application date, so plan them on the earlier clock. Remember that Article 4 on AI literacy has applied since 2 February 2025 to providers and deployers of all AI systems. Confirm the current consolidated text on EUR-Lex before you fix an internal deadline, because amendments have changed these dates once already.
What should we request in a partner quote for AI Act work?
Ask for a written scope that lists each AI feature covered, the roles you hold for each one, and the articles the work addresses. The quote should separate one-time work, such as the inventory, classification records and documentation set, from recurring work, such as re-classification when features change and monitoring of model updates. Ask which deliverables you own at the end, in what format, and who signs off each record. Confirm what the partner will not do, including legal opinions, certification or any assessment that must come from an independent body. Also ask how changes to scope are priced and how the engagement ends. DeployOpen works from a fixed written scope, so the quote follows from that document.
Do we become the provider if we build on a third-party model?
You can, and the answer turns on what you put your name on and what you change. Article 25(1) makes a distributor, importer, deployer or other third party the provider of a high-risk system if it puts its name or trademark on it, makes a substantial modification that keeps it high-risk, or changes the intended purpose of a non-high-risk system, including a general-purpose AI system, so it becomes high-risk. Under Article 25(4), you should agree in writing with the model supplier on the information, technical access and assistance you need. That clause does not apply to free and open-source tools other than general-purpose AI models, so check the licence and category of each component before you rely on it.
How DeployOpen helps SaaS teams prepare AI Act evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and prepares the systems and evidence an AI Act assessment will look at for the AI features you ship. We do not issue reports or certificates, and we do not decide your provider or deployer role; that stays with your organization and, where required, an independent assessor.
How we scope
- Written scope lists each AI feature, its intended purpose and whether your company is the provider, deployer or both.
- Scope names the model suppliers, their contract terms and which Article 50 disclosures your product must show.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We configure chatbot disclosure notices and machine-readable marking of generated outputs in your stack.
- We build an AI system inventory with documented high-risk assessments, including any Article 6(3) exemption files.
- We test marking and disclosure behaviour and record the results as evidence you can hand to an assessor.
How we hand over
- You receive the inventory, classification records, disclosure specifications, test results and supplier agreement checklist.
- Documents are written so your product, legal and compliance teams can maintain them after handover.
- We walk your owners through each artifact, and we note which items an independent assessor must still review.
How we support
- Ongoing support, upgrades and continuous testing of AI features are available as a retainer.
- Retainers can cover re-classification when a feature changes its intended purpose or gains new capabilities.
- Ask any provider of AI or compliance services to confirm in writing what they will and will not certify.
