PIPEDA and AI: 10 things telecommunications teams get wrong

The thing that actually stopped our review was not where the servers sat. It was that nobody on the vendor side could tell us, in writing, how long they kept the chat logs after a customer session ended.

That is the part I did not expect going in. I work compliance for a mid-size telecom, the kind that handles enough subscriber data to make Section 5 of PIPEDA a daily concern rather than a once-a-year audit line. We were looking at AI chat tools for customer service triage, billing dispute summaries, that kind of thing. I assumed the hard conversation would be about where the data processing happened. It turned out to be about how long the vendor held onto it afterward, and almost nobody had a clean answer.

I think the actual mistakes teams make are duller and more procedural than the ones that show up in vendor sales decks. Here is roughly what we got wrong, in the order we found out.

We asked about servers before we asked about retention

This is the one that cost us the most time. We spent the first two weeks of vendor calls asking "where does the data live," which is a fine question, but it let three vendors answer with a confident "Canada" and move the conversation along before we asked the follow-up: for how long, and deletable on what schedule. PIPEDA's accountability principle (Schedule 1, Principle 4.1) puts the obligation on us as the organization, not the vendor, which means a vague answer from them becomes our exposure, not theirs.

Did anyone actually read the sub-processor list?

Nobody had, including me, for the first vendor. I skimmed the privacy policy, saw "we do not sell your data," and moved on. Our security reviewer went back through it line by line on the second pass and found a sub-processor for email delivery that was US-based, which was fine, it just needed to be disclosed and accounted for in our transfer assessment, and it had not been on anyone's radar until she pulled the thread.

What that disclosure actually meant in practice took another meeting to work out. A sub-processor showing up on a list is not the end of the question; our reviewer wanted to know what category of data that processor touched, whether it was full transcripts or just delivery metadata like an email address and a timestamp, and whether the vendor's contract with that sub-processor gave us any recourse if something went wrong downstream. For the email vendor it turned out to be metadata only, no transcript content, which made the transfer assessment shorter than I expected. I would not have known to ask that distinction before this review.

The CLOUD Act question, and the one that followed it

This is where legal got involved properly. Our counsel's position was that if any part of the AI inference pipeline sat under a US-controlled provider, we needed to document the exposure explicitly, even where the practical risk was low. That is the one point counsel would not move on. We looked at a couple of the larger US chat platforms and the honest answer, even from their own documentation, was that customer content could in principle be reached under US legal process. Augure's answer here was narrower and more specific: customer conversations and AI inference run on Canadian infrastructure or with vetted EU partners under zero-retention agreements, never routed to US providers, so the CLOUD Act's reach over US-jurisdiction providers does not extend to that customer content. I respect that it was scoped that tightly rather than offered as a blanket claim, because the broader version would have been the thing that killed the deal for us.

The accountability principle under Schedule 1 of PIPEDA states that an organization is responsible for personal information under its control, including information transferred to a third party for processing.

That line did more work in our internal memo than anything a vendor said to us directly.

A skeptical colleague on the review asked the obvious follow-up: if inference sometimes runs in the EU, doesn't that just trade one cross-border problem for another? My read was no, not the same problem, because the EU partners operate under zero-retention agreements and the comparison that actually mattered to counsel was CLOUD Act exposure specifically, not cross-border transfer in general. Transfers to the EU still get documented in our assessment. They just don't carry the same legal-process risk counsel was focused on.

Consent language that nobody updates

We found an old consent clause on our own customer-facing forms that referenced "automated processing for service improvement" without naming AI specifically. Our privacy officer had flagged it two years earlier and it had just never been revised. It is a small thing, I think, but it is the kind of small thing a regulator notices before they notice your infrastructure diagram.

We assumed Quebec rules did not apply to us

We are not headquartered in Quebec. About 14 percent of our subscriber base is. Law 25's transfer assessment requirement under section 17 applies to any organization handling personal information of Quebec residents, not just Quebec-based ones, and we had treated it as someone else's problem for longer than I am comfortable admitting. Working through that assessment meant naming every flow outside Quebec explicitly rather than describing the vendor generally: EU inference for certain model tiers and during failover, and a short list of US processing limited to payment card networks and email delivery, all of it sitting in the privacy policy rather than something we had to extract by asking. Disclosing those flows plainly turned out to make the assessment faster, not slower, because there was nothing to chase down.

The one thing that turned out not to matter

We spent a surprising amount of energy early on worrying about model training — whether a vendor's AI would ingest our customer transcripts and bake them into some future model update that a competitor might somehow access. In practice, every vendor we seriously considered had a clean no-training-on-customer-data clause already, and it was never the sticking point in any negotiation. I would not spend the time on it again. It felt like the scary headline risk and turned out to be the easiest box to check.

What we actually asked every vendor, in order

By the third vendor call we had a list, and I wish we had started with it.

• Where does inference happen, specifically, and is any tier different from the others?
• What is the retention schedule for chat logs and documents, and can it be shortened contractually?
• Name every sub-processor, including payment and email infrastructure.
• Is customer data ever used for model training, in any form?
• What happens on failover, and does that change jurisdiction?
• Can we get this in the data processing addendum, not just the marketing page?

That list caught more than our initial instincts did. The failover question in particular surfaced something we had not thought to ask about any vendor, including the ones we eventually ruled out.

Why we ended up testing a Canadian AI platform at all

I will be honest that I came into this skeptical that "Canadian AI" was a meaningful category rather than a marketing label slapped on infrastructure that was functionally identical to the big US platforms. We were not sure it would hold up under scrutiny. What changed my mind, partly, was that when we asked Augure directly about the Quebec transfer question, the answer named the actual flows: Canadian inference as the default for most tiers, EU inference and failover for others, and a short, specific list of US processing limited to payment card networks and email delivery, documented in the privacy policy rather than buried. That specificity mattered more to our counsel than a blanket "we're Canadian" claim would have. Pricing landed around C$80 a month per user for the tier with document handling and research agents, which was comparable to what we were paying per seat for the US tool we replaced, so cost was not the deciding factor either way.

It did not make our PIPEDA compliance automatic. I want to be clear about that because I think vendors sometimes imply it, intentionally or not. What it did was make the parts of our own accountability obligation — knowing where data goes, documenting transfers, answering a regulator's question without a six-week scramble — considerably easier to discharge, because the answers were specific instead of reassuring.

What I would redo

I would get the retention schedule in writing before the second meeting with any vendor, not the fourth. I would also stop assuming our own consent language was current just because nobody had complained about it. Those two things cost us more time than the actual vendor comparison did, which was not what I expected when we started.

If you are doing this review yourself, the questions matter more than the vendor name on the slide. augureai.ca has the privacy policy and sub-processor documentation if you want to see what a specific answer looks like next to a vague one.