Checklist di go-live

Stabile

Settimo e ultimo passaggio della guida rapida. Questa checklist separa un servizio pubblicato da un servizio pronto per il pubblico.

Esegui i controlli con il team di progetto e registra l'esito. Ogni voce non spuntata è un rischio che ti assumi consapevolmente.

Configurazione

• Il progetto è pubblicato nell'ambiente produzione e la versione attiva è quella approvata.
• Il modello AI è collegato e il modello di fallback è configurato e provato.
• Temperatura e maxTokens sono coerenti con il tipo di servizio.
• Il prompt di sistema è stato riletto e approvato da un referente di reparto.
• Il prompt contiene le regole di handover verso un operatore.
• L'avatar ha nome e immagine definitivi, senza segnaposto.
• Il messaggio di benvenuto è nella lingua corretta e non contiene testo di prova.
• Tutti i domini di produzione sono nell'elenco autorizzato, incluse le varianti con e senza www.
• Nessun dominio di prova, localhost o staging è presente nell'elenco di produzione.
• I flussi conversazionali attivi sono stati percorsi dall'inizio alla fine almeno una volta.
• Gli strumenti collegati rispondono correttamente e gestiscono il caso di errore.
• Gli endpoint webhook rispondono 200 e la verifica della firma HMAC è attiva.
• Le note di rilascio dell'ultima pubblicazione sono compilate.

Contenuti

• Tutti i documenti sono in stato Indicizzato: nessuno in errore o parziale.
• I documenti obsoleti sono stati rimossi, non solo affiancati dalle nuove versioni.
• Tariffe, orari, sedi e recapiti sono aggiornati alla data di go-live.
• Le quindici domande più frequenti ricevono una risposta corretta nella prova di recupero.
• L'agente dichiara di non sapere quando l'informazione non è presente, invece di inventarla.
• Nessun documento contiene dati personali di terzi o informazioni riservate.
• I documenti scansionati hanno superato la verifica dell'OCR.
• È individuato un referente responsabile dell'aggiornamento dei contenuti.
• È fissata la cadenza di revisione periodica della knowledge base.

Sicurezza

• Tutti gli utenti con ruolo amministrativo hanno l'MFA attiva.
• Esistono almeno due amministratori, per non restare bloccati in caso di indisponibilità di uno.
• I ruoli assegnati rispettano il principio del privilegio minimo.
• Non ci sono inviti in sospeso non più necessari.
• Gli account di persone non più operative sono disattivati.
• Le chiavi API in uso sono limitate allo stretto necessario e nessuna è condivisa fuori dai sistemi.
• Nessuna chiave API compare nel codice sorgente pubblico del sito.
• I segreti dei webhook sono conservati in un gestore credenziali, non in file di configurazione versionati.
• È definita la procedura di rotazione delle chiavi e la relativa periodicità.
• Il log di audit è stato consultato almeno una volta e il team sa dove trovarlo.

Conformità

• L'informativa privacy del sito cita il servizio di assistenza conversazionale.
• Il widget è integrato con il banner di consenso e non parte prima del consenso, dove richiesto.
• Il DPA con il fornitore è firmato e archiviato.
• I periodi di conservazione di sessioni e allegati sono coerenti con l'informativa pubblicata.
• È definita la procedura per rispondere alle richieste degli interessati ai sensi del GDPR.
• L'agente non richiede dati particolari, in ambito sanitario, giudiziario o finanziario.
• Il registro dei trattamenti è aggiornato con il nuovo trattamento.
• Nel contesto sanitario, la distinzione tra regime SSN e regime privato è gestita correttamente nei flussi.
• È verificato che l'agente non fornisca consulenza legale, fiscale o medica.

Il dettaglio degli adempimenti è in Conformità.

Monitoraggio

• La dashboard delle statistiche è accessibile ai responsabili.
• Sono definiti gli indicatori da osservare nella prima settimana: volume sessioni, tasso di handover, tempo di risposta, conversazioni senza risposta utile.
• Sono attive le notifiche per le conversazioni in attesa oltre la soglia stabilita.
• Il consumo di token è monitorato e la soglia di allerta è impostata in Fatturazione.
• È pianificata una revisione delle conversazioni reali entro sette giorni dal go-live.
• Il registro delle consegne webhook è monitorato per individuare errori ricorrenti.
• È definito chi controlla la coda e con quale frequenza durante l'orario di servizio.

Supporto e presidio

• Gli operatori sanno accedere alla Console e prendere in carico una conversazione.
• Gli orari di presidio umano sono definiti e comunicati nel messaggio del widget.
• È previsto un messaggio automatico fuori orario con i recapiti alternativi.
• È definito il percorso di escalation interno per i casi che l'operatore non può risolvere.
• Il team conosce i canali di assistenza descritti in Supporto.
• È fissata una riunione di verifica a una settimana dal go-live.
• È individuato il referente unico del progetto verso il fornitore.

Prova finale end-to-end

Primi sette giorni