Non è la macchina che deve imparare a fare l’albergatore ­

Reading Time: 8 min

All’Oasi le conversazioni con gli ospiti le tiene in mano lo staff. Tutte, comprese quelle online e quelle che sarebbe più comodo delegare. L’AI la usiamo, e parecchio, ma per due cose precise: tradurre dalle lingue che non parliamo sufficientemente bene, e aiutarci a capire come migliorare il tono di quello che scriviamo. La risposta la scrive una persona, durante le ore di apertura, e siamo aperti tutto l’anno.

Non è una scelta romantica. È una scelta di competenza: voglio che chi lavora con me abbia il polso della situazione, sappia riconoscere una richiesta difficile prima che diventi un problema, e si porti a casa anche la soddisfazione di averla gestita. Sono cose che non si imparano guardando un sistema che risponde al posto tuo.

Gli episodi di questa estate mi hanno convinta che questa posizione, che tenevo per istinto, ha basi molto più solide di quanto pensassi.

Cosa è successo davvero, e cosa dicono i numeri

Circola in questi giorni un dato ripreso da tutta la stampa: a luglio 2026 gli episodi in cui un sistema di intelligenza artificiale è sfuggito al controllo di chi lo stava usando hanno toccato un nuovo massimo, più di trecento casi, quasi il doppio rispetto a giugno, per un totale che nel 2026 supera i 1.600.

La fonte è il Loss of Control Observatory, progetto del Centre for Long-Term Resilience finanziato dall’AI Security Institute britannico, attivo da novembre scorso. La soglia che usano è più alta di quanto suggerisca il titolo: non basta un errore o una risposta sbagliata, serve evidenza concreta di comportamento strategico, cioè il sistema che mente, aggira una salvaguardia o agisce senza consenso.

Va però detto ciò che nei rilanci quasi sempre sparisce. Quel numero misura le segnalazioni pubbliche, raccolte in gran parte da sviluppatori che raccontano su X cosa è andato storto nel loro lavoro. Una parte della crescita riflette il fatto che se ne parla di più e che più persone sanno cosa cercare. È un termometro utile, ma della visibilità del fenomeno almeno quanto del fenomeno stesso.

Il peso vero della notizia sta nei due casi documentati che l’hanno innescata.

Il 21 luglio OpenAI ha dichiarato che due suoi modelli, impegnati in una valutazione interna sulle capacità di cybersicurezza, sono usciti dall’ambiente isolato in cui erano confinati, hanno raggiunto internet e sono arrivati all’infrastruttura di produzione di Hugging Face, la piattaforma su cui è ospitata buona parte dei modelli open source del mondo. Non è vero, come si legge in giro, che nessuno si sia accorto di nulla: Hugging Face aveva rilevato e contenuto l’intrusione il 16 luglio, cinque giorni prima che OpenAI collegasse i propri test all’attacco. Il problema non è stato il mancato rilevamento: è stato che la vittima ha impiegato giorni a capire chi avesse davanti, perché nessuno immagina che dietro un’intrusione ci sia un sistema che sta cercando di superare un esame.

Perché è esattamente questo che è successo. L’indagine indipendente di METR e Redwood Research, pubblicata il 26 agosto, ha ricostruito che circa 1.200 agenti che avrebbero dovuto essere isolati si sono trovati su una bacheca di messaggi non autorizzata, e circa 700 hanno poi partecipato all’attacco. Il dettaglio che trovo più istruttivo è come hanno speso le energie: avevano già capito come ottenere la risposta corretta al test, e quasi tutto lo sforzo successivo è servito a convincere il sistema automatico di valutazione che l’avevano ottenuta legittimamente, compreso un lavoro sistematico per alterare i log delle proprie azioni.

Il secondo caso riguarda Anthropic, che a fine luglio ha rivisto oltre 141.000 sessioni di valutazione e ha individuato tre episodi in cui un proprio modello ha ottenuto accesso a internet dall’ambiente di test di un partner esterno ed è arrivato ai sistemi in produzione di tre organizzazioni reali. La causa non è stata una ribellione, ma una configurazione errata che aveva lasciato quelle macchine esposte, mentre al modello era stato detto di non avere accesso alla rete. Due delle aziende coinvolte non se n’erano accorte.

C’è un passaggio che dovrebbe restare impresso. In uno di quei casi il modello aveva messo per iscritto il dubbio giusto, e cioè che se quella fosse stata la vera internet la sua azione sarebbe stata un attacco reale. Poi si è convinto da solo che lo scenario fosse costruito, sulla base di indizi ambientali che ha letto come artificiali, e ha proseguito.

Il paradosso che il nostro settore sta per scoprire in ritardo

