Common Deployer Obligations Mistakes SaaS Teams Still Make

The most common deployer obligations mistake is treating the EU AI Act as a label someone can assign once, instead of a workflow the team must operate every time a relevant AI system is used. For SaaS teams, the practical work is to know when the company uses an AI system under its authority, whether that use is high-risk, which provider instructions apply, who performs human oversight, which logs are controlled, how incidents are escalated, and where the evidence lives.

Article 26 of the AI Act is the anchor for deployers of high-risk AI systems. It requires deployers to use high-risk systems according to the instructions for use, assign human oversight to competent people with training, authority, and support, manage input data where the deployer controls it, monitor operation, keep automatically generated logs under their control for the required period, and act when risk or serious incidents appear. Article 27 can also require a fundamental rights impact assessment for some deployers and use cases. Article 13 matters because provider instructions are one of the main inputs deployers need in order to operate the system correctly.

The mistake is not that SaaS teams ignore these words. The mistake is that they leave them in a legal note while product, security, support, operations, and sales keep moving with unclear responsibilities. Here are the common mistakes that still show up, and the controls that make them easier to avoid.

This sits beside the wider EU AI Act overview for SaaS providers, the way AI governance is changing SaaS vendor expectations, the questions teams should ask before adopting new AI tools internally, and the AI controls buyers increasingly ask about. Deployer obligations are not a separate legal island. They are one operating track in the broader AI governance system.

Mistake 1: Assuming deployer obligations only belong to customers

Many SaaS companies think about deployer obligations only when customers use their product. That misses internal use. A SaaS company can be a provider for one AI feature, a deployer for an internal AI workflow, and both in different parts of the same commercial relationship.

Internal examples can include AI used for support triage, HR screening, employee performance signals, fraud prioritisation, financial risk workflows, complaint routing, security investigation, or customer-health scoring. Not every internal AI use is high-risk, but the role question should still be asked per workflow. If the company uses the system under its own authority, the deployer track may be relevant.

The fix is to add a deployer role field to the AI inventory. Each AI workflow should show whether the company is provider, deployer, both, or neither for that use. The answer should not be copied from vendor status. It should be based on who controls the actual use.

Mistake 2: Treating vendor documentation as the control

Provider instructions are essential, but they are not the deployer's operating control by themselves. Article 13 expects high-risk AI systems to come with instructions that are relevant and understandable for deployers. Article 26 then expects deployers to use the system according to those instructions.

The common failure is storing the provider PDF in a procurement folder and calling the issue closed. That does not show that the instructions were translated into product behaviour, internal SOPs, support scripts, training, monitoring, access rules, or release criteria.

The fix is to create an instruction-to-control map. For each material instruction, record the operating step, owner, evidence, review point, and exception path. If the provider says trained staff must review outputs, the deployer record should show who is trained, what they review, how they override, and where review evidence is stored.

Mistake 3: Assigning human oversight without authority

Human oversight is often described too casually. A team may say a person is "in the loop" because someone sees the output before action is taken. That is weak if the person lacks competence, time, context, authority, or support.

Article 26 is more specific. The natural persons assigned to oversight need the necessary competence, training, authority, and support. In practice, that means the reviewer must understand the system's intended use and limits, know what failure patterns to watch for, have a route to escalate concerns, and be able to challenge, override, pause, or reject the output where the workflow requires it.

The fix is to define the oversight task like an operational control. Name the role, training requirement, review criteria, escalation path, override authority, evidence artifact, and backup owner. If oversight is impossible at the speed or volume of the workflow, do not pretend it exists. Redesign the workflow or lower the risk before launch.

Mistake 4: Forgetting input data until after launch

Where the deployer controls input data, Article 26 expects that data to be relevant and sufficiently representative in view of the intended purpose. SaaS teams often remember this only after the system behaves badly, a customer challenges an output, or a privacy review discovers sensitive fields flowing into a model.

Input data control is not only a data science question. It also touches product design, permissions, customer configuration, data retention, privacy, security, and contractual boundaries. If the workflow allows unsupported data, stale data, unapproved fields, or customer content outside the intended purpose, the deployment record is incomplete.

The fix is to define allowed data sources and prohibited inputs before use. Record which fields are permitted, which data quality checks are needed, whether customer or employee data can be entered, what happens when data is missing, and who approves changes to the input set.

Mistake 5: Waiting for an incident to understand logs

Logs are one of the easiest controls to postpone and one of the hardest to reconstruct. Article 26 requires deployers of high-risk AI 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 provides otherwise.

The common mistake is discovering too late that logs sit inside a vendor console, are not exported, are overwritten quickly, omit the events needed for investigation, or are not mapped to the customer, user, workflow, or decision at issue.

