The short answer
Every process discovery project meets the same question from Legal and HR, usually in the first meeting: what exactly are you collecting from employees, and did they agree to it?
The answer depends on the collection model, and the models differ more than most buyers realize.
Background observation captures activity without asking each time. It is deployed to a population, disclosed in policy, and runs continuously. It produces consistent coverage and it triggers a formal process in many jurisdictions.
Participation-based collection asks people to contribute and lets them decide what to share. It produces coverage that depends on participation rates and it removes most of the employee relations timeline.
Both can be fully compliant. They are not equivalent in how employees experience them, and that difference determines whether people tell you the truth about their workarounds.
That last point is the one most evaluations miss. A discovery method that is legally sound and experienced as monitoring produces guarded answers, and guarded answers about process are worse than no answers, because they look like data.
Key takeaways
- The legal question and the trust question are separate. Meeting one does not resolve the other.
- Background observation typically triggers works council consultation in parts of Europe and employee relations review in many organizations, and that timeline often exceeds the technical rollout.
- Data minimization is the strongest single control: collect what answers the question, not what the system can capture.
- The distinction between process observation and employee monitoring is real, but employees judge it by how the program is introduced, not by the architecture.
- Aggregation before analysis is what keeps discovery from becoming individual performance measurement.
- People describe their workarounds honestly when the process does not feel like an audit.
The four collection models
| Model | How evidence is gathered | Consent basis | Typical approval path |
|---|---|---|---|
| System log extraction | Event data already stored in ERP, CRM, ticketing | Existing business records processing | Data protection review; usually straightforward |
| Background desktop observation | Continuous capture of screen and application activity | Legitimate interest with disclosure, or explicit agreement | DPIA, works council or union consultation, employee relations review |
| Session-based recording | Employee starts and stops a capture session | Explicit, per session | Lighter, but coverage is inconsistent |
| Participation-based conversation | Employees describe their work and choose what to share | Explicit, per participant | DPIA; generally no works council trigger |
The first is the simplest legally and the narrowest in coverage. The second is the broadest in activity coverage and the heaviest in approval. The fourth reaches reasoning and intent, which the others cannot, and depends on people choosing to participate.
What regulators and works councils actually ask
The questions are consistent across jurisdictions, even where the legal frameworks differ.
What is the purpose? Process improvement is an acceptable purpose. Individual performance evaluation is a different purpose with different requirements, and a system built for the first must not be usable for the second.
Is the collection proportionate? Capturing everything because the technology allows it fails a proportionality test almost everywhere. The collection has to be scoped to what answers the stated question.
Can individuals be identified? If yes, under what conditions and who can do it. Pseudonymization at the point of capture, with re-identification requiring separate authorization, is the standard that regulated deployments aim for.
What is retained and for how long? Indefinite retention of activity data is difficult to justify. A defined retention period tied to the purpose is expected.
Were employees informed, and how? Notice buried in an updated policy document meets a minimum standard and does not build trust. Direct communication about what is happening and why does both.
Can employees object? In several regimes this is a right, not a courtesy. The program design has to accommodate it without collapsing.
In Germany and several other European jurisdictions, works councils have codetermination rights over systems capable of monitoring employee behavior or performance. That applies regardless of whether monitoring is the intent, which is why background observation triggers the process even when the vendor's architecture is designed to prevent individual measurement.
Consent and coverage
The tradeoff each model makes
| Model | Activity coverage | Reasoning captured | Approval burden | Employee experience |
|---|---|---|---|---|
| System logs | Partial, systems only | None | Low | Invisible |
| Background observation | High | None | High | Depends entirely on framing |
| Session recording | Inconsistent | Minimal | Moderate | Disruptive to workflow |
| Participation-based | Depends on participation | High | Low | Contributory |
No model is best on all four. The choice depends on which constraint is binding: activity precision, reasoning, timeline, or trust.
Why the trust question determines data quality
This is the part that gets treated as a soft consideration and is actually the hardest constraint.
Process discovery is trying to find the undocumented layer: the reconciliation spreadsheet, the informal pre-approval, the manual check one region added. Every one of those exists because someone worked around an official process.
If the person believes the exercise might be used to evaluate them, describing a workaround is describing a deviation. The rational response is to describe the official process.
That produces a specific failure: a discovery output that confirms the documentation. It looks like validation. It is silence.
Three design choices reduce this:
Separate the exercise from performance management explicitly and structurally. Not only stated, but true at the data level. If output cannot be disaggregated to an individual, the statement is verifiable.
Frame around difficulty rather than compliance. Asking what makes the work hard produces honest answers. Asking whether anyone deviates from the standard process does not.
Let managers hear the aggregate, not the individual. If a manager can see who said what, participation quality drops immediately and permanently.
Design principles for a compliant, credible program
1. Define the question before the collection
Data minimization is not a constraint on discovery; it is a discipline that improves it. Naming the specific business question narrows what needs collecting, which shortens approval and produces a cleaner analysis.
2. Separate process observation from employee monitoring at the architecture level
The distinction is real: process observation looks at how work flows through a system, employee monitoring looks at individual performance. Making it structural rather than declarative means aggregating before analysis, so the analytical layer never processes direct identifiers.
3. Bring Legal, HR, and works council representatives in during design
The common failure is presenting a completed program for approval. Involvement during design surfaces constraints while they can still shape the approach, and turns representatives into participants rather than gatekeepers.
4. Write the employee-facing explanation before you write the policy
If you cannot explain to a person in three sentences what is being collected, why, who sees it, and what happens to it, the program is not ready. The policy document is a legal artifact; the explanation is what determines participation quality.
5. Decide who owns the internal narrative
If the program is announced by IT as a technical deployment, the framing is set before the business can correct it. Announcement by the function that owns the improvement, naming the outcome employees will see, produces a different reception.
6. Commit to showing results back
The strongest single trust signal is that something visibly changed because of what people said. Programs that collect and disappear teach the organization not to participate next time.
7. Plan the timeline realistically
For background observation in a European or unionized environment, the employee relations process routinely takes longer than the technical deployment. Building it into the plan avoids a stalled pilot and an unhappy sponsor.
The questions to ask a vendor
| Question | What a good answer sounds like |
|---|---|
| When is data pseudonymized? | At the point of capture, before it leaves the device or session |
| Can individual output be reconstructed? | Only through a separate, access-controlled step with defined authorization |
| What is the minimum viable collection for our question? | A specific, scoped answer rather than "everything we can" |
| Where is data processed and stored? | Named regions, with residency options if required |
| Is customer data used for model training? | A clear no, in writing |
| What certifications apply? | SOC 2 Type II at minimum; ISO 27001, HIPAA, GDPR posture as relevant |
| What is the retention period and who sets it? | Configurable, tied to purpose, customer-controlled |
| Can an employee decline? | Yes, without consequence, and the program still works |
| What have works councils asked you in past deployments? | Specific examples, which indicate real experience |
The last question is the most informative and the one buyers ask least.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform that reaches the operation through conversation rather than observation. That method choice carries directly into the consent question.
Participation is explicit. People choose to take part and choose what they share. There is no agent installed on employee devices and no background capture of activity, which removes the works council and employee relations timeline that desktop observation typically triggers, and changes how the program is received internally.
The experience matters for data quality, not only for compliance. Across deployments, 93% of participants complete the conversation and rate the experience 9.1 out of 10. That completion rate is the operative number in this context: people finish, and they describe their actual workflow, because the conversation is oriented toward what makes their work difficult rather than toward whether they are following a process correctly.
In the published Mercado Libre case, Horizon ran discovery across 2,000 employees in Finance and adjacent functions in five countries in four days, against a manual baseline of 11 to 20 weeks. Despegar compressed 17 weeks of discovery into five. Horizon is SOC 2 compliant and does not train models on customer data.
Those are outcomes from specific engagements rather than a projection for any organization.
The tradeoff is honest. Conversation does not produce the minute-level activity precision that continuous observation does. If the question is how many minutes a manual reconciliation consumes across 400 people, observation is the better instrument. If the question is why the reconciliation exists and what would break if it were removed, that has to come from the people doing it, and it comes more honestly when they chose to participate.
Program checklist
- Is the business question specific enough to scope the collection?
- Have Legal, HR, and employee representatives been involved during design rather than at approval?
- Is the separation between process observation and performance evaluation structural, not only stated?
- Is data pseudonymized at the point of capture?
- Is the analytical output aggregated so individuals cannot be identified by managers?
- Is there a defined retention period tied to the purpose?
- Can an employee decline without consequence, and does the program still function?
- Is there a three-sentence explanation an employee will actually understand?
- Who owns the announcement, and does the framing match the purpose?
- Is there a commitment to show results back to participants?
- Has the employee relations timeline been built into the project plan?
- Have you asked the vendor what works councils have raised in prior deployments?
Common mistakes
Treating approval as the finish line. A compliant program that employees experience as surveillance produces guarded data. The compliance question and the trust question are separate.
Announcing through IT. The framing is set by whoever introduces it. A technical announcement produces a technical interpretation.
Collecting everything the tool supports. Proportionality is a legal requirement in several regimes and a practical one everywhere: broader collection means longer approval and noisier analysis.
Letting managers see individual responses. Participation quality drops immediately and does not recover.
Framing questions around compliance. Asking about deviation produces denial. Asking about difficulty produces description.
Collecting and disappearing. If nothing visibly changed, the next program will have a participation problem the design cannot fix.
FAQ
Do you need employee consent for process discovery?
It depends on the collection method and jurisdiction. System log analysis of existing business records generally relies on established processing grounds. Desktop observation typically requires a data protection impact assessment and, in many European jurisdictions, works council consultation, because the system is capable of monitoring behavior regardless of intent. Participation-based methods rely on explicit consent from each participant.
What is the difference between process observation and employee monitoring?
Process observation examines how work flows through an organization: where it slows, which handoffs create rework, how steps vary. Employee monitoring examines individual performance. The distinction is meaningful when it is structural, meaning the analytical output cannot be disaggregated to an individual. When it is only declarative, employees are right to be skeptical.
Do works councils have to approve process mining?
In Germany and several other European jurisdictions, works councils hold codetermination rights over systems technically capable of monitoring employee behavior or performance. That threshold is about capability rather than intent, so tools that observe desktop activity generally fall within it. Log-based analysis of existing system records is treated differently in many cases, though a data protection assessment is still expected.
How long does works council approval take?
It varies widely by organization and country, and it routinely exceeds the technical deployment timeline. Teams that treat it as a parallel workstream starting at project kickoff fare considerably better than those that raise it after tooling is selected.
Does asking employees produce less reliable data than observing them?
They produce different kinds of data with different reliability profiles. Observation is more reliable for durations and application sequences, since self-reported time estimates are poor. Conversation is more reliable for reasoning, exception consequence, and improvement ideas, which observation cannot capture at all. The reliability of conversational data depends heavily on whether participants believe the exercise is safe.
What should be in the employee communication?
What is being collected, why, who will see it, what will not happen with it, whether participation is voluntary, and what the person can expect to see change as a result. Three to five sentences, sent by the business owner rather than by IT or Legal.
Compliance is the floor, not the goal
Every serious vendor in this space can produce a defensible privacy architecture. That is table stakes, and it is not what determines whether the discovery works.
What determines it is whether the person who has been quietly reconciling two systems by hand for four years decides to mention it. That decision is made on how the program feels, not on how the DPIA reads.
See it. Fix it. Own it.