The moment this is for
The agent demo looks useful. A form comes in, the system reads the message, checks the CRM, drafts a follow-up, proposes a note, and suggests the next status.
Then someone asks the only question that matters before production: what is this thing allowed to do?
If the answer lives in a meeting recap, a Slack thread, or the vendor's default permissions, the workflow is not ready. Write the approval policy first. One page is enough for the first pass.
The goal is not to slow the pilot down. The goal is to make the first pilot reviewable, reversible, and honest about risk.
What the worksheet decides
An AI approval policy turns a vague “human in the loop” promise into working rules. It names the workflow, the data boundary, the actions allowed without review, the actions that require approval, the actions that stay manual, the reviewer, the evidence shown to that reviewer, and the receipt left behind. If the logging fields are still fuzzy, start with the AI agent receipt template before expanding autonomy.
That page becomes the spec for the approval queue. It tells the builder which proposals the system may create, when it must stop, and what the business needs to inspect before anything reaches a customer, a record, money, or a public page.
Use it before platform selection
Do this before comparing agent platforms. The policy exposes the real requirements: data access, review routing, evidence display, audit logs, permissions, destination systems, escalation rules, and rollback.
A tool that looks impressive in a demo may be a poor fit if it makes execution easy and receipts hard. A useful approval policy does not need legal language. It needs plain decisions a builder and reviewer can follow.
Copy-paste worksheet
AI approval policy worksheet
Copy this into a working document. Fill it out for one workflow, not the whole business.
Workflow name
Name the repeatable workflow in one sentence. Example: “Draft intake follow-up for website leads.”
Workflow owner
Name the business owner responsible for the process, not just the technical builder.
Trigger
What starts the workflow? Form submission, support ticket, uploaded document, CRM change, website edit request, inbox message, scheduled report, or another event.
Allowed source data
List the exact systems, records, fields, documents, pages, or messages the AI may read. Keep this to the smallest useful set.
Blocked source data
List data the AI should not read: payment details, unrelated customer records, private HR notes, credentials, broad file drives, sensitive medical/legal/financial data, or anything outside the workflow.
Draft-only actions
What may the AI prepare without changing the business? Draft email, CRM note, support category, extracted field set, website copy proposal, review packet, summary, or routing suggestion.
Actions allowed without review
Name any low-risk actions the system may execute after testing. Include the condition and limit. Example: “Add internal support category tag only when no refund, legal, security, outage, or account-access language appears.”
Actions allowed after approval
Name actions the AI may propose but a person must approve before execution: send customer message, update CRM lifecycle stage, write to the system of record, publish content, issue credit, close ticket, or change permissions.
Actions never allowed
Name the line the first version will not cross. Include legal, medical, financial, HR, security, access-control, deletion, public publishing, irreversible, or relationship-sensitive decisions when relevant.
Reviewer role
Name the role that can approve, edit, reject, or escalate. Avoid “human review” without an owner.
Backup reviewer
Name who handles the queue when the primary reviewer is unavailable.
Escalation triggers
List conditions that stop the workflow: missing source evidence, conflicting records, angry customer, legal/security/refund language, regulated data, access changes, public claims, high dollar impact, or reviewer uncertainty.
Evidence shown to reviewer
List what the reviewer must see before approving: source record, source excerpts, proposed action, fields that will change, risk reason, confidence signal if used, policy rule, and rollback note.
Receipt fields
Define the audit record: workflow name, source IDs, source excerpts, model/system version, proposed action, policy checks, reviewer decision, edits, final action, timestamp, destination system, rollback link.
Rollback owner and path
Who fixes the mistake, and how? Revert commit, correct CRM field, send correction email, restore record, reopen ticket, flag document, revoke access, or notify security/compliance.
First-run review sample
How much work stays under review before relaxing rules? Example: first 50 items, first 2 weeks, or until two reviewers agree the failure modes are understood.
Success signal
What would prove the pilot is useful? Faster review, fewer missed fields, shorter response drafting time, cleaner routing, lower backlog, better receipts, or fewer manual handoffs.
Date for policy review
When will the team revisit the policy after seeing real queue behavior?
| Field | What to write |
|---|---|
| Workflow name | Name the repeatable workflow in one sentence. Example: “Draft intake follow-up for website leads.” |
| Workflow owner | Name the business owner responsible for the process, not just the technical builder. |
| Trigger | What starts the workflow? Form submission, support ticket, uploaded document, CRM change, website edit request, inbox message, scheduled report, or another event. |
| Allowed source data | List the exact systems, records, fields, documents, pages, or messages the AI may read. Keep this to the smallest useful set. |
| Blocked source data | List data the AI should not read: payment details, unrelated customer records, private HR notes, credentials, broad file drives, sensitive medical/legal/financial data, or anything outside the workflow. |
| Draft-only actions | What may the AI prepare without changing the business? Draft email, CRM note, support category, extracted field set, website copy proposal, review packet, summary, or routing suggestion. |
| Actions allowed without review | Name any low-risk actions the system may execute after testing. Include the condition and limit. Example: “Add internal support category tag only when no refund, legal, security, outage, or account-access language appears.” |
| Actions allowed after approval | Name actions the AI may propose but a person must approve before execution: send customer message, update CRM lifecycle stage, write to the system of record, publish content, issue credit, close ticket, or change permissions. |
| Actions never allowed | Name the line the first version will not cross. Include legal, medical, financial, HR, security, access-control, deletion, public publishing, irreversible, or relationship-sensitive decisions when relevant. |
| Reviewer role | Name the role that can approve, edit, reject, or escalate. Avoid “human review” without an owner. |
| Backup reviewer | Name who handles the queue when the primary reviewer is unavailable. |
| Escalation triggers | List conditions that stop the workflow: missing source evidence, conflicting records, angry customer, legal/security/refund language, regulated data, access changes, public claims, high dollar impact, or reviewer uncertainty. |
| Evidence shown to reviewer | List what the reviewer must see before approving: source record, source excerpts, proposed action, fields that will change, risk reason, confidence signal if used, policy rule, and rollback note. |
| Receipt fields | Define the audit record: workflow name, source IDs, source excerpts, model/system version, proposed action, policy checks, reviewer decision, edits, final action, timestamp, destination system, rollback link. |
| Rollback owner and path | Who fixes the mistake, and how? Revert commit, correct CRM field, send correction email, restore record, reopen ticket, flag document, revoke access, or notify security/compliance. |
| First-run review sample | How much work stays under review before relaxing rules? Example: first 50 items, first 2 weeks, or until two reviewers agree the failure modes are understood. |
| Success signal | What would prove the pilot is useful? Faster review, fewer missed fields, shorter response drafting time, cleaner routing, lower backlog, better receipts, or fewer manual handoffs. |
| Date for policy review | When will the team revisit the policy after seeing real queue behavior? |
Short version for teams that need a one-page start
If the full worksheet feels heavy, answer these six questions first:
- What may the AI read?
- What may it draft?
- What may it change only after approval?
- What must it never do?
- Who reviews the proposed action, and what evidence do they see?
- What receipt proves what happened if someone asks later?
Example: intake follow-up for website leads
Use this example to see the difference between a principle and an operating boundary.
Workflow name
Draft intake follow-up for new website leads.
Allowed source data
Form submission, company URL, approved service descriptions, last CRM note for that lead, public case-study links.
Blocked source data
Billing history, unrelated CRM records, private margin notes, production credentials, previous customer records outside the lead account.
Draft-only actions
Draft follow-up email, prepare CRM note, list missing fields, recommend next status.
Actions allowed without review
Create internal review packet only. No external message and no lifecycle-stage change.
Actions allowed after approval
Send follow-up email and write CRM note after reviewer edits or approves.
Actions never allowed
Quote pricing, promise a delivery date, sign terms, approve access, mark deal won/lost, or send credentials.
Reviewer role
Sales or operations owner for the intake queue.
Escalation triggers
Enterprise/security language, legal terms, urgent deadline, request for regulated-data handling, unclear source, or AI-suggested promise not supported by approved service copy.
Evidence shown to reviewer
Original form, proposed email, CRM note, missing-field list, source links used, and policy rule that required approval.
Receipt fields
Source form ID, draft, reviewer edits, approved email, send timestamp, CRM note, reviewer name, rollback/correction note.
Rollback owner and path
Operations owner sends correction if needed, amends CRM note, and records the correction in the receipt.
First-run review sample
Review the first 50 leads before allowing any auto-created internal tags.
| Field | Example |
|---|---|
| Workflow name | Draft intake follow-up for new website leads. |
| Allowed source data | Form submission, company URL, approved service descriptions, last CRM note for that lead, public case-study links. |
| Blocked source data | Billing history, unrelated CRM records, private margin notes, production credentials, previous customer records outside the lead account. |
| Draft-only actions | Draft follow-up email, prepare CRM note, list missing fields, recommend next status. |
| Actions allowed without review | Create internal review packet only. No external message and no lifecycle-stage change. |
| Actions allowed after approval | Send follow-up email and write CRM note after reviewer edits or approves. |
| Actions never allowed | Quote pricing, promise a delivery date, sign terms, approve access, mark deal won/lost, or send credentials. |
| Reviewer role | Sales or operations owner for the intake queue. |
| Escalation triggers | Enterprise/security language, legal terms, urgent deadline, request for regulated-data handling, unclear source, or AI-suggested promise not supported by approved service copy. |
| Evidence shown to reviewer | Original form, proposed email, CRM note, missing-field list, source links used, and policy rule that required approval. |
| Receipt fields | Source form ID, draft, reviewer edits, approved email, send timestamp, CRM note, reviewer name, rollback/correction note. |
| Rollback owner and path | Operations owner sends correction if needed, amends CRM note, and records the correction in the receipt. |
| First-run review sample | Review the first 50 leads before allowing any auto-created internal tags. |
When the policy is drafted and the team is deciding whether to expand permission, bring it into the AI workflow launch review packet with the security boundary, shadow-week evidence, receipt plan, and rollback owner.
FAQ
What is an AI approval policy?
An AI approval policy is a short operating document that says what an AI workflow may read, draft, change, send, escalate, log, and roll back. It gives builders and reviewers a shared boundary before the agent touches real systems.
Is this a legal or compliance template?
No. This worksheet is an implementation planning tool, not legal advice or a compliance guarantee. Regulated workflows should involve the client's legal, privacy, compliance, or security stakeholders before production use.
Does every AI action need human approval?
No. Internal, reversible, low-risk actions may become safe to automate after testing. Customer-facing, financial, access-related, regulated, public, irreversible, or ambiguous actions should require review until the workflow has evidence that more autonomy is safe.
When should we fill this out?
Fill it out after choosing one workflow and before choosing the agent platform. The worksheet will show which platform requirements matter: permissions, review routing, evidence display, logs, destination-system controls, and rollback.
What should we do after filling it out?
Use it as the spec for the approval queue or pilot. If the team cannot agree on the boundary, the workflow is not ready for production automation. If the team can agree, the first build has a clearer job, reviewer, receipt, and stop line.
Bring the worksheet to a 20-minute review
If you have one candidate AI workflow, fill out the worksheet before choosing the tool. Bring the rough version to BaristaLabs and we can pressure-test the boundary: what the agent may read, where the draft stops, who approves, what gets logged, and what should stay manual in the first version.
Best fit for customer communication, CRM updates, support triage, document extraction, website changes, and sensitive admin workflows.