Prima di firmare: cosa insegna un framework da CIO enterprise a chi valuta un fornitore AI per un piccolo hotel

Walid Al-Hajj, dirigente tecnologico con vent’anni di esperienza tra banche e proptech, oggi consulente per Technium Consulting, ha scritto su Hotel Business un pezzo che parte da un’immagine che chiunque abbia mai assistito a una demo di un fornitore tecnologico riconosce immediatamente: il chatbot risponde in due secondi a una domanda complessa, il modello di revenue management fa salire il RevPAR proiettato su una struttura campione, la sala resta in silenzio colpita. Poi arriva il contratto, comincia l’integrazione vera, e un anno dopo il pilota viene silenziosamente spento.

Il dato che apre l’articolo, e che vale la pena riportare per intero, proviene da uno studio del MIT NANDA, ripreso da Fortune: il 95% dei progetti pilota di AI generativa nelle aziende non produce alcun impatto misurabile sul risultato economico. Gartner, in un’altra stima citata da Al-Hajj, prevedeva che il 30% dei progetti di AI generativa sarebbero stati abbandonati dopo la fase di proof of concept entro fine 2025. Sono numeri che meritano di circolare più di quanto lo facciano, perché l’entusiasmo con cui l’AI viene proposta al nostro settore raramente si accompagna a un livello di trasparenza sui tassi di fallimento reali.

Il framework, pensato per grandi gruppi

Il cuore dell’articolo è un metodo in quattro passaggi: calcolare il costo totale, non solo il canone di licenza, scontare il ritorno atteso per il rischio reale di fallimento, fissare metriche e criteri di uscita prima ancora di iniziare il pilota, e verificare la conformità normativa prima della firma, non dopo. È un metodo rigoroso, costruito con lo stesso approccio con cui un istituto bancario valuterebbe un nuovo sistema, ed è esplicitamente pensato per gruppi alberghieri strutturati: Al-Hajj parla di costruire una stima su sei voci di costo, integrazione, pulizia dei dati, riqualificazione del personale, monitoraggio del modello, licenze e gestione del cambiamento, con una build enterprise personalizzata che può costare tra 500.000 e 2 milioni di dollari, più il 30-40% ogni anno per mantenerla. Parla di confrontare i risultati con una “struttura di controllo abbinata”, cioè una proprietà gemella dello stesso gruppo su cui non si applica il pilota, per isolare l’effetto reale dello strumento. È evidente che questo framework, nella sua forma completa, appartiene a un mondo fatto di portfolio di decine o centinaia di hotel, con un CIO dedicato e un team che può permettersi di condurre test controllati.

Cosa resta, tradotto per la nostra scala

Qui, però, invece di scartare l’articolo come irrilevante, ho preferito isolare i principi che restano validi anche per una struttura indipendente, perché, a ben vedere, sono quelli più importanti del pezzo, non i numeri in dollari.

Il primo principio è che una demo non è una prova. Gira su dati puliti, su un numero ristretto di domande preparate, senza nessuno dei problemi di integrazione che caratterizzano una struttura reale in funzione da anni. Ogni volta che valuto una proposta tecnologica per un cliente, anche insieme al consulente tecnico con cui collaboro su alcuni progetti, la prima domanda che faccio non è “quanto costa”, ma “fammelo vedere funzionare sui miei dati reali, non sui vostri”, e questo articolo mi conferma che è la domanda giusta, non solo prudenza personale.

Il secondo principio, quello del costo totale contro il canone di licenza, è forse il più trasferibile di tutti, e forse ancora più urgente per una piccola struttura che per una grande catena, perché una catena può assorbire un pilota fallito su una singola proprietà, mentre per un hotel indipendente ogni euro e ogni ora spesa in un progetto che non funziona pesa direttamente sul conto economico dell’unica struttura che si gestisce. Le sei voci di costo che Al-Hajj elenca, integrazione, pulizia dei dati, formazione del personale, monitoraggio, licenza e gestione del cambiamento, restano tutte rilevanti anche a scala ridotta, semplicemente con cifre più piccole. Quando ho lavorato al progetto di dati strutturati per il mio hotel, di cui ho già parlato in un articolo precedente, il costo reale non è stato solo il compenso del professionista che ha costruito lo schema, ma anche il tempo che ho dovuto dedicare a fornire informazioni corrette, verificare il risultato e tenerlo aggiornato nel tempo, un costo che raramente viene messo per iscritto prima di iniziare un progetto simile.

Il terzo principio, quello dei criteri di uscita fissati prima di cominciare, è probabilmente il più difficile da applicare in una piccola struttura, proprio per ragioni umane: quando sei tu stesso il decisore, il finanziatore e spesso anche l’utilizzatore del nuovo strumento, è molto più difficile ammettere che un pilota non sta funzionando, perché non c’è alcun comitato esterno a cui rispondere. Scrivere prima di iniziare, magari anche solo in una nota condivisa con chi ci affianca nella gestione, cosa dovrebbe succedere entro quale data perché lo strumento valga la pena di continuare, è un esercizio semplice che consiglio a chiunque stia per firmare un contratto con un fornitore AI, indipendentemente dalla dimensione della struttura.

Il punto che riguarda tutti, senza eccezioni

L’ultima parte dell’articolo, quella sulla conformità normativa, è quella che considero applicabile senza alcuna riduzione di scala, e che collega direttamente a un tema che avevamo già affrontato parlando di DeepSeek e del Garante Privacy italiano. Al-Hajj ricorda che l’Information Commissioner’s Office britannico ha multato Marriott per 18,4 milioni di sterline per una violazione relativa a 339 milioni di dati degli ospiti, e sottolinea un punto legale cruciale: è l’hotel, in quanto titolare del trattamento, a rispondere, anche quando il problema nasce nel sistema cloud di un fornitore esterno. Le cinque verifiche che propone prima di firmare qualunque contratto AI, cosa sa il modello sui dati personali degli ospiti, se i dati alimentano l’addestramento del fornitore, se il sistema può discriminare in modo involontario nell’assegnazione di prezzi o upgrade, come viene gestita la sicurezza, e se il sistema può spiegare le proprie decisioni quando richiesto, valgono esattamente allo stesso modo per un hotel di dodici camere quanto per una catena internazionale, perché il GDPR non fa sconti in base alle dimensioni della struttura.

Un promemoria pratico

Per chi gestisce una struttura indipendente e non ha un ufficio legale o un reparto IT a cui delegare queste verifiche, il consiglio più concreto che porto a casa da questo articolo è di trasformarlo in una lista minima da tenere accanto a ogni proposta commerciale che arriva sulla scrivania: chiedere sempre di vedere lo strumento funzionare sui propri dati, non su quelli campione del fornitore, mettere per iscritto prima di firmare cosa deve succedere entro quale data perché valga la pena continuare, e chiedere esplicitamente, senza timore di sembrare sospettosi, dove vanno i dati dei propri ospiti e se alimentano l’addestramento di modelli di terzi. Non serve un dirigente bancario in casa per applicare questi tre principi. Serve solo la disciplina di farli precedere alla firma, non seguirli.

FAQ