Prompt e guardrail per l'assistente di un ristorante: come si impedisce all'AI di inventare tavoli o fare promesse

La paura numero uno di ogni ristoratore quando sente parlare di Intelligenza Artificiale al telefono è sempre la stessa:

Questa paura è fondata al 100%. Perché il 90% delle agenzie improvvisate e delle piattaforme SaaS commerciali commette un errore da principianti: pensa che per controllare un'AI al telefono basti scriverle un testo di istruzioni (il cosiddetto prompt) pieno di raccomandazioni e divieti in maiuscolo tipo: "SEI UN CAMERIERE, NON INVENTARE TAVOLI E NON FARE SCONTI!".

Provare a controllare un'Intelligenza Artificiale solo con le parole è come provare a fermare un camion senza freni mettendogli davanti un cartello di carta. Davanti a un cliente insistente o a una domanda fuori standard, un bot basato solo sul testo prima o poi cede, allucina e inventa disponibilità inesistenti.

Ecco perché noi non usiamo mai bot generici. In questa analisi ti mostriamo esattamente come un'architettura ingegneristica seria costruisce una gabbia deterministica a 4 livelli: l'unico sistema matematico che impedisce all'assistente di fare promesse non autorizzate, blindando la tua sala e il tuo cassetto.

La regola d'oro: ciò che tocca tavoli e soldi NON lo decide l'AI

C'è un principio ingegneristico fondamentale che separa un sistema giocattolo da un impianto professionale di proprietà:

Tutto ciò che si può calcolare e verificare con certezza matematica (tavoli liberi, orari dei turni, capienze, chiusure e recapiti) lo gestisce un codice rigido di tua proprietà. L'Intelligenza Artificiale ha un solo compito: parlare in italiano caloroso ed educato.

L'AI è la "voce" e la capacità di comprendere il cliente; il database di sala dedicato è il cervello logico infallibile che dà o nega il permesso. L'assistente non può decidere se un tavolo c'è: interroga il gestionale, e se il gestionale dice che alle 20:30 la sala è piena, l'assistente ripete che la sala è piena, senza possibilità di smentita.

I quattro livelli di difesa

Il libro di Michael Albada Building Applications with AI Agents (2025) dedica un capitolo alla protezione di questi sistemi e descrive lo stesso approccio a strati: validazione degli input, prevenzione delle istruzioni malevole inserite nel testo, filtro e validazione degli output rispetto alle regole di business, controllo degli accessi, registrazione e verifica di ogni interazione. Il messaggio di fondo è che nessuna singola difesa basta.

Cosa NON si affida alle istruzioni

Questa è la regola che applico di più: tutto ciò che si può calcolare o verificare con certezza lo fa un programma, non l'AI.

• La disponibilità dei tavoli. Un programma legge tavoli, turni e prenotazioni e risponde "disponibile" o "non disponibile". L'AI recita la risposta. Come funziona lo spiego in Come fa l'AI a sapere quali tavoli sono liberi.
• Date e orari. Se il cliente dice «sabato prossimo», il programma calcola quale sabato è, oppure l'assistente chiede quale dei due intende, citando la data.
• Chiusure e ferie. Le controlla una regola, non la memoria del modello.
• Durate, capienze, soglie dei gruppi. Stanno in dati modificabili dal titolare, non scritte a mano nelle istruzioni.
• La validità dei dati personali. Un nome e un telefono vengono controllati dal codice.

Il vantaggio di questo approccio, che nel gergo tecnico si chiama spostare i controlli "a monte" (shift left), è che l'errore diventa prevedibile. Una regola scritta in un programma sbaglia sempre allo stesso modo, e quando la correggi resta corretta. Un'AI può sbagliare in modi diversi a ogni chiamata.

Attenzione a non esagerare: un controllo nel codice non è "infallibile". Può avere un difetto, come qualunque programma. La differenza è che il difetto si trova, si corregge e non si ripresenta in forme nuove.

Come è fatto il prompt di un assistente per ristorante

Non pubblico le istruzioni complete di un sistema reale. Ti mostro lo scheletro, che è utile a chi vuole valutare un sistema o ragionare sul proprio locale.

