Responsible AI checklist
The pilot worked once. The queue looked clean. Then someone asks whether the workflow can update the CRM without the same review step.
Open this checklist before the answer becomes yes. Name the workflow, its highest allowed v1 action, the receipt fields, the rollback owner, the manual fallback, and the criteria for earning more permission.
Step 1
proposed action
Step 2
approval evidence
Step 3
receipt fields
Step 4
rollback path
Permission gate
Expansion depends on written criteria, not on a clean demo or a small successful sample.
A four-step flow showing proposed action, approval evidence, receipt fields, and rollback path before permission expands.
Copyable artifact
Fill this for one workflow before raising its authority. The point is to make the undo path visible while the workflow is still small enough to change.
Stop line
If any rollback field is blank, do not expand permission yet. Keep the workflow draft-only, reviewed, or manual.
Workflow identity
The reviewer should see the source, rule, preview, risk reason, and stop cases before the workflow touches a customer, record, public page, or sensitive system.
The run should be reconstructable after the decision: what started it, what source was used, who decided, what happened, and which version produced it.
Permission should not expand while ownership, manual fallback, correction path, audit sample, or expansion criteria are still blank.
Plain-text version to copy into a planning doc
AI workflow rollback checklist Workflow: Business owner: Technical owner: Reviewer: System touched: Action proposed: Highest allowed action in v1: draft / reviewed action / limited automatic action / manual only Before approval: Source evidence shown: Policy rule shown: Before/after preview shown: Risk reason shown: Known cases where action must stop: Receipt: Run ID: Source IDs / excerpts: Reviewer decision: Final action: System touched: Final state: Version / prompt / model / tool identifier: Rollback: Rollback path: Rollback owner: Customer or stakeholder notification condition: Correction SLA or review window: Manual fallback: Next audit sample: Permission expansion criteria:
Field guidance
Each field should help a reviewer decide whether one workflow is ready for more authority. If a field cannot be completed from real evidence, keep the workflow in the reviewed lane.
Write the ceiling, not the hope. If the first version is draft-only or reviewed action, keep it there until the permission expansion criteria are met.
The reviewer needs to see what will change before approving. For a CRM note, that means the target record and proposed text. For a page update, that means the diff.
Use the same vocabulary as the receipt: stable IDs, source excerpts, reviewer decision, final action, final state, and workflow version.
Name the person or role who can correct the record, send the clarification, revert the page, restore the tag, or reduce workflow permission after a miss.
Describe how the work continues if the workflow is paused. The fallback should be specific enough that the team can keep serving customers without granting more AI permission.
Do not use a clean demo as the gate. State the evidence, sample, receipt quality, reviewer confidence, and stop conditions needed before the workflow moves beyond v1.
Permission expansion gate
Permission expansion criteria should be written before the workflow gets more access. Do not treat the field as a note the team fills after the system already has write permission.
If the team cannot name the rollback owner and manual fallback, keep the workflow draft-only or reviewed. The cleanest path is to finish one checklist, run the next sample under review, and use the receipt to prove what happened.
Related artifacts
The checklist works best when it sits beside the approval policy, review queue, receipt template, security boundary, and wrong-change rollback guide.
Use this upstream guide to answer the buyer objection: what happens when the AI workflow updates the wrong record, sends the wrong reply, or changes the wrong page?
Map the wrong-change pathUse the receipt template to fill the Run ID, source IDs, reviewer decision, final action, final state, and version fields without vague notes.
Review the receipt templateUse the approval queue guide to decide which evidence, policy rule, risk reason, and reviewer decision belong in the before-approval section.
Compare approval statesWrite allowed, review-required, and never-allowed actions before the rollback checklist becomes a production permission decision.
Copy the approval policyPlace the rollback checklist inside the larger boundary, approval, receipt, eval, observability, and escalation control map.
Open the controls guideRun the data and access review before the workflow receives source access, production credentials, write permission, or vendor/model exposure.
Map the security boundaryFAQ
Use it after one workflow has worked in a pilot or shadow run and before the team expands from draft-only or reviewed action into broader permission. The checklist is for one named workflow, not a companywide AI policy.
Keep the workflow draft-only, reviewed, or manual until the team can name the rollback path, rollback owner, manual fallback, receipt fields, and permission expansion criteria.
No. This is an implementation planning resource, not legal, privacy, security, or compliance advice. Regulated workflows should involve the client's legal, compliance, privacy, security, or operational stakeholders before production use.
The receipt proves what happened in one run. The rollback checklist asks whether the workflow has enough receipt fields, ownership, manual fallback, and stop criteria before permission expands.
BaristaLabs next step
Bring one workflow, one proposed action, and the systems it might touch. We can review the owner, fallback, receipt, and permission criteria before the workflow expands.