Multi-channel AI guardrails that hold
Humint Labs delivery for one accountable policy across voice, web chat and messaging, with every intervention traceable, tested and owned.
- Delivery
- Designed, built and operated by Humint Labs for a multi-channel assistant across voice, web chat and messaging.
Guardrail operating proof
Reference design scope across voice, web chat and messaging.
Reference design target: policy checks run in an explicit sequence.
Reference design target: blocking, redirecting and escalation are distinct.
Reference design target: guardrail changes are tested before release.
Measures describe the operated multi-channel guardrail model and its release-path controls.
What your enterprise receives
An accountable guardrail operating model that keeps policy consistent across channels whilst retaining the evidence and recovery paths each channel needs.
Policy model
A written, channel-independent policy with explicit decision owners and approved channel exceptions.
Shared policy core
Ordered controls that resolve one decision across voice, web chat and messaging.
Channel matrix
Delivery adaptations that respect the channel without changing the underlying allow, redirect or deny decision.
Acceptance and regression pack
Adversarial and false-refusal cases that test safety and usefulness together on every relevant change.
Operating evidence
Traceable intervention outcomes, owned overrides and release records that make policy behaviour reviewable.
How Humint Labs gets it live
- Step 01
Agree the policy decisions
Define scope, intervention types, authority and the deliberate channel differences the enterprise will operate.
- Step 02
Implement the shared core
Build the ordered policy path, channel adapters, exception register and evidence model around the assistant.
- Step 03
Validate and operate
Run the acceptance pack, review intervention patterns and govern policy changes through the release path.
The operating challenge
One assistant answers inbound enquiries across voice, web chat and messaging. When policy is implemented separately by channel, the same decision drifts: a refusal becomes a hedge, a redirect disappears or an exception survives without an owner.
The operational problem is not simply detecting unsafe content. It is making each policy decision consistent, explainable and testable before it reaches a customer interaction.
What we found
- Channel differences are real, and almost all of them belong to delivery rather than to policy. What a caller hears is shorter than what a chat user reads, and a messaging reply may arrive an hour later. Whether the answer is allowed is not a channel question, and every place it had been treated as one was a defect waiting to be found.
- Voice arrives as transcription output, not as text a person wrote. There is no punctuation to anchor a pattern, numbers are spelled as words, and names come through approximated. A pattern-based check tuned against typed input weakens exactly where confirming a value with the person is slowest.
- The order the layers ran in was carrying weight that nobody had assigned. Layers had been added in the order incidents happened, which meant an expensive grounding check ran on turns that a scope check would have ended for nothing.
- Blocking and redirecting were both being reported as the guardrail firing, and the single label hid the important fact underneath: most interventions should not end the conversation. A control that only knows how to stop is a control that gets loosened until it stops working.
- Nothing had a test. Configuration was tuned against a handful of remembered examples, so a change could be argued about but not demonstrated, and a regression could only be found by a person meeting it in production.
Where the bottleneck sat
The constraint was never detection quality. It was that guardrail behaviour lived as configuration, tuned by hand, with no written definition of correct behind it.
Without that definition no change could be shown to be an improvement, and no channel could be shown to behave the same as the others. Everything built afterwards follows from writing the definition down first.
Design rationale
Part of the answer was not code. Before any layer was moved, the policy was written once as a channel-independent statement, with the deliberate channel exceptions listed beneath it, each carrying the reason it exists and the name of the person who agreed it.
That exercise resolved more than the reordering did. Two behaviours that had been logged as bugs were correct and are now recorded as intended, and one that everybody had assumed was intended had no owner and no rationale, so it was removed.
Our Solution
Humint Labs designed and operates five policy layers in a fixed order: topic and scope, content safety and personal information handling before generation, then grounding and output validation after it. A shared policy core resolves one decision across every channel.
Deliberate channel differences sit in an owned override register, while every intervention records whether it redirected, blocked, redacted, withheld or required recovery. The guardrail configuration moves through the same review and release path as application code.
Scroll diagram horizontally
Shared policy core
One definition of scope, harm classes and personal information handling, resolved by every channel from the same source. A channel adapter can change how a decision is rendered, in length, in phrasing, in whether a disclosure is spoken or linked. It cannot change what the decision was.
Topic and scope, layer one
Runs first because it is the broadest and the cheapest, and because a turn that is out of scope needs none of the checks below it. It redirects rather than blocks: it names what the assistant does cover and offers it, which is the difference between a boundary and a wall.
Content safety, layer two
Harm classes, evaluated on the inbound turn and again on the outbound answer, because the two directions fail differently. This is the only layer permitted to end a turn outright. When it does, the assistant refuses once and offers a route to a person, rather than explaining its reasoning, which is both an unhelpful reply and a description of the control to anyone probing it.
Personal information, layer three
Pattern and context matching, applied before anything is written to a store or a trace. It redacts in place and lets the turn continue, because a person who has just typed an account number has not done anything wrong. The unredacted value never reaches storage, which is what stops the trace store becoming a second uncontrolled copy of the conversation.
Grounding check, layer four
Runs after generation because it needs a draft to inspect. Every claim in the answer must be traceable to a passage the retriever actually returned from the versioned knowledge layer. A draft that fails is withheld rather than softened, because a hedged ungrounded answer is still an ungrounded answer and reads as more trustworthy than it is.
Output validation, layer five
Shape, length, formatting and the rules of the channel the answer is bound for. A spoken answer cannot carry a bulleted list or a link, and a messaging reply has a length the platform will truncate. This layer regenerates once. A second failure is treated as a system fault and handed over, not retried until something passes.
Channel override register
The small set of places where a channel's conventions justify a deliberately different behaviour, each recorded with the reason, the owner and a review date. The register exists so an intended difference cannot be read later as a bug, and so a bug cannot survive by looking like an intended difference. Overrides govern delivery. An override that changes an allow or deny decision is rejected at review.
Acceptance suite and regression pack
Every layer has its own suite, with an adversarial set and a false-refusal set for each, plus a channel matrix that runs the same policy cases through transcription output as well as typed input. The pack runs on every change to configuration or code, not once before go-live, because a guardrail with no test is a hope with a version number.
Guardrails tuned tight enough to be safe are tuned tight enough to be useless, and that failure is far harder to see than the one everybody guards against. An unsafe answer produces a complaint. An assistant that has quietly stopped answering half of what it could answer produces silence, and the silence reads as adoption that never arrived. The remedy is a second test set with the opposite polarity: alongside the adversarial cases sits a false-refusal set of ordinary, entirely legitimate enquiries that the assistant must answer, and a change that raises adversarial pass rate whilst dropping false-refusal pass rate fails the pack. Neither number is allowed to be reported without the other. That is also the only honest way to argue about a threshold, because a threshold argued without both numbers is settled by whoever is most worried in the room.
What changed in the operating model
- A policy decision is made once and rendered three ways, rather than implemented three times and reconciled after a transcript review.
- The layers run in a stated order for a stated reason, so adding a sixth layer is a decision about where it belongs rather than an append.
- A guardrail firing is recorded as what it did, redirect, block, redact or withhold, so the shape of intervention is visible instead of a single count that hides it.
- A channel exception has an owner, a rationale and a review date, so a deliberate difference cannot be mistaken for a defect a year later, and a defect cannot hide as a deliberate difference.
- Guardrail configuration moves through the same review and release path as application code, and is versioned with it, so a policy change is as inspectable afterwards as a code change.
- A tightening is now argued with two numbers rather than one, which is what stopped the slow drift towards an assistant that is safe because it answers nothing.
Continue into the evidence
More case studies
Governed agent tooling for enterprise AI operations
One governed toolset for an enterprise platform’s management surface, designed and operated by Humint Labs to make authority, tenant isolation and auditability executable.
Industry: Insurance
Answering insurance enquiries, escalating everything else
Humint Labs designed and delivered a grounded service layer that resolves routine insurance enquiries, equips agents with usable evidence and escalates consequential matters with full context.
Automated regression assurance for retrieval-grounded agents
Humint Labs delivery that turns retrieval and generation evidence into a fast, repeatable release decision.