Santé · 4 min de lecture
Les projets d'IA en santé calent rarement sur le modèle. Ils calent en revue de confidentialité, sur quatre questions d'ingénierie dont chacune peut devenir un paramètre que l'on peut montrer.
La plupart des projets d'IA en santé qui s'arrêtent ne s'arrêtent pas parce que le modèle n'était pas assez bon. Ils s'arrêtent en revue de confidentialité et juridique, où les questions sont des questions d'ingénierie et où le projet n'a pas de réponses d'ingénierie. Voici un tour des quatre questions qui reviennent presque toujours, et de la façon dont chacune devient un paramètre que quelqu'un peut montrer, tester et défendre, au lieu d'une assurance donnée en réunion.
Note de périmètre : ce texte est un guide d'ingénierie sur les contrôles, pas un avis juridique ni un énoncé de ce qu'exige une réglementation. NeuralSeek fait l'objet d'audits SOC 1 et SOC 2 Type II et est conforme à la loi HIPAA. C'est à vos conseils juridiques, à votre bureau de la confidentialité et à votre audit interne de décider de ce qui s'applique à votre organisation.
On suppose souvent que la réglementation interdit de mettre des données cliniques à proximité d'un modèle de langage, et le projet attend alors une réponse juridique qui ne vient jamais vraiment. En pratique, la revue demande rarement une permission dans l'abstrait. Elle pose quatre questions concrètes : ce qui parvient au modèle, quelle trace existe ensuite, ce que le système peut voir, et comment démontrer tout cela.
Chacune trouve sa réponse dans la configuration, et un projet qui arrive avec les réponses déjà configurées passe une revue très différente de celui qui arrive avec une démonstration et une promesse.
La meilleure réponse possible à cette question est « rien », et on y arrive plus souvent que les équipes ne le croient. Si les informations protégées sont retirées avant l'assemblage du prompt, ce que le fournisseur du modèle en fait cesse d'être un sujet.
Les meilleures configurations expurgent en deux passes, pour les raisons exposées dans l'article sur la détection des PII. Une passe déterministe rapide retire les identifiants structurés (numéros de dossier, dates, coordonnées) avec une latence négligeable. Une passe contextuelle attrape ensuite ce que les motifs ne voient pas : un nom dans une note clinique en texte libre, un lieu formulé de douze façons, une description qui identifie une personne sans la nommer.
La troisième décision porte sur ce qui se passe en cas de correspondance, et elle mérite d'être réglée délibérément par workflow : masquer la valeur, la remplacer par un jeton stable pour que la phrase reste lisible, la retirer ou refuser la requête. Réglée une fois, appliquée de façon constante et visible dans la configuration plutôt que dans le code de quelqu'un.
On ne peut pas rendre compte d'un accès qu'on n'a pas enregistré, et une revue ne présumera rien de ce que votre système a fait. Deux traces complémentaires font l'essentiel du travail : un journal durable et infalsifiable de chaque interaction, à l'échelle de l'organisation, et une trace des prompts eux-mêmes, pour qu'une question posée des mois plus tard puisse être reconstituée avec le contexte réel du système.
Le test pratique est de savoir si produire cette trace est un export ou un projet. Si un relecteur demande ce qu'un assistant précis a dit à une personne précise un jour précis, et que la réponse prend une semaine à assembler, le contrôle n'existe pas vraiment encore.
L'expurgation et la journalisation comptent peu si une récupération peut atteindre des documents qu'elle n'aurait jamais dû pouvoir atteindre. C'est une question d'accès, pas seulement de connexion : un assistant conçu pour un service doit être structurellement incapable de récupérer les dossiers d'un autre service, et pas seulement découragé de le faire.
Cela s'applique au niveau de la récupération, en limitant les documents que chaque client ou unité peut interroger, avant tout classement. En complément, les identifiants et les secrets de connexion doivent rester entièrement hors des prompts et des réponses. Sinon, le dossier de preuves que vous remettez à un relecteur devient un endroit d'où une clé peut fuiter.
La dernière question est celle qui décide de la durée de la revue. Une configuration correcte mais non documentée est traitée comme une affirmation. Les organisations qui passent vite la revue sont celles qui peuvent placer chaque contrôle en face de l'exigence qu'il satisfait, dans une structure que le relecteur connaît déjà.
Cette correspondance fait la différence entre un questionnaire de sécurité qui devient une chasse aux preuves de plusieurs mois et un questionnaire auquel on répond à partir d'un document. C'est aussi, utilement, la trace qui survit au départ des personnes.
Quand NeuralSeek fonctionne dans votre environnement, le périmètre de conformité est le vôtre et les données n'ont jamais besoin de le quitter. Les contrôles ci-dessus, c'est à nous de les fournir, et à vous de les configurer et de les exploiter.
NeuralSeek fait l'objet d'audits SOC 1 et SOC 2 Type II et est conforme à la loi HIPAA.
Continuer la lecture
Des lectures pratiques pour créer, gouverner et exécuter des agents IA.
Pour les paramètres, consultez la documentation du produit (en anglais).
La question difficile, c'est ce que le système était configuré pour faire un jour donné. Voici comment y répondre, du journal de chaque modification de paramètre aux preuves exportées.
En savoir plus sur les pistes d'auditPourquoi le modèle ne peut pas régler le problème seul, à quoi ressemble une attaque cachée dans un document et comment la contenir.
En savoir plus sur l'injection de promptInscrivez-vous en ligne et commencez par un essai de deux semaines, ou parlez à un expert NeuralSeek pour exécuter NeuralSeek dans votre cloud.