EU AI Act Compliance for AI Workflow Automation

The EU AI Act is a risk-based regime, so what an AI workflow must do depends on the tier its use case lands in. Routine back-office automation such as data entry, file routing, and spam filtering is largely unregulated. Chatbots and agents that interact with people must disclose they are AI. Workflows that decide about people in hiring or credit scoring are high-risk and need human oversight plus automatic logging of every input, step, and output.

TL;DR

• Obligations follow the use case: prohibited, high, limited, or minimal risk.
• Annex III areas, such as employment and creditworthiness, are the starting point for a high-risk label. Talking to people directly triggers the Article 50 disclosure duty.
• High-risk steps need human oversight under Article 14 and automatic event logging under Article 12.
• Auditors need each output traced to its source data, the rule applied, and a named reviewer.
• Deterministic RPA scripts sit outside the Act. LLM and agent steps inside the same workflow are in scope.

The request usually arrives as a spreadsheet. Internal audit wants every workflow where an AI model now drafts, scores, or routes something, and the audit committee wants to know which of those the EU AI Act touches. Over the past year, LLM steps found their way into procurement approvals, HR onboarding exception routing, IT service requests, and finance approvals, mostly added by the teams who run those processes. Answering the request is a classification exercise done step by step, followed by proof that each high-risk step has a person in charge and a record an auditor can re-perform.

1. Does the EU AI Act apply to your AI workflow?

Regulation (EU) 2024/1689 reaches a US company once its AI system is placed on the EU market or its output is used in the EU. A Chicago-run hiring workflow that screens applicants for a Dublin office is in scope. Two questions then set your exposure: what role you play, and whether the step is AI at all.

Are you a provider or a deployer?

A provider develops an AI system, or has one developed, and places it on the market under its own name. A deployer uses an AI system under its own authority. Most companies that add an LLM step to a vendor approval are deployers. The duties for general-purpose AI models sit with the model’s provider, which leaves the team calling its API with deployer duties. You take on provider duties if you put your own name on a high-risk system or change its intended purpose into a high-risk one.

Does the workflow cover RPA steps, or only LLM and AI agent steps?

Scope is decided step by step. Article 3(1) defines an AI system as one that infers from its input how to generate outputs. A deterministic RPA script that copies invoice fields into SAP following fixed rules does not infer, so it sits outside the Act. An LLM that reads the same invoice and decides which approver gets it does infer, so it is in scope. One procurement workflow often contains both, which is why the classification in the next section works on individual steps.

2. How do you classify each workflow step by risk tier?

Classify by asking what the step decides and about whom. The four tiers, in the order the Act sets them:

What is the step test?

Run these questions against every step that calls a model:

1. Does the step infer an output, or does it follow fixed rules? Fixed rules put it outside the Act.
2. Does it make or shape a decision about a person in an Annex III area, such as employment or creditworthiness? If yes, start from high-risk.
3. Does a person interact with it directly, as with a chatbot or an agent that sends messages? If yes, the transparency duty applies.

Article 6(3) carves out Annex III systems that only perform a narrow procedural or preparatory task, where the decision stays human and the system does not profile people. If you rely on the carve-out, write down your reasoning.

The table records judgments, and a regulator will ask for your reasoning before it accepts your label. The use case decides the tier.

3. Which controls does each tier require?

Human oversight and logging are the two controls auditors test first. High-risk steps carry the full set:

• Human oversight: A named person reviews, overrides, interrupts, or stops a high-risk step before it takes effect (Article 14). Design it as human in the lead: the reviewer holds the decision and the AI prepares it.
• Automatic logging: The system records events over its lifetime, covering inputs, steps, and outputs. Every human and AI action carries context, metadata, and a timestamp (Article 12).
• Continuous risk management: Risk assessment runs for the life of the system. A changed model, prompt, or data source triggers a fresh evaluation (Article 9).
• Data governance: Training, validation, and input data must be relevant, representative, and checked for errors and bias (Article 10).
• Technical documentation: A written description of the system, its purpose, and its testing exists before the step goes live (Article 11).
• Transparency: Anyone talking to a chatbot or receiving output from an agent is told it is AI (Article 50). This applies at the limited tier too.
• Limits of logging: A complete log proves what happened, and the reason it happened still has to be recorded, which is where auditors push.

Providers of high-risk systems also register them, run a quality management system, and report serious incidents. Certain deployers, including those scoring credit, complete a Fundamental Rights Impact Assessment.

Compliance tooling clusters around these controls. Vanta and OneTrust are compliance-automation tools that track policies and controls across a program, and KNIME is a visual analytics platform for data workflows. Each covers part of the record, and the tier decision stays with you.

4. AI workflow automation explainability for auditors: what do they need?

To an auditor, explainability means one test. Someone outside the build team traces why and how an automated decision was reached, from the source data through the rule or logic applied to the logged output, and arrives at the same answer. A log that only records outcomes fails that test, however complete it is. Internal auditors, external auditors, and regulators all run versions of it.

Which pillars make an AI workflow explainable?

• Source-to-output lineage: The record shows which data was pulled, how it was mapped to each field, and which output resulted.
• Visible decision logic: The rule, prompt, or logic that fired is recorded next to the result.
• Attributed audit trail: Each action is recorded with who or what took it and when, and AI actions are logged separately from human actions.
• Human review checkpoints: Steps with a high error cost, such as financial reporting entries or legal review, get a named accountable reviewer every time.
• Rationale and confidence score: The AI step attaches a plain-language rationale and a confidence score to every result.
• Tamper-evident, reproducible record: Logs cannot be edited after the fact, and versioned prompts and models let the auditor re-run the step.

