Most automation failures are not caused by one bad prompt. They come from unclear ownership, inconsistent data, missing exception handling, and systems that act without enough review.
/ 01
The ten mistakes
These problems appear repeatedly in early automation projects.
- Choosing a tool before defining the process
- Automating several departments at once
- Using production data before testing
- Giving integrations excessive permissions
- Treating AI output as fact
- Skipping a human approval step
- Ignoring duplicate and retry behavior
- Logging secrets or customer content
- Failing to assign an owner
- Launching without a rollback and maintenance plan
/ 02
Build failure paths deliberately
Define what happens when a provider is unavailable, an input is missing, a duplicate request arrives, credentials expire, or confidence is low. A safe workflow pauses or routes the exception instead of inventing a successful result. Document a maximum retry count and a dead-letter or exception queue.
Make destructive or external actions harder than drafts. CISA's secure-by-design guidance emphasizes ownership of customer security outcomes; responsibility cannot be shifted to users through a warning after an unsafe default.
/ 03
Make success observable
Use structured status, correlation IDs, alerts, and a small set of business metrics. Observability should explain whether the workflow completed, not expose the sensitive content it processed. Monitor the rate of completion, exception, retry, human edit, and reversal by workflow version.
Write a stop rule before launch. Examples: disable automatic sending if the correction rate exceeds 5%, if unauthorized data appears, if a required provider loses authentication, or if duplicate actions are detected.
/ 04
Turn the list into a release gate
A checklist matters only when it changes the release decision. Assign an owner and evidence to each control: a screenshot of permission scopes, a test report for duplicate handling, a link to the rollback runbook, or an alert demonstration. Mark unresolved items as accepted risk with a named approver and review date.
Before each material workflow change, rerun the cases most likely to break. Model upgrades, prompt changes, provider API changes, and new data sources can alter behavior even when the interface looks unchanged.
- Process owner signs off on expected behavior
- Security owner reviews data and permissions
- Tester verifies normal and exception cases
- Operator demonstrates disable and recovery
- Business owner approves production scope and metrics
/ Practical takeaway
A reliable automation has a defined owner, constrained access, test data, human review, exception handling, monitoring, and a recovery plan.