Sweet Pal
In arrivo su App Store

Il blog di Sweet Pal

Appunti da chi costruisce un'app per il diabete di tipo 1: intelligenza artificiale, vibe coding e tutto quello che c'è in mezzo.

venerdì 23 ottobre 2026

AI e diabete di tipo 1: cosa deve fare e cosa mai

Un assistente AI per il diabete di tipo 1 osserva, mostra e spiega, ma non decide dosi. Le regole di sicurezza che abbiamo scritto in Sweet Pal, e perché.

Un assistente con l'intelligenza artificiale per chi vive con il diabete di tipo 1 può fare molto: capire un pasto raccontato a parole, rimettere in ordine i dati, far vedere come si è mossa la glicemia le altre volte. Una cosa però non deve farla mai: decidere al posto della persona e del suo team diabetologico. In Sweet Pal questa non è una promessa scritta in fondo a una pagina. È un insieme di regole costruite dentro il prodotto, alcune nel modello e alcune, le più importanti, fuori.

Partiamo da un fatto scomodo. Un modello linguistico è bravissimo a scrivere e a capire il tono di una frase, ma è anche imprevedibile in un modo che qui non ci possiamo permettere: lo stesso messaggio, in due momenti diversi o con due modelli diversi, può avere due risposte diverse. Per una battuta va bene. Per una glicemia bassa no. Per questo ci siamo dati un principio semplice: una regola di sicurezza si valida sul caso peggiore, non sul motore migliore. Se una protezione funziona solo quando il modello si comporta bene, non è una protezione. Le regole più delicate, quindi, le scriviamo due volte: una nelle istruzioni del modello e una nel codice, dove si comportano sempre allo stesso modo.

I valori a rischio scavalcano tutto

Nelle istruzioni della chat di Sweet Pal c'è una regola che viene prima di ogni altra. La chiamiamo regola zero: la sicurezza acuta batte tutto. Con un valore in zona di ipoglicemia, con i chetoni o con un forte malessere, la risposta cambia natura: due o tre frasi, scritte con calma, che invitano ad agire secondo il protocollo concordato con il proprio team. Niente offerte, niente spunti, niente grafici. E la regola vale anche se la persona dice di sentirsi bene o che "le capita sempre". Sentirsi bene con un valore basso non smentisce il rischio: si chiama ipoglicemia inavvertita, ed è proprio il caso in cui una risposta rassicurante farebbe danni.

L'abbiamo imparato sul campo. Quando abbiamo separato le decisioni dalla scrittura delle risposte, nell'architettura che abbiamo raccontato in Prima decidere, poi parlare, una frase come "sono a 62, sto bene, mi capita sempre" veniva letta come un racconto, tranquillo, quasi colloquiale. La soluzione è stata una domanda dedicata, una sola, che chiede se nel messaggio c'è un valore a rischio e che, se la risposta è sì, scavalca tutte le altre decisioni. Qui sbagliare per prudenza costa poco; sbagliare dall'altra parte no.

Il modello però non è l'unico a guardare. L'app, sul telefono, legge quello che ha scritto la persona, non la risposta del modello, e decide da sola se il momento è urgente. Cerca parole che non hanno bisogno di numeri, come "ipoglicemia", "chetoni" o "mi sento svenire", e cerca un valore glicemico dichiarato, che confronta con il limite basso del range di quella persona, non con una soglia uguale per tutti. È prudente per costruzione: un numero da solo non basta mai, perché "ho mangiato 60 g" non è una glicemia. Serve il numero con la sua unità, oppure una forma come "sono a 52" o "ho 55". Meglio non accendere l'allarme che accenderlo a sproposito in una conversazione tranquilla: un allarme che suona spesso smette di essere ascoltato.

Quando la regola scatta, la bolla della risposta cambia aspetto: un segno pieno in un rosso spento e una riga, "Adesso conta questo". Abbiamo scelto la serietà, non la paura, perché chi legge in quel momento sta già male e un fondo rosso acceso aggiungerebbe solo un peso. Lo stesso vale quando la glicemia viene inserita a mano dal pulsante rapido: lì la risposta non la scrive il modello ma la compone l'app con i dati che ha già, e se il valore è basso la voce si abbassa. Nessuna analisi, nessuna previsione, nessuna quantità: solo il rimando al protocollo del team, e un po' di compagnia.

