You Shouldn’t Have to Keylog Your Own Employees to Understand Your Process.

Listen to how these products are sold, and the architecture gives itself away. One vendor pairs process mining with desktop task mining it describes as "full-spectrum" visibility, and frames its mission around connecting people to processes. Another offers desktop task and click discovery alongside its process graph. The rest of the category carries versions of the same capability.

Now notice what always travels with it: a heavy wrapper of reassurance. Privacy-first. Anonymization. PII masking. You control what's collected. Configurable consent. Works-council-friendly deployment.

That reassurance is the tell. A product that measures machine-to-machine transactions doesn't need a privacy manifesto. A product that records what a named employee typed at 2:47pm does. The compliance scaffolding isn't a feature bolted on for trust — it's a confession about what the tool fundamentally is.

The surveillance isn't a design choice. It's forced by where these tools sit. Process mining reconstructs a process after the fact from event logs batch-extracted out of your ERP, CRM and ticketing systems. Those logs contain only the transactions the systems of record chose to write down.

They do not contain the work between the systems: the spreadsheet someone maintains on the side, the email that authorizes an exception, the copy-paste from one screen into another, the swivel-chair reconciliation that never touches a database. That un-logged work is exactly where cost, risk and delay accumulate — and it leaves no trace in the logs.

So to see it, task mining instruments the only sensor left: the human. It records the desktop because the desktop is where the invisible work happens. This is reconstruction by surveillance — inferring the shape of a process you don't run by watching the people who run it by hand.

Give it its due. In a legacy estate, this is genuinely useful. If a process is smeared across a dozen disconnected tools with no shared backbone, desktop capture may be the only honest way to map the end-to-end path before you redesign it. As a diagnostic for the mess, task mining earns its keep. The problem starts when a diagnostic gets sold as a destination.

There is a different answer to "how does work actually happen here" — and it requires a camera on no one. Run the work on governed rails.

In Entroid a process isn't observed from the outside; it executes inside the fabric as a composition of five primitives. Deterministic Workflows sequence the steps and enforce the rules. Atomic Agents perform the bounded unit of work at each leaf. Functions expose the calculations and business logic. Connectors are the only primitive that touches an external system, and they do it under authentication, authorization, rate limits and audit. Intelligence Orchestration chooses the path at runtime and owns which agent is permitted to do what.

Because the work runs here, structure isn't reconstructed after the fact — it is the native exhaust of execution. Every step is captured as authoritative execution data at the moment it happens and bound into an immutable, per-action audit trail. You don't infer who approved an exception from a screen recording; the approval was a governed gate in the workflow, and it either cleared inside its authority limit or it could not happen at all.

Consider a payment-posting agent that clears an incoming remittance. In the observe-only model, you'd learn how the work is done by recording the clerk's screen. In a governed runtime, the agent posts inside a Deterministic Workflow: the segregation-of-duties check, the threshold that forces a human approval above a limit, the Connector write to the ledger — each is a discrete step, each is timestamped, each is bound to the decision that authorized it. The record isn't captured from the employee. It is the work.

For a COO, CHRO or data-protection officer, this is the distinction that matters: auditable-by-construction is not surveillance under a nicer name — and the difference is the entire point.

Task mining collects behavioral data about a person on a machine: keystrokes, mouse paths, application dwell time, screen content. That is employee personal data. It's why the tools ship with consent flows, and why works councils fight over them.

A governed workflow captures the process, not the person: which step ran, which rule fired, which approval cleared, what an agent decided and why. Human-in-the-loop is a first-class property of the runtime — the agent pauses, surfaces its reasoning, takes the human's feedback, and resumes — and that exchange becomes part of the process record, not a recording of someone's desktop.

• No desktop agents. Nothing to install on anyone's laptop, nothing capturing screens or keystrokes.
• No consent theater. There is no employee behavioral data to disclose, anonymize or defend, because none is collected.
• No works-council standoff. You're auditing the work product and its governance, not monitoring the workforce.
• Policy is a gate, not a report. A non-compliant action is prevented at the moment of action — never flagged in a dashboard after it already went wrong.

"What are my people doing?" is the question task mining answers. It's the wrong question. The right one is: why is my process not owned by a system that can execute and govern it?

Task mining is a flashlight for a building with no wiring. It's indispensable while you're feeling along the walls in the dark — and it becomes pointless the moment the lights come on. Once work runs on a governed fabric, you already hold the blueprint and the live telemetry. There is nothing left to reconstruct, because nothing was ever un-owned.

So the executive choice isn't "which task-mining tool has the best privacy controls." It's more fundamental: are you buying a sharper instrument for observing the chaos, or a runtime that removes the reason the chaos was invisible in the first place?