IA exécutée localement pour la détection des renseignements personnels

Contexte

Un cabinet canadien de services professionnels exploite une plateforme de gestion documentaire qui contient des milliers de documents clients et internes. La Loi 25 du Québec impose des obligations de protection des renseignements personnels; les respecter commence par savoir où se trouve cette information. Le cabinet avait besoin d’une capacité de détection fonctionnant entièrement dans son propre environnement.

Défi

Repérer les renseignements personnels dans des milliers de documents hétérogènes — numéros d’assurance sociale, numéros de carte d’assurance maladie, conditions médicales, identifiants bancaires et des dizaines d’autres catégories — en français et en anglais, avec une grande précision, et sans qu’un seul document ne soit envoyé à un service infonuagique ou à une API externe.

Mon rôle

Direction de l’architecture et de la technologie : conception du pipeline de détection et du modèle de sécurité, livraison de la composante IA avec mon équipe, et préparation du dossier d’architecture et de code pour la revue de sécurité du client.

Architecture / approche

Un service IA autonome installé sur une machine dédiée dans le réseau du client. Il lit la file de documents de la plateforme, analyse chaque document localement avec quatre détecteurs en parallèle — deux modèles de reconnaissance d’entités nommées, des dictionnaires d’entités et 79 règles de patrons —, puis réconcilie les candidats en trois étapes (fusion, validation contextuelle, vérifications algorithmiques) avant de réécrire les constats dans la plateforme. La conception suit les quatre propriétés que j’utilise pour évaluer l’IA souveraine : résidence, isolation, gouvernance des modèles et imputabilité.

Technologie

Modèles NER publics figés (CamemBERT pour le français, DistilBERT multilingue) compilés en Core ML pour l’inférence locale sur le moteur neuronal de la machine; services Python (30 000+ lignes) pour le traitement, la classification et la réconciliation des documents; intégration MariaDB à la plateforme; validation algorithmique des identifiants (Luhn, RAMQ, MRZ, IBAN).

Exécution

Les détecteurs ont été construits et ajustés catégorie par catégorie sur les types de documents réels de la plateforme, puis assemblés dans le pipeline parallèle et la réconciliation en trois étapes. La composante a été installée sur la machine dédiée, raccordée à la file de documents et livrée avec un dossier complet d’architecture et de code pour que l’équipe TI du client puisse la revoir de façon indépendante.

Contraintes

Pas de nuage, pas d’API externe, pas de grand modèle de langage et pas d’apprentissage sur les données du client. Une seule connexion sortante — vers la base de données du client. Des documents bilingues et des formats d’identifiants propres au Québec et au Canada.

Leçons clés

1. La souveraineté est un ensemble de propriétés vérifiables; l’architecture la plus simple qui les satisfait est généralement la bonne.
2. Des modèles figés combinés à une validation algorithmique donnent un comportement auditable qu’un LLM généraliste ne peut pas offrir.
3. Livrer le dossier de revue de sécurité avec le code — et non après — raccourcit le chemin vers la production.