Field Note · Governance

Why AI Agents Fail After Deployment (It Is Not the Model)

New Sinch research names the leading causes of AI agent rollbacks: PII exposure and hallucination. The contributing cause is quieter. Most organizations shipped without full security sign-off, and found the risk only after an incident.

6 min read Published June 22, 2026

DefinitionAn AI agent rollback is the decision to pull a deployed AI agent out of production, usually after the agent exposed sensitive data, produced a factually wrong answer in a customer-visible context, or violated a policy that no one realized applied until it was triggered. The pattern is a sequencing problem: organizations ship first and govern after the incident.

New Sinch research, reported by Capacity in June 2026, finds that AI agents deployed in customer-facing contexts are falling short of expectations in production. The leading causes of rollback: PII exposure and hallucination. The contributing cause: most organizations shipped their agents without full security or IT sign-off, and discovered the risk only after an incident.

The pattern Sinch describes is the sequencing problem at the center of most AI production failures. Organizations ship first and govern after the incident.

Why the "ship fast" approach breaks differently for AI than for software

In software development, shipping fast and iterating is a reasonable default. The worst outcomes from a buggy feature are usually recoverable: a broken flow, a 404, a confusing UI. You fix it in the next deploy.

AI agents break differently. When an agent exposes PII or hallucinates a factual claim in a customer conversation, the incident is often not recoverable the same way. A client receives wrong information about their account. A prospect gets a confident, incorrect answer about your services. A staff member relies on an agent output that was wrong in a way nobody caught until it was logged somewhere official.

The harm is rarely catastrophic for a small business. The trust erosion is real. And the more customer-facing the agent, the more the trust erosion compounds.

The discipline that prevents this is not complicated. It is governance before deployment: defining what the agent is authorized to say, what data it can access, what it does when it does not know the answer, and who reviews it before it goes live with real users.

Most small businesses skip this because governance sounds like a large-company concern. It is not. It is a sequencing question: what do you need to have figured out before this agent talks to a customer?

The gap is governance, and governance is a design step, not a legal department.

The three failure modes Sinch identifies and what they tell operators

01
PII exposure
The agent accessed, surfaced, or transmitted personally identifiable information it had no business handling in that context. This happens most often when agents are given broad access to company data without a policy governing what they are allowed to surface. The fix is access control and data segmentation before deployment: the agent should only see what it needs to see.
02
Hallucination in high-stakes contexts
The agent produced a confident, incorrect answer. This is most damaging when customers act on that information: pricing, policy, availability, timelines. The fix is scope definition plus fallback design. An agent that says "I do not have that, let me connect you with someone who does" is more valuable than one that confidently answers everything.
03
Missing sign-off
The agent went live without security review, IT approval, or formal sign-off from someone whose job is to think about risk. The agent worked fine in testing, so it went to production, but the test environment did not surface the PII risk because the test data was not real, or because no one asked what happens when someone asks about another client's account.

Three parallel risk categories, not a sequence. Source: Sinch, via Capacity (June 2026).

Each of these is an independent risk, not a step in a chain. An agent can clear one and fail another. For example, a lawyer worried about privileged information should not connect their email to an LLM without prior clearance from IT and security. The absence of a formal process does not remove the risk. It just moves the responsibility for catching it onto whoever builds the system.

What this means for small businesses adding AI agents

Small businesses are not immune to these failure modes. In some ways they are more exposed, because there is no dedicated security team, no formal IT sign-off process, no policy review cycle. The discipline has to come from whoever is building the system.

Before deploying any customer-facing AI agent, three questions should have clear answers. What data does this agent have access to, and is that access appropriate for every possible conversation it might have, not just the expected conversations, but the edge cases? What is this agent not authorized to answer, because "everything" is not a scope? And who has reviewed this before it talks to a real customer, even if the reviewer is just you?

The Sinch findings are not a reason to avoid AI agents. They are a checklist for operators who want them to work. The technology is capable. The gap is governance, and governance is a design step, not a legal department. See how we approach operations design or learn about our audit process.

Related Questions

Why do AI agents get rolled back after deployment?

The most common causes are PII exposure and hallucination in customer-facing contexts, per Sinch research (June 2026). Most rollbacks follow one pattern: the agent shipped without formal security review, and the risk only became visible after a real incident with a real user.

What is PII exposure in an AI agent context?

PII exposure occurs when an AI agent surfaces or transmits personally identifiable information, including names, account details, or contact information, in a conversation where that data should not be accessible or visible. It typically happens when an agent is given broader data access than its job requires.

What does AI agent governance mean for a small business?

For a small business, governance means defining scope before deployment: what the agent is authorized to answer, what data it can access, what it does when the answer is outside its scope, and who reviews it before it goes live. It does not require a dedicated security team. It requires deliberate decisions made before launch, not after an incident.

How do you prevent AI agent hallucinations from reaching customers?

Scope the agent tightly. Define what it is and is not authorized to answer. Build a fallback for questions outside that scope. Hallucinations in customer-visible contexts almost always occur when the agent is handed questions it was never designed to handle.

Is it safe to deploy AI agents without IT approval in a small business?

Potentially, but only if you have done the work that IT approval is designed to cover: reviewing data access, defining scope, testing with realistic scenarios including adversarial ones, and setting a fallback policy. The absence of a formal IT process is not a waiver of the risk. The operator has to run the checklist themselves.

The Work Behind the Work

The agent is capable. The governance is the design step most operators skip.

Take the first step toward a business that runs with clarity and momentum.