Process discovery for AI automation is the evidence-led study of how work enters, moves, changes and finishes across people and systems before an automation is designed. It reconstructs case families, decisions, documents, data, queues, exceptions, authority and outcomes so the team can choose an appropriate intervention and define what success and safe failure mean.
The documented process is often the route people were expected to follow, not the process they use. Workshops compress multiple case families into one clean flow, system logs omit judgment and off-system work, and headline volumes hide the exceptions that consume most effort. If a team automates that fiction, it may accelerate the easiest step while moving errors, delay and risk to somebody else.
Begin with the completed outcome and work backwards through evidence. Use event data, artefacts, observation and practitioner accounts to challenge one another. Segment cases before calculating an average. Expose every decision, exception and authority boundary, then redesign the target workflow before assigning AI to a task. The right result may be an AI component, deterministic automation, a policy change, better source data or no automation at all.
Evidence
Triangulate the process instead of believing one representation
Start with complete cases, not a blank flowchart. For a representative sample, collect the request, attachments, system history, communications, decisions, approvals, revisions and final result. Follow a single case across team and system boundaries. An event log can show sequence and delay at scale, but an event may be generated automatically, entered late or shared across several activities. A document can reveal the information used, while observation reveals searches, judgment and work carried out in spreadsheets or messages.
Interview several roles separately before reconciling the model. Performers know practical variation; approvers know the controls they expect; recipients see defects that upstream teams may call complete. Mark each activity as observed, system-derived, stated or inferred and record where sources disagree. Process mining is valuable for discovering variants and conformance patterns from event data, but it is one evidence method. A defensible discovery explains both what the log can prove and what remains outside it.
- Sample complete cases across time, source and outcome.
- Link events with stable case identifiers and test their quality.
- Observe searches, judgment and off-system coordination.
- Ask downstream recipients about corrections and unusable outputs.
- Label evidence strength and unresolved contradictions.
Variation
Treat exceptions and decisions as the substance of the process
A single happy path is rarely the correct unit for automation. Segment cases using variables that change the work: document completeness, customer type, jurisdiction, language, transaction value, risk, novelty and required approval. Measure each family separately. The routine majority may suit straight-through automation while a low-volume family needs specialist judgment. Conversely, a small exception class may offer the greatest value if its repeated evidence search can be assisted safely.
For every decision, record the question, available evidence, governing policy, accountable role and consequences of error. Determine whether the apparent judgment is a stable rule, pattern recognition under uncertainty, negotiation or the exercise of formal authority. Capture missing-evidence and conflict states. NIST’s AI Risk Management Framework emphasizes establishing the intended purpose, context, impacts and human oversight before deployment. A process map that shows boxes but not decisions and affected people is too shallow to support that work.
| Lens | Discovery question | Design consequence |
|---|---|---|
| Evidence | What must be known and from where? | Source, freshness and missing-data path |
| Variation | Which case families change the work? | Eligibility and routing |
| Decision | What rule or judgment changes the case? | Automation, assistance or human authority |
| Exception | Why can the normal route not continue? | Recovery, escalation and learning |
| Outcome | Who receives what and with what quality? | Acceptance and downstream measurement |
Redesign
Remove avoidable work before automating what remains
Discovery should challenge the process, not merely digitize it. A repeated classification may exist because intake lacks a required field. Manual reconciliation may result from two systems using different identifiers. A long approval chain may contain duplicate checks with no distinct authority. Improve the source, policy, ownership or interface first. The cheapest and safest automation is often a requirement that no longer needs to be performed.
Design the target workflow at the level of responsibilities and states. Define the canonical case record, who may change it, what evidence travels with a decision and how work returns from an exception. Use deterministic automation for stable rules and integrations. Use AI for variable interpretation or generation where representative evaluation is possible. Keep accountable judgment where the consequence, ambiguity or authority demands it. Do not place a person after every model call; assign review based on risk and evidence.
- Eliminate duplicate entry and controls with no distinct purpose.
- Repair source data before compensating with inference.
- Create one canonical case state and explicit ownership.
- Assign technology by variability, evidence and consequence.
- Design exception recovery before the normal route.
Pilot
Use the pilot to test assumptions that could reverse the decision
Select a bounded case family with sufficient volume and representative difficulty. Freeze the baseline definition before testing. Specify which input is eligible, what output is acceptable, which decisions remain with people and how failures are recorded. Include integration, queueing, review and downstream acceptance. A laboratory result that excludes malformed documents, peak demand or the receiving team does not estimate production behavior.
Count every resource required to create the outcome, including expert correction, manual context preparation, monitoring and exception handling. Compare quality before speed; an incorrect fast result can generate more work than the original process. Review results by case family and failure severity. Establish go, redesign, hold and stop criteria in advance. If discovery shows that policy ambiguity or missing source data dominates, closing the automation pilot and fixing the process is a successful decision, not a failed project.
- Test the riskiest assumption, not the easiest demonstration.
- Use representative cases and an unchanged baseline.
- Measure the complete path to an accepted outcome.
- Include hidden human support in cost and quality.
- Decide with pre-agreed expansion and stop criteria.
What good looks like
Useful outcomes from process discovery for AI automation
- A named start and end define one measurable business outcome rather than a vague departmental process.
- Case families separate routine work from variants whose effort, evidence, authority or consequences differ.
- Observed events, documents and interviews form a reconciled evidence record with known blind spots.
- Each decision records its inputs, policy basis, owner, uncertainty and route for exception or appeal.
- Queues, handoffs, rework, shadow systems and downstream corrections are visible in the current-state model.
- The target workflow removes unnecessary work before deciding which remaining tasks need AI.
- The proposed automation has clear eligibility, human-review, escalation and prohibited-action boundaries.
- A representative pilot can prove end-to-end quality, operating effort and realized value against a baseline.
Operating model
How to run the work
- 01
Frame the outcome and case
Define the trigger, unit of work, completion event, customer or internal recipient and business consequence. State the decision the discovery must support. Set boundaries wide enough to see upstream quality and downstream correction, and select a representative observation period.
- 02
Build the evidence record
Extract available event histories, sample complete case files, observe work and interview performers, approvers and recipients. Map each source to the question it can answer. Reconcile timestamps and identifiers, document missing activity and avoid treating a system event as proof of productive work.
- 03
Segment cases and expose variation
Group cases by evidence need, decision path, value, risk, language, source quality and exception type. Quantify volume, handling, waiting, rework and outcome for each family. Trace common variants and investigate outliers rather than forcing all work through one average diagram.
- 04
Redesign before assigning technology
Remove duplicate checks, clarify policy, improve intake and move evidence closer to its source. Define the desired state with roles, authority, service levels and recovery paths. Allocate deterministic rules, AI assistance and human judgment according to variability and consequence.
- 05
Specify and test a bounded pilot
Choose eligible case families and a comparison baseline. Define inputs, outputs, integrations, review, escalation and stop conditions. Run representative cases end to end, count hidden support and correction effort, and decide whether to stop, redesign, expand or operationalize.
Evaluation
Questions that change the decision
- What completed outcome and recipient define the process boundary?
- Which case families are materially different and should not share one automation rate?
- Which evidence sources reveal events, content, judgment, off-system work and downstream defects?
- Which steps exist because of policy or risk, and which persist only through historical habit?
- Where is authority exercised, and can a person explain, contest or reverse the decision?
- Which problems should be removed through process or data design before any AI is introduced?
- Which remaining tasks suit rules, workflow automation, AI assistance or accountable human judgment?
- What pilot evidence would change the decision, and what result must stop deployment?
Failure modes
Where teams lose control
A workshop map can describe the official process while omitting the workarounds that keep it functioning.
Event logs can confuse screen activity or status updates with genuine progress.
Shared identifiers may be missing, reused or changed, producing false case histories.
One average can hide a small exception class responsible for most effort and harm.
Removing a control as “waste” can eliminate a safeguard whose purpose was not visible to the discovery team.
Automating an upstream task can increase downstream queueing, review or correction.
Observed employees may temporarily follow policy more closely than usual.
A pilot can overperform because experts repair outputs outside the measured workflow.
Historical outcomes can encode inequity or past policy violations and should not automatically become training targets.
A narrow discovery can optimize departmental speed while making the customer’s end-to-end experience worse.
Measurement
Measure the finished job
Measure the completed workflow, including review effort and exceptions. Output volume on its own is not evidence of a better process.
- case arrivals, completions and backlog by family and period
- active handling time and end-to-end cycle time by percentile
- queue time, handoffs, returns and reopened cases
- first-pass acceptance and material downstream correction
- exception incidence, cause, handling effort and business impact
- evidence completeness and source quality at the point of decision
- eligible share for each proposed intervention and reason for exclusion
- human review, escalation, override and unresolved-case rates
- total operating effort and cost per correctly completed outcome
- pilot improvement versus baseline with confidence and known limitations
Questions
Common questions
What is process discovery for AI automation?
It is the evidence-led reconstruction of real work across cases, people, systems, decisions and exceptions before choosing an automation. It establishes current performance, target design, technology boundaries and a representative pilot contract.
Is process mining the same as process discovery?
Process mining uses event data to discover and analyze flows and variants. Process discovery is broader: it can combine logs with files, observation, interviews, policy, decision analysis and downstream outcomes. Logs are powerful evidence but rarely describe all judgment and off-system work.
How long should an automation discovery take?
Duration depends on process breadth, data quality, case variation and risk. A bounded discovery should stop when it can support the stated decision with representative evidence, known limitations, a target workflow and pilot criteria, not when every historical variation has been diagrammed.
What makes a process suitable for AI automation?
A suitable process has a valuable and measurable outcome, sufficiently observable inputs and outputs, repeatable case families, manageable exceptions, evaluable behavior and clear authority. AI is useful only for the variable component; rules, integration or process change may solve the rest better.
Sources
Primary references
- AI Risk Management Framework Core National Institute of Standards and Technology
- NIST AI RMF Playbook: Map National Institute of Standards and Technology
- Process Mining resources and IEEE Task Force links Process Mining
About the author
Malcolm Ferguson
Malcolm writes from the buyer side about procurement, sourcing, due diligence and the evidence suppliers need to pass a serious evaluation.
Zenith
AI workflow automation for repetitive, document-heavy and research-heavy operations.
Operations, finance, commercial and transformation teams. Start with the workflow, constraints and evidence you already have.
See Zenith→