What will an auditor ask, and where is the evidence?

How do PCAOB, SOX, and AI frameworks apply?

PCAOB amendments to AS 1105 (audit evidence) and AS 2301 (responses to risk) on technology-assisted analysis apply to audits of fiscal years beginning on or after 15 December 2025, so calendar-year companies meet them in their 2026 audits. Under SOX, an AI step inside a finance approval is a control or part of one, so it gets tested like one. AICPA AU-C 500 sets the equivalent evidence standard for non-issuer audits. NIST AI RMF and ISO 42001 give auditors a structure for reviewing AI risk across a program. SHAP and LIME attribute a single model prediction to its input features, which explains the model and leaves the workflow around it to the audit trail.

Where does AI-assisted audit evidence fail?

• Equal weighting: An AI reviewer gives every exception the same weight, so a material control gap sits beside a missing signature.
• Phantom controls: The output cites a control that does not exist, and nobody checks it against the control library.
• Over-reliance: Auditors accept the AI’s default thresholds and sampling without setting their own.

Sample evidence record: one AI-assisted vendor approval

The worked case is a vendor approval in which an AI step scores a new supplier’s documents and a procurement manager decides. It is minimal-risk: vendor approval is outside Annex III and the decision stays human. The record still carries everything an auditor needs, because the same structure scales up to a high-risk step.

To re-perform it, the auditor works through these steps:

1. Pull the record by instance ID and confirm it has not been altered.
2. Retrieve the source records from the system of record and match them to the logged inputs.
3. Confirm the rule or prompt version and the model version from deployment history.
4. Re-run the step, or recompute the result, and compare the output.
5. Check that the reviewer’s role permitted the approval and that the timestamps run in order.
6. Log any difference as an exception with its weight, so one gap does not fail the whole record.

5. When do the EU AI Act deadlines apply, and what are the penalties?

As of October 2026, the dates for workflow teams under the amended timeline are:

• 2 August 2026: Article 50 transparency duties apply, covering chatbot and agent disclosure.
• 2 December 2027: Annex III high-risk obligations apply under the Digital Omnibus (Regulation (EU) 2026/1744), covering hiring, HR, and credit-scoring workflows.
• 2 August 2028: Obligations apply to high-risk AI embedded in products already regulated under EU product law.

Penalties under Article 99 of the AI Act reach €35 million or 7 percent of worldwide annual turnover for prohibited practices. Breaches of high-risk obligations reach €15 million or 3 percent. The gap between those figures reflects how the Act ranks harm. The cheapest point to fix a classification error is before December 2027, while your high-risk steps are still being designed.

6. How does a governed application platform produce this evidence?

Auditors ask for evidence that mostly comes from the approval layer around the model. Kissflow is an AI-powered enterprise application platform where business teams and IT build, automate, and govern their core work, driven by business logic, not code. For an EU AI Act review, it is the governed execution and exception layer around SAP, Oracle, Salesforce, and Workday, where vendor approvals, onboarding exceptions, and finance sign-offs get decided and recorded.

How its approved capabilities map to the controls:

• Attributed audit log: Every action is timestamped and attributed, which gives the Article 12 record a named actor for each step.
• One log for AI and people: AI changes use the same audit log as manual edits, so an auditor reads one record for both.
• Segmented layer: Kissflow operates in the business-process layer, segmented from core systems, so the approval record sits beside the system of record.
• Go-live control: An admin controls what goes live, which gives an auditor one owner for rule changes.
• Inspectable AI output: AI Builder, generally available as of May 2026, generates blueprints: structured metadata that describes business logic. Every artifact is a standard Kissflow component a developer can open and read.
• Limitation: Kissflow does not assign your risk tier or explain a model’s internal behavior the way SHAP does. Classification, risk assessment, and EU AI Act compliance responsibility stay with your organization as the deployer.

Its certifications are SOC 1 Type II, SOC 2 Type II, SOC 3, ISO/IEC 27001, HIPAA, GDPR, and CCPA, and data residency is available in the US, EU, APAC, and Oceania. These certify security and privacy controls. EU AI Act conformity is a separate assessment.

See how AI Builder generates an approval app from a requirements document.

Which tier is your workflow in?

Classify one step at a time. The companies that struggle when Annex III duties arrive are likely to be the ones that cannot show why they labeled a step minimal, who reviewed it, or which prompt version ran on a given day. The tier table, the step test, and the evidence record above are the same discipline applied at three depths.

Your next step is a single list: every workflow step that calls a model, with what it decides and who it affects. Then place each one. A step that decides about a person’s job or credit is high-risk. A step that talks directly to a person needs an AI disclosure. A step that moves documents, routes tickets, or sorts invoices is minimal. A script that follows fixed rules sits outside the Act.

Build your first audit-ready approval workflow with AI Builder and see every AI step and reviewer decision in one audit log.

Frequently asked questions

What is the EU AI Act about?

The EU AI Act (Regulation (EU) 2024/1689) is the European Union’s law on artificial intelligence. It sets duties for organizations that build AI systems (providers) and those that use them (deployers) whenever a system reaches the EU market or its results are used there, with the duties phased in between 2025 and 2028.

What should we do when a model, prompt, or data source in a high-risk workflow changes?

Run a fresh risk evaluation, and check whether the change alters the system’s intended purpose. Under Article 25, a deployer that makes a substantial modification to a high-risk system, or repurposes a system for a high-risk use, takes on the provider’s duties, which include documentation and conformity assessment.