I launched a RAG-based document assistant for a client last year. It was elegant: users asked questions, the system pulled relevant documents from their shared drive, and Claude synthesized answers. The client loved it. Three months later, their legal team asked a question that made my stomach drop: "Does this comply with Quebec Law 25?" I didn't have a good answer. I'd focused entirely on making the system work, not on what it was allowed to do. That conversation cost us weeks of remediation and a hard lesson in building before thinking about governance.
The thing is, I'm not alone. Most developers I know treat privacy and compliance as an afterthought, something the legal team handles. But reading about Quebec's Law 25 and how it actually applies to generative AI systems made me realize that's not just naive, it's technically backwards. This isn't legal theater. It's architecture. The law penalizes two engineering failures: poor security and mishandling automated decisions. Both are decisions I make when I write code.
What Quebec Law 25 Actually Is (And Why It Matters Beyond Quebec)
Law 25 modernized Quebec's privacy framework, bringing it closer to GDPR. The penalties are brutal: up to $10 million or 2% of global revenue for administrative violations, $25 million or 4% for penal offenses. But here's what got my attention: the Commission d'accès à l'information (CAI) has already issued orders targeting AI and biometric systems. They've ordered organizations to shut down systems, destroy data, and notify affected people.
The critical part for developers is this: the law applies to generative AI whether anyone at the CAI sat down and wrote guidance specifically for LLMs or not. The regulator has said so in writing. If you're building RAG systems, copilots, or AI agents that touch personal information, even indirectly through retrieval indexes, you're in scope.
The Two Engineering Problems Hidden in Legal Language
When I look at what the CAI actually penalizes, two things jump out that aren't about paperwork. They're about what I build.
First: failing to take reasonable security measures (section 10). This isn't theoretical. If I'm indexing documents for retrieval, every piece of personal information on that drive is now part of my index. If that index gets dumped in logs, goes to an API, or sits unencrypted somewhere, I've failed. I've seen teams treat model logging as a convenience feature. It's a liability vector.
Second: failing to handle decisions made by automated processing (section 12.1). This one surprised me. If my system generates something that could be considered a "decision" about a person, a risk score, a recommendation, a prediction, I have to inform the person it happened and let them submit observations about it. The CAI's case on the school dropout prediction tool makes this concrete: the predictions themselves were new personal information. The system had to disclose that it existed.
What This Means for Systems I'm Actually Building
Here's my honest take: most AI systems we're building right now should trigger a privacy impact assessment before we write a line of code. A RAG assistant connected to a CRM? That's an information system handling personal data. An agent with mailbox access? Same thing. A copilot over customer support tickets? Absolutely.
I used to think privacy impact assessments (PIAs) were compliance theater, a document you write to check a box. I was wrong. A proper PIA forces me to ask questions I should be asking anyway: What personal information can this system actually access? What does the model see? What gets logged? What happens when someone asks for their data back?
The CAI's guidance recommends that AI assessments specifically include algorithmic impact analysis, essentially auditing bias and fairness in automated decisions. This isn't about being ethical (though it is). It's about being legally defensible when something goes wrong.
A Practical Reality Check
Here's what I wish I'd done with that client project:
Before building:
1. Map all data sources the AI can read
2. Classify what's personal information (it's broader than you think)
3. Document security controls for data in transit to the model
4. Decide: does this system make decisions about people?
- If yes, plan for disclosure and challenge mechanisms
5. Get sign-off from whoever is designated as responsible
That last point matters. Law 25 assigns the responsibility for personal information protection to the person with highest authority by default. That might be you if you're running the company. That's worth knowing before launch.
The Real Cost of Moving Fast and Breaking Things
What struck me most reading about the CAI's approach: they haven't handed out major fines yet, but they've issued plenty of orders to shut systems down. The absence of massive penalties isn't permission. It's just that the enforcement machinery is still warming up. And the path to a fine is shorter than I thought, organizations get a notice of non-compliance, and if they don't remediate properly, the penalties follow.
The best defense isn't arguing in court later. It's a credible remediation plan ready to go when a notice arrives. And the only way to have that is to have thought about these obligations before launch.
What I'm Doing Differently Now
I'm building a checklist into my project intake process. Before the first sprint, before the first GitHub issue: privacy impact assessment conversation. Not because I'm suddenly compliant-minded, but because it makes my systems better. It forces clarity on data flows, security, and what the system actually does.
I'm curious what you're doing with AI systems right now. Are you hitting these questions, or are they on someone else's todo list?
Source: This post was inspired by "Quebec Law 25 and Generative AI: What to Settle Before Production" by Dev.to. Read the original article
