Deployer Obligations: Practical Guide for SaaS Teams

Deployer obligations under the EU AI Act are the operating duties that apply when an organisation uses an AI system under its authority. For SaaS teams, the practical work is not only deciding whether the company built the AI system or bought it from a vendor. It is deciding when the company is using a high-risk AI system, who controls the deployment, which instructions must be followed, what human oversight is required, what logs and monitoring evidence must be kept, and when the use must be paused or escalated.

The clearest starting point is Article 26 of Regulation (EU) 2024/1689. It says deployers of high-risk AI systems must use those systems in line with the provider's instructions, assign competent human oversight, manage input data where they control it, monitor operation, keep automatically generated logs where under their control, and act when a risk or serious incident appears. Some deployers may also need workplace notices, registration checks, data protection impact assessment support, or a fundamental rights impact assessment.

That sounds legal, but the day-to-day answer is operational: create one deployer-obligations record for each relevant AI workflow. The record should show the system, intended purpose, provider instructions, human oversight owner, input-data controls, monitoring process, log retention, incident route, affected users, customer or worker notices, and reassessment triggers.

Why deployer obligations matter in practice

Many SaaS teams focus first on provider obligations because they ship AI-enabled products to customers. That is important, but it is incomplete. The same company may also be a deployer when it uses AI internally, embeds a third-party tool in operations, uses AI for support triage, uses automated scoring in sales or hiring, or configures a vendor system for a customer-facing workflow.

Deployer obligations matter because they sit close to live use. A vendor may provide documentation, instructions, model cards, logs, and monitoring guidance, but the deployer decides how the system is used in the real workflow. The deployer knows which employees rely on outputs, which customers are affected, which data is entered, which exceptions are allowed, and when a human can override the system.

This is why deployer work belongs in the same governance model as AI governance expectations for SaaS vendors, the broader EU AI Act overview for SaaS providers, and the operating discipline needed to avoid static compliance documents.

When deployer obligations may apply

Start with role and risk classification. The team may be a deployer when it uses an AI system under its authority, even if another company developed the system. The obligations in Article 26 are specifically framed around high-risk AI systems, so a deployer review should first ask whether the use is inside a high-risk category and whether the SaaS team is controlling the use in practice.

Common SaaS examples include AI used for employee management, customer risk scoring, fraud triage, access decisions, regulated financial workflows, complaint prioritisation, or other workflows where outputs may materially affect people. Some AI uses may be outside high-risk scope but still raise transparency, privacy, security, contractual, or customer-trust questions. Do not force everything into one bucket. Record whether the issue is high-risk deployer duties, transparency duties, privacy review, vendor risk, customer documentation, or a voluntary governance control.

Also check whether the team is only a deployer. A SaaS company can be provider for one feature, deployer for an internal workflow, and both provider and deployer in different parts of a value chain. Role analysis should be done per AI workflow, not once for the whole company.

Build the deployer-obligations record

A strong deployer record starts with the system and use case. Name the AI system, vendor or internal owner, product area, business process, intended purpose, user group, affected persons, data categories, geography, and launch status. Attach the provider instructions and any customer-facing or internal documentation that explains permitted use.

Then record role and classification. The decision should explain why the team is acting as deployer, whether the system is high-risk, which AI Act provision or Annex III area is relevant, and which related workflows must also be reviewed. Keep uncertainty visible. If the classification is still open, the record should show the owner, blocker, and deadline.

Next, translate each duty into an operational control. The record should not say "Article 26 reviewed" and stop. It should show how the team will follow instructions, who performs human oversight, which input data checks apply, where logs live, how operation is monitored, when the provider is informed, when use is suspended, and which evidence proves the workflow ran.

Finally, connect the record to change management. Deployer obligations become stale when a vendor changes the model, the team changes the intended use, a feature moves from internal use to customer-facing use, human review is reduced, a new data source is added, or a customer uses the system in a more sensitive context.

Practical checklist for SaaS teams

Use this checklist before putting a relevant AI system into service and whenever the workflow materially changes.

• Confirm the exact AI system, vendor, workflow, intended purpose, user group, and affected persons.
• Decide whether the company is a deployer, provider, or both for this workflow.
• Screen whether the use is high-risk or whether another AI Act track is more relevant.
• Attach the provider's instructions for use and translate them into product, operations, support, or internal SOP steps.
• Assign human oversight to named people with competence, training, authority, and escalation support.
• Define input-data controls where the team controls the data entered into the system.
• Decide which logs are automatically generated, which logs are under the team's control, and how long they must be retained.
• Create monitoring signals for errors, drift, misuse, complaints, vendor changes, and unexpected output patterns.
• Define the route for risks, serious incidents, provider notifications, distributor or importer contacts, and authority escalation.
• Check whether workplace information duties, public-authority registration duties, DPIA support, or fundamental-rights assessment duties apply.
• Store evidence in one location with owner, date, decision, approval, open issues, and next review trigger.

For most SaaS teams, this checklist should be short enough to sit inside product review, vendor review, security review, or launch readiness. If it becomes a separate legal memo that product never sees, it will not control the live workflow.

Human oversight and competence

Article 26 makes human oversight a deployer responsibility when high-risk systems are used. The useful question is not only whether a human is "in the loop." It is whether the named person has enough competence, training, authority, and support to challenge the system's output.

