The Capability Test: CIPA Risk After the Verizon-Google AI Deal

The legal problem in the Verizon-Google AI data center deal is not that a dark-fiber contract proves anything improper about customer calls. It does not. The problem is that, while telecom infrastructure and cloud AI services keep moving closer together, a federal court has already allowed a California wiretapping claim to proceed on a narrower and more uncomfortable theory: an AI vendor may be exposed when its contracts and product architecture plausibly allow it to use call data for its own purposes, even if the complaint does not allege that the vendor actually did so.

That is the practical bite of the February 2025 order in Ambriz v. Google LLC, No. 3:23-cv-05437, in the Northern District of California. The court denied Google’s motion to dismiss a claim under California Invasion of Privacy Act § 631(a) after concluding that the plaintiff plausibly alleged Google had both the technical and contractual ability to use customer-service-call data for its own ends through Cloud Contact Center AI. The reported terms mattered because they disclosed that Google may use data collected on customer service calls for its own purposes with permission from the business client.[1]

For companies deploying third-party AI monitoring, transcription, call review, or quality-assurance tools, that distinction changes the audit. The first question is no longer only, “Did the vendor misuse the call data?” It is also, “What could the vendor plausibly do with the call stream under the agreement, the product settings, and the system design?”

What the Ambriz order actually changed

The procedural path matters because Google had already won once. In June 2024, Judge Rita F. Lin dismissed the CIPA theory under the statute’s “agent of a telephone company” exemption. The later order revived the case at the pleading stage, not because the court found actual misuse of customer calls, but because it accepted a different way of testing whether a third-party technology provider can be treated as more than a service extension of the company on the line.[1]

The dividing line is the difference between the “extension” test and the “capability” test. Under an extension-style analysis, the vendor is often framed as a tool or conduit for the company using it: software plugged into a call center so the business can route calls, generate transcripts, assist agents, or review service quality. If the vendor is only functioning as the company’s extension, the argument that it is a separate eavesdropper becomes harder.

The capability test asks a sharper question. It looks at whether the third party had the ability to use the communication for its own independent purposes. That inquiry is not confined to a post-discovery log of actual uses. At the pleading stage in Ambriz, the reported combination of product architecture and Cloud Contact Center AI terms was enough to create a plausible inference that Google could do more than merely process calls for the business client.[1]

That does not make liability automatic. It does not settle whether Google actually used any particular customer’s call for a separate purpose. It also does not mean every court applying California law will accept the capability test in the same way. The research record here supports a narrower conclusion: in at least this federal case, at this stage, allegations about a vendor’s technical and contractual ability to repurpose call data were enough to keep a CIPA § 631(a) claim alive.[1]

Capability lives in the quiet parts of the contract

The dangerous sentence is rarely the one that says the vendor will “support quality assurance” or “provide AI-powered agent assistance.” Those clauses describe the service the buyer thinks it purchased. The capability problem usually appears later, in the data-use language: product improvement, model training, benchmarking, analytics, service development, security monitoring, aggregated insights, or use “with customer permission.”

In Ambriz, that permission structure mattered. The reported Cloud Contact Center AI terms did not merely describe Google as passively relaying a call between a customer and a business. They allowed an inference that, if the business client granted permission, Google may use the call data for Google’s own purposes. For CIPA pleading purposes, that was the lever.[1]

A compliance review that stops at “the vendor says it does not sell personal information” will miss the issue. Sale is not the only possible independent use. Nor is a promise of confidentiality necessarily enough if another clause authorizes learning from call content, retaining transcripts, evaluating agent inputs, training or tuning models, creating derived data, or using interaction data outside the buyer’s immediate service process.

The same lesson applies beyond call centers. Law firms and legal departments using cloud voice tools already face a parallel review problem: before a recording, transcript, or summary is routed through an AI service, someone has to know what the vendor can retain, inspect, train on, or disclose. That is why the privilege-oriented workflow in AI Transcription and Privilege Waiver: A Risk Framework for Law Firms translates so well to consumer-call monitoring: the useful audit is not limited to what the tool produces, but follows what the vendor may do with the input.

Where the Verizon-Google deal fits, and where it does not

The July 24, 2026 Verizon-Google dark fiber agreement belongs in this analysis, but only with discipline. Reuters reported that Verizon signed a deal with Google worth more than $1 billion to provide fiber capacity, a transaction tied to Google’s infrastructure needs.[2] That is a significant commercial relationship. It is not evidence that customer-service calls travel over any particular route, that a specific data center is involved in any challenged call flow, or that the infrastructure deal changed Google’s Cloud Contact Center AI data practices.

The public reporting identified the value and basic nature of the deal, but it did not disclose enough about route geography, duration, or legal structure to infer surveillance mechanics from the fiber arrangement. Treating dark fiber as a shortcut to a wiretapping conclusion would be sloppy. Fiber capacity can support many ordinary cloud and network functions; the legal issue in Ambriz arises from the alleged call-monitoring product architecture and data-use permissions, not from the mere existence of telecom infrastructure.

