The moment you ship an AI feature, an assistant, a summarisation function, a score, a recommendation or a generative component, the question is no longer whether the EU AI Act applies to you but in which role and at what depth. Regulation (EU) 2024/1689 reaches Swiss and UK providers too, via Art. 2(1)(c), as soon as the output is used in the EU. A single business customer in Germany or France is enough to bring you into scope.

For most B2B SaaS providers the message is reassuring: your AI features are not high-risk. They mainly trigger transparency duties under Art. 50. For a small number of use cases the high-risk path under Annex III applies. If you provide your own model, you also meet GPAI duties. The only wrong response is not to classify at all. This article sets out what the AI Act concretely means for SaaS with AI features, how the roles split, how it all interlocks with your data processing agreement and the vendor security review, and how to start pragmatically today.

For the vast majority of AI features in B2B SaaS, Art. 50 is the central rule. Four situations matter. First: anyone operating an AI system that interacts directly with natural persons, such as a chatbot or a support assistant, must inform the person that they are interacting with an AI, unless this is obvious. Second: anyone generating synthetic audio, image, video or text content must mark it as artificially generated in a machine-readable way. Third: deepfakes must be disclosed separately. Fourth: AI-generated text on matters of public interest must be labelled as such.

In practice, for SaaS providers this means a notice in the UI that a function is AI-assisted, a marking of generated content, and clean documentation of those measures. This is well within reach and should be part of your product and release processes. Important: Art. 50 covers both providers and deployers, depending on the function. If you provide the AI system, you as provider are responsible for the technical marking; your business customer as deployer is responsible for informing its end users. The two duties dovetail, and both should be addressed clearly in the contract.

High-risk is the exception, not the rule, but it hits some B2B SaaS features directly. Annex III lists eight clusters. For SaaS providers, three are most relevant in practice. Cluster 4 (employment and HR) covers HR-tech: AI for CV screening, candidate ranking, applicant targeting, performance evaluation or behaviour monitoring. Cluster 5 (access to essential services) covers fintech and insurtech: credit scoring (other than pure fraud detection) as well as risk assessment and pricing in life and health insurance. Cluster 1 (biometrics) hits providers of identity and access functions.

If your AI feature falls into one of these areas, the obligation set is extensive: a risk management system (Art. 9), data governance (Art. 10), technical documentation (Art. 11), logging (Art. 12), transparency towards deployers (Art. 13), human oversight (Art. 14), robustness (Art. 15), quality management (Art. 17) and conformity assessment (Art. 43). There is an exemption mechanism under Art. 6(3) for systems without significant risk, for instance narrow preparatory tasks. That exemption is not automatic: it requires a documented justification and registration, and a system that performs profiling of natural persons is excluded from it. Here, initial classification decides between a light path and a six-figure compliance programme.

A separate layer of duties applies to providers of general-purpose AI models (GPAI). Most SaaS providers are not affected here: using an existing foundation model through an API and building a feature on top does not make you the provider of that model, so you are not a GPAI provider. If, on the other hand, you train your own model, substantially further-train an existing model (fine-tuning to an extent that amounts to providing your own model) or make a model available under your own name, GPAI duties can be triggered.

The core duties for GPAI providers include technical documentation of the model, information for downstream providers that integrate the model, a policy to comply with EU copyright law, and a sufficiently detailed summary of the training data. For particularly capable models with systemic risk, tightened duties apply. The line between mere API use and providing your own model has to be assessed case by case. It is decisive for your role and the scope of your duties, and it belongs at the start of every classification.

The allocation of roles is the most important fork, and for SaaS it is often counter-intuitive. A provider is anyone who develops an AI system and places it on the market under its own name. As a SaaS provider building an AI feature into your product and shipping it to business customers, you are usually the provider of that AI system, even if you use a third-party foundation model in the background. Your business customer, who uses the feature in its operations, is the deployer.

This split has concrete consequences. As provider, for high-risk features you carry the full compliance load under Art. 16, from technical documentation to conformity assessment. Your customer as deployer carries due-diligence, oversight and information duties under Art. 26 and, in certain situations such as banks or public bodies, a fundamental rights impact assessment under Art. 27. Watch out for configurability: if a customer substantially modifies your system or redistributes it under its own brand, it can itself become a provider under Art. 25. Clarify these roles per feature, not company-wide, and fix them in the contract.

AI compliance never stands alone. If your AI feature processes personal data, the Swiss Data Protection Act (nDSG) and, where there is an EU nexus, the GDPR apply in parallel. Your data processing agreement (DPA under Art. 9 nDSG, Art. 28 GDPR) must reflect the AI processing precisely: which data flows into which feature, whether it is used for model improvement (in a B2B context, regularly to be excluded or strictly limited), which sub-processors are involved, such as the model provider, and where the processing takes place.

Two points deserve special attention. First, the sub-processor list: if your AI feature calls an external model provider, that provider is a sub-processor and belongs transparently in your list, including data residency and any transfer to third countries. Second, automated individual decisions: if your feature makes decisions with a significant effect on people, Art. 21 nDSG and Art. 22 GDPR come into play, with information, intervention and explanation duties. A data protection impact assessment may be required. AI Act classification, DPA and DPIA belong in the same dossier, otherwise your answers to customers and supervisory authorities will contradict each other.

The practical pressure rarely comes from the supervisory authority first, it comes from the business customer. Enterprise procurement and third-party risk management now ask systematically about your AI features. Typical questions in the security questionnaire are: which AI functions process our data? Is our data used for training or model improvement? Which model provider is behind it, and where is the data processed? How is your AI governance organised? Is there an AI Act classification of your features? How do you ensure human oversight and transparency?

Answering these questions quickly, precisely and consistently keeps the deal moving. Hesitating or answering inconsistently risks weeks of delay in procurement or losing the mandate. This is exactly where preparation pays off: an AI inventory, a documented classification, clear DPA clauses on AI use, an up-to-date sub-processor list and a trust-center entry on your AI governance. Security and compliance thus become a sales enabler rather than a cost: you shorten the review and build trust.

The AI Act timelines are in motion. The Art. 50 transparency duties are set out, the high-risk deadlines fall from 2026/2027 and are under revision in the Digital Omnibus, so the date should be checked case by case. That uncertainty is not a reason to wait, it is a reason to lay the groundwork now. Start with what holds regardless of deadlines: a complete inventory of your AI features and their data flows, a documented initial classification (transparency, high-risk, GPAI), and a clear provider vs deployer role assignment per feature.

SIDD starts here with two services. The AI Governance Check (from CHF 3,900) gives you a documented AI inventory, the initial classification of your features and a prioritised action list that holds up to market surveillance and customer review. The AI Officer (from CHF 500/month) keeps your AI governance current on an ongoing basis, maintains inventory and classification and answers the AI questions in the security review reliably. We dovetail the data protection side via data protection advisory (nDSG) and, where there is an EU nexus, GDPR DPO and EU representative. To discuss a first read on your AI features, reach us via the contact form; for a full programme, request a proposal via our quote form.