Does my US SaaS company fall under the EU AI Act?

Article 2 sets the territorial scope of the AI Act. The regulation applies to providers placing AI systems on the EU market regardless of where the provider is established, and to providers and deployers whose output is used in the EU. A US-based SaaS company serving EU customers is inside the scope if the AI feature is used in the EU. The territorial reach is comparable to GDPR's. A US SaaS that limits its EU exposure must do so contractually, by excluding EU use of AI features through the subscription terms, and operationally, by enforcing geographic restrictions at the data layer.

Who is responsible if the AI feature makes a wrong decision?

The provider is responsible for the design, accuracy claims, and intended use of the system. The deployer is responsible for using the system inside the documented bounds, monitoring its operation, and exercising human oversight. Liability for a specific wrong decision is allocated by the contract between provider and deployer, by the substantive obligations of the AI Act, and by the national civil liability framework that applies in the Member State where the harm occurred. The deployer cannot generally transfer the deployer obligations to the provider, but the contract can address allocation of remedies and indemnification.

Do we need a notified body to assess our high-risk SaaS feature?

Most Annex III high-risk systems do not require third-party conformity assessment. The provider conducts internal conformity assessment under Article 43 and produces the technical documentation. The exceptions are systems that fall under branch one of Article 6 (safety components of regulated products under Annex I) and biometric systems under Annex III Category 1, which require notified body involvement. Most enterprise SaaS AI features fall outside the notified body requirement and conduct conformity assessment internally.

What changes when our customer is a public-sector deployer?

Public-sector deployers face additional obligations under Article 27, which requires a fundamental rights impact assessment before deploying a high-risk system. The assessment must cover the categories of natural persons likely to be affected, the foreseeable risks of harm, and the safeguards in place. The SaaS company supporting a public-sector customer should expect to provide more detailed technical documentation, support the customer's impact assessment work, and be prepared for direct authority inquiry. The penalty exposure is the same, but the documentation work is heavier.

How does the AI Act interact with our existing SOC 2 or ISO 27001 attestation?

SOC 2 and ISO 27001 cover information security controls. The AI Act covers a separate set of operational obligations specific to AI systems. The two regimes do not substitute for each other. A SOC 2 attestation does not satisfy Article 12 record-keeping, Article 13 transparency, or Article 26 deployer obligations. The SaaS company's compliance posture must address both regimes independently. Some controls (access management, audit trails, incident response) overlap and can be documented to satisfy both. The substantive AI Act obligations require artifacts that the SOC 2 framework does not produce.

EU AI Act for SaaS: How Embedded AI Features Pull Vendors Into the High-Risk Regime

The EU AI Act puts most of its operational weight on the provider and the deployer of a high-risk AI system. SaaS companies that embed AI features in product flows sit inside the provider role the moment their customer uses the product in a high-risk use case. The classification flows through Article 6 and Annex III, and it takes effect on August 2, 2026. The SaaS company faces the Article 99 penalty exposure of €15 million or 3% of global annual turnover on a per-obligation basis. The customer also faces exposure as the deployer, and the customer's procurement team is the one writing the contract clauses that determine how the obligations are allocated.

I want to walk through how SaaS deployments get pulled into the high-risk regime, the two roles a SaaS company can occupy, and what contract and architecture work has to happen before August 2.

Mandate

The EU AI Act allocates obligations across the AI value chain. Article 3 defines the actors: provider, deployer, importer, distributor, and authorized representative. The provider develops or has developed an AI system and places it on the market or puts it into service under its own name or trademark. The deployer uses the AI system under its authority.

A SaaS company that ships an AI feature is the provider of that feature. The customer that turns the feature on is the deployer. If the feature falls under any of the eight Annex III categories, the system is high-risk, and both roles carry obligations.

The SaaS company is most often the provider

Provider obligations under Articles 16 to 22 include implementing a quality management system, conducting conformity assessment, producing technical documentation, maintaining the technical documentation, drawing up the EU declaration of conformity, affixing the CE marking, registering the system in the EU database, and conducting post-market monitoring. The provider's obligations attach at the design and release layer. A SaaS company that ships AI features without a quality management system or technical documentation fails the provider obligations on its first deployment into a high-risk use case.

