Costruire la knowledge base del Comune: i passi che contano

Dalla scelta delle fonti ai permessi, fino alla manutenzione: i passaggi concreti per trasformare gli atti del Comune in una knowledge base utile.

Una knowledge base comunale non si compra: si costruisce. La tecnologia — indicizzazione dei contenuti, ricerca per concetti, generazione di risposte con citazioni — è ormai matura; quello che fa la differenza tra una memoria utile e un contenitore inerte è il lavoro documentale che ci sta sotto. La buona notizia è che si tratta di un percorso graduale, che produce valore fin dalle prime settimane e non richiede di fermare gli uffici. Richiede però un responsabile: qualcuno — la segreteria, il servizio informatico, un gruppo trasversale — che risponda della qualità della memoria come si risponde della qualità dell'archivio.

Ecco i passaggi che contano davvero, nell'ordine in cui conviene affrontarli.

Primo: scegliere le fonti, non caricare tutto

L'istinto è versare nell'IA l'intero archivio, alla rinfusa. È un errore: una memoria è utile se è curata. Conviene partire dai documenti che rispondono alle domande più frequenti degli uffici e dei cittadini, e allargare il perimetro per cerchi successivi, verificando a ogni passo la qualità delle risposte. Un perimetro piccolo e curato dà risposte affidabili da subito; un perimetro enorme e sporco produce solo sfiducia — e la sfiducia, una volta installata, è il vero costo del progetto.

• Regolamenti vigenti e carte dei servizi: la base delle risposte al pubblico
• Delibere e determine recenti: i precedenti che gli uffici cercano ogni giorno
• Convenzioni e contratti attivi: le regole dei rapporti in corso con fornitori e concessionari
• L'archivio storico dematerializzato: per ultimo nell'ordine, non per importanza

Secondo: governare versioni e permessi

Un regolamento abrogato che resta in memoria è più dannoso di un regolamento assente: l'IA risponderebbe con una regola che non esiste più. La knowledge base ha bisogno di un ciclo di vita: i documenti superati si marcano come storici, le nuove versioni prendono il loro posto, e la data dell'atto accompagna ogni risposta, così che chi legge sappia sempre a quale stagione normativa appartiene.

Lo stesso vale per la riservatezza: non tutto ciò che l'ente produce può essere letto da tutti. I fascicoli con dati personali entrano con i permessi degli uffici competenti, oppure restano fuori. Una memoria che ignora i profili di accesso non è un'innovazione: è una violazione del GDPR in attesa di accadere, e va progettata prima, non rattoppata dopo.

Terzo: misurare e correggere

La qualità di una knowledge base si vede dalle domande che sbaglia. Le prime settimane di uso reale sono la fase più preziosa del progetto: le risposte deboli o ambigue indicano documenti mancanti, testi poco chiari, versioni datate. Correggere la fonte — non la singola risposta — è la manutenzione che conta, perché sistema il problema per tutte le domande future. Aiuta fissare fin dall'inizio un piccolo rituale di manutenzione: una revisione periodica delle domande rimaste senza risposta soddisfacente, l'aggiornamento delle fonti dopo ogni seduta che modifica i regolamenti, un referente per ufficio che segnala i documenti nuovi da includere. Sono ore, non giornate — ma sono le ore che tengono viva la memoria.

È anche il criterio giusto per valutare gli strumenti: una piattaforma seria mostra da quali atti deriva ogni risposta e permette di risalire in un passaggio al documento da correggere. Se la risposta non è verificabile, non state costruendo la memoria dell'ente: state solo aggiungendo l'ennesimo chatbot.