EU AI Act SaaS Vendor Checklist 2026: questions before enabling AI features

Why this is suddenly a buying question

The EU AI Act is no longer an abstract policy headline for software buyers. Small teams now meet AI features inside CRMs, help desks, meeting tools, finance apps and HR workflows. The useful question is not whether a vendor says AI is included. It is whether the buyer can see what the feature does, where data goes, what can be disabled, and which answers are documented before real customer or employee data is connected.

Start with the feature inventory

Ask the vendor to list every AI feature that may touch your data: summaries, suggestions, scoring, routing, extraction, translation, search and chat. A product page that only says ‘AI-powered’ is not enough. You want names of features, admin switches, data sources, output locations and whether the feature is on by default. If the vendor cannot map features plainly, procurement should slow down.

Check training and retention language

Read the privacy, security and product documentation for training, human review and retention. The buyer-friendly wording is specific: customer content is or is not used for model training, logs are retained for a stated period, and admins can configure or disable features. Vague assurances are not proof of misuse, but they are a demo question that should be answered in writing.

Admin controls matter more than slogans

For most small teams, the practical risk is not science fiction. It is a teammate pasting sensitive notes into a summarizer, an AI feature exposing too much context, or an output being treated as a decision. Look for role-based access, audit logs, workspace-level controls, data region notes, export options and a documented way to turn features off during rollout.

Write a demo script before the call

Do not let the demo stay on a polished sample account. Ask the vendor to show a permission change, a deleted record, a sensitive note, a bad prompt, an export and an opt-out. Record which answers came from documentation and which came only from a salesperson. That distinction is boring, but it saves trouble later.

Separate regulated claims from useful workflow checks

Most Echoprysm readers are not classifying high-risk AI systems in a legal memo. They are choosing day-to-day software. Still, the regulation makes one habit valuable: ask who is responsible for the output, what human review is expected, and whether the vendor documents the limits. A tool that cannot explain its limits should not be rolled out to sensitive workflows first.

Red flags before uploading real data

Pause if the vendor has no public privacy route, no clear support contact, no admin documentation, no export story, no explanation of AI data use, or only broad marketing phrases. None of those gaps proves the software is unsafe. Together, they mean the team should test with dummy data and demand written answers before any real rollout.

A simple shortlist scorecard

Score each vendor on feature inventory, training language, retention language, admin controls, auditability, export path, support route and ability to disable AI features. Keep the scorecard as notes, not stars. The goal is to reduce uncertainty and make a defensible choice, not to crown a universal winner.

What this guide can and cannot verify

This guide uses public documentation and demo questions. It cannot verify private security implementation, actual support speed, hidden roadmap decisions or legal compliance for your organisation. It can help a buyer spot missing answers early and avoid treating ‘AI included’ as a sufficient evaluation.

Sources

Useful public references include the European Commission AI Act overview, vendor privacy documentation, security help centres and product admin guides. For exact vendors, add dated source links next to each claim so the page remains auditable after updates.