Celonis Under the EU AI Act: Process Mining Sits at Minimal-Risk

For practically every company, Celonis is minimal-risk under the EU AI Act. Process mining reconstructs how work actually flows through your systems — where orders stall, where invoices get reworked, where a procurement cycle leaks time. That is analytics over your own operational data, not a decision about any person. Beyond the general Article 4 AI-literacy duty, there are no mandatory obligations under Regulation (EU) 2024/1689 for running it.

The verdict only moves if you wire the output of a Celonis insight into a decision that the EU AI Act lists as high-risk — and for the kind of work Celonis is built for, that almost never happens. The more pressing obligation usually comes from the layer below the AI Act: GDPR data governance over the event logs Celonis ingests.

This page sets the default, names the narrow condition that could flip a deployment, and shows why the data-protection check comes first.

---

What Celonis actually does

Celonis is a process intelligence product. Its core is object-centric process mining: it reads event logs from your ERP, CRM and other systems — timestamps of each step a transaction passed through — and rebuilds the real, end-to-end process as a model you can interrogate. On top of that sit AI features: the Process Intelligence Graph that gives a "digital twin" of operations, AgentC-style agents and Process Copilots that answer questions in natural language and surface where a process deviates from its ideal path.

What all of this analyses is the process, not people. Order-to-cash cycle time, accounts-payable rework rates, supply-chain bottlenecks, procurement maverick spend. Producing a model of how invoices move, or alerting you that a process step is slowing down, is minimal-risk. It touches no Annex III area, triggers no transparency duty toward a third party, and carries no mandatory requirement under the Act beyond Article 4: taking measures to support the AI literacy of the staff who use it.

The AI layer runs on general-purpose AI (GPAI) models. Those carry their own obligations under Chapter V (Article 53) — but those duties sit with the model provider, not with you as a deployer of Celonis. Your classification depends entirely on what you do with the output.

The default and the (rare) flip

Under Article 6 and Annex III, an AI system is high-risk when it is used in one of the eight listed areas. For Celonis, the realistic ways a deployment could reach there are narrow:

• Annex III point 4 — employment and worker management: if you mined individual-employee activity to evaluate worker performance or behaviour and that evaluation drove decisions on promotion, allocation or termination, that specific deployment would be an employment-decision system. Mining the process a team runs is analytics; scoring the people to decide their treatment is an assessment.
• Annex III point 5(b) — creditworthiness: if a Celonis-derived signal materially drove whether a person obtained credit, that deployment would touch point 5(b). This is far outside the product's normal remit, but the principle holds — the use, not the tool, decides.

For the overwhelming majority of Celonis deployments — process efficiency, finance operations, supply chain — none of this applies, and the verdict stays minimal-risk. The decisive question is not "is Celonis high-risk?" It is: does the output of this analysis drive a decision about a person in an Annex III area? Aggregate process analytics across thousands of transactions is not a decision about any individual.

Two guardrails:

• Aggregate process metrics are not decisions about individuals. A rework rate across an AP process is analytics. A performance score attached to one named employee that gates their promotion is an assessment.
• A human reading the analysis and deciding is not the AI deciding. Where Celonis merely informs a human who makes the call, the Article 6(3) filter may apply — an Annex III system is not high-risk where it performs a narrow task or merely supports, without replacing or unduly influencing, a human assessment. Document it — and remember any system that profiles natural persons is always high-risk regardless of the filter.

The GDPR layer comes first

For Celonis, the data-protection question is usually the live one — because event logs frequently contain personal data. A purchase-order log carries the names of the people who raised and approved each step; an HR-process log is personal data end to end.

• Lawful basis and purpose limitation (GDPR Articles 5–6). Mining event logs that identify employees needs a lawful basis and must stay within the purpose for which the data was collected. Repurposing operational logs to monitor individual staff productivity can exceed that original purpose — a classic compliance trap with process mining.
• Data minimisation (GDPR Article 5(1)(c)). Pseudonymising or aggregating the user fields in event logs, where the analysis does not need named individuals, is the standard control — and it also keeps the deployment safely on the minimal-risk side of the AI Act.
• Solely automated decisions (GDPR Article 22). If a Celonis-driven output led to a decision with legal or similarly significant effects on a person without meaningful human involvement, GDPR Article 22 restrictions apply — separate from any AI Act duty.
• DPIA (GDPR Article 35). Systematic monitoring that could profile staff may require a Data Protection Impact Assessment under GDPR — distinct from the AI Act's Fundamental Rights Impact Assessment (Article 27).

Treat the GDPR governance of your event logs as the first gate. In practice it is where almost all of the real Celonis compliance work lives.

Worked example: Veldhoven Logistiek BV, a 300-person 3PL

Veldhoven Logistiek BV, a Dutch third-party logistics firm, ~300 employees, ~€48M turnover, deploys Celonis across operations. Two deployments, two answers.