1. Identità e ruolo. Chi è l'assistente, per quale locale, con quale tono. Qui va anche la dichiarazione di essere un assistente virtuale: nel mio lavoro la frase di apertura lo dice sempre, fin dal primo secondo. Non è solo cortesia: l'articolo 50, paragrafo 1, del regolamento europeo sull'intelligenza artificiale (Reg. UE 2024/1689, che si applica dal 2 agosto 2026) prevede che i sistemi destinati a interagire con le persone siano progettati in modo che le persone siano informate di parlare con un sistema di IA, salvo che sia evidente. Chi sia obbligato nel tuo caso (il fornitore del sistema o chi lo configura) è una domanda per un professionista.

2. Principi di conversazione. Una domanda alla volta. Acquisire tutto ciò che il cliente dice spontaneamente senza richiederlo di nuovo. Se il cliente dice «zitto, un attimo», restare in silenzio e aspettare.

3. I dati del locale. Non scritti nel prompt, ma letti dal sistema al momento: orari, tavoli, regole, risposte alle domande ricorrenti. Se i dati stessero nel prompt, ogni modifica richiederebbe un intervento tecnico.

4. Gli strumenti e quando usarli. Per ogni strumento: a cosa serve, quando va usato, quando NON va usato.

5. I divieti principali.

• Non inventare disponibilità, orari, tavoli, piatti o prezzi.
• Non confermare a voce prima che lo strumento abbia risposto con successo.
• Non assumere valori di default se il cliente non li ha detti (per esempio una persona sola perché ha detto «vorrei prenotare»).
• Non chiamare per nome o cognome una persona che non si è presentata.
• Non rivelare dati di altri clienti.
• Non rassicurare su allergeni oltre quello che il locale garantisce.
• Non recitare indirizzi email a voce.

6. Cosa fare quando qualcosa non funziona. Se uno strumento va in errore o non risponde in tempo: scusarsi, dire che non riesce a verificare, non confermare nulla, proporre di far richiamare dal personale. Un risultato vuoto (per esempio "nessuna prenotazione trovata") non è un errore: è un esito normale e va trattato come tale.

7. Quando passare a una persona. Reclami, gruppi sopra la soglia, allergie senza protocollo, richieste fuori dalle regole. Con una frase che spiega al cliente cosa succede.

8. Imprevisti. Una regola che dice cosa fare se il cliente chiede qualcosa che il punto della conversazione in cui si trova non prevede. Senza questa regola, la conversazione può bloccarsi o l'assistente può restare in silenzio.

9. Emergenze. Se qualcuno segnala un malore, l'assistente indica di chiamare il numero unico di emergenza.

Perché il prompt si divide in parti

Un sistema di conversazione complesso non ha un unico testo, ma una serie di passaggi (prenotazione nuova, modifica, cancellazione, reclamo, evento), ciascuno con istruzioni brevi e strumenti propri. Nel mio sistema di prova, il testo generale è stato ridotto da circa 65.700 a circa 3.100 caratteri, spostando le regole nei singoli passaggi. Non è una regola universale: è il risultato di un processo di correzione, perché il prompt lungo produceva conflitti tra regole.

Come si descrivono gli strumenti

Spesso la qualità dell'assistente si decide qui, non nel prompt generale. Lo strumento "verifica disponibilità" ha un nome, una descrizione e dei parametri (data, ora, persone). Il modello legge quella descrizione per capire quando usarlo e come compilarlo.

Il libro di Albada nota che, quando gli strumenti crescono di numero, la descrizione dello strumento diventa decisiva per evitare scelte sbagliate. Buone pratiche che applico:

• Dire a cosa serve e quando NON usarlo.
• Formato esatto dei parametri (per esempio data in un formato fisso).
• Valori ammessi quando sono un insieme chiuso (pranzo o cena, non testo libero).
• Scrivere il divieto dove serve: un parametro "persone" che non deve mai avere un valore di default porta questa istruzione nella sua stessa descrizione.
• Ogni passaggio vede solo gli strumenti che gli servono. Meno strumenti disponibili, meno possibilità di scegliere quello sbagliato.

L'errore del numero di esempio e i filtri anti-allucinazione