Still, the deal makes the litigation harder to treat as a small vendor-contract footnote. Verizon appears in the Cloud Contact Center AI context and is also commercially tied to Google’s infrastructure buildout. For counsel, that combination is strategically relevant because it places customer-service AI, telecom scale, and cloud capacity in the same operational ecosystem. The strategic significance is narrower: large AI infrastructure partnerships increase the urgency of understanding how call data rights are allocated when cloud AI products sit inside customer-service channels.

A separate report has described a $5 billion Arizona state-law class action related to this broader set of issues, but that matter should be treated as a flagged related proceeding unless its complaint, docket, and procedural posture are independently confirmed. It should not carry the analysis until the underlying materials are checked.

The consent problem is now a capability problem

Many customer-service consent scripts were built for recording, not for third-party AI participation. “This call may be recorded for quality assurance” tells the customer something about the company’s use of the call. It may not tell the customer that a separate cloud AI vendor receives, analyzes, retains, or may use the call data under permissions granted by the business client.

The capability test makes that gap more expensive. If the vendor’s agreement allows independent use, the company cannot safely evaluate notice by asking only whether the customer knew the company would record the call. The more precise question is whether the customer was told enough about the third-party role that the company can defend the interception, processing, and permitted downstream uses in the jurisdiction at issue.

Consent also has to be jurisdiction-specific. The research record does not support a universal rule that every court will adopt the capability test, and CIPA doctrine remains uneven across state and federal decisions. That uncertainty does not help the company that has already deployed the tool nationally with one generic script and no record of which vendor permissions were active in California call flows.

Vendor contracts need less comfort language and more disabling language

A contract can say the vendor is a service provider, processor, or agent and still leave open the functional question that matters under the capability test. Labels help, but they do not answer whether the vendor can use the call stream for itself. The better provisions are operational: they prohibit specific secondary uses, require documented opt-outs, bind affiliates and subcontractors, and make configuration settings enforceable rather than optional.

For AI call-monitoring tools, counsel should be looking for clauses that do four things. First, they confine vendor processing to providing the contracted service to the business client. Second, they bar training, tuning, benchmarking, product development, or analytics using customer call data unless that use has been separately approved through a process that matches the notice given to callers. Third, they require deletion or return of call data across audio, text, logs, derived outputs, and support copies. Fourth, they give the buyer audit evidence: configuration exports, retention reports, subprocessors, incident records, and change notices.

The permission language deserves special attention. A vendor term that says it may use data for its own purposes “with customer permission” can look harmless to procurement because the buyer is the vendor’s customer. In a call-center setting, however, the person whose voice enters the system is also a customer in the ordinary sense. The legal review has to specify whose permission is being described, who can grant it, and whether the caller ever received notice of that grant.

Audits should map the call stream, not just the vendor name

A vendor inventory that lists “Google,” “AI transcription,” or “contact center analytics” is not enough. The audit needs to follow the call stream from the moment the caller hears the notice through routing, recording, transcription, AI analysis, storage, model interaction, human review, export, retention, and deletion. Each handoff should be tied to a contract clause and a product setting.

• Identify every third party that receives live audio, recordings, transcripts, summaries, metadata, embeddings, sentiment scores, or QA outputs.
• Compare caller-facing notices against the vendor’s permitted uses, not merely against the company’s intended uses.
• Preserve evidence of historical settings because a later opt-out does not prove what was disabled during the challenged period.
• Separate security and service-monitoring uses from product-improvement or model-development uses.
• Check whether affiliates, subcontractors, support personnel, or cross-product services can access call data under the same permission grant.

The point is not to ban AI from call centers. Transcription, agent assist, routing, summarization, and QA review can reduce real operational mess. The point is that the legal exposure does not wait for a smoking-gun training log if the plaintiff can plausibly point to a contract and architecture that allowed independent vendor use.

What should change now

Companies using third-party AI on service calls should start with the deployments already in production. Pull the governing terms that applied when the tool was launched, not just the current online terms. Confirm whether call audio, transcripts, metadata, or derived data could be used for vendor purposes. Then compare that answer with the call notice, privacy policy, consent flow, and any state-specific rules that apply to the caller.

New contracts should make independent vendor use an explicit business decision rather than a default buried in product terms. If the company wants to permit product improvement or model development, the approval should be matched to a consent and disclosure strategy. If it does not, the agreement and settings should disable those uses in language specific enough to be useful in litigation.

The Ambriz order should also be checked against PACER before any case-specific filing, board report, or risk memo relies on it, because the available research here is based on secondary reporting and later docket developments may matter. The same caution applies to related state-law class action reports whose complaints and procedural status have not been independently verified.

For now, the cleanest operational takeaway is limited but important: inventory not only what AI call-monitoring vendors actually do with customer-service data, but what the agreements, permissions, and systems plausibly allow them to do. Under the capability theory accepted in Ambriz, that difference can decide whether a wiretapping claim gets past the courthouse door.

References

1. Federal Judge Allows Google Customer Service AI Class Action to Proceed, ZwillGen
2. Verizon signs deal with Google worth over $1 billion, Reuters, July 24, 2026