The Four Gates
If you want AI in CX to scale without blowing trust, you need gates. Not a committee. Not a document nobody reads. Working stop rules.
Truth · Safety · Recovery · Audit
Why governance gates matter for AI in customer experience
Governance in most organisations means committees, review boards and documents that nobody reads after approval. That model does not work for AI in customer experience, where decisions happen in milliseconds and the cost of getting it wrong is measured in customer trust, not compliance checklists. The four gates replace bureaucratic governance with working stop rules — conditions that must be met before a behaviour is allowed to run, and defined fallbacks for when they are not.
The cost of scaling without controls is not hypothetical. It is the chatbot that confidently gives wrong refund information because nobody defined what "confirmed refund" means. It is the routing logic that sends vulnerable customers to a bot because nobody specified safety checks. It is the moment that fails silently because nobody defined what success looks like or how to detect failure. Gates prevent all of this — not by slowing things down, but by making the rules explicit before the service goes live. This is the governance layer that sits on top of behaviour specs and makes them safe to scale.
Gate 1
Truth
Are we confident enough in what we believe is true?
Validates data freshness, source reliability, and confidence levels before decisions are made.
Prevents: Acting on stale or unverified data
Checks
- ✓Data freshness
- ✓Source of truth
- ✓Confidence threshold
- ✓Conflicts between systems
- ✓"Unknown" handling
If gate fails
Fallback to safer behaviour (inform/advise) or escalate.
Gate 2
Safety
Is this response appropriate for the customer and situation?
Ensures fallback paths exist and failure modes are understood before automation scales.
Prevents: Automated harm at scale
Checks
- ✓Vulnerability indicators (where applicable)
- ✓Emotional context / high-stress moments
- ✓Risk of harm or misdirection
- ✓Tone constraints and prohibited actions
If gate fails
Human handover or constrained response.
Gate 3
Recovery
If it fails, how do we detect and recover?
Requires observable outcomes and early warning signals before expanding scope.
Prevents: Scaling before proving value
Checks
- ✓Outcome definition for the moment
- ✓Logging of signals and decisions
- ✓Feedback capture
- ✓Monitoring and alert thresholds
If gate fails
Don't scale. You're driving with your eyes shut.
Gate 4
Audit
Can we explain what happened and why?
Confirms regulatory requirements are met and decisions can be explained on request.
Prevents: Regulatory risk
Checks
- ✓Privacy/consent boundaries
- ✓Regulated actions (finance, health, vulnerable customers)
- ✓Policy enforcement rules
- ✓Audit requirements
If gate fails
Restrict behaviour, redirect, or escalate.
How the four gates work together
The four gates are not independent checklists. They follow a sequential logic where each gate enables the next. Truth comes first: if you cannot verify what you believe about the customer's situation, no amount of safety checking will help — you are protecting the wrong decision. Safety comes second: once you know the truth is reliable, you can assess whether the intended response is appropriate for this customer in this moment. Recovery comes third: if the behaviour passes truth and safety but you have no way to detect failure or capture feedback, you are scaling blind. Audit comes last: if you cannot explain what happened and why, you cannot learn, you cannot comply, and you cannot earn trust at scale.
This sequence matters because it prevents a common failure mode: organisations that invest heavily in audit and compliance while ignoring truth quality. They can explain every decision — but the decisions themselves are based on stale data and untested assumptions. The gates force a bottom-up discipline: get the truth right first, then make it safe, then make it recoverable, then make it auditable.
A practical way to define gates
For each behaviour:
- 1Define pass conditions
- 2Define fail behaviour (fallback/escalate)
- 3Define stop rules
- 4Define what gets logged
- 5Define who owns review
Gates in practice: what good looks like
A well-governed adaptive moment looks like this: the service detects a delivery delay using verified signals. It checks the truth contract — the carrier API confirms the delay, freshness is within threshold, confidence is high. It checks safety — the customer is not flagged as vulnerable, the tone is appropriate for the situation. It logs the signals, the decision and the outcome. And if the behaviour fails — the customer contacts support anyway — the recovery gate captures that feedback and feeds it back into the behaviour spec.
A poorly governed moment looks like this: the service detects a possible delay based on an estimated delivery window. It sends a proactive message with compensation — but the delivery arrives on time. There is no recovery mechanism, so the error goes undetected. There is no audit trail, so when the pattern repeats across thousands of customers, nobody knows why compensation costs have increased. The difference is not technology. It is whether the framework was applied.
Ready to put gates into practice?
The Reality Check helps you understand where your gates need strengthening.