Skip to main content

Quebec Law 25: Privacy-First AI Governance Implementation

Quebec's Law 25 is one of the clearest examples of why privacy-by-design language must become runtime behavior for AI systems. The statute modernized Quebec's private-sector privacy regime and pushed several concrete obligations closer to how systems are actually built: privacy impact assessments, cross-border transfer evaluation, transparency around automated decisions, and more explicit accountability for personal information. For AI teams, that means governance has to be visible in the live route, not just in a procurement checklist.

Keeptrusts is not a complete Law 25 solution. It cannot author the privacy impact assessment for you, determine whether a transfer is legally acceptable, or draft the notices required for a person affected by an automated decision. What it can do is help make the route's privacy posture match the conclusions of those exercises. That includes minimizing personal information before provider calls, restricting providers to the set approved through your transfer and vendor review, requiring human review where automation should not operate alone, and preserving evidence for the privacy office.

Use this page when​

  • You need to operationalize Quebec Law 25 for AI workflows that handle personal information.
  • You are reviewing cross-border provider use or automated decision support under a privacy-first design standard.
  • You want technical evidence that a route follows the privacy posture your assessment approved.

Primary audience​

  • Primary: Privacy officers, compliance managers, platform engineers
  • Secondary: legal counsel, product managers, security teams

The problem​

Law 25 changes AI governance because it makes system design a privacy issue. The law expects organizations to assess privacy impacts when acquiring, developing, or redesigning information systems or electronic service delivery projects involving personal information. That expectation matters for AI because copilots and decision-support services are usually introduced as upgrades to existing workflows rather than entirely new systems. Teams often skip the design review precisely because the change feels incremental.

The cross-border problem is equally important. Many AI routes rely on providers, storage systems, or operational tooling outside Quebec. Law 25 requires an assessment before communicating personal information outside Quebec, with attention to the sensitivity of the information, the purpose of use, protection measures, and the legal framework of the destination jurisdiction. In practice, that means the provider set approved in the assessment should be the provider set enforced by the route. Without that link, the assessment becomes a paper artifact.

Automated decision transparency creates another challenge. Even if the AI route does not make the final decision, it may materially influence a person-facing outcome. That is especially true in claims handling, account controls, fraud review, employment screening, and customer support escalation. If the route acts like a straight-through system, privacy leaders have difficulty explaining where human judgment enters.

The solution​

The best operating pattern is assessment-backed route design. Use the Law 25 assessment to decide which data can reach the model, which providers are approved, whether cross-border transfer is acceptable, and where human review must occur. Then encode those decisions into the Keeptrusts route.

pii-detector supports data minimization by redacting or blocking personal information in request text and buffered response flows. data-routing-policy turns provider review into live enforcement by filtering targets against declared handling constraints such as zero-data-retention, training opt-out, retention windows, and internet-egress restrictions. human-oversight gives you an explicit stop when a workflow should not operate as unattended automation. audit-logger and evidence exports preserve a reviewable trail for the privacy function.

This is where Keeptrusts adds real value for Law 25 teams. It does not invent a privacy decision. It operationalizes one. That distinction matters because privacy-first AI governance works only when the legal conclusion changes runtime behavior.

Implementation​

For a Quebec route that handles personal information and may influence a person-facing decision, a conservative configuration looks like this:

pack:
  name: quebec-law-25-reviewed-route
  version: "1.0.0"
  enabled: true

providers:
  targets:
    - id: law25-reviewed-provider
      provider: openai
      model: gpt-5.4-mini-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0
        in_memory_only: true
        allow_internet_egress: false

policies:
  chain:
    - pii-detector
    - data-routing-policy
    - human-oversight
    - audit-logger

policy:
  pii-detector:
    action: redact
    redaction:
      marker_format: label
      include_metadata: true

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    require_in_memory_only: true
    allow_internet_egress: false
    on_no_compliant_provider: block
    log_provider_selection: true

  human-oversight:
    action: escalate

  audit-logger: {}

This configuration works well when your Law 25 review has already concluded that the route may process personal information, that only a narrow provider set is acceptable, and that a final answer should not be delivered without review. If your cross-border analysis approves only certain providers or operating regions, the route should reflect that. If the analysis says the workflow must remain local or tokenized, use a stricter deployment pattern and consider Regulated Execution for stronger residency and evidence controls.

The key operational habit is change control. When the provider set changes, the policy should change. When a workflow becomes more consequential, the route should move into a reviewed lane. That makes Managing Policy Changes part of privacy governance, not just platform hygiene.

Results and impact​

Teams that adopt this model stop treating the PIA as a one-time approval artifact. It becomes a design input for the route itself. Privacy leaders can compare the assessment's conclusions with actual provider constraints and escalation behavior. Engineers get clearer guardrails. Product teams know when an assistant may remain in a lower-control lane and when it must move into a reviewed one.

That improves auditability and everyday operations at the same time. Instead of debating whether the system is "privacy first" in principle, the organization can show that the route redacts personal information, blocks non-reviewed providers, and requires review for higher-impact outputs.

Key takeaways​

  • Law 25 makes AI design questions operational because PIAs, cross-border review, and automated-decision transparency all map to runtime behavior.
  • The approved provider set in your assessment should be the provider set enforced in the route.
  • pii-detector, data-routing-policy, and human-oversight are the core building blocks for a privacy-first lane.
  • Stronger sovereignty and evidence requirements can be handled with regulated execution when needed.
  • Policy change management is part of privacy governance because route drift can undermine the original assessment.

Next steps​