Stime da confermare, non decisioni

Tutto il resto della giornata, che per fortuna non è un'emergenza, segue un'altra famiglia di regole. Quando racconti o fotografi un pasto, Sweet Pal stima i carboidrati e te li presenta per quello che sono: un valore da confermare o correggere, non un numero da prendere per buono. Quando racconti un bolo che hai fatto, l'app capisce dose e orario e te li propone da registrare nel diario. Ma una domanda come "quanto bolo devo fare?" non viene trattata come un bolo da registrare, e non riceve una dose come risposta. È la regola che conta di più, scritta senza sfumature nelle istruzioni del modello: non consigliare mai una terapia o una dose. Anche nelle condizioni d'uso lo diciamo in modo esplicito: l'app non formula diagnosi, non prescrive terapie, non modifica lo schema di cura e non è collegata a microinfusori, penne connesse o sistemi automatici. La dose la decidi e la esegui tu, con il tuo team.

Non basta evitare di dare consigli: bisogna evitare anche di sembrare di darli. Il Simulatore fa vedere come potrebbe muoversi la curva con un pasto, un'attività o un bolo, e la prima versione del testo che accompagnava il grafico suonava come un piano, in seconda persona e al futuro. Nessuna frase conteneva una dose, eppure era sbagliato. Oggi quei testi parlano della curva, in terza persona: "la glicemia parte da", "dopo circa mezz'ora il pasto spinge la curva verso l'alto", "l'insulina del bolo frena la salita". I tempi si dicono come tempo trascorso dall'inizio dell'illustrazione, non come "tra mezz'ora", che suonerebbe come un appuntamento.

L'ultima regola riguarda l'onestà statistica. Un assistente che vede i tuoi dati ogni giorno è tentato di trovare schemi ovunque, e "ti succede sempre" è una frase facile da scrivere e quasi sempre falsa. Nelle istruzioni di Sweet Pal la scala è precisa: un singolo episodio è un aneddoto, due o tre volte sono "le ultime volte", e le tendenze vere arrivano solo dal motore statistico, che distingue un indizio ancora precoce da un legame consolidato. Quando l'app mostra un legame, mostra anche su quanti episodi si regge.

Schermata Note di Sweet Pal: in alto un'osservazione sul tempo in range dopo l'attività, con la scritta «Un'osservazione, non un consiglio» e «Osservato su 20 episodi»; sotto, l'elenco «In osservazione» con sette indizi non ancora confermati, ognuno con i suoi numeri.
La schermata Note. Ogni osservazione dice su quanti episodi si regge («Osservato su 20 episodi») e si presenta come «un'osservazione, non un consiglio»; sotto, gli indizi ancora da confermare, ognuno con i suoi numeri.

Questo serve a chi usa l'app, che può dare il giusto peso a ciò che vede, e serve al suo diabetologo, che davanti a un'osservazione sa subito se è un'impressione o qualcosa su cui ragionare. Messe in fila, le regole disegnano un confine chiaro: da una parte quello che un assistente AI per il diabete di tipo 1 fa bene, cioè capire il linguaggio di tutti i giorni, togliere fatica al diario, ricordare le volte passate, rendere visibile ciò che nei numeri resterebbe nascosto; dall'altra quello che non gli spetta, cioè decidere quanta insulina, cambiare una terapia, rassicurare quando i numeri dicono il contrario. Non è un limite che subiamo. È il motivo per cui ci si può fidare di quello che l'app fa.

In sintesi:

  • Le regole di sicurezza di Sweet Pal si validano sul caso peggiore: le più delicate vivono sia nelle istruzioni del modello sia nel codice dell'app.
  • Un valore a rischio, i chetoni o un forte malessere scavalcano tutto, anche quando la persona dice di stare bene.
  • I carboidrati sono stime da confermare; i boli raccontati si registrano, ma l'app non suggerisce mai una dose.
  • I testi delle simulazioni descrivono la curva in terza persona, senza tono da istruzione.
  • Ogni legame mostrato dice su quanti episodi si regge: un episodio è un aneddoto, non uno schema.

Pubblicato da Simone Tolomelli alle · Etichette: T1D · 6 min di lettura