Chez Northbridge Health, l’équipe qui gère l’API du modèle CareClaims Triage doit prendre des décisions justifiables avant qu’une mise à jour du modèle n’atteigne les opérations de traitement des demandes d’indemnisation. L’enjeu consiste à renforcer l’ensemble du cycle de vie du modèle contre les risques d’empoisonnement, d’extraction et d’inférence, tout en produisant des preuves capables de résister à un examen technique, à une évaluation de la confidentialité et à un audit. Une surface d’attaque correspond à tout point où un acteur peut affecter, interroger, observer ou influencer le système de modèle. Un objectif de contrôle définit le résultat de protection que l’architecture doit atteindre ainsi que les preuves permettant de le démontrer.
L’API du modèle ne constitue qu’un seul point d’exposition. Les données d’entraînement, les tâches de réglage fin (fine-tuning), les entrées du registre de modèles, les paramètres de déploiement, les réponses de l’API et les journaux opérationnels ont tous des implications en matière de sécurité et de gouvernance. L’objectif n’est pas de collecter tous les artefacts possibles, mais d’établir une traçabilité reliant une décision importante aux données approuvées, au comportement évalué du modèle, au déploiement autorisé et à l’utilisation observée de l’API.
Une chaîne d’attaque contre un modèle peut débuter au point d’entrée des données sur la plateforme et se poursuivre jusqu’à la mise en production et l’utilisation du modèle. L’empoisonnement des données d’entraînement, l’empoisonnement lors du réglage fin et l’insertion de portes dérobées (backdoors) affectent le comportement du modèle avant son déploiement. L’extraction de modèle, l’inversion de modèle et l’inférence d’appartenance surviennent lorsque le comportement ou les résultats de l’API divulguent davantage d’informations que le service ne devrait en révéler. Chaque catégorie traverse différentes limites de responsabilité ; par conséquent, un contrôle périmétrique unique ne peut couvrir l’intégralité du cycle de vie.
Pour CareClaims Triage, l’architecture doit mettre en évidence les points où la provenance est vérifiée, où l’évaluation bloque la mise en production, où les requêtes API sont restreintes et où les signaux d’utilisation sont conservés pour examen. Ces contrôles créent des points de décision sans supposer qu’un signal isolé prouve nécessairement une activité malveillante. Nous pouvons ainsi cartographier la surface d’attaque et les limites de contrôle prévues :
L’ingénierie de sécurité est responsable de l’intégrité des chaînes de déploiement, des protections des API et de la couverture de détection. L’ingénierie d’apprentissage automatique (machine learning) est responsable de la reproductibilité des décisions d’entraînement et d’évaluation. La gouvernance des données définit les usages autorisés, les exigences de traçabilité (lignage) et les règles de conservation. Une approbation conjointe est requise lorsqu’une modification du modèle a une incidence sur le traitement des demandes d’indemnisation ou la manipulation de données sensibles. La séparation des tâches est cruciale, car une version de modèle peut être techniquement valide tout en ne disposant pas d’une provenance ou d’une autorisation jugée acceptable.
Un objectif de contrôle solide précise le résultat attendu, le responsable désigné, le périmètre d’approbation et l’élément (artefact) conservé à titre de preuve. Les preuves doivent permettre une reconstitution des faits après un incident, et non simplement attester de l’existence d’un processus. Nous pouvons examiner les enregistrements qui relient une décision concernant un modèle aux responsables désignés :