Reading Time: 5 minutes

If your automations can speak, score, or decide, they can also create compliance risk. In 2026, that risk is no longer theoretical. The EU AI Act is in force, and many obligations are expected to be enforceable from 2 Aug 2026, the 2026 enforcement deadline.

This EU AI Act checklist is written for automation teams shipping real workflows, not policy decks. It focuses on AI Act compliance requirements: what to inventory, how to classify, what evidence to keep, and how to run AI-enabled automation day to day.

This is operational guidance, not legal advice.

1) Start with an AI inventory, then perform risk classification fast

Most teams fail on the first step because they do not know what “AI” they run. Count everything, including vendor features and “small” models embedded in RPA steps.

Use a single inventory register for RPA, IPA, workflow rules, ML models, and LLM-based agents. If you need a quick triage, the EU AI Act Compliance Checker is a practical starting point for scoping, useful for SMEs and enterprise teams alike to meet EU AI Act standards.

Capture these fields per system (keep it lean at first): purpose, users, affected groups, decision impact, data types, model/provider, deployment locations, and fallback process.

A simple decision tree helps teams classify consistently:

  • If the system uses prohibited AI practices, stop and redesign.
  • If it makes or strongly influences decisions in listed high-risk areas (Annex III, for example employment or credit), treat it as high-risk AI systems.
  • If it interacts with people (chatbot, voice agent), apply transparency obligations.
  • If it is internal triage with low impact, keep it minimal-risk, but still govern it.

This table anchors common automation use cases against typical risk posture for 2026 planning:

Automation use case Likely AI Act risk tier What to do now (2026)
Customer support agent (LLM chatbot) Limited risk (transparency) Label AI interaction, train staff, log conversations and escalation outcomes
Document processing for contracts or claims Varies (can be high-risk by context) Classify by domain, document data quality, add human review for exceptions
Hiring workflow automation (CV screening, ranking) High-risk Build full evidence pack, human oversight, bias and performance testing
Fraud or risk scoring (financial services) High-risk Strong monitoring, explainability support, controls for drift and false positives
IT ticket triage and routing Often minimal risk Basic monitoring, change control, and security hardening

For timing, keep an internal one-page calendar. Many organisations track key dates using an external reference like the EU AI Act enforcement timeline, then map it to their release train.

Treat “classification” as a product decision. Once you tag a system as high-risk, you must be able to prove you run it safely.

2) High-risk AI systems evidence pack, what auditors will ask for

When a high-risk AI system is involved, your biggest job is not writing a policy. It is producing an evidence pack that shows controlled design, controlled data, controlled operations, controlled change, and addresses fundamental rights via a fundamental rights impact assessment.

Build one evidence pack per high-risk AI system, with links to artefacts stored in your normal tools (Jira, Confluence, SharePoint, GRC). Keep it versioned, because audits care about what was true at the time.

Minimum artefacts (templates you can copy)

Risk management system (one per system)

  • Scope and intended purpose, plus out-of-scope uses you block
  • Foreseeable misuse, failure modes, and harm analysis
  • Controls, residual risk decision, and sign-off owners

Data governance

  • Training and evaluation data sources, with provenance
  • Data quality checks, bias testing approach, and refresh plan
  • Retention, access controls, and data minimisation rationale

Technical documentation

  • System architecture, model details, and dependencies
  • Testing results (accuracy, robustness, security) and thresholds
  • Change log, release notes, and rollback plan

Human oversight

  • Who reviews, when they review, and how overrides work
  • Clear stop conditions (kill switch), plus manual fallbacks

Audit logs and traceability

  • Input, output, model version, prompts, and tool calls (where relevant), retained in audit logs
  • Reason codes for decisions, plus reviewer actions

Acceptance criteria examples for common automations

Use acceptance criteria to prevent “it works” deployments that later fail in production.

  • Customer support agent: AI responses show an “AI-assisted” label, escalation triggers fire within set confidence bounds, and high-severity intents route to a human within a defined time.
  • Document processing: extraction accuracy meets a threshold on a held-out set, low-confidence fields force manual review, and the system stores source-to-output trace links.
  • Hiring automation (automated decision-making): ranking never becomes the sole decision input, adverse impact testing runs each release, and candidates can request a meaningful explanation route.
  • Fraud scoring (automated decision-making): false positive rate stays within agreed limits by segment, analysts can inspect top drivers, and drift alerts trigger retraining review.
  • IT ticket triage: misroutes stay below a target, priority changes require confirmation, and suspicious prompts or injections get blocked and logged.

If you need a structured way to interpret “high-risk” in operational terms, keep a bookmarked explainer such as Pinsent Masons’ guide to high-risk AI systems for internal alignment across legal, risk, and engineering.

3) Vendor and general-purpose AI controls for automation stacks

Automation teams rarely build alone. You buy general-purpose AI models, copilots, OCR engines, and decisioning components. Your compliance posture depends on the behaviour of AI providers and deployers, so procurement needs more than a security questionnaire.

Add a short AI supplier addendum aligned with the EU AI Act and request evidence of conformity assessments early, before a pilot becomes a dependency.

Vendor questionnaire items (high-signal, low-bloat)

  • What is the system’s intended purpose, and what uses are prohibited?
  • Which parts are general-purpose AI, and which are task-specific?
  • What documentation do you provide for logs, testing, and model changes?
  • How do you support human oversight (override, review queue, confidence scores)?
  • What is your incident notification process, and what timelines do you commit to?
  • How do you handle data retention, training reuse, and customer data isolation?

Policy bullets you can adopt for internal automation delivery

  • Do not deploy AI to make employment decisions without human review.
  • Do not allow an LLM agent to execute payments or user access changes without approval.
  • Log model version and prompt context for any user-impacting automation.
  • Block unsupported uses by design (UI, API, and role permissions).
  • Require release gates for changes that affect decision logic or training data.

For teams building formal management systems, a readiness approach that maps artefacts to an evidence pack can help, such as Glocert’s EU AI Act readiness assessment guide.

4) Run AI-enabled automation safely, monitoring KPIs and incident response

Compliance is ongoing operations. Controls that look good on paper fail when alerts are noisy, owners are unclear, or humans stop reviewing.

Start post-market monitoring with a small KPI set that matches your risks. Track them weekly for high-risk systems, and at least monthly for others.

Here is a compact KPI table you can lift into an ops dashboard:

KPI How to measure Typical trigger
Human review rate % of in-scope decisions reviewed Drops below agreed minimum
Performance and drift Accuracy, error rate, stability by segment, bias detection and mitigation Material deviation from baseline
Override outcomes % overrides, plus reason codes Spike in overrides or repeats
Incident response time Time to triage and contain Breaches internal SLA
Data quality failures Missing fields, outliers, schema breaks Threshold breach after release

Incident runbook (six steps that work under pressure)

  1. Triage: confirm impact, scope, and affected users.
  2. Contain: pause the automation or switch to manual mode.
  3. Preserve evidence: snapshot logs, prompts, model versions, and configs.
  4. Correct: fix root cause, then validate with model evaluation and targeted tests.
  5. Communicate: notify internal owners, vendors, and regulators when required.
  6. Prevent: update controls, thresholds, and training for responders.

Keep your AI literacy training practical. Train reviewers on what the system can fail at, not on theory. Also rehearse “stop” decisions, because the hardest moment is choosing downtime over harm.