La situazione
Una startup AI-native del benessere voleva un diario che vivesse dentro WhatsApp. Durante la settimana l'utente manda messaggi e note vocali, il venerdì riceve un report personale. Niente app da installare, dati molto intimi, budget da MVP. I rischi da evitare erano due: perdere qualcosa che una persona aveva affidato al diario, oppure esporlo.
Cosa ho fatto
Ho fatto tutto da solo, dai requisiti al documento di consegna, in cinque settimane. La regola che mi sono dato è semplice: prima si mette al sicuro quello che l'utente ha scritto, poi si fa tutto il resto. Trascrizioni, analisi e report girano dopo, in fasi separate, e ognuna può ripartire da sola se qualcosa va storto.
Sui dati ho cifrato tutto quello che è personale, compreso il numero di telefono, senza perdere la capacità di riconoscere chi torna a scrivere. E ho tenuto l'architettura piccola: un servizio in meno ogni volta che potevo, con un punto preciso nel codice da cui cambiarlo più avanti.
Cosa è cambiato
Il cliente ha ricevuto un prodotto pronto da lanciare e un documento di consegna che dice cosa può rompersi, cosa resta da fare prima del lancio e come si rimette in piedi il sistema. Il debito tecnico noto è scritto lì, accanto all'architettura. Il sistema è fatto perché una nota vocale mandata il martedì arrivi nel report del venerdì anche se nel frattempo una fase si inceppa.
Cosa ho imparato
Il numero di telefono era l'unica identità che il diario conosceva, e insieme uno dei dati da proteggere di più. Tenerlo in chiaro era fuori discussione. Cifrarlo e basta voleva dire decifrare tutti i numeri a ogni messaggio in arrivo per capire chi stava scrivendo. Lì ho visto che proteggere un dato e ritrovarne il proprietario sono due problemi distinti. Ho tenuto due versioni del numero: una cifrata, per quando serve davvero, e una che serve solo a riconoscere chi torna a scrivere. Anche la seconda la tratto come dato personale.
Nel diario le chiavi di cifratura stanno fuori dal database, per scelta. La conseguenza l'ho scritta in chiaro nel documento di consegna: un database ripristinato senza le sue chiavi è illeggibile. Un backup riuscito dà la sensazione di poter rimettere in piedi il prodotto, e qui da solo non rimette in piedi niente. Per questo database e chiavi si recuperano con due procedure diverse, affidate a due custodi diversi, e il documento chiede una prova di ripristino completa prima del lancio. Da allora considero verificato un piano di backup per dati cifrati solo dopo un ripristino che arriva fino ai dati leggibili.
Il prodotto prometteva un report personale ogni venerdì. Scritta come istruzione al modello, «riassumi la settimana» lasciava aperte le domande che prima o poi un utente fa: quale settimana, in quale fuso orario, con quali messaggi, se una nota vocale trascritta in ritardo ci rientra, e se «pronto» vuol dire «consegnato». Nessun prompt risponde a queste domande. Qui ogni report sa da quali messaggi nasce, che periodo copre e in che stato si trova. Da allora definisco un report periodico prima di scriverne il prompt, così anche mesi dopo si può spiegare cosa ha riassunto un report preciso.