← Blog

AI Data Protection for Telecom: CPNI Rules When Call Detail Reaches a Model

Parminder Singh
Parminder Singh··6 min read
Summarize with AI

FCC rules at 47 CFR 64.2005 restrict how a carrier may use customer proprietary network information, and 47 CFR 64.2011 sets a seven-business-day notification duty to the Secret Service and FBI after a CPNI breach. Care and network teams now paste that same call detail into commercial chat products. This article maps the CPNI regime onto the authenticated model request.

Compliance & Regulationai-compliancetelecomfcccpniauditdata-protection
AI Data Protection for Telecom: CPNI Rules When Call Detail Reaches a Model

47 CFR 64.2011(b) gives a telecommunications carrier seven business days after reasonable determination of a CPNI breach to notify the United States Secret Service and the FBI electronically, and bars it from telling customers or the public until seven full business days have passed after that filing. The same section defines a breach as occurring when a person, "without authorization or exceeding authorization, has intentionally gained access to, used, or disclosed CPNI." A care supervisor pasting thirty rows of call detail into a chat product to summarise a churn pattern has just moved CPNI to a party with no authorization under that rule. Nothing in the carrier's own logging records it. Getting ai data protection telecom right starts at that request.

I want to work through which CPNI duties model usage actually strains, why the carrier's existing instrumentation misses the traffic, and what the per-request record has to hold when the Enforcement Bureau asks.

TL;DR

  • CPNI use is restricted by purpose under 47 CFR 64.2005, and a model provider processing call detail is not one of the permitted purposes.
  • A disclosure to an unauthorized party meets the breach definition in 64.2011(e), which starts a seven-business-day clock to the Secret Service and FBI.
  • Carriers must keep a record of breaches and notifications for a minimum of two years under 64.2011(d), and that record has to describe the CPNI involved.
  • The February 2024 rewrite of 64.2011 was published and then delayed indefinitely, so the operative text is the older seven-day framework.

The duties model usage strains

Three obligations come under pressure once care, network engineering or marketing teams start using models on live subscriber data.

Purpose limitation is the first. 47 CFR 64.2005 permits a carrier to use CPNI without customer approval only for defined purposes, including marketing service offerings within categories the customer already subscribes to, inside wiring installation and repair, and protecting the carrier against fraudulent or unlawful use of the service. Sending call detail to a third party so a model can summarise it appears nowhere in that list. The rule also bars a carrier from using CPNI to identify or track customers who call competing providers, which is exactly the kind of analysis an analyst might casually ask a model to perform.

The breach definition is the second, and it is broader than people expect. Under 64.2011(e), a breach happens when someone without authorization, or exceeding their authorization, intentionally gains access to, uses, or discloses CPNI. An employee who is authorized to see call detail but not authorized to send it outside the carrier has exceeded authorization. The intent that matters is the intent to disclose, not an intent to cause harm.

Recordkeeping is the quiet one. 64.2011(d) requires carriers to keep a record of any breaches discovered and notifications made, and that record "must include, if available, dates of discovery and notification, a detailed description of the CPNI that was the subject of the breach, and the circumstances of the breach." Carriers retain it for a minimum of two years. A detailed description of what left is the hardest field to fill in after the fact.

The rule text to cite is older than people assume

Anyone writing a CPNI control document in 2026 should check which version of 64.2011 governs, because the answer is counterintuitive.

At 89 FR 10002, on February 12, 2024, the Commission amended 64.2011 by revising the section heading and paragraphs (a) through (e). That revision would have added a Commission notification, a 500-customer exemption threshold, a thirty-day customer notification deadline and an annual February 1 summary filing for small breaches. The amendments were delayed indefinitely. The operative text is still the older framework: seven business days to the Secret Service and FBI, no customer notice until seven full business days after that, two years of records.

I find this the most useful detail in the whole regime, because control documents that cite the 2024 language are describing a rule that has not taken effect, and a filing built on the wrong clock is worse than no filing.

Why the carrier's logging misses it

A carrier is among the most heavily instrumented enterprises that exists. Mediation systems, CDR pipelines, provisioning logs and lawful intercept infrastructure all produce records, and the compliance function knows how to read them.

