A SaaS team can inherit a general-purpose model from a supplier while remaining responsible for assessing the product it builds around that model. Embedding the model does not by itself determine the product’s obligations. Assess the architecture, intended purpose, deployment context, and controls around its use [1], [2], and [4]. For SaaS teams, EU AI Act compliance turns on how the model is integrated, what the product does, and who controls its use. This article examines EU AI Act compliance for SaaS using the available evidence and a practical perspective.
Classify the activity, not only the model
Many SaaS products now call an external model through an API. The model may generate text, summarize documents, classify support tickets, search a knowledge base, or trigger actions through connected tools.
Using an external model does not automatically make the SaaS company a GPAI model provider. The upstream provider supplies the model; the SaaS company may provide the downstream AI system, while a customer or internal operating team may deploy it. Role classification and obligations turn on the product architecture, intended purpose, modifications, deployment context, actual use, and applicable provisions.
The role assessment deserves closer attention when the product architecture or intended use includes any of these features:
- Fine-tuning or materially modifying the model
- Repurposing the model for a new domain or function
- Adding retrieval, tools, autonomous workflows, or decision logic
- Placing the resulting model or AI system on the EU market
- Deploying the system in a potentially high-risk or transparency-relevant context
Consider one shared model used in two SaaS products. In a support copilot, it drafts a reply that a human reviews and approves before sending, so the product’s workflow keeps the final communication under human control. In a CRM agent, it selects a record, updates the CRM, and sends a customer communication without that approval, so the SaaS team must govern tool permissions, action limits, audit records, and release decisions more directly. The underlying model is the same, but the products raise different questions about provider and deployer roles, transparency, human oversight, external actions, and deployment context [3] and [4].
How EU AI Act compliance for SaaS changes by role
The AI Act separates obligations connected to general-purpose AI models from obligations connected to AI systems. For SaaS teams, the distinction determines which architecture decisions, ownership records, and release controls need review.
| Role | What the role covers in a SaaS chain |
|---|---|
| GPAI model provider | Develops or places the general-purpose model on the market and handles model-level duties under the applicable provisions [1], [2], and [4]. |
| Downstream AI-system provider | Incorporates the model into a product, defines the system’s intended purpose, and makes the resulting AI system available or puts it into service [1] and [3]. |
| Deployer | Uses the AI system under its operational control in a workplace, customer, or decision context. A SaaS company can also be a deployer when it operates the system itself; roles may differ across deployments [1] and [3]. |
Architecture, intended purpose, users, deployment arrangements, and the controls each party can operate determine the relevant responsibilities. Supplier documentation informs the review but does not replace the SaaS team’s assessment of its downstream feature, operating setting, autonomy, affected users, outputs, and external actions [1], [2], and [4].
For instance, a vendor may remain the GPAI model provider while a SaaS company becomes the downstream AI-system provider for a recruiting assistant that ranks applications. The customer using that assistant may be the deployer, while the SaaS company is also a deployer when its own staff use the system to screen candidates. In a field-service deployment, the same SaaS company may provide the workflow while the customer’s operations team controls the system and its recommendations. These role assignments depend on the actual product configuration, intended purpose, and operational control.
Common mistake: assuming the model provider covers the SaaS product
Use the model provider’s documentation as an input to product governance, not as a substitute for reviewing the SaaS feature’s permissions, review points, and release decisions. Systemic-risk status at the model level does not by itself determine the product’s position.
Integration, modification, and operational autonomy
Record the external-model integration, supplier documentation, data-processing boundaries, versioning practices, and data-handling terms, including retention, training use, regional transfers, and human review. Link those records to product-level controls for access, retrieval sources, output review, and disclosure of AI-generated content.
Then assess whether fine-tuning, adapters, additional training, repurposing, or other changes materially alter the system’s behavior or intended purpose. Keep a concise change record covering the original model and version, material updates to data, weights, adapters, prompts, policies, domains, decision contexts, limitations, evaluation evidence, and release ownership. Use that record to focus review on changes that affect behavior, intended purpose, recommendations, or external actions [1], [2], and [4].
Operational autonomy requires a separate control review. Retrieval-augmented generation, tool calling, browser access, CRM updates, and workflow automation can make the downstream system more consequential than the base model. A sales assistant that drafts a message leaves approval and sending with a human; an agent that selects prospects, accesses records, updates the CRM, sends communications, and escalates cases without review acts directly on external systems. Tool permissions, approval points, action limits, and customer deployment therefore belong in the same governance review.
Risk classification is contextual
Generative AI alone does not determine whether a SaaS product is high risk. Assess the intended purpose, affected people, domain, decision function, and degree of autonomy.
Those categories point to different control priorities. High-risk uses can involve risk management, data governance, logging, and human oversight. Transparency-risk uses instead concern disclosure of AI interaction or identification of generated or manipulated content. Minimal-risk uses generally carry fewer prescribed obligations, although voluntary governance may still be useful [1] and [3].
Product planning should distinguish a general-information chatbot from an AI system supporting a regulated or high-impact decision. A shared foundation model can serve both products, but their purposes and deployment contexts may lead to different assessments.
The Act and Commission materials identify 2 August 2025 for the GPAI provisions discussed here and 2 August 2026 for Article 50 transparency obligations. Treat these as qualified application dates and verify the precise provision, scope, exemptions, and transitional rules against the current sources [1], [2], [4], and [5].
A practical EU AI Act compliance checklist for SaaS teams
Use this checklist to organize evidence, product controls, and release records; it does not establish legal compliance or replace a provision-by-provision review. Model inventories, documentation reviews, logging, and user disclosures can fit within ordinary engineering and release work rather than a single final approval gate.
Build a model and supplier inventory
Inventory every external model and AI service used by the product. Record the provider, model name, version, endpoint, region, business use case, data exchanged, documentation, contractual restrictions, supplier updates, and deprecation notices in one record. This gives engineering, procurement, security, and compliance teams a shared view of the AI supply chain.
A customer-support copilot should link its model and supplier record to the knowledge sources it can retrieve, the human-review step before a reply is sent, prompt and approval logs, and release controls for changes to prompts, tools, or model versions.
Map the architecture and data flows
Maintain a current diagram or written record of prompts, retrieval systems, vector stores, tools, agents, application databases, human review points, and external services. Mark sensitive data flows and separate model processing from application controls such as identity, permissions, retention, audit records, and customer delivery.
Manage modifications and releases
Track AI changes alongside source-code releases, including updates to fine-tuning datasets, adapters, system prompts, safety policies, retrieval indexes, source documents, model versions, fallback providers, tool permissions, action limits, supported user groups, geographies, and human-review rules. Use that history to identify changes in behavior, risk, transparency, or supply-chain role and to decide when a documented release review is warranted.
Add risk, oversight, and incident controls
Before launch, document the intended purpose and assess whether the use case may be high risk or transparency relevant. Assign responsibility for monitoring outputs, handling incidents, and deciding when a human must review or override the system. These assignments make the risk assessment usable in day-to-day product operations. Use proportionate logs—such as model and workflow versions, tool actions, reviewer decisions, and incident references—to support reconstruction and corrective action. Review the retained data for privacy and security implications.
Design user transparency into the interface
Where disclosure is required, place it directly in the product experience. A notice hidden only in general terms may not provide meaningful user understanding.
The interface may need to disclose AI interaction or label generated or manipulated content. Show human-review, recommendation, correction, and escalation controls in the relevant user journey when they affect a user’s decision.
Where Donusoft fits in the engineering workflow
In a SaaS product, Donusoft can support the engineering controls that make the assessment operational: tracking model-version changes, connecting retrieval indexes to release records, governing CRM permissions and approval gates, logging tool actions, and placing customer-facing AI disclosures in the relevant workflow. These capabilities support the product records and operational controls described above; they do not constitute a compliance assessment for any specific product.
For the broader operational controls that support this work, see Donusoft's practical AI governance guide. That guide covers ownership, human review, logging, access controls, and monitoring; this article focuses on the additional EU AI Act and GPAI questions that SaaS teams must assess.
Conclusion: Keep compliance decisions with product records
Compliance decisions should live alongside architecture, release, and customer-deployment records. Keep supplier evidence, risk controls, transparency measures, and change records close to feature behavior, tool access, human approval, and customer deployment. Revisit the assessment when those conditions change. EU AI Act compliance for SaaS is therefore a multi-factor review grounded in evidence and the product’s real operating context.
Frequently Asked Questions
How do architecture and deployment context affect classification?
Classification depends on the system’s intended purpose, autonomy, interfaces, users, and deployment context, not on API use alone [2] and [4].
When can fine-tuning or modifying a model change a company’s responsibilities?
Fine-tuning, material modification, or repurposing may warrant a more detailed assessment of the company’s role and obligations. Teams should preserve records of the original model, changes, datasets, intended purpose, and release context [1], [2], and [4].
What documentation should SaaS teams request from an AI model provider?
Teams should request available technical documentation, integration information, model limitations, copyright-policy information, and training-content summaries where required. Provider updates and model versions should also be tracked [1], [2], and [4].
When must a SaaS product tell users they are interacting with AI?
The relevant obligation depends on the system and the applicable transparency provisions. The cited guidance associates 2 August 2026 with the application of Article 50 obligations, subject to the provision’s scope, transitional rules, and the specific system context [5].
What is the difference between a high-risk AI system and a transparency-risk system?
High-risk classification concerns systems subject to broader risk-management and governance requirements under applicable conditions. Transparency risk generally concerns informing users about AI interaction or identifying generated or manipulated content; the categories are not interchangeable [1], [3].
When do the cited GPAI and Article 50 transparency obligations apply?
The cited materials associate 2 August 2025 with certain GPAI provisions and 2 August 2026 with relevant Article 50 transparency provisions. Treat both as qualified dates and confirm the applicable scope and transitional rules against the cited sources before publication [1], [2], [4], and [5].
Sources
- [1] Regulation (EU) 2024/1689 — Artificial Intelligence Act
- [2] Guidelines on the scope of obligations for providers of general purpose AI models under the AI Act
- [3] What are the obligations for high risk, transparency risk, and minimal risk AI systems?
- [4] General Purpose AI Models in the AI Act — Questions & Answers
- [5] Guidelines on Transparency Obligations for Providers and Deployers of AI Systems
;)
