What to send before an AI workflow audit

A useful AI workflow audit starts before the call. Not with a polished deck. With enough operating evidence to see where the work begins, which sources are authoritative, where the process breaks, and who is allowed to approve the result.

If the request is only “we want to use AI,” the audit has to spend its first pass finding a workflow. A better packet gives the audit something falsifiable: one repeated process, recent examples, known exceptions, explicit authority, and a reviewable output.

The goal is not to make the idea look ready. It is to support an honest verdict: build, repair, defer, or stop.

Define the audit intake contract

Keep the first audit bounded to:

• one recurring workflow;
• one named process owner;
• one decision or handoff the workflow supports;
• one reviewable artifact;
• one set of approved sources;
• one human authority map;
• one representative evaluation set;
• one decision about what happens next.

Do not send the whole company and ask the audit to “find the AI opportunity.” That is strategy discovery, not a workflow audit. Start where a person can point to the trigger, current steps, output, reviewer, and consequence of being wrong.

Good candidates sound like:

• “Every week we research a fixed lead list before sales decides whom to contact.”
• “Incoming forms need classification and assignment, but a human must approve any reply.”
• “Documents arrive by email and someone copies defined fields into a tracker.”
• “A manager builds the same status brief from approved project sources.”
• “Support requests need triage before a human writes or sends the final answer.”

Weak candidates sound like “automate operations” or “add agents to the business.” Those may be real ambitions. They are not testable first scopes.

If you are still choosing the workflow, use the first-workflow scorecard before assembling the packet.

Build an evidence register before telling the story

Do not turn the packet into a persuasive narrative. Record the evidence state first.

For every material claim about the workflow, mark it as:

• observed — supported by a current example, source record, or reproducible process step;
• assumed — believed by the team but not yet checked;
• unknown — required for the decision but not available;
• conflicting — credible sources or owners disagree;
• stale — the source may no longer describe the current process.

Also record who owns the source, when it was last updated, and what wins when sources disagree. Access to a file does not make that file authoritative.

A small evidence register is enough:

Unknown is not a defect in the packet. Hiding the unknown is.

Bring representative examples, not a convenient highlight reel

Five to ten recent examples usually reveal more than a long requirements document, but selection matters more than count. Do not bring only clean cases that make the workflow look easy.

Include examples across these case types:

For each example, preserve the chain:

1. input received;
2. source or version used;
3. decision or transformation performed;
4. output produced;
5. reviewer response;
6. correction, escalation, or final disposition.

The audit does not need raw production data by default. Sanitized examples, synthetic records that preserve the relevant structure, or a controlled screen-share may be safer. The important part is keeping the test condition and expected reviewer decision intact.

Record source authority and access boundaries

List every source the workflow relies on, even when access will not be granted during the audit.

For each source, record:

• system or document name;
• business owner;
• data owner;
• authoritative fields;
• update cadence or version rule;
• read, write, export, API, or webhook availability;
• sensitivity classification;
• retention and deletion constraints;
• conflict rule when another source disagrees;
• credentials or approvals needed for a later prototype.

Do not include credentials, access tokens, private keys, session cookies, or unrestricted production exports in the intake packet. The packet should identify the access dependency without becoming the secret handoff.

This is where many broad ideas become smaller. Good. A narrow workflow with known source authority beats an “end-to-end agent” that guesses which spreadsheet is true.

Map human authority before proposing autonomy

Name the human decisions the workflow touches. Separate preparation from authority.

A useful authority map answers:

• Who may review the artifact?
• Who may approve it?
• Who may correct the underlying source?
• Which actions may be drafted but never executed automatically?
• Which cases require legal, finance, HR, security, or partner review?
• When must the workflow stop rather than improvise?
• Who owns a correction after an output has already moved downstream?

For a sales workflow, research and draft preparation may be in scope while lead qualification, pricing, promises, and outreach remain human-owned. For support, classification and a held reply draft may be in scope while refunds, account changes, legal positions, and send authority stay outside it.

If nobody owns the approval step, the process is not ready for more autonomy. Assigning authority is part of the repair work.

Describe the current process without cleaning it up

Document what happens now, including manual workarounds and unofficial handoffs.

For each step, capture:

• trigger;
• actor;
• source opened;
• judgment applied;
• output created;
• handoff destination;
• wait state;
• common exception;
• current reviewer;
• correction path.

Do not rewrite the process as it ought to work. An audit built on an aspirational flow will optimize the fiction and miss the actual bottleneck.

Timing and volume can help, but label them honestly. Use observed ranges and collection windows where available. If they are estimates, mark them as assumptions. Do not manufacture precise savings from one unusually bad week.

Name the artifact and its acceptance contract

A first workflow should produce something a reviewer can inspect. “The AI handled it” is not an artifact.

Examples include:

