What this solves
Most teams do not need a bigger AI wishlist. They need to know which repeated workflow is worth touching first, which data is safe to use, and where human review must stay in the loop.
The audit is for operators who can point to manual drag but do not yet know whether the right next step is a prompt, a small integration, a reviewed agent workflow, or nothing.
When to request the audit
Use the audit when the workflow has enough shape to inspect, but not enough certainty to build safely.
| Good audit candidate | Wrong starting point |
|---|---|
| A recurring task with recent examples, a named reviewer, and a visible output people already use. | A broad mandate to “add AI” without a workflow owner or source material. |
| A process where drafting, extraction, research, routing, or summarization could help if the review gate is clear. | A workflow that would let automation approve refunds, legal terms, finance decisions, HR actions, or public commitments. |
| A team that wants to decide whether to build, defer, or kill the first candidate before buying another tool. | A team looking for promised savings, autonomous replacement, or a demo that ignores maintenance. |
If the wrong-starting-point column sounds familiar, fix the owner, examples, and authority boundary first. The audit works better once there is something real to inspect.
What we inspect
- The current workflow: actors, tools, handoffs, approvals, exceptions, and repeated rework.
- The input quality: source systems, documents, free-text notes, spreadsheets, CRM fields, and missing data.
- The decision boundary: what can be drafted or classified by AI, and what still needs a human owner.
- The maintenance path: monitoring, escalation, logs, change control, and who fixes the workflow when it drifts.
Deliverables
- A workflow inventory with impact, feasibility, risk, and maintenance scoring.
- An opportunity map that separates quick wins from brittle automation theater.
- A pilot backlog with the smallest useful prototype, data needs, owner, and review gate.
What the audit report answers
The useful output is not a deck of AI ideas. It is a short operating report that lets an owner decide whether to build, defer, or kill the candidate workflow.
| Decision question | What the report should show |
|---|---|
| Is the workflow real enough? | Named owner, current tools, repeated inputs, expected output, and examples we can inspect. |
| Where does AI help? | Drafting, classification, extraction, research, routing, or summarization steps that can be reviewed before use. |
| What must stay human? | Approval points, customer-facing commitments, refunds, legal/compliance calls, edge cases, and stop conditions. |
| What would a pilot need? | Clean sample inputs, target artifact, reviewer, success signal, logging needs, and maintenance owner. |
| What should we not automate yet? | Missing source data, unclear authority, brittle exceptions, privacy exposure, or process debt that should be fixed first. |
This keeps the first decision practical: build the smallest reviewed artifact, gather better examples, or leave the workflow alone for now.
What we need from you
- Two or three real workflow examples, sanitized if needed.
- Screenshots, exports, or access to the tools involved where appropriate.
- A decision owner who can say what the workflow is allowed to change.
- Constraints we should respect: compliance, customer trust, data sensitivity, budget, and timeline.
If you are still choosing the first candidate, use How to choose your first AI workflow without creating a mess to score repetition, inputs, output, authority, failure mode, and maintenance, then copy the one-page candidate brief before the audit. If you already know the workflow, use the pre-audit packet in What to send before an AI workflow audit: workflow name, recent examples, source systems, reviewer, output artifact, constraints, and the operating signal that would make the work worth continuing.
Risks and constraints
AI automation fails when the process is undefined, the data is messy, or nobody owns exceptions. The audit surfaces those problems before implementation. That can be annoying. It is cheaper than building an impressive demo nobody can operate.