Deployment one: order-to-cash mining. The operations team mines the order-to-cash process to find where shipments stall and invoices get reworked, with Process Copilot answering questions in natural language. The analysis is over the process — thousands of transactions in aggregate. No individual is being assessed by the AI; managers read the findings and change the workflow. Minimal-risk under the AI Act. The event logs still carry personal data, so the GDPR controls — lawful basis, minimisation, pseudonymising the user fields — apply.

Deployment two: warehouse-worker performance scoring. A manager proposes mining individual pickers' activity logs to produce per-worker productivity scores that feed shift allocation and performance reviews. This would sit in Annex III point 4 — worker management. Because the output would materially drive employment decisions about named people, that deployment would be potentially high-risk; the Article 6(3) filter would only help if a manager genuinely decided on independent judgment, and per-worker scoring profiles individuals, which defeats the filter outright. It would also raise sharp GDPR Article 22 and Article 35 issues. Veldhoven, running it under its own authority, would be the deployer (Article 26); high-risk deployer duties would be due by 2 December 2027 under the Digital Omnibus, Regulation (EU) 2026/1744, in force since 27 July 2026 (the original date was 2 August 2026).

Same product, same company — the second design would create a high-risk programme and a serious GDPR exposure, while the first does neither. The fix for the second is usually to keep the analysis at process level and not score individuals at all.

On exposure: a deployer breach of the high-risk requirements sits at €15,000,000 or 3% of worldwide annual turnover under Article 99(4), and the cap applies the lower of the two figures for an SME under Article 99(6) — and, since the Digital Omnibus, for a small mid-cap such as Veldhoven (~300 staff, not an SME) under Article 99(6a).

How Confir helps

Confir registers each way your company uses Celonis as a distinct AI system and classifies it by its actual use under Articles 5 and 6 with Annex III logic — so process-efficiency mining and any per-worker scoring get different verdicts, and the Article 6(3) filter and the GDPR cross-map are applied explicitly rather than assumed. The engine is deterministic and rule-based: same intake, same finding, with the rule that fired shown in plain English. Where a deployment reaches high-risk, it scopes the Article 26 deployer duties and the Article 27 FRIA where relevant.

Frequently Asked Questions

Is Celonis high-risk under the EU AI Act?

No, for practically every deployment. Process mining analyses operational event data to show how work flows — it touches no Annex III use case and carries no mandatory obligations beyond the general Article 4 AI-literacy duty, so it is minimal-risk. It could become potentially high-risk only in the narrow case where its output materially drives a decision about a person in an Annex III area, such as scoring individual worker performance to gate promotion. Aggregate process analytics is not a decision about anyone.

Could Celonis ever be high-risk?

In theory, yes, if you misuse the output. If you mined individual-employee activity to produce performance scores that drove employment decisions (Annex III point 4), or fed a signal into a creditworthiness decision (point 5(b)), that specific deployment could be high-risk. These uses are far outside the product's normal remit. The classification follows the use, not the tool — keep the analysis at process level and it stays minimal-risk.

Does GDPR apply to Celonis event logs?

Yes, and it is usually the obligation that bites first. Event logs from ERP, CRM and HR systems frequently identify the people who performed each step, so you need a lawful basis (GDPR Articles 5–6), must respect purpose limitation, and should minimise or pseudonymise the user fields where the analysis does not need named individuals (GDPR Article 5(1)(c)). For most companies, GDPR governance of the logs is where the real Celonis compliance work lives.

Can we use process mining to monitor individual staff productivity?

Tread carefully. Repurposing operational logs to monitor and score named employees can exceed the original purpose under GDPR, may trigger Article 22 on automated decisions, and — if the score drives employment decisions — can pull the deployment into Annex III point 4 high-risk territory. The safer pattern is to keep the analysis at process level rather than scoring individuals, which keeps you minimal-risk under the AI Act and on stronger GDPR ground.

Who is responsible for the GPAI model inside Celonis AI?

The model provider. The general-purpose AI models behind Celonis's AI features carry Chapter V obligations under Article 53 — technical documentation, downstream information, a copyright policy and a training-data summary — that rest with their providers, not with you as a Celonis deployer. Your obligations flow only from how you use the output, which is why classification is about deployment, not the underlying model.

Are we a deployer or a provider when we use Celonis?

Almost always a deployer (Article 26) — you run process mining under your own authority for your own operations. You would only become a provider under Article 25 if you placed an AI system built on Celonis output on the market under your own name, substantially modified a high-risk system, or repurposed one for a high-risk use. For internal process intelligence, deployer status is the right answer, and the deployer duties are lighter than the provider stack.

Related guides

• Snowflake Cortex under the EU AI Act
• SAP Joule under the EU AI Act
• Annex III — the eight high-risk use cases explained
• Article 6 — how high-risk AI systems are classified
• Article 26 — deployer obligations explained
• Deployer — definition and obligations
• Provider vs deployer — which one are you?