Failure modes

Automating a process that was never actually defined. The most repeated failure pattern in sourced 2026 material: a process that ran on tribal knowledge and case-by-case judgment gets automated before anyone writes down what it actually is, and the automation either breaks on the first real exception or silently makes the wrong call. Fix the process first — The pilot-build sequence's specification step exists specifically to force this. [Directional]

Integration brittleness. A vendor renames a field, an API version deprecates, an upstream tool changes its export format — and a no-code workflow breaks silently rather than loudly, because nothing was watching for it. The first 20–100 real transactions through a new automation are what surface most of the failure modes that survived clean internal testing, which is exactly why The pilot-build sequence's shadow-run window matters. [Directional]

Over-automating a customer-facing, trust-sensitive process. A 2026 survey of 1,011 US adults found 47% would abandon a brand that misuses their data, and only 19% view AI as actually improving their customer experience. [Established — named survey, disclosed sample size] The specific mechanism behind the drop in trust, consistent across 2026 customer-experience trade coverage: when a bot blocks escalation to a human, the customer's experience shifts from "service" to "containment" — a closed ticket that didn't solve the problem reads to the customer as being stonewalled, not helped. [Directional] This is the sharpest version of the resolution-rate definitional gap named in What actually automates: a metric that looks good on your dashboard can be actively damaging the relationship it's supposedly measuring.

Access-control and credential gaps. IBM's Cost of a Data Breach Report found that among organizations reporting a breach involving an AI model or application, 97% lacked proper AI access controls, and compromised APIs and cloud misconfigurations each accounted for 27% of breaches that reached an AI system — the two most common ways in. [Established — IBM/Ponemon Institute report, named methodology, via IBM's own press release] For a solo operator or small team, the practical version of this is API keys and integration credentials created once for a pilot and never revisited, scoped far more broadly than the automation actually needs, and shared across tools with no single owner.

Governance gaps at scale. The same Gartner prediction named in KPIs and kill switches — over 40% of agentic AI projects canceled by end of 2027, driven by deployment without clear strategy or governance — applies just as directly to a solo operator's automation program as to an enterprise one. The scale is smaller; the failure pattern (build fast, skip monitoring, discover the gap only after an incident) is identical.

Treating a contractor's build as a black box. If nobody in-house understands what was actually built, the day it breaks you're either paying emergency rates to an unfamiliar contractor or negotiating from weakness with the original one. This is the single most commonly cited maintenance failure in sourced automation-consulting material, and it's the direct argument in Build vs buy vs DIY for doing at least one build yourself before you outsource one. [Directional]