The fix is to decide the logging model before launch. The record should say which logs exist, who controls them, retention period, export method, access owner, incident use, customer review use, and any legal hold or deletion interaction. If the team does not control logs, the risk should be visible and vendor commitments should be reviewed.

Mistake 6: Mixing deployer, provider, transparency, and privacy work

AI governance becomes confusing when every question is placed in a single "AI Act review." Deployer obligations are one track. Provider obligations, transparency duties, GDPR analysis, security review, vendor risk, accessibility, and customer documentation can all be relevant, but they answer different questions.

When teams mix them, ownership becomes vague. Product assumes legal is handling AI Act risk. Legal assumes security has vendor evidence. Security assumes product owns output behaviour. Sales assumes the trust answer is approved. Nobody owns the deployer record.

The fix is to separate the decision tracks and connect them through one workflow record. The deployer section should answer role, classification, instructions, oversight, input data, monitoring, logs, incident route, notices, and reassessment. Other sections can link privacy, transparency, vendor risk, and customer commitments without blurring the duties.

Mistake 7: Treating fundamental rights impact assessment as a generic DPIA

Some teams hear "impact assessment" and assume an existing privacy DPIA covers everything. Article 27 is more specific. It applies to certain deployers and high-risk AI uses, and it requires assessment of the process, period and frequency of use, affected groups, risks of harm, human oversight measures, and measures such as internal governance and complaint mechanisms. It can complement a GDPR DPIA where the same work covers part of the requirement.

The mistake is either ignoring Article 27 entirely or treating it as a duplicate privacy form. That leaves teams without a clear answer when a public-sector customer, financial-services workflow, insurance-related use case, or other sensitive deployment raises fundamental rights questions.

The fix is to add a short Article 27 screen to deployer intake. Ask whether the deployer type and use case fall into scope, whether a DPIA already exists, which elements are covered, which are missing, and who approves the assessment before first use.

Mistake 8: Failing to define suspension and escalation triggers

Article 26 requires action when the deployer has reason to consider that use according to instructions may still result in a relevant risk. The deployer may need to inform the provider or distributor and the relevant market surveillance authority, and suspend use. Serious incidents also require escalation.

This is a poor thing to design during a crisis. If no one knows who can pause the workflow, who contacts the provider, who assesses reporting, or who informs customer-facing teams, the organisation loses time exactly when the evidence needs to be clean.

The fix is to predefine triggers. Examples include unexpected harmful output, repeated override failures, unavailable logs, vendor withdrawal of documentation, complaints from affected people, material model change, use outside intended purpose, security incident, or evidence that staff cannot perform oversight. Attach each trigger to an owner and first action.

Mistake 9: Letting customer answers drift from internal evidence

Enterprise buyers increasingly ask how AI-enabled SaaS products are governed. They may ask about feature inventory, data boundaries, human review, vendor oversight, monitoring, incident handling, and role analysis. If the customer answer is not connected to the deployer record, the team can overpromise or contradict itself.

The fix is to build customer-facing answers from evidence. A trust-centre note, security questionnaire response, or sales enablement answer should point back to the same record used by product, security, legal, and compliance. If the team cannot prove a control internally, it should not promise it externally.

What SaaS teams should do next

Start with one workflow that is already live, close to launch, or creating difficult customer questions. Build a deployer-obligations record with the AI system, intended purpose, provider instructions, role conclusion, high-risk screen, oversight owner, input-data controls, logs, monitoring, incident route, notices, impact-assessment screen, evidence location, and reassessment triggers.

Then connect the record to normal delivery. Product discovery should ask whether AI is used under the company's authority. Vendor review should collect instructions and log commitments. Security and engineering should define evidence, monitoring, and access. Legal and compliance should approve role and assessment conclusions. Release readiness should confirm that owners, controls, and evidence exist before launch.

Deployer obligations become manageable when they are translated into owners, triggers, and evidence. They become expensive when they stay as a legal interpretation until a customer, audit, incident, or regulator asks what actually happened.

FAQ

What should teams understand about Deployer Obligations?

Teams should understand when deployer obligations may apply, what operational changes are required, and what evidence proves that instructions, oversight, input-data controls, logs, monitoring, and escalation work in practice.

Why does Deployer Obligations matter in practice?

Deployer Obligations matters because the deployer controls the live use of the AI system. Even strong provider documentation does not prove that the SaaS team followed instructions, assigned competent oversight, monitored operation, or handled incidents correctly.

What is the biggest mistake teams make with Deployer Obligations?

The biggest mistake is treating deployer obligations as a one-time legal interpretation instead of a repeatable workflow with owners, triggers, evidence, review points, and escalation paths.

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.