High-Risk AI Systems Checklist for Founders and Compliance Leads

High-risk AI systems need a checklist because the hard part is rarely understanding the phrase. The hard part is proving that the team has reviewed the right use case, assigned the right owners, triggered the right controls, and kept enough evidence to answer a customer, board, auditor, or regulator without rebuilding the story from memory.

Under the EU AI Act, high-risk classification can arise through regulated product routes or through listed use cases in Annex III. The European Commission's draft classification guidelines, published in May 2026, are useful implementation material for applying Article 6, but the regulation remains the source of legal obligation. For SaaS teams, the checklist below turns that structure into operating questions.

Use this checklist alongside AI governance expectations for SaaS vendors, the EU AI Act guide for SaaS providers, questions before adopting AI tools internally, and why AI regulation is moving faster than many founders expect.

1. Confirm the AI use case exists

Start by confirming whether the workflow actually uses AI. Avoid vague labels like automation, intelligence, insight, scoring, recommendation, assistant, classifier, or optimization. They may describe AI, but they do not answer the classification question.

Capture:

• system name and product area;
• business purpose and intended use;
• model, vendor, API, or internal component involved;
• whether the output is a score, ranking, recommendation, classification, prediction, summary, decision, or action;
• who sees the output and what they do with it;
• whether the feature is customer-facing, employee-facing, internal, or embedded in another product.

If there is no AI system, record that conclusion and close the high-risk checklist. If there is AI, move to classification.

2. Identify your AI Act role

Role analysis matters because obligations can differ for providers, deployers, importers, distributors, product manufacturers, and other actors in the AI value chain. A SaaS company may be a provider for one system, a deployer of a vendor system for another, and a reseller or integrator in a third workflow.

Record:

• who develops or substantially modifies the system;
• who places it on the EU market or puts it into service;
• who controls the intended purpose;
• who controls customer configuration;
• whether a vendor provides instructions for use, technical documentation, or AI Act role statements;
• whether the customer is expected to operate the system as deployer.

Do not assume that vendor-provided AI removes your responsibility. Your deployment, configuration, customer promises, and use of outputs still matter.

3. Screen the regulated product route

The first high-risk route concerns certain regulated products. An AI system can be high-risk when it is intended to be used as a safety component of a product, or is itself a product, covered by Union harmonisation legislation listed in Annex I, and the product or AI system must undergo third-party conformity assessment.

Ask:

• Is the AI connected to medical devices, machinery, transport, aviation, radio equipment, toys, lifts, industrial equipment, or another Annex I product environment?
• Does the AI support safety-relevant behaviour, diagnostics, monitoring, control, warning, certification, or failure detection?
• Could failure or malfunction endanger health, safety, persons, property, or regulated product operation?
• Is a third-party conformity assessment required for the product or AI system?
• Has product counsel or the relevant regulatory owner reviewed the route?

Many ordinary B2B SaaS tools will not enter this route. But teams selling into health, industrial, robotics, mobility, infrastructure, or device markets should not dismiss it without evidence.

4. Screen Annex III use cases

The second high-risk route is often more relevant for SaaS. Annex III covers listed areas where AI can affect rights, opportunities, access, safety, or important life outcomes.

Ask whether the system is intended for, or could be configured for:

• biometric identification, biometric categorisation, or emotion recognition in listed contexts;
• critical infrastructure management or safety;
• education, vocational training, admission, assessment, or learning outcomes;
• recruitment, candidate filtering, employment decisions, task allocation, performance evaluation, or worker management;
• access to essential private or public services;
• creditworthiness or insurance risk assessment in relevant contexts;
• law enforcement, migration, asylum, border control, administration of justice, or democratic processes;
• ranking, scoring, filtering, or eligibility decisions that materially affect people.

Classification follows intended purpose and concrete use. The same model family may be low risk in an internal drafting assistant and high risk in an employment screening workflow.

5. Check customer configuration risk

SaaS products are often configurable. A feature that looks low risk in the default product may become sensitive when a customer uses it to rank applicants, score workers, assess students, route vulnerable users, or influence access to important services.

Ask:

