The disclosure rule and the kill switch
Two pieces complete the policy, and both have to be written before the incident that needs them.
"Am I talking to a bot?"
Customers ask. Your policy needs the answer scripted in advance, because the honest answer is now partly a legal question:
- Utah's Artificial Intelligence Policy Act (2024, amended 2025, in force to July 2027) requires disclosing generative AI use when a consumer clearly asks — and proactively, without being asked, in high-risk interactions like financial, legal, medical, or mental-health advice. It also expressly limits blaming the AI for statements that violate consumer-protection law. "The bot said it, not us" is codified as a non-defense.
- California's B.O.T. Act (2019) is narrower than its reputation: it bars undisclosed bots used to knowingly deceive in commercial transactions, with a safe harbor for clear disclosure. It does not ban support bots — but notice the shape of the safe harbor. Disclosure is the cheap, always-available defense.
The pattern across both, and the honest-broker position anyway: when asked, answer truthfully, immediately, without weasel words. In the loop you've built, the truthful answer is also a good one — "AI drafts suggestions; a person reviews every reply, and a person is reading this thread" is a stronger trust statement than most companies can honestly make. If your workflow makes that sentence false, the fix is the workflow, not the sentence.
The kill switch is exact steps, not a principle
An eval-passed macro just misstated the refund window to a customer. What happens in the next ten minutes? If the answer involves anyone figuring out how to stop the macro, you don't have a kill switch — you have an aspiration. The policy names:
- How to pull one macro — the exact toggle, field, or config line that takes it out of suggest-first, and who may flip it (hint: anyone on shift; a kill switch with an approval queue is a decorative switch).
- How to pull all suggestions — the bigger lever for when the problem isn't one macro but the pack itself (a policy changed and the KB index wasn't updated — every macro citing it is now wrong at once).
- Who sends the correction — a named human, under their own name. The customer who got the wrong answer gets a person, not a corrected template.
- Where the incident lands — and this is the part that separates teams that get better from teams that get bitter: the failed interaction becomes a golden case in the offending macro's eval set. The macro re-earns eval-passed against a set that now contains its own failure, or it stays in review.
Step 4 is the ratchet. Blame consumes the incident; the eval set banks it. A year of incidents handled this way leaves you with the strongest golden sets in the company, each one grown from a real miss — which means the gate is hardest exactly where your deployment has actually failed before.
The checkpoint runs this entire drill in code: pull the macro, send the correction, grow the golden set, re-run the evals, watch the macro fail its own incident and land back in review-required. That's the system working.