La mancanza di un'analisi dei rischi adeguata ai sensi della Security Rule è il principale obiettivo di enforcement dichiarato dall'OCR di HHS per il 2026, e di gran lunga la categoria più ampia di azioni di enforcement pubblicate. Questo ambito ora include gli agenti IA che creano, ricevono, mantengono o trasmettono PHI — non solo utenti umani e sistemi tradizionali. Se l'OCR ha aperto una revisione o richiesto un Corrective Action Plan, la prova più solida è un registro verificabile di cosa hanno toccato i vostri agenti e quando. Il Vault di VeriSwarm produce quel registro; non produce una risoluzione del CAP né una determinazione di conformità — vedi cosa questo non copre.
Il 45 CFR §164.308(a)(1)(ii)(A) richiede una valutazione accurata e approfondita dei potenziali rischi e vulnerabilità per la riservatezza, l'integrità e la disponibilità degli ePHI detenuti da un'entità. Le aree di interesse dichiarate dall'OCR di HHS per il 2026, in ordine di priorità, sono: mancanza di un'adeguata analisi dei rischi di sicurezza, mancanza di politiche e procedure, mancanza di formazione del personale, adempimento del diritto di accesso e segnalazione delle violazioni. L'analisi dei rischi guida questa lista — e non di poco. Le azioni di enforcement pubblicate nel 2025 citano carenze nell'analisi dei rischi con un rapporto di circa 3:1 rispetto a ogni altra categoria di violazione HIPAA combinata.
Lo schema che l'OCR sta perseguendo non è una lacuna burocratica. Sono entità che non hanno mai aggiornato la propria analisi dei rischi per tenere conto di come i PHI si muovono realmente oggi attraverso i loro sistemi — anche tramite attori automatizzati che non esistevano quando è stata redatta l'analisi dei rischi originale.
Un'analisi dei rischi redatta per una forza lavoro umana presuppone un insieme noto e delimitato di attori che toccano ePHI. Un agente IA infrange questo presupposto. Lo stesso agente può chiamare un fornitore di LLM, invocare un'integrazione di pianificazione appuntamenti o fatturazione, scrivere in un registro di conversazione ed effettuare l'escalation verso un fornitore di riserva in caso di errore — quattro nuovi punti in cui i PHI possono fluire che un'analisi dei rischi legacy non è mai stata concepita per coprire, e quattro nuovi punti su cui un revisore dell'OCR farà domande se si verifica un incidente.
Questo è esattamente il vettore che il briefing sulla privacy sanitaria di Datavant del maggio 2026 individua direttamente: un'analisi dei rischi costruita intorno agli utenti umani non coglie il caso in cui l'attore della minaccia è l'agente stesso, che agisce sulla base di istruzioni errate, non un attaccante esterno o un insider malintenzionato.
Che stiate rafforzando proattivamente un'analisi dei rischi o rispondendo a un Corrective Action Plan emesso dall'OCR, la richiesta è la stessa: dimostrare cosa è successo, quando e sotto quali controlli — in una forma che non possa essere stata silenziosamente riscritta dopo i fatti. Vault produce quel registro per ogni decisione dell'agente, ogni chiamata a uno strumento e ogni evento di tokenizzazione dei PHI, concatenati con un collegamento SHA-256 al predecessore.
GET /v1/suite/vault/verify
→ {
"ok": true,
"events_verified": 41_902,
"first_event_id": "evt_...",
"last_event_id": "evt_...",
"errors": []
}Accanto alla catena grezza, un report di conformità per framework impacchetta le stesse prove sottostanti in un formato di attestazione:
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..."
}Un'interruzione nella catena, o un controllo segnalato come fallito, vi indica esattamente dove guardare prima che lo faccia un revisore. Questa è la differenza tra ricostruire le prove sotto la pressione di una scadenza e semplicemente riprodurle.
Vault e i report di conformità sono uno strato di prove, non un esito legale. Non costituiscono un'analisi dei rischi completa, una certificazione di conformità HIPAA, né una risoluzione di un Corrective Action Plan dell'OCR ancora aperto. Condurre l'analisi dei rischi in sé — identificare le minacce, valutare probabilità e impatto, documentare le misure correttive — resta un lavoro che la vostra organizzazione deve svolgere, tipicamente con il coinvolgimento della consulenza legale una volta che l'OCR è formalmente coinvolta. Ciò che produce VeriSwarm è il registro sottostante che l'analisi dei rischi e qualsiasi risposta a un CAP possono citare: prova verificabile di cosa hanno toccato gli agenti, quando e sotto quali controlli, invece di un registro non verificabile o di un foglio di calcolo ricostruito.
Vault e Guard sono funzionalità del piano Max (299 $/mese) — non incluse nel livello gratuito di VeriSwarm, che copre solo il punteggio di fiducia degli agenti e l'ingestione degli eventi.
La Security Rule di HIPAA richiede alle covered entity e ai business associate di "condurre una valutazione accurata e approfondita dei potenziali rischi e vulnerabilità per la riservatezza, l'integrità e la disponibilità delle informazioni sanitarie protette elettroniche" (45 CFR §164.308(a)(1)(ii)(A)). L'OCR di HHS ha indicato la mancanza di un'adeguata analisi dei rischi come la sua principale area di interesse per l'enforcement dichiarata per il 2026, ed è stata la categoria più ampia di azioni di enforcement pubblicate — con un ampio margine rispetto a ogni altra categoria di violazione HIPAA combinata.
Sì, se l'agente crea, riceve, mantiene o trasmette ePHI. Un'analisi dei rischi limitata solo a utenti umani e sistemi tradizionali non coglie l'intera superficie di attacco di un agente: i fornitori di LLM che chiama, le integrazioni di strumenti che invoca, i log e la memoria di conversazione su cui scrive, e i fornitori di riserva a cui esegue l'escalation in caso di errore. Lo schema di enforcement dell'OCR non prevede eccezioni per gli attori automatizzati — un agente che gestisce PHI rientra nell'ambito esattamente come farebbe un membro umano del personale.
Un Corrective Action Plan (CAP) richiede tipicamente all'entità di dimostrare un'analisi dei rischi completata, di correggere le lacune identificate secondo una tempistica e — secondo lo schema di enforcement del 2026 — di accettare un obbligo di supervisione dell'OCR di 2 anni. La prova più solida in quel processo è un registro verificabile: quali PHI ha toccato l'agente, quando e sotto quali controlli. Un registro modificabile è una prova debole in una revisione del CAP; un registro concatenato tramite hash che dimostra verificabilmente di non essere stato alterato dopo i fatti è una prova più solida, sebbene non sostituisca l'analisi dei rischi né il lavoro di remediation in sé.
Vault concatena ogni evento registrato — decisioni dell'agente, valutazioni di policy, tokenizzazione e rehydrate dei PHI — con un collegamento SHA-256 al predecessore. GET /v1/suite/vault/verify percorre la catena e restituisce pass/fail con l'evento esatto in cui si verifica un'interruzione, se presente. Questo fornisce a una revisione di analisi dei rischi (o a una risposta a un CAP) una risposta verificabile automaticamente alla domanda "potete dimostrare che questo registro non è stato modificato", invece di una semplice affermazione.
No. L'endpoint di conformità di VeriSwarm (GET /v1/compliance/{framework}) genera un report di attestazione per tenant rispetto a un framework specificato, con conteggi delle prove tratti da Vault e Guard. È un pacchetto di prove strutturato, non una determinazione dell'OCR. Se tali prove soddisfino una specifica revisione dell'OCR o un requisito di CAP è un giudizio legale e fattuale che spetta all'OCR — o alla vostra consulenza legale —, non a VeriSwarm.
È un controllo che un'analisi dei rischi può citare, non un sostituto dell'esecuzione dell'analisi stessa. La tokenizzazione PII di Guard (POST /v1/suite/guard/pii/tokenize) riduce l'esposizione effettiva — i PHI non raggiungono mai l'LLM o la chiamata a uno strumento non tokenizzati — e ogni evento di tokenizzazione viene registrato in Vault, il che è a sua volta una prova a cui un'analisi dei rischi può fare riferimento. Il funzionamento dettagliato della tokenizzazione è trattato in profondità nella pagina sugli agenti IA conformi a HIPAA.
Per capire come funziona realmente la tokenizzazione dei PHI al confine dell'agente — il controllo su cui si basa questo registro di prove — vedi Agenti IA conformi a HIPAA: tokenizzare i PHI prima che il modello li veda. Per la mappatura completa delle priorità di enforcement dell'OCR nel 2026 rispetto alle capacità di VeriSwarm, inizia da VeriSwarm per il settore sanitario.
Una demo guidata di 30 minuti, dal vivo sulla tua flotta — non con dati dimostrativi. Porta la priorità dell'OCR o il requisito di CAP che stai affrontando realmente.