L'absence d'une analyse de risques adéquate au titre de la Security Rule est le principal axe de mise en application déclaré par l'OCR de HHS pour 2026, et de loin la plus grande catégorie de mesures d'application publiées. Ce périmètre inclut désormais les agents d'IA qui créent, reçoivent, conservent ou transmettent des PHI — pas seulement les utilisateurs humains et les systèmes traditionnels. Si l'OCR a ouvert une revue ou demandé un Corrective Action Plan, la preuve la plus solide est un registre vérifiable de ce que vos agents ont touché et quand. Le Vault de VeriSwarm produit ce registre ; il ne produit ni résolution de CAP ni détermination de conformité — voir ce que cela ne couvre pas.
Le 45 CFR §164.308(a)(1)(ii)(A) exige une évaluation précise et approfondie des risques et vulnérabilités potentiels pour la confidentialité, l'intégrité et la disponibilité des ePHI détenues par une entité. Les axes déclarés par l'OCR de HHS pour 2026, par ordre de priorité, sont : l'absence d'une analyse de risques de sécurité adéquate, l'absence de politiques et de procédures, l'absence de formation du personnel, la satisfaction du droit d'accès et la notification des violations. L'analyse de risques arrive en tête de cette liste — et pas de peu. Les mesures d'application publiées en 2025 citent des manquements en analyse de risques dans une proportion d'environ 3:1 par rapport à toutes les autres catégories de violation HIPAA combinées.
Le schéma que sanctionne l'OCR n'est pas une lacune administrative. Ce sont des entités qui n'ont jamais mis à jour leur analyse de risques pour tenir compte de la manière dont les PHI circulent réellement aujourd'hui dans leurs systèmes — y compris via des acteurs automatisés qui n'existaient pas lorsque l'analyse de risques initiale a été rédigée.
Une analyse de risques rédigée pour une main-d'œuvre humaine suppose un ensemble connu et borné d'acteurs touchant des ePHI. Un agent d'IA brise cette hypothèse. Le même agent peut appeler un fournisseur de LLM, invoquer une intégration de planification ou de facturation, écrire dans un journal de conversation et escalader vers un fournisseur de secours en cas d'erreur — quatre nouveaux endroits où les PHI peuvent circuler, qu'une analyse de risques héritée n'a jamais été conçue pour couvrir, et quatre nouveaux points qu'un examinateur de l'OCR interrogera si un incident survient.
C'est précisément le vecteur que le briefing de Datavant sur la confidentialité en santé de mai 2026 pointe directement : une analyse de risques construite autour des utilisateurs humains passe à côté du cas où l'acteur de la menace est l'agent lui-même, agissant sur des instructions erronées, et non un attaquant externe ou un initié malveillant.
Que vous renforciez de manière proactive une analyse de risques ou que vous répondiez à un Corrective Action Plan émis par l'OCR, l'exigence est la même : prouver ce qui s'est passé, quand, et sous quels contrôles — sous une forme qui ne puisse pas avoir été discrètement réécrite après coup. Vault produit ce registre pour chaque décision d'agent, chaque appel d'outil et chaque événement de tokenisation de PHI, enchaînés avec un lien SHA-256 vers leur prédécesseur.
GET /v1/suite/vault/verify
→ {
"ok": true,
"events_verified": 41_902,
"first_event_id": "evt_...",
"last_event_id": "evt_...",
"errors": []
}Aux côtés de la chaîne brute, un rapport de conformité par framework regroupe ces mêmes preuves sous-jacentes dans un format d'attestation :
GET /v1/compliance/42-cfr-part-2
→ {
"framework": "42-cfr-part-2",
"status": "technical_preview",
"controls": [ /* per-control pass/warn/fail with evidence counts */ ],
"generated_at": "2026-08-05T..."
}Une rupture dans la chaîne, ou un contrôle signalé comme échoué, vous indique exactement où regarder avant qu'un auditeur ne le fasse. C'est toute la différence entre reconstruire des preuves sous la pression d'un délai et simplement les rejouer.
Vault et les rapports de conformité constituent une couche de preuves, pas un résultat juridique. Ils ne constituent pas une analyse de risques complète, une certification de conformité HIPAA, ni une résolution d'un Corrective Action Plan de l'OCR encore ouvert. Réaliser l'analyse de risques elle-même — identifier les menaces, évaluer la probabilité et l'impact, documenter les mesures correctives — reste un travail que votre organisation doit accomplir, généralement avec un conseil juridique impliqué une fois l'OCR formellement engagée. Ce que produit VeriSwarm, c'est le registre sous-jacent que l'analyse de risques et toute réponse à un CAP peuvent citer : une preuve vérifiable de ce que les agents ont touché, quand, et sous quels contrôles, plutôt qu'un journal non vérifiable ou une feuille de calcul reconstruite.
Vault et Guard sont des fonctionnalités du plan Max (299 $/mois) — non incluses dans le niveau gratuit de VeriSwarm, qui couvre uniquement le scoring de confiance des agents et l'ingestion d'événements.
La Security Rule de HIPAA exige des covered entities et business associates qu'ils « procèdent à une évaluation précise et approfondie des risques et vulnérabilités potentiels pour la confidentialité, l'intégrité et la disponibilité des informations de santé protégées électroniques » (45 CFR §164.308(a)(1)(ii)(A)). L'OCR de HHS a désigné l'absence d'analyse de risques adéquate comme son principal axe de mise en application déclaré pour 2026, et cela a constitué la plus grande catégorie de mesures d'application publiées — de loin devant toute autre catégorie de violation HIPAA combinée.
Oui, si l'agent crée, reçoit, conserve ou transmet des ePHI. Une analyse de risques limitée aux seuls utilisateurs humains et systèmes traditionnels passe à côté de toute la surface d'attaque d'un agent : les fournisseurs de LLM qu'il appelle, les intégrations d'outils qu'il invoque, les journaux et la mémoire de conversation dans lesquels il écrit, et les fournisseurs de secours vers lesquels il escalade en cas d'échec. Le schéma de mise en application de l'OCR ne prévoit aucune exception pour les acteurs automatisés — un agent traitant des PHI entre dans le périmètre exactement comme le ferait un membre humain du personnel.
Un Corrective Action Plan (CAP) exige généralement de l'entité qu'elle démontre une analyse de risques complète, qu'elle corrige les lacunes identifiées selon un calendrier et — selon le schéma de mise en application de 2026 — qu'elle accepte une obligation de surveillance de l'OCR de 2 ans. La preuve la plus solide dans ce processus est un registre vérifiable : quelles PHI l'agent a touchées, quand et sous quels contrôles. Un journal modifiable est une preuve faible lors d'une revue de CAP ; un registre enchaîné par hash prouvant qu'il n'a pas été altéré après coup constitue une preuve plus solide, sans toutefois remplacer l'analyse de risques ni le travail de remédiation lui-même.
Vault enchaîne chaque événement enregistré — décisions d'agent, évaluations de politique, tokenisation et réhydratation de PHI — avec un lien SHA-256 vers son prédécesseur. GET /v1/suite/vault/verify parcourt la chaîne et renvoie pass/fail avec l'événement exact où survient une rupture, le cas échéant. Cela donne à une revue d'analyse de risques (ou à une réponse à un CAP) une réponse vérifiable de manière automatisée à la question « pouvez-vous prouver que ce journal n'a pas été modifié », plutôt qu'une simple affirmation.
Non. Le point de terminaison de conformité de VeriSwarm (GET /v1/compliance/{framework}) génère un rapport d'attestation par tenant pour un framework nommé, avec des décomptes de preuves issus de Vault et Guard. C'est un dossier de preuves structuré, pas une détermination de l'OCR. Savoir si ces preuves satisfont une revue spécifique de l'OCR ou une exigence de CAP relève d'un jugement juridique et factuel que l'OCR — ou votre conseil juridique — rend, pas VeriSwarm.
C'est un contrôle qu'une analyse de risques peut citer, pas un substitut à la réalisation de l'analyse elle-même. La tokenisation PII de Guard (POST /v1/suite/guard/pii/tokenize) réduit l'exposition réelle — les PHI n'atteignent jamais le LLM ou l'appel d'outil sans être tokenisées — et chaque événement de tokenisation est journalisé dans Vault, ce qui constitue en soi une preuve qu'une analyse de risques peut référencer. Le fonctionnement détaillé de la tokenisation est couvert en profondeur sur la page consacrée aux agents d'IA conformes à HIPAA.
Pour savoir comment fonctionne réellement la tokenisation des PHI à la frontière de l'agent — le contrôle sur lequel repose ce dossier de preuves — voir Agents d'IA conformes à HIPAA : tokeniser les PHI avant que le modèle ne les voie. Pour la correspondance complète entre les priorités de mise en application de l'OCR en 2026 et les capacités de VeriSwarm, commencez par VeriSwarm pour le secteur de la santé.
Une démonstration guidée de 30 minutes, en direct sur votre propre flotte — pas de données de démonstration. Apportez la priorité de l'OCR ou l'exigence de CAP à laquelle vous êtes réellement confronté.