None of that instrumentation sits on the path between an analyst's browser and a model provider. The request leaves as ordinary TLS to a reputable hostname. A data loss prevention tool tuned for payment cards and social security numbers will pass a list of dialed numbers, call durations, timestamps and cell site identifiers without comment, because none of those look like the patterns it matches. Classification of telecom-specific data is the gap, and I covered the general shape of it in AI data classification.

The agentic pattern widens it. Carriers now run workflows that triage trouble tickets, draft customer communications and summarise network events. Those services read subscriber records by design and call models on shared service credentials, so the record names a service account and never the supervisor whose question started the chain.

What the record has to carry

The record that answers the Enforcement Bureau gets written when the request leaves the authenticated user, before any response comes back.

Per request, the useful content covers the timestamp, the employee authenticated through the carrier's identity provider, that person's role and business unit, the calling application or agent, the destination provider with model name and version, the classification applied to the request body, whether the content held CPNI, the policy version in force, the enforcement outcome, and a hash of request and response.

The subscriber axis carries the weight here. An FCC inquiry or an internal investigation asks about accounts and date ranges, so retrieval by subscriber identifier, by employee, or by time window is what makes the record usable. A record keyed only to employee and timestamp forces a reconstruction that nobody finishes inside seven business days. The cross-regulation view sits in audit trail requirements by regulation.

Two structural points. Storage has to sit outside the reach of the applications that made the requests, because the employees being recorded operate those same systems. And retention has to clear the two-year floor in 64.2011(d) with room for the state notification regimes that 64.2011(f) leaves standing.

The seven-day clock is the reason to enforce inline

Most CPNI controls are written as policy and enforced by annual training and an officer certification. The notification clock deserves better, because the consequence of missing it is a filing failure on top of whatever caused the disclosure.

An inline enforcement point can treat requests carrying CPNI markers differently from ordinary operational traffic, routing them to an internal model or refusing them outright. A refusal produces a record showing the control operated at the moment somebody tried, which is more valuable than a clean log. More importantly, when something does get through, the record already holds the detailed description of the CPNI involved that 64.2011(d) asks for, and the clock starts with the facts in hand. Blind spots in outbound model traffic are the general case, covered in shadow AI.

DeepInspect

DeepInspect is a stateless proxy between authenticated users or agents and any LLM endpoint. Identity resolution, classification of the request body, model routing and policy enforcement run inline on the HTTP request before it reaches the provider, which puts an enforcement point in front of exactly the traffic the CPNI rules care about.

Each decision writes a signed record carrying the authenticated employee, the role and business unit, the classification applied, the destination model and version, the policy version in force, the outcome and the timestamp. Records commit to append-only storage before the response returns, retention configures past the two-year floor in 64.2011(d), and retrieval by person, subscriber, model version or time range completes in seconds. The boundary covers authenticated HTTP traffic between your people or agents and the models they call. The CPNI officer role, the annual certification, breach determinations and the filings to the Secret Service and FBI stay with the people who own them today.

If your care team is summarising churn in a chat tab and your logs show a hostname, the purpose limitation is the control already failing. Book a demo today.

Frequently asked questions

Do the FCC's CPNI rules mention artificial intelligence?

No. Part 64 Subpart U describes information, purposes and duties without naming technology. AI usage enters scope because CPNI moves through it, which is why the scoping work belongs with the carrier's CPNI officer and counsel and not with a tool vendor.

Is pasting call detail into a chat product a reportable breach?

It meets the elements in 64.2011(e) if the recipient lacked authorization, and the determination is the carrier's to make on the facts. What the carrier needs is a record precise enough to make that determination from evidence instead of from interviews, because the seven-business-day clock runs from reasonable determination.

Does an enterprise agreement with the model provider fix the purpose problem?

A contract about training and retention addresses vendor risk and produces no evidence about individual requests. 64.2005 restricts the purposes for which CPNI may be used, and a commercial agreement does not add a permitted purpose to the rule.

Does anonymising the numbers put the data outside CPNI?

Removing dialed digits leaves durations, timestamps, locations and service configuration, and those are the substance of what the rules protect. Aggregate customer information has its own treatment in the rules, and reaching it requires real aggregation rather than masking a column.