• a cited lead brief with source links, fit notes, and open questions;
• a triage queue with reasons, urgency, suggested owner, and escalation state;
• an extraction table with source references and missing-field markers;
• a weekly executive brief separating facts, interpretation, decisions, and follow-up;
• a review packet showing proposed changes, evidence, risk, and approval status.

Then define acceptance criteria for that artifact:

• required fields;
• citation or provenance rules;
• allowed values;
• missing-data behavior;
• confidence or uncertainty display;
• reviewer decision states;
• external-action boundary;
• correction and replay behavior;
• retention or audit-log requirement.

The artifact contract makes the workflow testable. Without it, reviewers are judging fluency and polish instead of operating quality.

The audit-findings guide explains how those inputs become an observed baseline, authority map, exception model, and pilot recommendation. The synthetic audit report shows the shape of a proof-safe output.

Include constraints that can kill the idea

Say the constraints early. They are decision inputs, not inconvenient footnotes.

Common stop or repair conditions include:

• customer or employee data cannot leave approved systems;
• the source has no reliable version or owner;
• legal, financial, medical, hiring, or compliance judgment cannot be delegated;
• reviewers use incompatible acceptance standards;
• the workflow changes faster than it can be maintained;
• there is no way to detect or reverse a bad write;
• volume is too low to justify implementation and maintenance;
• the useful output depends on context the system is not allowed to access;
• the sponsor wants execution authority but cannot name an accountable approver.

A good audit can recommend process repair, a reporting view, a deterministic automation, a held AI-assisted draft, or no build. It should not manufacture an AI project to justify the meeting.

Add a safe transfer manifest

Before sending files, include a manifest so the packet can be reviewed without opening every attachment.

Use this structure:

Workflow:
Process owner:
Decision owner:
Audit decision needed:

File or example:
Purpose:
Case type: normal / edge / failure / privacy / recovery
Source and version:
Evidence state: observed / assumed / unknown / conflicting / stale
Sensitivity: public / internal / confidential / restricted
Sanitization performed:
Allowed use during audit:
Retention or deletion requirement:
Missing context:

Prefer a small, named set of files over an inbox export or shared-drive dump. Remove unrelated records. Preserve stable identifiers only when they are needed to trace a case, and replace direct personal or customer identifiers when the audit does not need them.

Raw public-form submissions should not be copied into agent prompts, analytics, issue trackers, screenshots, or public artifacts. If a public input matters, use a human-sanitized summary that preserves the workflow fact without carrying the original untrusted text forward.

Do not send these by default

Leave these out unless a specific, approved secure handoff requires them:

• credentials, tokens, private keys, cookies, or recovery codes;
• unrestricted mailbox, drive, CRM, HR, finance, or support exports;
• customer-specific material unrelated to the selected cases;
• legal advice or privileged material without the right review path;
• screenshots that expose hidden tabs, notifications, account IDs, or unrelated records;
• old process documents presented as current truth;
• generated requirements written without process-owner review;
• a deck that claims savings or accuracy without a measured baseline.

More material does not create a better audit. Better authority and case selection do.

Copy this pre-audit packet

1. Workflow and decision
- Workflow name:
- Trigger and finish state:
- Process owner:
- Decision owner:
- Artifact the workflow should produce:
- Decision requested from the audit: build / repair / defer / stop

2. Current process
- Steps and actors:
- Sources and authority rules:
- Current reviewer:
- Exceptions and wait states:
- Correction or recovery path:

3. Evidence register
- Observed facts:
- Assumptions:
- Unknowns:
- Conflicts:
- Stale sources:

4. Representative cases
- Normal:
- Edge:
- Failure:
- Privacy:
- Recovery:

5. Boundaries
- Sensitive data:
- Allowed access:
- Prohibited actions:
- Human-only decisions:
- Retention and deletion:

6. Operating value
- Current observed effort or delay:
- Consequence of errors:
- Signal that would justify continuing:
- Ongoing owner and review cadence:

The packet is ready when another reviewer can understand what must be tested, which evidence is trustworthy, what remains unknown, and who has authority over the result.

Use the packet to force a verdict

The audit should end with one of four outcomes:

• Build — the workflow has a stable artifact, approved sources, representative cases, a clear review gate, and a bounded first slice.
• Repair — the idea may be useful, but source authority, process ownership, acceptance criteria, or recovery needs work first.
• Defer — the decision depends on access, evidence, volume, policy, or timing that is not available yet; record the trigger for revisiting it.
• Stop — the workflow is too unstable, too consequential, too restricted, or too weak in operating value to justify the build.

That verdict is more useful than a list of possible tools. It tells the team what to do next and what evidence would change the decision.

If the packet is ready, bring it to an AI Workflow Audit. If it is not, start with one normal case and one failure case. The gap between them usually shows where the real work is.