The customer is the deployer

The customer that uses the feature in a high-risk use case is the deployer. The deployer carries the Article 26 obligations: use in accordance with instructions, human oversight assignment, monitoring of operation, log retention under Article 19, and serious incident reporting. The deployer also carries the Article 12 record-keeping obligation, which requires the system to produce automatic logs over its lifetime.

Some SaaS companies carry both roles

A SaaS company that uses AI in its own internal operations is the deployer of those internal systems. A SaaS company that ships AI features to customers is the provider of the customer-facing system. Many SaaS companies carry both roles simultaneously: provider of the customer feature and deployer of internal automation that supports the same feature.

Compliance gap

Most SaaS companies I look at are inside the high-risk regime through one or more product lines and have not built the provider infrastructure that Articles 16 to 22 require.

The feature gets shipped before the conformity assessment

The SaaS development cadence routinely outpaces the regulatory artifact production. A new AI feature ships in a quarterly release. The conformity assessment, technical documentation, and EU declaration of conformity are six-month efforts. The feature is live in customer environments before the documentation that justifies it exists. The Article 99 exposure attaches from the moment the system is placed on the market.

The customer contract leaves the obligations unallocated

Standard SaaS subscription agreements predate the AI Act. They are silent on how AI Act obligations split between provider and deployer. They omit any requirement on the SaaS company to produce Article 12 logs the customer can retain. They place no incident-reporting duty on the customer under Article 26. Without contractual allocation, both parties face the obligations directly with no operational bridge.

Cross-border data flows complicate the picture

A SaaS company headquartered outside the EU that serves EU customers is still inside the AI Act if the use case falls under the regime. The territorial scope under Article 2 captures systems whose output is used in the EU regardless of where the provider is established. US-based SaaS companies serving EU lenders, EU recruiters, EU healthcare deployers, and EU public-sector customers are inside the scope.

Sub-processor AI is invisible

A SaaS feature that uses an upstream LLM provider routes data through the upstream provider's infrastructure. The SaaS company is the provider of the customer-facing system. The LLM provider has separate obligations under Articles 53 to 56 as a general-purpose AI model provider. The customer needs visibility into both, but the standard SaaS architecture does not produce that visibility. The customer's Article 12 record-keeping obligation extends to data flows the customer cannot see.

What SaaS companies must build

The provider obligations under Articles 16 to 22 require several specific artifacts.

The quality management system documents the development, post-market monitoring, incident reporting, and corrective action processes for the AI features. The technical documentation under Article 11 describes the system, its intended purpose, training and validation data, accuracy figures, foreseeable misuse, and the human oversight measures expected of the deployer. The EU declaration of conformity is a one-page document that the provider signs at release. The CE marking attaches to the system documentation. Registration in the EU database is done through the AI Office portal.

Beyond the documentation, the SaaS company must build the runtime evidence that Article 12 requires. Every high-risk decision the system makes must be recorded automatically, with identity, input data, output, policy state, and timestamp. The customer (the deployer) retains the records under Article 19. The architectural answer is to produce those records inline and to make them available to the customer's compliance function.

DeepInspect

This is the runtime infrastructure SaaS companies need to satisfy the provider half of the regime and to give their customers what Article 19 expects. DeepInspect sits as a stateless proxy between the SaaS application and the LLM. Every request that flows through produces a signed per-decision audit record with identity, policy version, data classification, and outcome. The records are exported to the customer's environment in formats the customer's compliance function can ingest.

For SaaS companies, the operational benefit is that the same proxy serves multiple customers, multiple use cases, and multiple high-risk classifications. The provider obligations are satisfied centrally. The customer's deployer obligations are satisfied through the per-decision record export. The contractual allocation between provider and deployer is grounded in a shared evidence layer rather than separately reconstructed in each customer environment.

If your SaaS product embeds AI features used by EU customers in high-risk categories, your provider readiness is a runtime evidence question, not a documentation question.

Book a demo today.