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.
Often missing from event-level review
Questions on a given call
- What evidence supports the disclosure outcome reported for this call, beyond a policy written down elsewhere.
- What the configured PHI-boundary path reported, and what routing evidence shows about the member record.
- What escalation outcome and event time were reported when the caller asked for a person.
- What the configured authorization path reported for consequential commitments.
- Which properties an outside reviewer can check independently, and which still depend on operator evidence.
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, and the cloud provider’s governance suite. Those tools answer important operating questions, but may not independently establish what a configured control path reported for one covered call.
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 can preserve the configured path’s signed report: the named control, reported outcome, and reported event time for a covered call. Verification makes later modification of covered bytes detectable and checks key attribution; routing, contemporaneity, execution, effectiveness, and coverage require surrounding evidence.
Controls worth evidencing
Four control reports worth preserving.
These are common review questions for a consequential call. Glacis does not implement the underlying consent, privacy, escalation, or authorization design for you; a configured path can report selected outcomes, while deployment evidence establishes what actually ran and where.
Disclosure that the caller is speaking to AI
Whether an automated-system disclosure is required depends on the jurisdiction, channel, role, and use. Where a per‑call disclosure applies, a receipt can preserve what the configured disclosure control reported for a covered call; that remains different from proving that legally sufficient disclosure occurred.
Protected health information at the boundary
The model boundary is where reviewers often ask about a member record. A configured path can report the PHI-boundary outcome for a covered call. Architecture, routing, and data-flow evidence must establish where the check executed and where the transcript and member data traveled.
Escalation to a human
For a covered trigger, a receipt can preserve whether the configured path reported an escalation, allow, or decline outcome. The record does not by itself prove that the rule executed correctly or that every applicable call traversed the path.
Scope of what the agent may commit to
Eligibility statements, benefit quotes, appointment commitments, and other statements that may read as a determination need an explicit authorization design. A receipt can preserve the configured scope control’s reported outcome for a covered turn; testing and incident evidence determine whether the design contained the risk.
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 can do on a configured path is preserve the consent control’s signed report for a covered call and the result it returned. That record should be paired with platform telemetry and coverage evidence; a missing receipt does not by itself prove the control never ran.
From call to evidence
One member call, recorded as a governed action.
The call routes to the AI agent
In the illustrated architecture, the call remains on the existing contact-center platform and Glacis is not placed in the audio path. Confirm that boundary for the configured deployment.
The disclosure control evaluates
Before the agent speaks, the arbiter can record the configured disclosure control’s reported result for this covered call. The signature binds that report; platform telemetry and coverage analysis establish the underlying delivery and evaluation.
The boundary check runs locally
Before the member record reaches the model, the arbiter can evaluate it against policy inside your infrastructure. Whether content leaves that environment depends on the configured model path and surrounding systems; the resulting record does not prove system-wide data locality.
Escalation and scope evaluate during the call
For covered turns, the receipt can carry the configured path’s reported outcome: triggered, declined, allowed, or blocked. Execution and coverage require surrounding evidence.
The receipt is signed and chained
For a configured, supported path, selected governed actions can produce signed records with disclosed linkage. A reviewer can inspect supported records at /verify; coverage and completeness require separate accounting.
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
The checks run 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
An architecture diagram and mutable self‑reported logs may not answer a buyer’s questions about a particular action. A signed record can give the reviewer integrity and key-attribution checks for covered fields, while the buyer still evaluates the key owner, deployment path, completeness and control design.
That can make selected security-review questions more concrete. It does not guarantee a shorter review, a faster sale, independent operation, or acceptance by the buyer.
What a receipt is, and is not
The boundary of the claim.
A receipt reports the named control and outcome for a covered event. Verification can check supported signatures, key attribution, and integrity of the covered fields; it does not by itself establish that the underlying control executed, that the report is true, that capture was complete, or that the system is safe or compliant.
Configured receipts can carry hashes and signatures while excluding call audio, transcripts, member records, and other raw content. The receipt profile should state exactly which fields and commitments it carries.
Receipts minted through the Glacis portal may carry a Glacis service-operated witness countersignature and inclusion proof against an append‑only log. Receipts minted through the SDK or self-hosted path may be operator‑signed only. Both are verifiable, but a second signature does not by itself establish organizational independence, and the receipt records which path produced it.
Runtime coverage
What a scoped implementation defines.
For one named call type, agree the action boundary, control path, evidence profile, deployment plan, and acceptance criteria. Timing follows the verified scope and agreed plan.
One named call type
Start with a single call type and declare the covered path, exclusions, and evidence boundaries.
Controls defined with you
Disclosure, boundary, escalation, and scope, written as policy your team owns, then configured for the selected path and tested in the deployment.
Signed records for covered actions
Hash‑chained and Ed25519‑signed, with the configured profile carrying covered control outcomes while excluding call content. Portal‑minted receipts may also carry a Glacis service witness countersignature and inclusion proof.
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.
The call type you would least like to explain, to begin with.
Start with one named call path. Route its consequential actions through a configured control boundary and give the oversight committee signed records they can check — with scope and exclusions stated plainly.