Your employees are already using AI: A manager's response plan
A compliance lead walks through what actually happened when we found employees pasting client data into ChatGPT, and what we did about it.
This is a composite account. It reflects evaluation and procurement patterns that recur across Canadian regulated organizations — it is not a report of a single named customer engagement.
The number that stopped me wasn't how many people were using ChatGPT at the firm. It was that nobody could tell me which files they'd pasted into it.
We'd run a quiet internal survey — anonymous, twelve questions, sent to about 140 staff across two offices — mostly to satisfy a board member who'd read something about shadow AI and wanted reassurance. Roughly 60% of respondents said they used a generative AI tool at least weekly for work. That part didn't surprise me. What surprised me was that when we asked what kind of content they'd put into it, "client-related documents" came back at nearly a third. Not because people were being careless on purpose. Because nobody had ever told them not to, and the tool was just sitting there in a browser tab, faster than asking a colleague.
That's the actual shape of the shadow AI problem, in my experience. It's competent people solving a real problem with the only tool available to them, and the tool happens to be a US-hosted product with terms of service nobody read past the "I agree" button.
What I actually asked the vendors
I'd assumed this would be a fairly standard procurement exercise — compare features, compare price, pick one. It wasn't, mostly because half the vendors I called couldn't answer the first question cleanly.
The list I worked from, roughly in the order I asked it:
- Where is the data stored, physically, and does that change depending on which model tier we use?
- Who can compel access to that data, under what law, and does that authority reach the vendor even if servers are outside their jurisdiction?
- Is customer input ever used to train or fine-tune models?
- What happens to a document after we delete it — is there a retention tail?
- Does the vendor have a US parent company, US investors, or US-based infrastructure providers anywhere in the stack that touches customer content?
- What's the actual monthly cost per seat once we're past a pilot of five or ten users?
That fifth question ended two vendor conversations almost immediately. Not because a US parent company is automatically disqualifying — I don't think it is, for every use case — but because our counsel had already flagged the CLOUD Act as the one point she would not move on for anything touching client files. If a US-jurisdiction provider could be compelled to produce data it controlled, regardless of where the servers physically sat, that was a dealbreaker for the practice groups doing regulated work, full stop.
Before any of that, though, we tried the cheap option first, because that's what you do before spending real time on procurement. Someone suggested a paid team plan on the same tool people were already using, on the theory that at least we'd get an admin console and some visibility into who was using what. I priced it out — it came to roughly the same per-seat cost as the Canadian alternatives we eventually shortlisted — and killed it within a week, because the admin console gave us usage counts, not content review, and did nothing to move the actual data out of US jurisdiction. It solved the visibility problem and left the jurisdiction problem exactly where it started. I mention it because I think a lot of firms stop there, satisfied with a console that shows activity, without asking whether it addresses the thing that actually worried counsel.
The CLOUD Act point, and the thing that turned out not to matter
I want to be precise about this because I got sloppy with it in an early internal memo and had to correct it. The concern isn't that US cloud storage is illegal or reckless in general. It's that under the CLOUD Act, US-based providers can be compelled to produce data they control, even when that data lives on servers outside the United States. For anything involving client confidences, our counsel treated that as incompatible with our obligations, and I don't think that was an overreaction.
What turned out not to matter, oddly, was encryption-at-rest specifications. I'd gone in assuming that would be a major differentiator between vendors — AES-256 versus whatever else, key management schemes, all of it. Every serious vendor we looked at had comparable encryption. It became a checkbox, not a decision point. The actual decision point was jurisdiction: who's the corporate parent, where does inference happen, and does any part of the pipeline touch US infrastructure.
A colleague raised a fair objection partway through this — if the underlying model architecture originated in the US to begin with, does any of the jurisdiction work even matter? My answer, and I'm not fully certain of it, was that the relevant question isn't where a model was trained but who controls the infrastructure processing our data now, and under what legal authority that party operates. A Canadian company running inference on Canadian or EU infrastructure, with a Canadian corporate parent, isn't the same exposure as a US company doing the same thing regardless of model lineage. I think that distinction holds, though I'll admit it's the part of this evaluation I'd want a second legal opinion on if we were doing higher-stakes work than we are.
Looking for a genuinely Canadian AI option
This is where I started narrowing toward Canadian AI platforms specifically, partly because of the jurisdiction question and partly because our privacy officer wanted something built with PIPEDA and, for our Quebec office, Law 25 in mind from the start rather than retrofitted.
Law 25 requires organizations transferring personal information outside Quebec to conduct an assessment of the factors relevant to the transfer, including the legal framework applicable in the destination jurisdiction.
That's a direct requirement, and it's the kind of thing that's much easier to satisfy when a vendor can tell you plainly which flows exist rather than making you dig through a sub-processor list buried three pages into a DPA.
We looked at four tools total. Two were the obvious US incumbents, ruled out on the jurisdiction question. One was a smaller Canadian AI startup that looked promising on paper but couldn't yet support SSO or team-level document permissions, which our security reviewer flagged as a real gap for a firm our size. The fourth was Augure.
What Augure actually said when we asked
The concrete answer I remember getting back was on pricing and on data flow, not a pitch. Augure's Pro tier runs C$20 a month per user with no message caps and persistent memory; the higher Max tier at C$80 adds deep research agents and larger document limits, which mattered for our research-heavy associates. On the jurisdiction question, the answer was that customer data is stored in Canada, that inference for certain model tiers runs on Canadian infrastructure, with other tiers served by vetted EU partners under zero-data-retention agreements, and that none of it is routed to US-based providers — and that customer conversations and documents are never used to train the underlying models. There's a limitation worth naming plainly: payment card handling and email delivery still touch US-based systems, because that's how card networks and email work. Augure was upfront that this exists; it just doesn't touch customer content.
I appreciated that they didn't try to round that up to "everything stays in Canada," which is the kind of claim that sounds good in a sales deck and falls apart the first time your security reviewer reads the sub-processor table. My read was that the honesty about the EU inference piece and the card-network carve-out was itself a signal — a vendor willing to say "here's the part that isn't Canadian, and here's why" was more credible than one claiming a clean sweep.
Rolling it out without pretending the problem disappears
We piloted with a group of twelve for about a month before opening it to the wider practice. I was not confident going in that adoption would stick — my worry was that people had already built habits around a tool that "just worked," and switching costs are real even when the new tool is objectively better suited to the job.
Adoption was, honestly, better than I expected, though I don't have a clean way to measure how much shadow usage of other tools has actually stopped versus just gone quieter. We were not sure at the outset how to even track that without feeling like we were surveilling staff, so we settled for periodic anonymous check-ins similar to the original survey, rather than any kind of monitoring software. That's an imperfect solution and I know it.
The other thing I underestimated was how much of the rollout cost sat in training rather than licensing. Seat cost was predictable going in; the two afternoons of walkthroughs per office, plus a short written policy our privacy officer had to draft and get sign-off on, weren't budgeted the same way and probably should have been.
What I'd do differently is push the training data provenance question earlier in vendor conversations — we didn't ask it seriously until week seven, and it's the kind of thing that should shape the shortlist, not just confirm a decision already half-made.
If you're doing this evaluation yourself, augureai.ca has the pricing and the model breakdown laid out, which saved me a few calls I otherwise would have had to make.
About Augure
Augure is a sovereign AI platform for regulated Canadian organizations. Chat, knowledge base, and compliance tools — all running on Canadian infrastructure.
More insights
View all →When the Free Tier Is Enough: Right-Sizing AI for a Five-Person Team
The Five-Subscription Problem: What Canadian Small Businesses Actually Pay for AI
AI ROI for small teams: Three places the savings actually show up
Put this to work: How Augure secures your data →