Business Process Audit Before AI Implementation is an evidence-based review of how work is being done today, what data and systems support it, where exceptions occur, and which metrics can be used to approve future automation. The result of the audit is not an abstract “maturity level,” but a set of artifacts and a decision for each hypothesis: pilot, fix the process first, or stop.
It is useful to start with one frequent, problematic, data-rich, and constrained process. These are exactly the criteria recommended by the National AI Centre of Australia: the process should have a clear start and end, participants, inputs, outputs, and time costs. Organizational readiness should be assessed more broadly — across strategy, governance, data, culture, infrastructure, and models — as in the Microsoft AI Readiness Assessment.
Short answer: a good audit connects the AS-IS map, baseline, data inventory, integration diagram, exception log, risk register, candidate matrix, and pilot brief. Without these eight outputs, it will be difficult to assess budget, impact, and acceptance criteria for an AI project.
This material is intended for owners, COOs, CIOs, functional leaders, and process analysts. It is a practical template, not a universal standard, legal opinion, or guarantee of ROI.
Key points in one minute
- Audit the process, not the desire to “implement AI.”
- Separate employee narratives from measurements in CRM, ERP, logs, and case samples.
- Capture not only the main path, but also exceptions, returns, and manual workarounds.
- Evaluate candidates along three axes: business value, readiness, and risk.
- Do not automate a broken process: sometimes you need a policy update, data cleanup, or a standard integration first.
- End the audit with a one-page pilot brief and a pre-defined
go / revise / stopdecision.
Contents
- How an Audit Differs from AI Readiness and PoC
- How to Choose a Process for Audit
- KARTA-AI Method
- Step 1. Define the scope and outcome
- Step 2. Gather evidence
- Step 3. Build the AS-IS and baseline
- Step 4. Check data and integrations
- Step 5. Assess risks and human-in-the-loop
- How to Rank Candidates
- Eight Required Audit Artifacts
- How to Approve the Audit and Choose the Next Step
- Frequently Asked Questions
- How AI Sunrise Conducts an Audit Before AI
- Conclusion
How an Audit Differs from AI Readiness and PoC
These three concepts are often mixed up, even though they have different objects and outputs.
| Format | Main Question | Object | Result |
|---|---|---|---|
| AI readiness assessment | is the organization ready to work with AI systematically | company or function | maturity areas and improvement plan |
| business process audit | is there a suitable process and what needs to change | specific end-to-end process | AS-IS, baseline, data, risks, and pilot brief |
| PoC | does the key hypothesis work technically | limited function and sample | prototype and technical measurements |
| pilot | does the solution work in a real workflow | limited user group | business, quality, and cost metrics |
An audit comes before a PoC when the task is not yet defined. If the process, data, and success criteria are already set, you can move faster to technical validation. But a PoC does not replace a business audit: a model may perform well on a test and still not fit the real workflow, roles, or economics.
In an open IDEA article, the audit is described as a process map, data and integration requirements, a candidate ranking, and a roadmap. This is a useful example of a commercial format, but the published timelines, prices, and case results refer to the vendor’s own offering and claims, not to a universal standard. Original IDEA page was viewed on August 10, 2026.
How to Choose a Process for Audit
Do not start with a list of models. First, make a short list of processes where there is an observable problem and an owner of the outcome.
A strong candidate
- occurs often enough to accumulate data and notice change;
- has a clear beginning, end, and recipient of the result;
- includes a meaningful amount of text, documents, images, signals, or decisions;
- creates measurable delays, errors, rework, or missed opportunities;
- has an owner who can change the policy and approve the outcome;
- allows for a limited pilot and a return to manual operations.
A weak candidate
- is performed rarely and is unique each time;
- does not have a shared definition of “done”;
- depends on informal agreements that nobody wants to document;
- uses data without a clear owner or legal basis;
- the error is irreversible, and human confirmation is excluded;
- the stated problem can be solved by changing the policy or through standard automation.
High pain by itself does not make a process suitable. If inputs are not captured, decisions are not explained, and results are not measured, the first project is about establishing process discipline.
The MAP-AI Method
MAP-AI — a working framework for assessing a single process:
- K — Scope: start, end, triggering event, output, and boundaries.
- A — Actors: roles, authority, recipients, and process owner.
- R — Result: definition of done, quality, due date, and cost.
- T — Trace: sequence of operations, decisions, and data.
- A — Anomalies: exceptions, returns, manual workarounds, and errors.
- I — Measurements: baseline for volume, time, quality, and losses.
- I — Integrations: systems, access, formats, and constraints.
The AI hypothesis is added only after the first seven blocks are completed. Otherwise, the technology starts to dictate the problem statement.
Process Card
| Field | Example Format | Evidence |
|---|---|---|
| start event | incoming request registered | Measured: CRM event |
| result | request resolved or escalated | User-provided + policy |
| owner | support manager | User-provided |
| volume | N requests for the selected period | Measured: export |
| cycle time | median and percentiles | Calculated from timestamps |
| errors | repeat requests and returns | Measured by rule |
| cost | labor + systems + rework | Calculated from inputs |
| unknown | share of hidden requests outside CRM | Unknown before sampling |
Evidence labels protect the audit from false precision. Words like "seems," "usually," and "approximately" are acceptable in interviews, but in conclusions they should become Estimated, Proxy or Unknown, until they are confirmed.
Step 1. Define the boundaries and the result
Describe the process in one sentence: "from event X to result Y for recipient Z." For example: "from a new customer email to a logged resolution or escalation to the responsible specialist."
Then capture:
- what happens before the start and after the finish;
- which departments and external parties are involved;
- who owns the result and the metric;
- which channels are included in the first version;
- which cases are intentionally excluded;
- what rule determines that a case is successfully completed.
If the boundaries keep expanding, split the process. "Sales as a whole" is too broad a unit; "qualification of an inbound lead through assignment to an owner" is already testable.
Step 2. Gather evidence
Interviews show how participants understand the work. Logs show how part of the work happened in systems. Observation and case sampling reveal manual workarounds that never made it into the policy or the events.
Minimum sources
- Policy, SLA, templates, and job descriptions.
- Interviews with the owner, performers, and result recipients.
- Exports from CRM/ERP/Service Desk and timestamps.
- Sampling of routine, complex, and error cases.
- List of systems, tables, folders, chats, and mailboxes.
- Data on returns, complaints, manual corrections, and incidents.
There is no universal sample size for any process. Record the period, inclusion and exclusion rules, gaps, and possible bias. If part of the flow is handled in private chats, a CRM export does not represent the entire process.
Triangulation
For a disputed step, look for at least two independent confirmations: the performer’s statement plus a log; the policy plus a sample; the report plus observation. A discrepancy should not be averaged out — it should be recorded as a finding.
Example: the policy requires a response within one business day, the manager believes the team responds faster, and the timestamps show a long tail. The correct conclusion is not an "average opinion," but the cycle time distribution and a hypothesis about the tail’s causes.
Step 3. Build the AS-IS and baseline
AS-IS — the observed map of the current process. It should show human and system actions, decision points, queues, returns, input and output data. Microsoft’s Process Mining documentation describes process variants as different sequences of actions and recommends analyzing frequency and execution time. Microsoft Documentation is useful as an example of measurable map elements, even if your company uses a different tool.
What to include for each step
| Field | Question |
|---|---|
| action | what exactly happens |
| role/system | who or what performs the step |
| input | what information is needed |
| output | what is created or changed |
| work time | how much active labor is required |
| waiting | how long the case sits in the queue |
| decision rule | how the next branch is selected |
| exception | what breaks the main route |
| evidence | where the fact comes from |
Baseline metrics
- number of cases for the period;
- median and percentile cycle time, not just the average;
- employee active time;
- share of returns and rework;
- share of cases by each routing option;
- number of handoffs between systems;
- share of inputs with missing data;
- cost of a successfully completed case;
- the cost of a critical error, if it can be reasonably estimated.
Do not carry metrics over from someone else’s case. The baseline is built from this process’s data and a fixed definition of the metric.
Step 4. Check data and integrations
Data inventory
For each source, fill in:
| Field | What to record |
|---|---|
| owner | who approves use and is responsible for updates |
| format | table, PDF, image, audio, API, event log |
| volume | rows, documents, hours, or storage volume |
| freshness | update date and frequency |
| completeness | required fields and missing values |
| labels | whether there is a ground-truth answer or class |
| access | roles, consent, contractual, and technical restrictions |
| lineage | where the data came from and how it was transformed |
For RAG, currency, document structure, and the ability to cite the source are critical. For a predictive model, sufficient history and no future data leakage are critical. For computer vision, representative capture conditions and class definitions are critical. For an agent, API availability, permissions, and reversibility of actions are critical.
Integration map
Do not write “integration with CRM.” List the operations: read the record, find related requests, create a task, save the result, attach the source. For each operation, specify authorization, limits, timeout, retry, idempotency, logging, and behavior when unavailable.
If the needed API does not exist, that is a separate finding. Sometimes it is cheaper to change the process or add a standard integration layer than to force the agent to work through a brittle imitation of user actions.
Step 5. Assess risks and human-in-the-loop
The NIST AI RMF is designed to incorporate trustworthiness and risk management into the design, development, use, and evaluation of AI systems. Official NIST overview does not define a specific Russian checklist, but it confirms the lifecycle: risk is assessed before launch and continues to be monitored after it.
Risk register
| Risk | Trigger | Consequence | Control | Owner | Residual risk |
|---|---|---|---|---|---|
| incorrect answer | source missing | wrong decision | refusal + citation + escalation | process owner | evaluate in the pilot |
| extra action | repeat request | duplicate in the system | idempotency + confirmation | IT owner | verify with tests |
| data exposure | wrong role | access violation | RBAC + filtering + logging | security | review |
| degradation | documents changed | quality drop | versioning + regression evaluation | knowledge owner | monitor |
Levels of autonomy
- Search: AI shows relevant sources.
- Draft: AI suggests an answer or action, and a person approves it.
- Restricted action: AI acts within a whitelisted set of scenarios with logging and rollback.
- Autonomous path: the system selects and executes a chain of actions.
The higher the autonomy and the cost of a mistake, the more permissions, confirmations, tests, and monitoring are needed. For the first pilot, a draft or read-only mode is often enough.
How to rank candidates
Do not reduce everything to one polished score. Keep three axes separate.
Business value
- frequency and volume;
- active time and waiting time;
- cost of errors and rework;
- impact on customer, revenue, risk, or throughput;
- strategic importance.
Readiness
- clear boundaries and an owner;
- repeatability and measurable results;
- available data with an owner;
- documented systems and APIs;
- ability to run a limited and reversible pilot.
Risk
- consequences of an error;
- personal, commercial, or other sensitive data;
- level of autonomy;
- explainability and verifiability of the result;
- dependence on an external vendor or a fragile integration.
Use the 0–3 scale only after formally defining each level in writing. Do not treat the sum as objective truth. Two candidates with the same total may have very different profiles: high value and high risk versus moderate value and high readiness.
| Decision | Profile |
|---|---|
| Pilot now | value is confirmed, readiness is sufficient, risk is controlled |
| Prepare | there is value, but data, policy, or an integration layer is needed |
| Research | too many unknowns; a short assessment is required |
| Stop | value is not confirmed or the risk is disproportionate to the task |
Eight mandatory audit artifacts
- Scope card: start, end, outcome, owner, exceptions.
- AS-IS map: main route, variants, queues, and returns.
- Baseline sheet: volume, time, quality, cost, and metric definitions.
- Data inventory: sources, owners, quality, access, and lineage.
- System map: integration operations, roles, errors, and constraints.
- Exception catalog: types of edge cases and current handling.
- Risk register: triggers, consequences, controls, owners, and residual risk.
- Pilot brief: hypothesis, sample, decision, metrics, budget boundary, and stop/go.
Acceptance criteria for the package
- each number has an evidence type and a source;
- Unknowns are not hidden in averages;
- the map is confirmed by the owner and representatives of the teams doing the work;
- the main route and significant variants are tied to data;
- the system list contains specific operations, not just names;
- the risk is tied to control and accountability;
- candidate matrix keeps three axes separate;
- the pilot brief can be handed to the team without rediscovering the entire task from scratch.
How to accept the audit and choose the next step
Pilot it
Choose a pilot if the process is bounded, the baseline has been measured, data access is confirmed, the quality criterion is defined, and any error can be detected and handled. The pilot brief should name the frozen scope, user group, observation period, acceptable transaction cost, and decision criteria go / revise / stop.
Fix the process first
If there is no owner, no defined outcome, no single source of truth, or no baseline measurement, start with the process. Possible work: standardize fields, close manual workarounds, assign an owner, create an event log, or connect a standard integration. After the change, the baseline must be measured again.
Stop the hypothesis
Stopping is a normal audit outcome. Reasons include low frequency, unconfirmed value, unavailable data, irreversible risk, lack of control, or a simpler solution without AI. A documented stop saves budget and frees the team for a stronger candidate.
For the financial side, use the published model for AI implementation cost and TCO. The overall sequence from process to pilot is complemented by the guide “Implementing AI in Business Processes: Where to Start”.
Frequently asked questions
How many processes should be included in the audit?
For a deep assessment, start with one end-to-end process. For portfolio screening, you can collect several cards, but the same depth across dozens of processes will require a separate scope of work. The exact number depends on the goal, participants, and available evidence.
Who should participate?
The process owner, representatives of the executors, the recipient of the output, an analyst, the data owner, IT, and, if needed, security or legal. One interview with a manager is not enough to confirm the actual workflow.
Is process mining mandatory?
No. It is useful when systems contain accurate event logs and case IDs. For manual work, interviews, observation, and case sampling are needed. The tool does not replace defining boundaries, outcomes, and risk.
How is a data audit different from a process audit?
A data audit checks sources, quality, access, refresh cadence, and lineage. A process audit connects that data to actions, roles, decisions, exceptions, and business outcomes. For an AI pilot, both layers are needed.
Should the roadmap promise ROI?
No. Before the pilot, you can build a calculation based on the baseline and assumptions, but the actual impact is unknown. The roadmap should show the formula, sources, sensitivity, and the point for remeasurement.
What is a sufficient audit outcome?
A package that allows a well-founded decision to pilot / prepare / research / stop and hand off the chosen pilot brief to the team. A presentation without baseline, data, risks, and acceptance criteria is not enough.
How AI Dawn conducts an audit before AI
AI Dawn can assess the selected process, build the AS-IS map and baseline, inventory data and integrations, describe exceptions and risks, prioritize hypotheses, prepare an MVP or pilot brief, and then, once the decision is confirmed, assemble and integrate an AI agent, RAG, computer vision, or ML model.
The safest first step is to choose one process, lock in the current metrics, data sources, constraints, and acceptance criteria. This helps separate the audit from a technology sales pitch and determines in advance when to move to a pilot, when to fix the process, and when to stop. Discuss the project.
Conclusion
A business process audit before AI implementation is not about measuring how innovative the company is, but about making a verifiable decision for a specific job. The KARTA-AI method captures the scope, actors, outcome, trace, anomalies, measurements, and integrations; eight deliverables turn the findings into a handoff-ready package.
Start with one frequent, painful, data-rich, and bounded process. Compare interviews with logs and cases, measure the baseline, preserve the unknowns, verify the data, integrations, and risk. After that, choose pilot, prepare, research or stop before the main budget goes into development.