Premesse
La possibilità di interrogare un sistema gestionale scrivendo una domanda in linguaggio naturale invece di costruire un filtro manualmente – “quali asset critici nell’edificio A non sono stati verificati negli ultimi sei mesi” – è una delle capacità che più cambiano l’esperienza quotidiana di chi non ha dimestichezza con query strutturate.
La tentazione tecnica più diffusa, oggi, è risolvere questo problema inoltrando la domanda a un grande modello linguistico ospitato su un servizio cloud esterno. È una scorciatoia rapida da implementare, ma per un sistema che tratta dati aziendali sensibili su edifici, persone e infrastrutture, comporta un compromesso che molte organizzazioni – a ragione – non sono disposte ad accettare.
Perché inviare le domande di un utente, o i dati aziendali sottostanti, a un servizio LLM esterno è un problema per molte organizzazioni FM?
Un’interrogazione in linguaggio naturale su un sistema di Facility Management spesso riguarda informazioni che un’organizzazione considera riservate: la distribuzione di asset critici, lo stato di sicurezza di un edificio, dati aggregati su costi di manutenzione. Instradare queste domande – e talvolta i dati necessari a formularne la risposta – verso un servizio cloud esterno gestito da terzi introduce una superficie di rischio che va oltre il semplice funzionamento tecnico.
Significa affidare a un’infrastruttura non controllata dall’organizzazione stessa un flusso continuo di informazioni potenzialmente sensibili, con implicazioni di data sovereignty che, per determinati settori regolamentati o per proprietari particolarmente attenti alla riservatezza dei propri asset, sono semplicemente inaccettabili a prescindere dalle garanzie contrattuali offerte dal fornitore del servizio esterno.
Perché è fondamentale che ogni interrogazione in linguaggio naturale generi sempre e solo query di sola lettura?
Un principio di sicurezza che non dovrebbe mai essere negoziabile: un’interrogazione formulata in linguaggio naturale, per quanto ben progettato sia il motore che la interpreta, non dovrebbe mai poter generare un’operazione di scrittura o di modifica sui dati. Limitare rigorosamente l’interprete a generare esclusivamente query di lettura elimina alla radice il rischio che un’ambiguità nell’interpretazione di una domanda – un rischio intrinseco a qualunque sistema di comprensione del linguaggio, per quanto accurato – si traduca in una modifica indesiderata dei dati aziendali. È un vincolo architetturale semplice da imporre tecnicamente, ma che richiede una disciplina esplicita nel progetto del motore, per non lasciare mai la porta aperta a un’estensione futura che confonda interrogazione e modifica.
Come si progettano i guardrail contro un uso improprio o malevolo dell’interprete?
Anche un motore locale e deterministico deve difendersi da tentativi di uso improprio: qualcuno che prova a formulare domande costruite per esplorare sistematicamente dati a cui non dovrebbe avere accesso, o che tenta di far generare al motore query artificiosamente complesse per sovraccaricare il sistema.
Un motore ben progettato dovrebbe includere un rilevamento esplicito di termini o pattern “pericolosi” nella domanda formulata, bloccando immediatamente l’elaborazione e generando una notifica automatica agli amministratori di sistema, così che un tentativo sospetto non passi inosservato ma diventi visibile a chi ha la responsabilità di sorvegliare l’uso del sistema.
Perché conservare lo storico delle conversazioni senza salvare i dati grezzi restituiti è una scelta tecnica di minimizzazione, non un limite funzionale?
Mantenere uno storico delle domande poste da un utente è utile – permette di ripetere una ricerca precedente, di capire come viene effettivamente usato lo strumento nel tempo – ma salvare insieme allo storico anche i dati grezzi restituiti come risposta significherebbe duplicare informazioni potenzialmente sensibili in un secondo registro, aumentando la superficie di dati da proteggere senza un beneficio proporzionale.
Una scelta tecnica più prudente conserva l’intento della domanda – cosa è stato chiesto, in che forma – senza persistere il contenuto specifico dei dati restituiti in quel momento, che restano interrogabili di nuovo, alla fonte, se servono realmente in un secondo momento. È lo stesso principio di minimizzazione dei dati di cui ho parlato a proposito del GDPR, applicato qui in modo specifico allo storico delle interazioni con l’interprete.
Come si guida l’utente a formulare domande efficaci senza richiedergli di imparare una sintassi tecnica?
Un’interfaccia di composizione assistita, che suggerisce entità note – edifici, categorie, campi disponibili – mentre l’utente digita, per esempio attraverso menu contestuali richiamabili con caratteri speciali dedicati, riduce l’ambiguità delle domande formulate senza richiedere all’utente di conoscere la struttura interna del database.
È un compromesso tecnico intelligente tra la libertà del linguaggio naturale puro, che massimizza l’ambiguità, e un modulo di ricerca strutturato tradizionale, che massimizza la precisione ma richiede competenza tecnica: guidare la formulazione con suggerimenti contestuali mantiene alta la precisione senza sacrificare l’accessibilità per chi non ha familiarità con la struttura dei dati.
Che valore ha, per il proprietario e per il responsabile IT, sapere che questa capacità non dipende da un fornitore esterno di intelligenza artificiale?
Per il proprietario, significa che una capacità ormai percepita come uno standard atteso in un sistema moderno non comporta l’accettazione implicita di condizioni di trattamento dati dettate da un fornitore terzo di intelligenza artificiale, con tutte le incertezze normative e commerciali che questo comporta nel tempo.
Per il responsabile IT, significa poter includere questa funzionalità nel proprio perimetro di sicurezza controllato, senza dover gestire un’eccezione verso l’esterno per una singola funzione, per quanto utile, dell’applicazione. È un esempio concreto di come la sovranità sui propri dati, tema che attraversa in filigrana tutta questa serie, si applichi anche alla frontiera più recente della tecnologia applicata al facility management.
Conclusioni
Un’interrogazione in linguaggio naturale sui dati aziendali può essere realizzata interamente in locale, con un parser deterministico specializzato nel dominio FM, query sempre di sola lettura, guardrail espliciti contro usi impropri e uno storico conservato secondo un principio di minimizzazione dei dati – senza mai dover inviare domande o dati aziendali a un servizio esterno.
È una scelta architetturale che richiede più lavoro ingegneristico iniziale rispetto a una semplice integrazione con un servizio cloud di terzi, ma che restituisce all’organizzazione un controllo pieno su una capacità sempre più centrale. Nel prossimo articolo restiamo nell’ambito tecnico, ma ci spostiamo dall’intelligenza applicata ai dati alla salute del sistema stesso: l’osservabilità inclusa, pensata per chi deve monitorare il sistema senza un reparto DevOps dedicato.
Se vuoi un supporto qualificato sull’argomento puoi contattarmi qui