For a SaaS team, that means documenting the oversight task in plain language. Who reviews the output? What are they expected to notice? What information do they need? Can they override the output? Can they pause the workflow? Are they trained on the system's limits? Do they know when to escalate to security, legal, compliance, product, or the vendor?

Weak oversight looks like a support agent clicking approve without time, context, or authority. Strong oversight looks like a defined review step with decision criteria, exception handling, training records, escalation routes, and evidence that the reviewer can disagree with the system.

Input data, logs, and monitoring

If the deployer controls input data, the team should ensure it is relevant and sufficiently representative for the intended purpose. In operational terms, this means deciding which data sources are approved, which fields are prohibited, whether data quality checks are needed, and how exceptions are handled. The review should also connect to privacy, security, and customer-contract controls, especially where personal data or customer confidential data enters the system.

Logs are another practical pressure point. The AI Act expects deployers of high-risk systems to keep automatically generated logs under their control for a period appropriate to the intended purpose, with a minimum of six months unless another applicable law requires otherwise. A SaaS team should know whether logs are in the vendor platform, internal telemetry, audit events, support tools, security logs, or product analytics. It should also know who can retrieve them during a customer review, incident investigation, or regulator request.

Monitoring should be tied to the system's real use. Track incidents, complaints, unusual output patterns, vendor change notices, override rates, failed human reviews, data-quality exceptions, and customer support signals. The monitoring plan can be proportionate, but it should exist before the first serious question arrives.

Risk, incidents, and suspension

Deployer obligations include action when the team has reason to consider that use in accordance with instructions may still present a relevant risk. In that case, the deployer may need to inform the provider or distributor and the market surveillance authority, and suspend use. If a serious incident is identified, the deployer must inform the provider and then other relevant actors and authorities as required.

This should not be improvised in a crisis. Define the trigger list before launch. Examples include unexpected harmful output, repeated override failures, unavailable logs, vendor withdrawal of documentation, evidence that users are relying on outputs outside the intended purpose, complaints from affected people, security events, or a model change that invalidates the original assessment.

The incident route should include who can pause the system, who contacts the vendor, who assesses legal reporting, who informs customer-facing teams, and who records the decision. This is where a clear compliance owner model prevents slow, informal escalation.

Fundamental rights and workplace duties

Some deployers must perform a fundamental rights impact assessment before using certain high-risk AI systems. Article 27 focuses on bodies governed by public law, private entities providing public services, and certain high-risk uses such as specific creditworthiness or insurance risk-assessment contexts. The assessment should describe the process, period and frequency of use, affected groups, risks of harm, human oversight measures, and mitigation or complaint mechanisms. It complements, rather than replaces, a GDPR data protection impact assessment where one is required.

Workplace use deserves separate attention. Before putting a high-risk AI system into service at the workplace, employer deployers must inform workers' representatives and affected workers where the AI Act duty applies. SaaS teams should turn that into a practical launch control: check the employee context, local labour rules, notice wording, delivery channel, approval owner, and evidence that the notice was given before use.

Common mistakes

The first mistake is assuming deployer obligations are only for customers. Internal AI use can create deployer questions too, especially in HR, support, finance, risk, security, and operations workflows.

The second mistake is treating vendor instructions as a PDF stored in a procurement folder. Instructions should become operating steps, acceptance criteria, training notes, monitoring checks, and evidence requirements.

The third mistake is assigning human oversight without authority. A reviewer who cannot challenge, pause, override, or escalate the system is not a meaningful control.

The fourth mistake is forgetting logs until an incident or customer review. Teams should know before launch whether logs exist, who controls them, how long they are kept, and how they can be exported.

The fifth mistake is mixing provider and deployer duties into one vague "AI Act review." Separate the role analysis, then connect the records so responsibilities do not fall between teams.

FAQ

What is the practical purpose of deployer obligations?

The practical purpose is to make sure the organisation using a high-risk AI system can show that it follows instructions, assigns competent human oversight, controls relevant input data, monitors use, keeps logs, handles incidents, and reassesses the workflow when facts change.

When does deployer obligations apply to SaaS teams?

They may apply when a SaaS team uses a high-risk AI system under its authority, including certain internal, customer-facing, employee, financial, risk, support, or operational workflows. The team should assess role and classification per workflow.

What should teams document or change first?

Start with one deployer-obligations record for each relevant AI workflow. Capture role, classification, provider instructions, oversight owner, input-data controls, logs, monitoring, incident route, notices, impact-assessment needs, evidence location, and reassessment triggers.

Is the vendor responsible for all deployer duties?

No. Vendor documentation is important, but the deployer controls how the system is used in its own workflow. The deployer still needs evidence that instructions were followed and that oversight, monitoring, logs, and escalation work in practice.

Who should own deployer obligations?

Product or operations should own the workflow facts, engineering should own technical integration and logs, security should own vendor and monitoring evidence, legal and compliance should own interpretation and evidence standards, and a named business owner should decide whether launch is blocked.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission AI Act Service Desk, Article 26: Obligations of deployers of high-risk AI systems.
• European Commission AI Act Service Desk, Article 27: Fundamental rights impact assessment for high-risk AI systems.
• European Commission AI Act Service Desk, Article 13: Transparency and provision of information to deployers.