Generative AI on the phone: three guardrails before production.

Too many teams confuse demonstration with service. An LLM on the phone is not ready because it answers well in testing. It is ready when its scope is bounded, human supervision is real, and its traces are exploitable after the fact.

Without these three guardrails, you are not industrialising a capability. You are exposing the brand, legal compliance, and the customer journey to uncontrolled responses. The subject is not model performance. It is operational control, proof, and the ability to take back the reins when a conversation goes off track.

Scope bounding

The bot must know what it can say. It must also know what it must refuse. Everything else is out of scope. A generalised LLM left unconstrained improvises quickly on sensitive topics. On the phone, that improvisation becomes a promise, an error, or an information leak.

Bounding is not limited to a list of expected responses. It must cover authorised intents, permitted actions, forbidden topics, and escalation triggers. Otherwise, the model fills gaps with plausible but unvalidated formulations. That is where gaps appear: a refund mentioned too early, personal data repeated, a contractual exception invented.

Ask: "Can you show me the exact matrix of authorised intents, refusals, and escalations?" Require a verifiable contractual criterion: each intent must be versioned, tested, and associated with an explicit refusal behaviour. The classic trap is the grey zone. Its symptom: the bot answers confidently on an edge case, then the vendor talks about "probabilistic behaviour" after the fact.

Real human supervision

Displayed supervision is not supervision. A human capable of intervening during the exchange is required — not after. Deferred monitoring reassures committees. It does not protect the live customer.

Handoff must be immediate and without context loss. If the advisor picks up the call as if discovering the case from scratch, the automation promise turns into friction. The right system transmits the history, detected intent, data already collected, and reason for transfer. Otherwise, the customer repeats everything, and experience degrades at the exact moment the system claims to be helping.

A bot without immediate human handoff is not autonomous. It is simply uncontrolled.

Ask concrete questions: "Who monitors conversations in real time?" and "What signal triggers a human handoff?" Require a measurable threshold. Verify: what happens when the bot expresses uncertainty about a sensitive case? A system without an automatic escalation trigger for ambiguous cases relies on perfect AI judgement — which does not exist.

Full traceability

Every AI-generated response must be auditable after the fact. Not just a transcript. The complete trace: model version used, input data, detected intent, generated response, applied action, and timestamp. Without this trace, in case of a dispute or control audit, you cannot prove what happened, nor at what moment, nor under which configuration.

Traceability is not a luxury feature. It is a regulatory minimum on regulated markets. And even outside regulated contexts, it is the only mechanism that allows correcting a model that drifts without having to start from zero. Without a trace, you cannot know if a behaviour change comes from a model update, a data change, or an unexplained configuration drift.

Ask: "What does a conversation trace contain at the technical level, and in what format is it exportable?" Require the trace to include the model version and a hash identifying the configuration in place at time of the conversation. Verify that the retention period matches your legal and contractual constraints. The classic symptom of inadequate traceability: a post-incident audit that can only say "the bot said something wrong" without being able to specify exactly what, when, and under which rules.