Contact center AI
Your contact center AI answered. Did it follow your rules?
Performance monitoring tells you the call connected, how long it took, and what it cost. It does not tell you whether the AI said it was an AI, whether the protected‑health‑information boundary held, whether the call escalated when the member asked for a person, or whether the agent promised something it had no authority to promise.
The delineation
What your stack already records, and what none of it does.
Contact center AI is usually the most heavily instrumented AI system an organization runs, and the instrumentation is almost entirely about performance. That is worth being precise about, because the gap is narrower and sharper than “you need more monitoring.”
Already in your tenant
Recorded today
- Latency, token spend, error rate, and call volume, from your APM and your dashboards with OpenTelemetry hooks.
- Where the data sits and how it is classified, from your data‑posture and information‑governance tooling.
- Transcript retention, storage location, and who has access, from your platform and identity controls.
- A sampled quality review, from the handful of calls a supervisor listens back to each week.
Not recorded anywhere
Missing on a given call
- Whether the caller was told they were speaking to an AI — on this call, not as a policy written down somewhere.
- Whether the PHI boundary rule evaluated before the model saw the member record, and what it returned.
- Whether the escalation rule fired at the moment the caller asked for a person.
- Whether the agent stayed inside what it was authorized to commit to.
- Whether any of the four above can be shown to somebody outside your team without asking them to trust your logs.
The comparison worth drawing is not against developer tooling for language models — that is not what you are running. It is against what is already in your tenant: the observability stack with OpenTelemetry hooks, the data‑security posture tooling, the cloud provider’s governance suite. Every one of them tells you the system worked. Not one of them tells you the system followed the rules.
Verification and validation
The call completed. That is verification.
Verification asks whether the system did what it was built to do. The request was served, the response came back, the latency sat inside budget, the transcript landed in storage. Every observability tool you already own answers that question well, and answers it continuously.
Validation asks a different question: did the behavior match what the governor and the caller expected? Was the disclosure given before the agent spoke? Did the escalation path open when it was asked for? Did the agent stay inside the scope it was granted? A system can pass verification on every call and fail validation on a call that mattered.
A receipt is the record of the second question. It names the control, records that the control evaluated, and records what the control decided — on a specific call, at a specific moment, signed so the record cannot be quietly revised after the fact. That is the artifact your dashboards were never designed to produce.
Controls worth evidencing
Four controls, evidenced call by call.
These are the controls a reviewer asks about first, because each one is a runtime fact that either happened on a given call or did not. Glacis does not implement them for you. It evaluates them inline and records what they decided.
Disclosure that the caller is speaking to AI
A growing number of jurisdictions expect a caller to be told they are interacting with an automated system, and the expectation is per‑call, not per‑deployment. A receipt records that the disclosure control evaluated on this call and what it returned, which is a different claim from “the disclosure is configured in the platform.”
Protected health information at the boundary
The moment the member record reaches the model is the moment your reviewers ask about. The boundary check executes inside your infrastructure, before the crossing, and the receipt records that it ran and what it decided. The transcript and the record stay where they already are.
Escalation to a human
Escalation is the control everyone assumes works and nobody can evidence. When the caller asks for a person, when sentiment turns, or when the model’s confidence drops below the threshold you set, the receipt records whether the escalation rule fired, and if it did not, that it evaluated and declined.
Scope of what the agent may commit to
Eligibility statements, benefit quotes, appointment commitments, anything that reads to a member as a determination. The scope control defines what the agent is authorized to say and the receipt records that it evaluated on the turn where it mattered. This is the control that turns a bad call into a contained incident.
One boundary worth naming: consent
Glacis does not capture consent, and we are not going to imply otherwise. Recording notice, all‑party disclosure, and the caller’s affirmative response are product features of the contact center platform, and they sit orthogonal to the AI. What Glacis does is evidence that the consent control your platform implements actually evaluated on a given call, and what it returned. If it never ran, the receipt says so — which is the more useful finding.
From call to evidence
One member call, recorded as a governed action.
The call routes to the AI agent
Inside your environment, on the platform you already run. Nothing about this step changes, and Glacis is not in the audio path.
The disclosure control evaluates
Before the agent speaks. The arbiter records whether the disclosure your platform is configured to deliver actually evaluated on this call.
The boundary check runs locally
Before the member record reaches the model, the arbiter evaluates it against policy inside your infrastructure. The content does not leave.
Escalation and scope evaluate during the call
On the turns where they apply. Each evaluation is a decision the receipt can carry: it fired, it declined, or it blocked.
The receipt is signed and chained
One signed record per governed action, each committing to the one before it. Receipts assemble into the pack a reviewer verifies at /verify.
What one call’s receipt records, reduced to its key fields. Control names are the ones you define; these are the four this page has been describing.
Field shapes for this workflow, not a signed artifact. The verifier below loads a real receipt and checks its signatures in your browser.
Run the checks belowVerify it yourself
Run the checks in your browser.
The verifier fetches our canonical demonstration receipt — it records a clinical documentation workflow, the one we publish publicly — and checks both Ed25519 signatures and the hash commitments with WebCrypto, locally, on this page. A contact center receipt has the same structure with different control names.
Who this is for
The organization running it, and the vendor selling it.
If you run contact center AI
Several of the platforms now handling protected health information on member and patient calls did not start in healthcare. They built a strong general‑purpose product, found healthcare as a market, and arrived with something turnkey. That is not an accusation; it is a description of a maturing category.
It does mean the control evidence should not come from the vendor’s own dashboard. A validator outside the vendor’s control belongs in the contract and in the runtime, not in the quarterly report. Independent verification is what lets you stop grading the vendor’s homework.
If you sell contact center AI into healthcare
Your buyers are converging on the same question, and it is no longer answered by an architecture diagram. Self‑reported logs do not survive a serious review: they are written by the system under examination, they can be amended afterwards, and the reviewer has no independent way to check them.
A receipt the buyer verifies without trusting you is a shorter security review and a shorter sales cycle. It is also the cheapest possible answer to the question a buyer is increasingly asking out loud: who validates this other than you?
What a receipt is, and is not
The boundary of the claim.
A receipt is evidence that a defined control ran and what it decided. It is not a certificate that the system is safe, correct, or compliant, and we will not describe it as one. A receipt showing a permissive policy executing exactly as written is still a receipt; what it removes is the argument about what happened.
Receipts carry hashes and signatures, not content. The call audio, the transcript, and the member record stay in your environment. There is nothing in a receipt that could reconstruct them.
Receipts minted through the Glacis portal are countersigned by an independent witness and carry an inclusion proof against an append‑only log. Receipts minted through the SDK are operator‑signed. Both are verifiable; they are not the same claim, and the receipt records which path produced it.
Runtime coverage
What 30 days delivers.
Runtime coverage takes one named call type from instrumented to evidenced in 30 days. One workflow, not the whole contact center.
One named call type
We instrument a single call type end to end: the one your oversight committee asks about first, or the one your buyers do.
Controls defined with you
Disclosure, boundary, escalation, and scope, written as policy your team owns and can read, then executed inline by the arbiter.
A signed receipt per governed action
Hash‑chained, Ed25519‑signed, carrying the control outcomes and no call content. Portal‑minted receipts also carry a witness countersignature.
An evidence pack somebody else can check
The deliverable your reviewer, your regulator, or your buyer verifies at /verify, without taking anyone’s word for it.
Start with the call type you would least like to explain.
In 30 days it runs behind a live arbiter, and every governed action on it leaves a signed receipt your oversight committee can verify themselves.