AI
L’intelligenza artificiale è entrata nel mio lavoro da due direzioni diverse: come tecnologia da portare in produzione dentro un prodotto, con clienti veri e costi veri, e come strumento quotidiano che ha cambiato il modo in cui sviluppo e gestisco i sistemi. Sono due esperienze distinte, e la prima insegna cose che la seconda da sola non può insegnare.
AI in produzione
Il banco di prova è AboutMyHotel, la piattaforma di reputation intelligence per hotel di cui sono fondatore e sviluppatore unico. Il cuore del sistema è un livello di analisi basato su modelli linguistici che legge il testo delle recensioni e produce sentiment, temi ricorrenti, azioni suggerite, bozze di risposta e un briefing settimanale. Il lavoro è distribuito su quattro agenti con ruoli distinti, (analisi reputazionale, supporto, amministrazione, marketing) progettati come persona configurabili da pannello, non come prompt fissati nel codice: ognuno ha un ruolo, un modello assegnato e una propria base di conoscenza.
Usare un modello linguistico in un prototipo e usarlo in un prodotto in produzione sono due mestieri diversi.
In produzione ogni chiamata ha un costo, e il costo diventa un vincolo di progettazione, non un dettaglio da ottimizzare dopo. Da lì discendono le scelte architetturali: il routing per modello in base al compito, con un modello più capace per la generazione narrativa dei report e uno più leggero ed economico per l’estrazione strutturata e le traduzioni; la raccolta incrementale dei dati, perché il costo dell’analisi è proporzionale al volume elaborato; una pipeline a step disaccoppiati, che permette di far girare l’analisi su cadenze diverse dalla raccolta e di isolare i costi per fase.
L’altro fronte è l’affidabilità. Un modello linguistico non è deterministico, ma il prodotto che lo usa deve esserlo abbastanza da poter arrivare a un cliente: l’output va validato prima di essere consegnato, non dopo. E l’isolamento dei dati è una regola architetturale, non una buona intenzione: nessuna analisi può leggere dati di una struttura diversa da quella richiesta.
Obblighi di trasparenza e protezione dei dati
Un sistema di AI che interagisce con le persone ha obblighi di trasparenza precisi, definiti dall’articolo 50 dell’AI Act. Il lavoro interessante è stato la mappatura: individuare tutti i punti in cui un utente entra in contatto con un output generato da AI e implementare in ciascuno una disclosure esplicita. La superficie è più ampia di quanto sembri, perché non si limita all’interfaccia di chat: include i PDF dei report, le email, le risposte ai ticket e le pagine legali del sito.
Sul fronte dei dati, l’impostazione che ho progettato e implementato parte da scelte concrete: hosting e database in Unione Europea, tag di misurazione attivati solo su evento di consenso, accordi formali per il trattamento dei dati con i fornitori, backup cifrati fuori sede. Con una considerazione in più: le recensioni sono contenuti scritti da persone terze che attraversano un modello linguistico, quindi il tema non è solo la protezione dei dati del cliente, ma anche il trattamento di contenuti altrui.
Strumenti quotidiani
Fuori dal progetto AboutMyHotel, l’AI è parte del mio flusso di lavoro di tutti i giorni: sviluppo assistito di temi e plugin, analisi dei log, diagnosi di problemi in produzione, indagine degli incidenti su più server, automazione delle attività DevOps ricorrenti. Li integro in due modi, a seconda di cosa serve. Con il Model Context Protocol (MCP) collego gli strumenti direttamente agli ambienti su cui lavoro, così l’assistente ragiona sul contesto reale invece che su una descrizione di seconda mano. Con le API, invece, il modello entra dentro il codice: automazioni, elaborazioni in blocco, funzionalità di prodotto.
La regola con cui li uso è la stessa che vale per ogni diagnosi: lo strumento accelera, ma la direzione tecnica, la verifica e la decisione restano mie. Un’ipotesi suggerita da un modello vale quanto un’intuizione: finché non è verificata con un riscontro, non è una risposta.