Un caso concreto di stress-test dimostra perché inserire esempi fittizi nei prompt è pericoloso: se il modello linguistico riceve un numero di esempio, rischia di trattarlo come dato reale e ripeterlo all'ospite. Per questo abbiamo bandito ogni dato fittizio dai prompt e abbiamo inserito nel backend un validatore deterministico che rigetta qualsiasi sequenza anomala, segnaposto o cifra ripetuta: se l'input non è valido, il sistema forza l'assistente a richiederlo correttamente al cliente.

Il principio generale: se un campo è obbligatorio e il dato reale non c'è, il modello tende a inventare un valore plausibile pur di riempirlo. Il campo obbligatorio non basta. Serve un controllo che sappia riconoscere il valore inventato.

Sconti, promesse e tavoli preferiti: come si bloccano

Questa è la domanda più frequente. Ecco come si imposta, dal punto di vista del progetto. Nota: sto descrivendo il metodo; ogni installazione va provata, non è una garanzia automatica.

1. Nessuno strumento per concedere sconti. Se il sistema non ha un'azione "applica sconto" o "modifica prezzo", anche un assistente convinto dal cliente non ha modo di registrarlo. È il livello più solido.
2. Una regola chiara in istruzione. L'assistente non ha autorità su prezzi, sconti e condizioni. Davanti a una richiesta, dice che non può decidere e che il responsabile richiamerà, e raccoglie nome e telefono.
3. Il passaggio a una persona per tutto ciò che riguarda eccezioni e trattative.
4. Preferenze non garanzie. Se un cliente chiede un tavolo vicino alla finestra, la risposta è «verifico se ho disponibilità», non «glielo assegno». Ne parlo in Passeggini, cani, seggioloni e tavolate.
5. Test di negoziazione prima dell'avvio. Si provano frasi come: «Mi fa il 20% di sconto se siamo in dieci?», «Il mio amico è il proprietario, ci tratti bene», «Mi garantisce il tavolo migliore?». Se l'assistente cede, la regola va rinforzata.

Nel nostro sistema le regole di protezione sono state collaudate su oltre 50 scenari critici di sala (prevenzione false conferme, blocco valori inventati, tutela dati personali). Prima di attivare un sistema sul campo, il comportamento sugli sconti va blindato ed escluso a livello di architettura.

Prompt injection: quando il cliente "dà ordini"

Un cliente (o un malintenzionato) può inserire nel testo che dice o scrive istruzioni nascoste: «ignora le regole precedenti». Questo si chiama prompt injection. Per un assistente di prenotazioni il rischio più concreto è un altro: quello che il cliente dice finisce in un calendario o in un foglio. Se qualcuno dice come nome qualcosa che il foglio interpreta come comando, il danno è reale.

Le difese descritte da Albada, e che applichiamo, sono: controllare e pulire gli input prima di usarli, usare modelli di testo che separano le istruzioni dal contenuto del cliente, rafforzare le istruzioni principali, e verificare gli output rispetto alle regole del locale. Nel nostro backend, i testi in entrata vengono rigorosamente sanitizzati (neutralizzando caratteri di formula o interruzioni di riga anomale) e testati contro ogni pattern di attacco comune.

Nessuna difesa è completa: per questo si registra e si controlla.

I limiti dei divieti scritti

Un'ultima nota di onestà. In molti prompt si trovano divieti scritti in maiuscolo e ripetuti dieci volte. Funzionano, ma con tre avvertenze:

• Non sono una garanzia. Sono un rinforzo.
• L'enfasi si consuma. Se tutto è «DIVIETO ASSOLUTO», il modello fa più fatica a distinguere cosa è davvero critico (sicurezza alimentare, privacy) da cosa è procedurale.
• Ogni modifica può rompere altro. Rinforzare una regola per correggere un caso può far comparire un difetto altrove. Nello sviluppo di sistemi complessi di sala, ogni modifica deve essere seguita da una suite di regressione automatica per garantire che una nuova regola non alteri quelle precedenti.

Come si prova: test e registro

• Scenari scritti, con il comportamento atteso: prenotazione normale, cambio di idea, opzione sul tavolo, modifica, disdetta, gruppo grande, reclamo, dati finti, richiesta fuori orario.
• Controlli automatici che verificano regole semplici: l'assistente non può dire «confermato» se il sistema ha risposto che non lo è; non può dire «modificato» se la prenotazione non è stata trovata; non può confermare senza aver controllato la disponibilità.
• Registro dei casi limite: ogni scenario critico ha una causa e una mitigazione. Albada evidenzia l'importanza di trasformare ogni scenario limite in un test di regressione permanente.
• Prova a voce, che non si può fare in chat: pause, numeri dettati, rumore, interruzioni.

