Jak chronić dane użytkowników w aplikacji zbudowanej z AI (bez zespołu ds. bezpieczeństwa)

Pewna coachka, którą znamy, zbudowała przez weekend aplikację do śledzenia klientów za pomocą kreatora aplikacji z AI. Notatki z sesji, cele, sprawdzanie postępów — wszystko, co kiedyś trzymała w notesie, teraz przeszukiwalne i uporządkowane. Działało tak dobrze, że dwie zaprzyjaźnione coachki poprosiły, by też mogły z tego korzystać.

Wtedy do niej dotarło: nie trzymała już własnych notatek. Trzymała cudze notatki o ich klientach — szczegóły zdrowotne, osobiste zmagania, nazwiska. Gdyby te dane wyciekły, nie byłby to jej wstyd. Byłby ich.

Nie potrzebujesz zespołu ds. bezpieczeństwa, by ogarnąć to odpowiedzialnie. Potrzebujesz trzech nawyków i gotowości, by zadać kreatorowi AI kilka bezpośrednich pytań. Ten przewodnik pokazuje, jak chronić dane użytkowników w aplikacji zbudowanej z AI na poziomie, który naprawdę ma znaczenie dla małego produktu.

Zacznij od zauważenia, jakie dane użytkowników faktycznie trzymasz

Większość twórców to lekceważy. „Mam tylko formularz rejestracji” zwykle oznacza, że masz:

Adresy e-mail — wystarczająco, by kogoś zasypać spamem albo wyłudzić dane.
Nazwiska powiązane z zachowaniem — co kupili, co napisali, kiedy się logują.
Cokolwiek Twoi użytkownicy wpisują w pola tekstowe — a ludzie wpiszą w pole notatek wszystko: numery telefonów, szczegóły medyczne, pensje, narzekania na szefa.

Poświęć dziesięć minut i zapisz każdą informację o osobie, którą Twoja aplikacja przechowuje. Nie pola bazy danych — ludzkie znaczenie. „E-mail”, „jakie suplementy biorą”, „notatki, które ich trener o nich napisał”. Ta lista to Twoja powierzchnia odpowiedzialności. Cała reszta tego wpisu dotyczy tego, jak ją zmniejszyć i zabezpieczyć.

Nawyk 1: Zbieraj mniej

Najtańsze do ochrony są dane, których nigdy nie zebrałeś. Zanim cokolwiek zabezpieczysz, skróć listę.

Przejdź przez listę, którą właśnie zrobiłeś, i zapytaj o każdą pozycję: czy tego używam?. Aplikacja coachki prosiła przy rejestracji o datę urodzenia, bo szablon rejestracji w kreatorze AI ją zawierał. Nigdy nigdzie jej nie użyła. Jedno zdanie do kreatora AI — „usuń datę urodzenia z rejestracji i skasuj kolumnę” — i cała kategoria wrażliwych danych zniknęła.

Rzeczy, które aplikacje często zbierają i nigdy nie używają: daty urodzenia, numery telefonów, adresy fizyczne, płeć, „skąd się o nas dowiedziałeś”. Jeśli nie używasz tego w tym miesiącu, zawsze możesz poprosić o to później. Nie możesz cofnąć wycieku.

Nawyk 2: Kontroluj, kto co może zobaczyć

Są dwie wersje tego pytania i potrzebujesz obu.

Wewnątrz aplikacji: czy jeden użytkownik może zobaczyć dane innego użytkownika? Jeśli Twoja aplikacja ma klientów i coachów, czy klient A może kiedykolwiek zobaczyć notatki klienta B? Napisaliśmy cały przewodnik o uprawnieniach użytkowników w aplikacji zbudowanej z AI, ale w skrócie: opisz zasadę kreatorowi AI prostym językiem („coach widzi tylko własnych klientów; klienci widzą tylko siebie”), a potem przetestuj to samodzielnie na dwóch kontach. Zaloguj się jako jeden użytkownik, spróbuj dotrzeć do danych innego użytkownika, klikając wokół. Pięć minut, dwa konta testowe. Ten jeden test łapie najczęstszy wyciek w małych aplikacjach.

Poza aplikacją: kto może zobaczyć samą bazę danych? To Ty, Twoja platforma kreatora AI i każdy, z kim podzieliłeś się loginami. Co prowadzi nas do pytań.

Nawyk 3: Zadaj kreatorowi tych pięć pytań

Nie musisz głęboko rozumieć odpowiedzi. Musisz zapytać, a odpowiedzi powinny być pewnymi „tak”. Wklej je do swojego kreatora aplikacji z AI po kolei:

„Czy hasła użytkowników są przechowywane jako hash, czy każdy może je odczytać?” Jedyna akceptowalna odpowiedź zawiera słowo „hash”. Jeśli Twoja aplikacja przechowuje hasła, które każdy może odczytać, napraw to dzisiaj — to zwykle poprawka na jeden prompt, a większość nowoczesnych kreatorów robi to poprawnie domyślnie.
„Czy połączenie z aplikacją jest szyfrowane (HTTPS)?” Poszukaj kłódki we własnej przeglądarce. Jeśli adres Twojej aplikacji zaczyna się od https://, masz to z głowy.
„Gdyby ktoś zdobył plik bazy danych, czy mógłby odczytać wrażliwe pola?” Tu chodzi o szyfrowanie spoczynkowe (at rest). Większość platform hostingowych obsługuje to automatycznie — i tak zapytaj i zapisz odpowiedź.
„Które usługi zewnętrzne otrzymują dane użytkowników?” Narzędzia mailowe, analityka, procesory płatności. Nie usuwasz ich — uzupełniasz swoją listę, bo każda usługa trzymająca dane Twoich użytkowników jest częścią Twojej powierzchni odpowiedzialności.
„Czy jest kopia zapasowa i kto ma do niej dostęp?” Kopie zapasowe to kopie Twoich danych, a kopie też wymagają ochrony. (Jeśli w ogóle nie skonfigurowałeś kopii zapasowych, zacznij tutaj).

Zapisz odpowiedzi w dokumencie. Ten dokument to początek Twojej postawy bezpieczeństwa i będziesz zadowolony, że istnieje, gdy klient — albo prawnik klienta — zapyta po raz pierwszy.

Kiedy ktoś powie „usuń moje dane”

Ktoś w końcu to zrobi, a prawo w większości miejsc (RODO w Europie, podobne przepisy gdzie indziej) mówi, że musisz to faktycznie zrobić. Zdecyduj teraz, jaka jest Twoja odpowiedź:

Czy potrafisz usunąć jednego użytkownika i wszystko z nim powiązane? Poproś kreator AI, by to dodał — „zbuduj akcję administracyjną, która usuwa użytkownika i wszystkie jego dane” — zanim będziesz tego potrzebował pod presją terminu.
Czy usunięcie ich w aplikacji usuwa ich też z Twojego narzędzia mailowego i analityki? Sprawdź swoją listę z pytania 4.
Kopie zapasowe wciąż będą ich zawierać przez jakiś czas. To normalne i zwykle w porządku — po prostu wiedz o tym, byś mógł powiedzieć to uczciwie.

Odpowiedź na żądanie usunięcia w jeden dzień, bo się przygotowałeś, wygląda profesjonalnie. Szamotanie się przez dwa tygodnie wygląda dokładnie na to, czym jest.

Napisz stronę prywatności prostym językiem

Pomiń na razie wygenerowany prawniczy bełkot na 4000 słów. Napisz pięć uczciwych zdań: co zbierasz, dlaczego, kto jeszcze tego dotyka (Twoje narzędzie mailowe, Twój procesor płatności), jak długo to przechowujesz i jak poprosić o usunięcie. Umieść to pod /privacy i podlinkuj ze swojej strony rejestracji.

To nie jest porada prawna, a jeśli obsługujesz naprawdę wrażliwe dane — zdrowie, dzieci, finanse — wydaj pieniądze na godzinę z prawnikiem. Ale jasna, uczciwa strona bije imponująco wyglądającą, której nikt nie potrafi przeczytać, a jej pisanie zmusza Cię, byś faktycznie poznał własne odpowiedzi.

Poprzeczka jest niżej, niż się boisz, i wyżej niż zero

Nie bronisz się przed państwami narodowymi. Bronisz się przed nudnymi, powszechnymi błędami: pozostawionym polem danych, którego nikt nie potrzebował, zasadą uprawnień, której nikt nie przetestował, tabelą haseł, którą ktoś zapomniał zhashować. Ochrona danych użytkowników na tym poziomie to nie umiejętność specjalistyczna — każdy z tych błędów da się naprawić promptem w prostym języku i pięciominutowym testem.

Coachka z początku zrobiła to wszystko w jedno popołudnie: usunęła dwa nieużywane pola, przeprowadziła test na dwóch kontach (i złapała jeden wyciek — klienci widzieli nawzajem swoje imiona na liście rozwijanej), zadała pięć pytań, napisała stronę prywatności. Jej aplikacja nie wyglądała potem ani trochę inaczej. Ale kiedy koleżanka zapytała „czy to coś jest bezpieczne dla notatek o moich klientach?”, miała prawdziwą odpowiedź.

Poświęć to popołudnie. Twoi użytkownicy dali Ci swoje dane na zaufanie — tak właśnie wygląda jego dotrzymanie.