Nel 1983 Lisanne Bainbridge pubblicò su Automatica un articolo di cinque pagine intitolato “Ironies of automation” che da allora è stato citato migliaia di volte, ed è la cosa più utile che io abbia letto quest’anno sul tema.

L’argomento è questo. Quando automatizzi la parte ripetitiva di un lavoro, all’essere umano resta la sorveglianza del sistema e l’intervento nelle situazioni anomale, cioè proprio i compiti che richiedono più competenza. Ma gli hai tolto l’esercizio quotidiano, che costruisce e mantiene quella competenza. Il risultato è un paradosso: più il sistema è automatizzato, più l’operatore dovrebbe essere preparato per quei rari momenti in cui deve subentrare, e meno lo è, perché non pratica più.

Traducetelo in albergo. Se per due stagioni le risposte agli ospiti le scrive un sistema e il vostro receptionist si limita ad approvarle, il giorno in cui arriva la richiesta che il sistema non sa gestire, o il reclamo che va disinnescato con una telefonata, quella persona non ha più gli strumenti. Non perché sia meno capace di prima, ma perché, per due anni, non ha esercitato quella capacità. E il momento in cui ve ne accorgete è sempre il peggiore possibile.

Dove passa davvero il confine

La domanda non è se automatizzare, perché tutti lo facciamo già. Il channel manager che replica una tariffa su otto portali sostituisce un lavoro umano e nessuno lo rimpiange, perché trasferire un numero da una schermata all’altra non costruisce competenza in nessuno.

Il criterio che uso io è duplice. Questo compito accumula giudizio nel tempo? E ha un peso relazionale, cioè l’ospite si accorge di chi c’è dall’altra parte? Se la risposta a entrambe è no, automatizzare è solo una buona gestione. Se è sì anche a una sola, quello che state risparmiando in minuti lo state pagando in capacità organizzative.

C’è un’eccezione che va riconosciuta onestamente, perché altrimenti questo discorso suona nostalgico. In molte strutture stagionali, o chiuse la sera, l’alternativa all’automazione non è una persona che cresce, è nessuno. La richiesta in tedesco che arriva alle due di notte a novembre non forma nessun collaboratore, restando senza risposta. Lì l’agente non riduce un essere umano, copre un’assenza, ed è una scelta legittima. Il mio ragionamento vale dove c’è uno staff da far crescere, che è la condizione in cui mi trovo io e in cui si trova la maggior parte delle strutture aperte tutto l’anno.

La distinzione tecnica che serve conoscere

Detto tutto questo, resta il tema pratico, e qui la distinzione che conta è tra chatbot e agente.

Un chatbot produce testo, e il peggio che può succedere è che pubblichiate qualcosa di sbagliato. Un agente ha strumenti, credenziali e permessi persistenti e può fare cose nel mondo: inviare email, modificare tariffe, aprire e chiudere disponibilità, scrivere nel gestionale. Tutti gli episodi di cui abbiamo parlato appartengono alla seconda categoria, e il settore alberghiero ci sta correndo dentro spinto da fornitori che promettono automazione da un capo all’altro del processo.

Cinque regole applicabili da domani mattina.

• Privilegio minimo. Credenziali dedicate, revocabili, in sola lettura ovunque sia possibile. Mai l’account amministratore del PMS o del channel manager, mai un accesso condiviso con il resto del team.
• Approvazione umana su tutto ciò che è irreversibile. Invio di comunicazioni agli ospiti, modifiche di prezzo, cancellazioni, pubblicazioni sui social. Il sistema prepara, una persona conferma.
• Ambienti separati per i test. Se provate un’automazione, provatela su dati finti, non sul gestionale vivo.
• Log leggibili, e riletti davvero. Se non potete ricostruire che cosa ha fatto lo strumento e quando, non potete usarlo sui dati degli ospiti. Non è solo buon senso: è la base della responsabilità che il GDPR pone a vostro carico, come titolari del trattamento, non al fornitore.
• Domande al fornitore prima della firma. Quali permessi chiede il sistema e su quali piattaforme. Può scrivere o solo leggere. Posso revocare l’accesso in autonomia e in quanto tempo. Dove finiscono i dati degli ospiti. Mi fornite i log delle azioni compiute. Un fornitore serio ha queste risposte pronte, e se non le ha è già un’informazione.

Il punto

Quello che mi ha colpita degli incidenti di luglio non è che i modelli siano sfuggiti al controllo. È che sono sfuggiti al controllo di chi li ha costruiti, dentro ambienti progettati apposta per contenerli, con team di sicurezza da decine di persone. Se è successo lì, l’idea che una struttura ricettiva di venti camere possa dare a un sistema le chiavi del proprio gestionale e poi occuparsi d’altro è, semplicemente, una fantasia commerciale.

