Come vengono separati i dati degli ospiti
Un ospite chiede la password Wi-Fi. Un altro chiede la stessa password senza essere mai entrato in quell’appartamento. A distinguerli non è una regola nel prompt.
La prima decisione architetturale del progetto è stata presa nella seconda settimana e ancora oggi sostiene tutto il sistema: esistono due aree di conoscenza, non una sola. Le informazioni pubbliche su Saas-Fee — ristoranti, impianti di risalita, meteo, eventi, farmacia e indicazioni per arrivare — si trovano in un corpus consultabile da chiunque. Tutto ciò che appartiene a uno specifico appartamento o hotel si trova in un secondo corpus, che non viene letto senza un accesso ospite valido.
La distinzione sembra ovvia finché non si costruisce l’alternativa. Un unico corpus con una regola nel prompt che dice «fornisci i dati della struttura solo agli ospiti autorizzati» trasferisce il controllo degli accessi a un modello linguistico. Questo non è controllo degli accessi: è una richiesta.
Che cosa rende un ospite un ospite
L’accesso avviene in due modi: tramite un link personale rilasciato dalla struttura oppure tramite una sessione verificata con un codice monouso inviato via SMS. Entrambi producono token e qui i token seguono una regola senza eccezioni: viene memorizzato soltanto l’hash SHA-256, mai il valore originale. Leggere il database non consente quindi di accedere.
- Codice SMS monouso: valido per 10 minuti
- Sessione ospite: 90 giorni
- Accesso dell’ospite a una struttura: fino a 12 mesi dopo il soggiorno
- Conversazioni e prenotazioni: fino a 24 mesi
Questi periodi non sono indicati soltanto qui. Sono registrati nel registro interno dei trattamenti GDPR, insieme a ogni servizio che vede i dati e allo scopo per cui li vede. Un ospite può chiedere in qualsiasi momento una copia o la cancellazione dei propri dati; esistono una pagina e un indirizzo dedicati a questo scopo.
Ciò che arriva dall’esterno non fa fede
Twilio, Meta e apaleo chiamano i nostri endpoint. Ogni chiamata viene verificata tramite la propria firma e registrata — ma la seconda regola è ancora più importante: il contenuto di un webhook non viene usato come fonte dei dati. Quando apaleo segnala che una prenotazione è cambiata, rileggiamo la prenotazione dall’API usando il suo identificativo. Falsificare il messaggio non significa quindi falsificare una prenotazione.
Il percorso di emergenza
Quando Lena riconosce un’emergenza medica, la risposta proviene da un testo fisso: prima il numero dell’ambulanza, poi che cosa comunicare alla centrale, quindi la Rega per i luoghi non raggiungibili da un veicolo. Nessun modello scrive questa risposta e nessuna delle dieci regole aggiuntive che riscrivono le altre risposte la modifica. Un modello che sta passando una brutta giornata non deve trovarsi tra un ospite e un numero di emergenza.
Ciò che è scritto qui è stato misurato. Ciò che manca viene dichiarato.
E qualcosa manca. Non è attivo alcun sistema di tracciamento degli errori e nessun monitoraggio esterno verifica il percorso di emergenza dall’esterno. Oggi scopriamo un guasto quando ce lo segnala un ospite. Questi sono i prossimi due passi, in quest’ordine: rendere visibile un guasto è la condizione necessaria per poter verificare tutto ciò che viene dopo.