Per configurare Amazon Quick per flussi di lavoro HIPAA, definite prima dell’uso di informazioni sanitarie protette (PHI) il BAA dell’account, la chiave di cifratura, il modello di identità e i controlli di accesso ai documenti. AWS descrive Amazon Quick come idoneo HIPAA, ma questa idoneità non rende automaticamente conforme l’intero ambiente del cliente.
Che cosa copre l’idoneità HIPAA
HIPAA è il quadro statunitense per la protezione delle informazioni sanitarie. Nella guida pubblicata il 22 ottobre 2026, AWS descrive l’idoneità di Amazon Quick per i client web, desktop e mobile; le istruzioni di configurazione si concentrano sulla versione web. Il cliente resta responsabile dell’accettazione del Business Associate Agreement (BAA), dell’uso di servizi idonei e della configurazione, governance e salvaguardia del proprio ambiente.
AWS indica che il BAA si accetta tramite AWS Artifact per uno specifico account AWS. L’accordo non si estende agli altri account, ai servizi non idonei o alla configurazione scelta dal cliente. Prima di procedere, identificate quindi l’account interessato e le responsabilità che spettano alla vostra organizzazione.
Decisioni da prendere prima di creare le risorse
AWS segnala che alcune scelte hanno conseguenze dopo la creazione delle risorse. La tabella riassume quando fissarle e che cosa comportano.
| Decisione | Quando definirla | Conseguenza |
| Chiave dei dati Amazon Quick | Prima della prima creazione di dati Quick nell’account | AWS afferma che la chiave dell’account non può essere cambiata successivamente. Le chiavi gestite dal cliente richiedono un abbonamento Enterprise; la cifratura gestita da AWS è descritta come idonea. |
| Modello di identità | Prima di assegnare utenti e autorizzazioni | AWS elenca IAM Identity Center, Active Directory, federazione IAM e utenti locali Quick. Cambiare provider richiede di riprovisionare autorizzazioni e appartenenze agli spazi. |
| Riconoscimento delle ACL dei documenti | Alla creazione di una knowledge base supportata | AWS afferma che l’impostazione non si può aggiungere in seguito. Associazioni errate tra identità e ACL possono esporre documenti senza errori o avvisi. |
La cifratura a riposo è attiva per impostazione predefinita con chiavi di proprietà o gestite da AWS, secondo la guida. Una chiave gestita dal cliente non è quindi un requisito generale per l’idoneità HIPAA; valutate se vi serve e, in tal caso, sceglietela prima che Amazon Quick crei dati nell’account. AWS indica che il rilevamento degli utenti inattivi è disponibile con IAM Identity Center o Active Directory.
Per una knowledge base con documenti sensibili, verificate la corrispondenza tra identità e ACL prima di acquisire i contenuti. AWS indica un aggiornamento predefinito ogni 24 ore e suggerisce di ridurre l’intervallo quando le modifiche agli accessi devono propagarsi più rapidamente.
Separare documenti e dati strutturati
I documenti non strutturati e i dati analitici strutturati richiedono controlli distinti nell’architettura descritta da AWS. Per i primi, la knowledge base usa ACL a livello di documento. Per i secondi, Amazon Quick Sight può applicare controlli a livello di riga e colonna, mentre i permessi del data lake a monte fanno capo a Lake Formation e al Glue Data Catalog.
Nell’esempio fittizio di AWS, i documenti in Amazon S3 passano a una knowledge base con ACL. I dati sui sinistri vengono invece preparati e de-identificati a monte, governati tramite Lake Formation e interrogati con Athena e Quick Sight. È un modello illustrativo: non descrive una distribuzione di un cliente.
Registri di audit e conservazione
AWS distingue AWS CloudTrail, che registra le operazioni API supportate e alcuni eventi non API, dai log vended di Amazon CloudWatch, che includono registrazioni specifiche delle funzioni di IA. AWS afferma che CloudTrail non registra il contenuto dei messaggi di chat né delle risposte. I log di chat e feedback in CloudWatch possono invece contenere PHI.
AWS elenca cinque tipi di log vended: CHAT_LOGS, FEEDBACK_LOGS, AGENT_HOURS_LOGS, INDEX_USAGE_LOGS e KB_FILE_SYNC_LOGS. Prima di avviare flussi con PHI, predisponete l’accesso ai registri e verificate il comportamento delle ACL e della registrazione usando flussi senza PHI, come raccomanda la guida.
La regola dei sei anni e la raccomandazione AWS sui log hanno ambiti diversi.
| Indicazione | Che cosa copre | Durata e decorrenza |
| 45 CFR §164.316(b)(1) e (b)(2)(i) | Documentazione richiesta dal Security Rule: policy e procedure scritte, oltre ai registri di azioni, attività o valutazioni che la norma richiede di documentare | Sei anni dalla creazione oppure dall’ultima data in cui la documentazione era in vigore, se successiva |
| Raccomandazione AWS | Conservazione dei log nell’ambito della guida operativa | Almeno sei anni; AWS la presenta come raccomandazione, non come la regola documentale citata sopra |
Il testo di 45 CFR §164.316 stabilisce quel periodo per la documentazione indicata dalla disposizione. Non formula un obbligo generale di conservare per sei anni ogni log grezzo, chat o dato di telemetria di Amazon Quick.
Verifiche prima di ampliare l’uso
AWS descrive le barriere di sicurezza di Amazon Quick come probabilistiche. La guida indica di affiancarle a controlli deterministici, come policy IAM, ACL e confini di rete. Prima di estendere l’uso, verificate quindi le autorizzazioni, le mappature ACL e i flussi di audit con dati senza PHI.
AWS descrive inoltre Amazon Quick come un servizio in una singola Regione, senza failover tra Regioni. Come possibile schema di ripristino, indica una distribuzione separata e dati di supporto in un’altra Regione.
Prima di abilitare un flusso con PHI, controllate che il BAA riguardi l’account previsto, che la scelta della chiave sia stata fatta, che identità e autorizzazioni siano corrette e che la knowledge base applichi le ACL necessarie.
