The feature-by-feature decision

  1. Define the feature. Record the AI-enabled function, intended purpose, users and markets rather than assessing the whole SaaS product as one block.
  2. Identify who puts it on the market. Record whose name or trade mark appears on the system and who controls the intended purpose.
  3. Separate model and system roles. Embedding a general-purpose AI model does not by itself answer who provides the downstream AI system.
  4. Check Article 25 changes. Rebranding, substantial modification or changing the intended purpose of a system so it becomes high-risk can transfer provider obligations.
  5. Record the evidence. Keep the rationale, supplier dependencies, contracts, risk decision, changes, owners and review triggers.

Three common SaaS scenarios

1. You build and sell the AI feature

Your company designs an AI feature and supplies the product under its own name. You are likely acting as the provider of that AI system. The applicable obligations then depend on the system, intended purpose and risk classification.

2. You use a third-party AI service internally

Your team uses an external AI system largely as supplied for support, analysis or operations. You are more likely acting as a deployer. Record permitted use, oversight, supplier evidence, data handling, monitoring and escalation.

3. You embed, rebrand or materially alter a third-party system

The answer depends on what you market, control and change. Article 25 can move provider responsibilities to another party for certain high-risk systems. Treat the underlying model, downstream system and your product feature as separate but connected records.

What evidence should procurement expect?

  • A feature-level AI system inventory with intended purpose, owner, users, geography and deployment status.
  • A dated provider/deployer decision with rationale and assumptions.
  • Model and supplier dependencies, versions and material contract responsibilities.
  • Risk classification and any high-risk, transparency or prohibited-practice assessment.
  • Change records showing when role or risk decisions must be revisited.
  • Named owners for testing, human oversight, incidents, supplier assurance and evidence review.

A buyer should be able to trace a governance claim to a controlled record—not just a policy statement. Use the procurement readiness guide to organise the wider evidence pack.

Why the role decision changes the work

Provider and deployer obligations are not interchangeable. Provider responsibilities can include system design, documentation, risk management and conformity duties where applicable. Deployer responsibilities can include use in accordance with instructions, oversight, monitoring, logs and impact-related duties in defined circumstances. The exact requirements depend on the system and use, so role classification is an evidence-backed starting point rather than a substitute for legal analysis.

Frequently asked questions

Is a SaaS company a provider or deployer under the EU AI Act?

Assess each feature separately. Developing an AI system or placing it on the market under your name points towards provider status; using another provider's system under your authority points towards deployer status. Both can apply across one product.

Can a SaaS company become a provider of a third-party AI system?

Potentially. Rebranding a third-party high-risk AI system, making a substantial modification, or changing its intended purpose so it becomes high-risk can transfer provider obligations under Article 25. Record the facts and obtain qualified advice where the classification is material.

Does embedding a third-party general-purpose AI model make us the model provider?

Not automatically. The role for the model and the role for the downstream AI system or feature are separate questions. Record the model supplier, downstream design, intended purpose, responsibilities and changes you make.

What role-classification evidence should a SaaS supplier keep?

Keep a feature-level inventory, intended-purpose statement, role decision and rationale, supplier and model dependencies, change history, risk classification, contractual allocation, control owners and review triggers.

Related guidance

Official sources

Reviewed 26 August 2026. This is general governance information, not legal advice or certification.