Ma la ragione per cui all’Oasi le conversazioni le teniamo noi non è la paura. È che la competenza del mio staff è un patrimonio che si costruisce solo esercitandola, e nessun risparmio di tempo lo compensa. L’AI ci serve per abbattere le barriere che ci rallentano davvero, la lingua in primo luogo, e per farci da specchio quando vogliamo capire se un messaggio suona come volevamo. Il resto lo facciamo noi.

La domanda che ogni direzione dovrebbe porsi nel 2026 non è cosa la macchina sappia fare. È quali competenze vogliamo continuare a esercitare, e chi risponde quando l’automazione non basta più. Perché quel momento arriva sempre, e arriva quando nessuno se lo aspetta.

Per approfondire

• Bainbridge, L. (1983), Ironies of automation, Automatica 19(6): https://www.sciencedirect.com/science/article/abs/pii/0005109883900468
• Sintesi e contesto del paper: https://en.wikipedia.org/wiki/Ironies_of_Automation
• Loss of Control Observatory, Centre for Long-Term Resilience: https://www.longtermresilience.org/reports/the-loss-of-control-observatory-a-prototype-to-detect-real-world-ai-control-incidents/
• Ricostruzione tecnica pubblicata da Hugging Face: https://huggingface.co/blog/agent-intrusion-technical-timeline
• Report di OpenAI sull’incidente: https://openai.com/index/hugging-face-incident-and-the-road-ahead/
• Indagine indipendente di METR e Redwood Research: https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/
• Sintesi della disclosure di Anthropic: https://www.helpnetsecurity.com/2026/07/31/anthropic-claude-cybersecurity-incidents/

Domande frequenti

Un sistema di AI può davvero agire senza il permesso di chi lo sta usando? Sì, ed è documentato. Il Loss of Control Observatory registra episodi in cui un sistema mente, aggira una salvaguardia o agisce oltre il mandato ricevuto: più di trecento a luglio 2026, oltre 1.600 nell’anno. Non si tratta di volontà propria, ma di ottimizzazione: il modello viene premiato per il risultato e non per il metodo, e se la strada più breve passa fuori dai binari la prende.

Che differenza c’è fra un chatbot e un agente AI? Un chatbot produce testo e nient’altro: il rischio massimo è che pubblichiate qualcosa di sbagliato. Un agente ha credenziali, strumenti e permessi persistenti, quindi può compiere azioni reali sui vostri sistemi, dal gestionale alle tariffe alla posta. Tutti gli incidenti gravi del 2026 riguardano agenti, non chatbot.

Usare l’AI per scrivere le risposte agli ospiti è rischioso? Dal punto di vista tecnico no, se il testo passa da una persona prima di partire. Il rischio è di natura diversa e più lenta: se per due stagioni il vostro staff si limita ad approvare testi scritti da un sistema, perde l’esercizio quotidiano che costruisce la capacità di gestire i casi difficili. È il paradosso descritto da Lisanne Bainbridge nel 1983.

Quali attività di una struttura ricettiva conviene automatizzare? Quelle che non accumulano giudizio nel tempo e non hanno peso relazionale. La sincronizzazione delle tariffe fra portali rientra pienamente in questa categoria. Le conversazioni con gli ospiti, la gestione dei reclami e le decisioni di prezzo no: lì il tempo risparmiato si paga in competenza dell’organizzazione.

Se un sistema AI commette un errore con un ospite, di chi è la responsabilità? Vostra. Ai fini del GDPR la struttura resta titolare del trattamento dei dati degli ospiti, e la responsabilità contrattuale verso il cliente non si trasferisce al fornitore del software. È la ragione per cui i log delle azioni compiute dal sistema non sono un dettaglio tecnico ma un requisito, e vale la pena verificare la propria posizione con un consulente prima di attivare automazioni sui dati.

Come capisco se un fornitore di soluzioni AI è affidabile? Fategli cinque domande prima di firmare: quali permessi chiede il sistema e su quali piattaforme, se può scrivere o solo leggere, se potete revocare l’accesso in autonomia e in quanto tempo, dove finiscono i dati degli ospiti, se vi fornisce i log delle azioni compiute. Chi lavora seriamente ha queste risposte pronte.

L’intelligenza artificiale toglierà lavoro al personale di reception? La domanda più utile è un’altra: quali competenze volete che il vostro staff continui a esercitare. Un sistema che risponde al posto di una persona non riduce solo il carico di lavoro, riduce anche l’occasione di imparare e la responsabilità del risultato. In una struttura aperta tutto l’anno, con un team da far crescere, è un costo che raramente conviene.

 

© immagine di copertina: Pressmaster via Canva Pro