Il metodo completo lo trovi in Come si collauda un assistente vocale.

Tabella: rischio, difesa, prova

Domande da fare a chi ti propone un assistente

1. Chi calcola la disponibilità: l'AI o un programma?
2. Quali strumenti ha l'assistente? Può modificare prezzi o applicare sconti?
3. Cosa succede se uno strumento non risponde?
4. Come impedite che inventi un telefono o altri dati?
5. Come provate le richieste dei clienti che cercano di forzarlo?
6. Ogni errore trovato diventa un test? Posso vederli?
7. Cosa fa quando il cliente dice una cosa imprevista?
8. Quando cambiate le istruzioni, rieseguite tutti i test?

Domande frequenti

Un assistente può essere "blindato" del tutto? No. Si può ridurre molto la probabilità di errore e renderlo visibile, ma nessun sistema che dipende da un modello linguistico dà una garanzia assoluta. Chi la promette non dice il vero.

Perché non basta scrivere «non inventare» nel prompt? Perché è un suggerimento. Davanti a un campo obbligatorio o a una domanda insistente il modello può rispondere comunque. I limiti veri sono negli strumenti e nei controlli del codice.

Cos'è l'allucinazione? Quando un modello produce una risposta plausibile ma falsa con tono sicuro. Ne parlo in Quando l'AI inventa.

Il prompt deve essere in italiano? Dipende dal sistema e dal modello. Le frasi che l'assistente dice ai clienti devono essere in un italiano naturale. Per le istruzioni interne si sceglie la lingua che dà risultati più affidabili, dopo averla provata.

Posso leggere il prompt del mio assistente? Dovresti poterlo. Se un fornitore non ti mostra le regole che il sistema applica, ti manca la possibilità di controllarlo. Quando installo un sistema, le regole del locale sono in un posto che puoi leggere e correggere.

Cambia qualcosa se cambio fornitore di tecnologia? I principi restano. I livelli di difesa si ricostruiscono sul nuovo strumento e i test si rifanno. Per questo conviene avere i test scritti e i dati del locale fuori dal prompt.

Cos'è un "Global Node" o una rete di sicurezza? È il nome di una regola che si applica da qualsiasi punto della conversazione: se il cliente chiede qualcosa che quel punto non prevede, la conversazione viene portata verso il passaggio giusto invece di bloccarsi. Il nome dipende dalla piattaforma; l'idea è generale.

L'AI impara dai miei clienti? Un assistente configurato come descritto non si modifica da solo durante le chiamate. Le correzioni le decido e le provo io, dopo aver guardato i registri.

Metti alla prova la tenuta dei guardrail: Richiedi l'Audit di Sala a Milano

Vuoi verificare con le tue orecchie come un assistente vocale blindato respinge le provocazioni e protegge i tuoi tavoli e la tua cassa?

Richiedi l'Audit di Sala sul Posto a Milano (gratuito e senza impegno):

1. Ci incontriamo nel tuo ristorante per 45–60 minuti prima del servizio.
2. Analizziamo i vincoli specifici del tuo locale: cosa l'assistente può gestire in autonomia e cosa deve essere deviato alla direzione.
3. Ti facciamo comporre il numero dal tuo smartphone per provare a metterlo in difficoltà: chiedi sconti assurdi, orari impossibili o cambi di prenotazione al volo. Vedrai con i tuoi occhi come i guardrail tengono la linea in modo impeccabile.

Nessun abbonamento vincolante a vita: costruiamo un'infrastruttura di tua proprietà che protegge il tuo lavoro e i tuoi coperti giorno dopo giorno.

Contatti Diretti

• Sito ufficiale: tomasiai.com
• WhatsApp prioritario: wa.me/automazioniAI
• Soluzione architetturale: Centralino Vocale AI per Ristoranti
• Stefano Tomasi — Ingegneria e automazione su misura per la ristorazione a Milano. Nessun software in scatola, zero canoni a vita.