Sovereign AI, in service of your infrastructure

What does "sovereign" mean, and what does it not mean?

Three verifiable things: processing runs on infrastructure located in Quebec or France, under the law applicable to your organization, and your data is not reused to train public models. This is not a marketing label but a set of contractual and technical constraints.

The word is used loosely, often to mean nothing more than hosting in a local data centre. That is not enough. A service hosted in Quebec but operated by an entity subject to foreign legislation remains exposed to access demands under that law. The three criteria have to be checked separately.

For organizations subject to Law 25, these are not theoretical questions: any disclosure of personal information outside Quebec requires a prior privacy impact assessment and assurance of adequate protection in the destination jurisdiction.

• Location. Where the data physically resides at rest, and where processing runs. This is the easiest criterion to verify and the only one most providers document.
• Applicable law. Which jurisdiction can compel the service operator. This is the decisive criterion, and the one contracts most often avoid naming.
• Reuse. Whether your logs and configurations are used to improve a model others rely on. By default, many consumer services answer yes.

What does AI actually do in monitoring?

It reduces noise. Out of millions of network events, it isolates the few hundred that warrant human attention, by learning your environment's normal behaviour rather than applying fixed thresholds that fire too often or too late.

The real benefit is not removing human analysis but making it possible: a team buried under thousands of daily alerts analyses nothing, and incidents there are reported by users before the technical teams see them.

• Anomaly detection. An endpoint suddenly querying hundreds of shares, an account authenticating from two continents within ten minutes, an unusual volume of encryption. These are weak signals a static threshold misses and a comparison against habitual behaviour reveals.
• Intelligent monitoring. Correlation of events across multiple sources to reconstruct a chain rather than isolated alerts, with dashboards oriented around services rather than equipment.
• Automation and continuous compliance. Detection of configuration drift against a reference state, and automatic remediation limited to a scope validated with you.

Is AI already a risk in your organization?

Yes, almost certainly, and without anyone having decided it. Your teams already use consumer assistants to write, summarise and code. With no acceptable use policy, confidential data is pasted into them daily, and that may constitute a disclosure of personal information outside Quebec.

This is currently the most concrete and least addressed need among the smaller organizations we meet. Four distinct exposures compound:

Our answer has two parts: a written and enforceable AI acceptable use policy, and deployment of analytical capability on infrastructure whose location and applicable law you control.

• Leakage through everyday use. A contract, a client list or an employee file pasted into an online service to get a summary. The terms of use of many consumer services permit reuse of those inputs.
• The absence of a policy. Without a written rule, everyone decides alone what is acceptable and nobody can be held responsible. It is also what makes an incident impossible to qualify afterwards.
• AI-boosted phishing and deepfakes. Producing a credible voice or face now costs a few clicks, which makes executive impersonation markedly more convincing. The Canadian Anti-Fraud Centre documents these typologies.
• Assisted decisions without traceability. As soon as automated processing influences a decision about a person, Law 25 requires informing them and allowing them to submit observations.

How do you guarantee auditability of automated decisions?

Every automated action is logged with its trigger, the rule applied and its result. Automatic remediation is bounded to a scope validated with you in writing, and any action outside that scope requires explicit human approval.

This constraint is not only regulatory, it is operational. Automation whose reasoning nobody can reconstruct becomes impossible to correct when it gets things wrong, and impossible to defend to an auditor. We therefore document the reference state, the rules, their exceptions and the people authorised to change them.

The corollary is that we deliberately limit what automation decides alone. Isolating a suspicious endpoint is a reversible and bounded action. Changing a production firewall rule is not, and it stays subject to human decision.