Sytuacja
Startup AI-native z obszaru dobrostanu chciał dziennik działający wewnątrz WhatsAppa. W tygodniu użytkownik wysyła wiadomości i notatki głosowe. W piątek dostaje osobisty raport. Bez aplikacji do instalowania, z bardzo intymnymi danymi i budżetem na MVP. Trzeba było uniknąć dwóch ryzyk: utraty czegoś, co człowiek powierzył dziennikowi, albo ujawnienia tego.
Co zrobiłem
Zrobiłem wszystko sam, od wymagań po dokument przekazania, w pięć tygodni. Przyjąłem prostą zasadę: najpierw zabezpieczamy to, co użytkownik napisał, potem robimy całą resztę. Transkrypcja, analiza i raporty uruchamiają się później, w osobnych etapach. Każdy może ruszyć ponownie niezależnie od pozostałych, jeśli coś pójdzie nie tak.
Zaszyfrowałem wszystkie dane osobowe, łącznie z numerem telefonu. Zachowałem przy tym możliwość rozpoznania osoby, która pisze ponownie. Utrzymałem też małą architekturę: o jedną usługę mniej, kiedy tylko się dało, z konkretnym miejscem w kodzie, w którym można ją później wymienić.
Co się zmieniło
Klient dostał produkt gotowy do uruchomienia i dokument przekazania. Jest w nim opis tego, co może się zepsuć, co trzeba jeszcze zrobić przed startem i jak przywrócić system. Znany dług techniczny jest zapisany obok architektury. System powstał tak, żeby notatka głosowa wysłana we wtorek trafiła do piątkowego raportu, nawet jeśli po drodze jeden etap się zatnie.
Czego się nauczyłem
Numer telefonu był jedyną tożsamością, którą znał dziennik, i jednocześnie jedną z danych wymagających największej ochrony. Przechowywanie go jawnym tekstem nie wchodziło w grę. Samo szyfrowanie oznaczałoby odszyfrowywanie wszystkich numerów przy każdej nowej wiadomości, żeby ustalić, kto pisze. Wtedy zobaczyłem, że ochrona danych i odnalezienie ich właściciela to dwa osobne problemy. Zachowałem dwie wersje numeru: zaszyfrowaną, na wypadek gdy naprawdę będzie potrzebny, i taką, która służy tylko do rozpoznania osoby piszącej ponownie. Tę drugą też traktuję jako dane osobowe.
Klucze szyfrujące dziennika celowo są poza bazą danych. Konsekwencję zapisałem wprost w dokumencie przekazania: baza odtworzona bez swoich kluczy jest nieczytelna. Udana kopia zapasowa daje poczucie, że produkt da się przywrócić. Tutaj sama nie przywraca niczego. Dlatego bazę i klucze odzyskuje się dwiema różnymi procedurami, powierzonymi dwóm różnym opiekunom. Dokument wymaga pełnej próby odtworzenia przed startem. Od tamtej pory uznaję plan kopii zapasowych dla zaszyfrowanych danych za sprawdzony dopiero po odtworzeniu, które kończy się czytelnymi danymi.
Produkt obiecywał osobisty raport w każdy piątek. Instrukcja dla modelu „podsumuj tydzień” zostawiała otwarte pytania, które prędzej czy później zada użytkownik: który tydzień, w jakiej strefie czasowej, z jakimi wiadomościami, czy notatka głosowa przepisana z opóźnieniem jeszcze do niego należy i czy „gotowy” znaczy „dostarczony”. Żaden prompt na to nie odpowie. Tutaj każdy raport wie, z których wiadomości powstał, jaki okres obejmuje i w jakim jest stanie. Od tamtej pory definiuję raport okresowy, zanim napiszę jego prompt. Dzięki temu także po miesiącach da się wyjaśnić, co podsumował konkretny raport.