What an AI-Automation Audit Actually Looks Like (Checklist Included)

The fixed-scope diagnostic to run before writing a line of automation code — what it covers, the scoring rubric, and the three failure modes it almost always finds.

Most AI automation projects don't fail in production. They fail before the first line of code, at the moment somebody says "let's automate this" without checking whether "this" is actually automatable. The graveyard is consistent: a chatbot nobody trusts, a Zapier chain someone is afraid to touch, an "AI agent" that got quietly turned off after it emailed the wrong customer.

The fix is boring, which is why it's skipped: audit the workflow before you build. Here's the diagnostic I run at Iluxxian — what it covers, the rubric it produces, and what it keeps finding.

The six questions an audit has to answer

1. Where do the hours actually go? Not where people say they go. Watch the workflow happen — screen recording beats interviews. A team that "spends all day on invoices" often spends 40 minutes on invoices and four hours on the exception handling around invoices. The exceptions are the real spec.

2. Is the data ready? This is the step most audits skip and the reason most automations die. An AI agent triaging leads can only be as good as the CRM fields it reads. If "deal size" lives in a free-text notes column in three different formats, no model fixes that — a data-cleanup step does, and it belongs in the plan and the budget. Automation is plumbing before it's intelligence.

3. Which steps are judgment, and which are rules? Every workflow decomposes into mechanical steps (fetch, format, copy, route) and judgment steps (approve, price, apologize). Mechanical steps automate fully. Judgment steps get a human-in-the-loop gate or they don't ship. Drawing this boundary wrong in either direction is expensive: automate judgment and you get incidents; hand-hold mechanics and you get no ROI.

4. What does a mistake cost? Classify every output as reversible (draft, internal log), costly (customer-facing message), or irreversible (payment, deletion, contract). The classification dictates the architecture: reversible actions can run free, costly ones need approval queues, irreversible ones need approval plus a kill switch plus logging you can replay.

5. What should it run on? Tool choice is a math problem, not a preference. Per-operation platforms (Make, Zapier) are fast to ship and expensive at volume — a loop that touches 10,000 rows a week will surprise you on the invoice. n8n self-hosted trades ops cost for maintenance. Custom Python/TypeScript costs more to build and the least to run. The audit does this arithmetic with your real volumes before anything gets picked.

6. Does the ROI survive honest math? Hours saved × loaded hourly cost, minus build cost, minus run cost, minus a maintenance line nobody wants to include (drift happens: APIs change, models update, edge cases accumulate). If the number only works with maintenance at zero, the project doesn't work.

The rubric

Each candidate workflow gets scored into a one-page verdict. The format matters less than the discipline; this is the actual shape of it:

workflow: invoice-triage
volume_per_week: 140
minutes_per_item_manual: 6
error_cost: reversible        # reversible | costly | irreversible
data_readiness: 2/5           # amounts inconsistent across CRM fields
judgment_steps: 1             # approval required over threshold
tool_fit: n8n + LLM extract   # per-op math fails at this volume on Make
verdict: automate-with-HITL   # human approves before send
prerequisite: normalize amount fields (est. 4 hrs, one-time)

Ten workflows scored like this gives you a portfolio: usually two or three "automate now," a few "automate after data cleanup," and at least one "leave it manual" that somebody was excited about. That last category is the audit paying for itself.

The checklist

  1. Inventory candidate workflows; measure real time spent (recordings, not estimates)
  2. Map each workflow's exceptions — they're the actual requirements
  3. Score data readiness for every input the automation reads
  4. Mark every step as mechanical or judgment
  5. Classify failure cost: reversible / costly / irreversible
  6. Place human-in-the-loop gates at every judgment step and irreversible action
  7. Run tool-fit math against real volumes (per-op pricing vs hosting vs custom)
  8. Price the ROI including maintenance, not just the build
  9. Define the kill switch and who owns it before go-live
  10. Write the verdict down — one page per workflow, no slideware

What it keeps finding

Three failure modes show up in almost every audit. First: garbage-in automation — a workflow scheduled for AI whose input data can't support it, discoverable in an hour, usually discovered in month three. Second: no gate on irreversible actions — an agent allowed to send, pay, or delete without a human click; this is how automations make the news inside a company. Third: per-operation pricing surprise — a design that's cheap at demo volume and triple the estimate at production volume, because nobody multiplied.

An audit is one to two days of work. Each of those failure modes, caught late, costs multiples of that — in rebuild time, in the political capital of a failed launch, or in the quiet decision to never try automation again. That last cost is the biggest one, because the workflows really were automatable. The diagnosis just came after the surgery.

Have a workflow you're about to automate?

Iluxxian runs fixed-scope automation audits — you get the scored rubric and build map above, useful even if you build elsewhere.

Start a build