• Can customers choose the data fields, scoring criteria, rules, thresholds, or output labels?
• Can customers use the feature in employment, education, credit, insurance, healthcare, essential services, or public-sector workflows?
• Does the product UI invite sensitive uses?
• Are sensitive configurations technically blocked, contractually restricted, or only discouraged in documentation?
• Is there a review gate before enabling high-risk configurations?

If the team cannot control or detect sensitive configurations, that uncertainty belongs in the risk record.

6. Assign owners and gates

High-risk AI work fails when it has no owner. Assign ownership before writing policies.

At minimum:

• product owner for intended purpose, configuration, release scope, and customer commitments;
• engineering owner for architecture, logging, versioning, fallback, and technical controls;
• legal or compliance owner for classification rationale, sources, approvals, and review triggers;
• security or risk owner for vendor evidence, access controls, monitoring, resilience, and incident escalation;
• customer-facing owner for approved statements, limitations, and questionnaire responses.

Then set gates. A missing classification should block release in sensitive domains. A likely high-risk classification should trigger deeper review and launch conditions. A documented no-high-risk conclusion should allow delivery to continue, but it should remain reviewable.

7. Define minimum evidence

Evidence should show what the team reviewed, why it reached the conclusion, what controls followed, and when the decision will be reopened.

Keep:

• intake form and system description;
• role analysis;
• regulated product screen;
• Annex III screen;
• intended-purpose statement;
• affected-person analysis;
• data categories and data-flow note;
• vendor documentation and instructions for use;
• classification conclusion, reviewer, date, rationale, and sources;
• launch decision and approval conditions;
• controls triggered and owner;
• next review date or trigger.

For likely high-risk systems, add risk-management records, data governance decisions, technical documentation owner, testing evidence, human oversight design, logging approach, monitoring plan, incident path, conformity-assessment route, and registration decision where relevant.

8. Translate controls into product work

Controls should live where delivery happens.

Turn risk management into a feature risk record. Turn data governance into rules for training, validation, testing, input, customer, prompt, and feedback data. Turn technical documentation into a maintained evidence folder. Turn transparency into customer instructions and internal playbooks. Turn human oversight into a real review process with authority to intervene. Turn monitoring into metrics that an owner reviews on a cadence.

The Commission's AI Act standardisation work is relevant because harmonised standards are being developed for areas such as risk management, dataset governance, record keeping, transparency, human oversight, accuracy, robustness, cybersecurity, quality management, and conformity assessment. Until standards and tools are settled, keep the reasoning and evidence clear enough to adapt.

9. Reopen the decision when facts change

Classification is not permanent. Reopen the checklist when:

• the intended purpose changes;
• a new model, vendor, or version is introduced;
• human review is reduced or removed;
• customers can configure sensitive workflows;
• a new customer segment or jurisdiction is added;
• data categories change materially;
• monitoring shows harmful, biased, unreliable, or unexpected outputs;
• new Commission guidance, standards, or internal risk appetite changes the analysis.

This is where many teams lose control. They classify once, then allow product, vendor, and customer use to drift away from the original facts.

Common mistakes

The first mistake is treating high-risk status as a brand label. Classification follows intended purpose and actual use, not the name of the model.

The second mistake is relying only on vendor assurances. Vendor evidence matters, but your deployment and customer commitments still matter.

The third mistake is assuming human review always solves the issue. Human oversight may be required, but it does not automatically remove high-risk status.

The fourth mistake is forgetting customer configuration. Configurable SaaS can create high-risk exposure even when the base feature seems ordinary.

The fifth mistake is scattering evidence. If product, legal, security, engineering, and sales each hold fragments, the company will struggle to answer consistently under pressure.

FAQ

What should teams understand about High-Risk AI Systems?

Teams should understand when high-risk AI systems may apply, what operational changes the classification triggers, and what evidence shows the work is actually happening.

Why does High-Risk AI Systems matter in practice?

It matters because high-risk classification can affect product design, launch gates, customer documentation, vendor review, monitoring, incident response, and audit evidence.

What is the biggest mistake teams make with High-Risk AI Systems?

The biggest mistake is treating high-risk AI as a one-time legal interpretation instead of a repeatable workflow with owners, triggers, evidence, and escalation paths.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission draft guidelines on the classification of high-risk AI systems.
• European Commission AI Act FAQ on high-risk AI systems.
• European Commission guidance on AI Act standardisation.