How we govern AI on a production network
Chaparral Wireless Networks · v2.1 · 2026-08-02
We run an AI agent, NICK, on a live wireless and cable network serving real customers. This document states what it is allowed to do, what it is not allowed to do, and how those limits are enforced.
We are publishing it because NCTC, the buying co-op we belong to, surveyed its members on AI in May 2026 and found that 44% of member companies lack AI governance frameworks — reported by Amy Maclean in "NCTC Members Test AI's Potential," Cablefax, 29 July 2026. NCTC's VP of Group Purchasing put the same finding in plainer words: members are using AI, but members don't have a strategy. Members need governance help. Every operator we've spoken to is being asked the same questions by their own counsel. We'd rather hand over our answers than describe them.
Nothing in here is aspirational. Where a control is enforced in code, we say so. Where it is a process a person has to follow, we say that too — because the difference matters, and we learned that the hard way.
1. What NICK is
An operations agent wired into the systems that actually run our network — monitoring, device inventory, configuration history, subscriber provisioning and ticketing. We call that collection ground truth.
NICK is not a model we trained. No operator our size trains models, and anyone claiming otherwise is selling something. What we built is the integration and the controls: what it can reach, what it is required to check before it answers, and what it cannot do without a person.
We do not publish the vendor list for the AI stack itself — the model provider, the voice and speech engines, the monitoring and inventory products it reads from. That is a commercial decision, not a security one.
We do publish the plant we work on — the radio, switching and cable gear our services cover. That is a competency, not a recipe: an operator deciding whether we understand their network needs to know we've touched their equipment. The two are different things and we treat them differently.
2. The first rule: it answers from ground truth, not from memory
An AI that recalls a fact confidently is more dangerous on a production network than one that admits it doesn't know.
So NICK is required to resolve facts from live systems rather than recall them. For the categories where a wrong answer costs real money, that requirement is enforced in code, not asked for in instructions:
- Billing figures are resolved from the system of record, and it reports where each value came
from. NICK cannot state a rate, a quantity or a total from memory, or from something said earlier in a conversation. (Enforced.)
- Contact details are resolved from a maintained directory. It cannot invent an address. (Enforced.)
- Storage locations are resolved from the system of record. It cannot guess a path. (Enforced.)
- Device and network facts are resolved from live query, monitoring and inventory, in that order of
precedence, with documentation ranked below all three. (Process.)
Why it exists: we had a class of failure where figures were restated from memory and conflated across jobs. The fence came out of that.
3. "I don't know" is a valid answer
NICK is expected to say when it cannot resolve something, and to distinguish between "I couldn't reach it," "I reached it and was refused," and "it isn't being monitored" — because those are three different problems and reporting the wrong one sends a technician to the wrong place.
It is also required to exhaust the obvious paths before declaring anything unreachable, and to wait long enough before verifying, because checking too early produces false failures.
Why it exists: NICK once declared a live concentrator unreachable based on one stale address. The device was fine. The real problem was a credential. A confident wrong answer cost more than no answer would have.
4. Nothing changes unseen
Every change to the network — whether NICK proposes it or a person does — carries:
- Pre-change review against the systems of record
- A ticket
- An entry in a change journal every surface writes to and can query before claiming something
did or didn't happen (the journal itself is code and always runs; but it is append-by-convention, not append-only by mechanism — the agent holds a credential that could rewrite history. Making it tamper-evident is on the list in §10, and until then we won't call it what it isn't.)
- Post-change verification
Read-only is the default posture. Approval is granted per action, never per session — agreeing to one change does not authorise the next one.
Why it exists: an undocumented configuration change took a large institutional customer offline. It took roughly 48 hours to trace, and most of that was spent working out what had changed. The journal exists so that question is never expensive again. We wrote that incident up internally; it is the reason the process exists at all.
5. Human gates on anything that reaches the public
We run a local cable channel produced with AI. The gates are specific:
| Content | Gate | Enforced? |
|---|---|---|
| Viewer submissions | Approved or rejected individually by a named person before entering the air queue; reviewer and timestamp recorded | ✅ In code. Nothing reaches the queue without a click, and playout draws only from approved items |
| Programming | A person approves each show format, and the checker that holds anything outside it now runs in the air path — a failed check parks the episode instead of airing it. Coverage is partial by design: it applies only to programmes that declare an approved format, which today is 2 of 23. The rest are governed by process, not mechanism | ⚠️ In code and enforcing where it applies — 2 of 23 programmes covered. See §10 |
| Air itself | Arm-gated. Unarmed, the scheduler recommends and does not act. One controller owns the channel; production hosts are blocked from airing at all | ✅ In code |
Why the last one exists: two systems once aired to the same channel simultaneously and garbled the output. The guard came out of that.
6. What it is not allowed to discuss
What NICK will talk about changes with who is in the conversation. For restricted participants, the internal capabilities are removed from the agent rather than discouraged by instruction, with a refusal at execution time and a notification if it's attempted.
Why it exists: we previously relied on a written rule telling the agent not to discuss internal tooling. It lost that instruction during an ordinary conversation and disclosed things it shouldn't have. Nobody was harmed, but the lesson was structural and we now treat it as a design principle:
A rule written in a prompt is a request. Only code is a control.
That distinction is why this document labels every control as enforced or process. Anyone publishing a governance framework that doesn't make that distinction is describing intentions.
7. Callers are told they're talking to an AI
Our customer line is answered by an AI assistant. It says so in its opening line on every call, before anything else happens and whether or not anyone asks. The greeting is checked in code before it is spoken: if the disclosure is missing from it, a known-good disclosing greeting is substituted.
Verified by placing a live call on 2026-07-31 — which is the only way to check this that we trust.
If a caller asks in any form — are you a real person, am I talking to a human, is this a recording, are you a bot — it answers plainly that it is an AI, before answering anything else. It is not permitted to deflect that question, and it will not. That path is enforced by a gate, not requested in instructions, and it answers in the language the caller used: a caller who asks in Spanish is told in Spanish that they are speaking to an artificial intelligence.
Where this falls short, stated plainly. The opening line discloses in English only. The Spanish in the greeting is an offer to switch language, not a disclosure. So a Spanish-speaking caller who never asks hears the offer and not the fact. We serve a majority Spanish-speaking community, and a disclosure half our callers may not parse is a weaker disclosure than we are comfortable claiming.
An earlier version of this document said the greeting discloses in both languages. It does not, and we would rather correct it here than leave it standing. Fixing the greeting itself is a change to a live customer-facing line and is on the list in §10.
It will decline to tell you which technology it runs on. Those are different things: the fact is public, the recipe is not. And a caller can ask for a person at any point in the call — the greeting says so out loud.
We didn't do this because a rule required it. New Mexico has no AI-specific disclosure law, and there is no federal rule written for an AI answering an inbound support line. A handful of states have passed chatbot disclosure laws with varying scope, and several of them expressly exclude customer service bots — so the specific obligations mostly don't reach us.
What does reach us is general deception law. Federal and state consumer-protection rules apply to any business's representations, including ours, and "we never actually said it wasn't a person" is a thin place to stand. We disclose up front because the alternative is a company that is technically truthful, and every example we studied of that going wrong looked fine right up until it didn't.
✅ Update, 2026-07-31 — this is now a mechanism rather than an instruction. The previous version of this page said the behaviour came from the agent's instructions and warned that instructions are not controls (§6). That gap is closed: a check now runs before anything is spoken. If the opening line doesn't disclose, it is replaced with one that does. If a reply to "are you a real person?" omits it, the disclosure is put back in front. Both substitutions are logged, so we can see when the model drifted rather than assuming it didn't.
Deliberately, "virtual assistant" and "in-house assistant" do not count as disclosure in that check — avoiding the word while sounding like a disclosure is the exact drift it exists to catch, and it is what we found when we audited ourselves.
8. Customer data
- Our hosted voice service is a telecommunications service, so customer proprietary network
information rules attach to it: used only for the purpose collected, safeguarded, with breach notification and annual certification. We apply the same handling to broadband and video customer records, which is a choice rather than an obligation — those sit under general consumer-protection law, not the carrier rules.
- Sensitive identifiers used for authentication are hashed locally. Where a caller's identity has to
be checked against something sensitive, the check happens without that value leaving our environment.
- Access to the management plane is segmented: our public-facing hosting cannot reach internal
monitoring, inventory or databases. That segmentation is enforced at the firewall and has been verified by test, not assumed.
We do not yet publish a data-retention and model-training statement. We would rather leave that blank than state something we haven't verified against our actual agreements. It's on the list.
9. What we don't claim
Governance documents are usually a list of virtues. These are our limits:
- Nothing here has been audited by a third party. Every control is self-attested. Logs we generate
are our claims, not independent evidence — and we'd say the same about anyone else's.
- Most change controls are process, not code. The journal and the audit trail are enforced. "Get
approval first" is discipline, and discipline fails.
- We have not eliminated the possibility of the agent being wrong. We've tried to make being wrong
cheap, recoverable and visible instead of silent.
- We are the vendor and the customer. NICK runs our own network. That gives us real operating
evidence and an obvious incentive to present it favourably. Weight it accordingly, and ask us for the incidents rather than the wins.
10. Where the build stands against this document
We said in an earlier draft that programming-level validation was "being implemented." It is built.
Every generated episode is checked against its approved format envelope before it can air — duration, resolution, frame rate, codec, audio presence, and a full decode of the file rather than a header check, because a truncated file that reports as healthy has put partial content on air before.
It fails closed. A missing format manifest, an unreadable one, a manifest nobody has signed, media that won't probe, a timeout, or an unexpected crash in the checker itself all produce the same result: the episode is held, not aired. There is deliberately no path through that code where an error results in airing — a crash must never be indistinguishable from a pass. A format with no named approver holds everything.
Updated 2026-08-01 — it is now wired into the air path. The playout script runs the check before a programme airs and refuses to air on a park verdict. Verified on the live playout host: the check is deployed, no bypass flag is set, and it defaults to enforcing.
And it is observably running, not merely installed. In the seven days to 2026-08-01 it recorded 14 verdicts on real episodes as they went to air — every one a pass. We are stating that number rather than the word "enforced" for a reason: it has passed 14 things and stopped none. The stop path is covered by tests, not yet by production. A gate that has never refused anything in the field has not been proven in the field, and we would rather publish that distinction than let a green log stand in for it.
What is still true, and it is the part that matters: coverage is partial. The check only applies to programmes that declare an approved format, and today that is 2 of 23 — the two that carry a measured, signed envelope. The other 21 pass through ungated and are governed by the human process above, not by the mechanism. We are not going to describe this channel as machine-gated until that number is most of the way to 23.
Why we haven't simply switched the rest on: an envelope has to be measured from the real library before it can be enforced. The two that are covered were measured across every episode then in rotation. Declaring a format with plausible-looking default values would park an entire catalogue on first run — which is the same failure as not checking at all, just louder. Measuring the remaining formats is the open work.
What this document still owes, with dates
Spanish disclosure in the opening line (§7). The greeting discloses in English only; the Spanish disclosure fires when a caller asks or speaks Spanish. In a majority Spanish-speaking market that is the weaker of the two arrangements and we know it. The fix is a change to a live customer-facing voice line, so it gets its own approval and its own verification call rather than being slipped in.
Naming these is the point of the section. Undated, they'd be a standing invitation to test us.
| Owed | Target |
|---|---|
| Wire the episode checker into the air path | Q3 2026 |
| ✅ | |
| Make the change journal tamper-evident rather than append-by-convention (§4) | Q4 2026 |
| A published data-retention and model-training statement (§8) | Q4 2026 |
| A stated evaluation regime — replaying known past failures against the agent on every change | Q4 2026 |
| A published position on prompt injection: NICK reads tickets and monitoring output, both of which outsiders can write into | Q4 2026 |
Two gaps that were named here in v1.1, and are now closed
Stop authority. One named person — our systems engineer — holds sole authority to stop the agent, with a scoped subset delegated for customer-facing surfaces. There are four defined levels from mute to revoke, each with the actual commands, a time target, and an explicit statement of what breaks at that level. The design rule the whole plan rests on: stopping the agent must never require the agent. Every path is executable by a human with shell access and nothing else.
⚠️ Honest limits, stated in the plan itself: authority is single-point today with no sealed break-glass credential for an alternate; levels 1–3 stop the agent but not a person with shell access; and the plan has not yet been rehearsed end to end, so its time targets are estimates rather than measurements. A drill is scheduled work.
Change control on the agent itself. §4 governs changes to the network. Changes to the agent — its instructions, its tools, its personas — are now covered by a regression suite that asserts the promises in this document are still present in the shipped configuration. It replays the two failures we have actually had: the disclosure guard from §6 and the voice greeting from §7. If a change removes a promise we published here, it fails there rather than on a customer call.
⚠️ What that suite does not do: it is static. It reads the shipped configuration; it does not invoke the model and cannot prove the model obeys its instructions. It proves the promise is still present and consistent — which is precisely the drift that bit us twice. Behavioural testing against a live model is a separate and later thing, and we would rather say that than let a green test stand in for a guarantee.
11. Why we published this
Every failure in AI media and AI operations we've studied — and we studied them before writing this — came from an oversight or disclosure gap, not from the technology being insufficiently clever. The organisations that got hurt had all described their systems more confidently than their controls justified.
We would rather be the operator whose governance document was too honest than the one whose marketing was.
12. What we will and won't answer
We invite challenges to this document, and we mean it. But an open invitation to answer hard questions, published next to an email address, is also a reconnaissance surface — so it's worth being precise about where the line falls, rather than deciding case by case with someone waiting on a reply.
We'll answer questions about:
- Any control described here — what it does, how it's enforced, where it's weak
- Outcomes, including bad ones: what has gone wrong, what it cost, what changed afterwards
- Our reasoning, and anywhere you think it's mistaken
- Anything in this document you believe is inaccurate. That one especially
We won't answer questions about:
- Which vendors, models, products or versions sit underneath any of it
- Network topology, addressing, hostnames, or how systems reach each other
- Credentials, access paths, or who holds which permissions
- Named staff, their access, or their responsibilities beyond what's stated here
That second list isn't evasion and it isn't about embarrassment. Those are the details that help someone attack the network, and none of them are needed to evaluate whether our governance is sound. A reviewer can judge every claim in this document without knowing a single product name — which is rather the point of writing it the way we did.
If you think something in the second list is genuinely necessary to assess a claim in the first, say so and make the argument. We'll consider it. We just won't be talked into it in the moment, which is why this section exists.
Corrections, challenges and requests for detail: we'll answer them, including the uncomfortable ones — within the boundary above.
Chaparral Wireless Networks · Chaparral, New Mexico · v2.1, 2026-08-02. Versioned. Material changes update the version and the date.