Bezpieczeństwo i dane: na co uważać, gdy budujesz aplikację biznesową z AI

Kiedy mówię founderom, że dziś mogą złożyć działającą aplikację biznesową w jeden wieczór, w odpowiedzi często słyszę cichą panikę. Nie dlatego, że to trudne — wręcz przeciwnie, stało się aż za łatwe. Panika jest w czym innym: „Przecież teraz to ja odpowiadam za dane. I za bezpieczeństwo. A nie jestem inżynierem”.

Buduję produkty z AI sam — w Dronehub, w Oswin AI, we własnych produktach edukacyjnych. Dronehub to deep-tech, gdzie do danych podchodzi się serio, bez prawa do „jakoś to będzie”. I właśnie dlatego chcę napisać ten tekst spokojnie, bez straszenia. Bezpieczeństwo danych w aplikacji z AI to nie magia dla wybranych. To zestaw dorosłych nawyków, które może przyswoić nie-inżynier. Nie wszystkie naraz, ale po kolei — jak najbardziej.

Przejdźmy przez nie po kolei. Nie jak przez traktat prawny, tylko jak przez to, na co sam patrzę, kiedy decyduję, co tej aplikacji można powierzyć.

Pierwszy nawyk: dawać modelowi tylko niezbędne minimum

Najważniejszą decyzję podejmujesz jeszcze przed jakimkolwiek kodem — kiedy rozstrzygasz, jakie dane w ogóle trafią do modelu.

W RODO jest zasada, którą warto wyciągnąć poza prawnicze ramy i zrobić z niej regułę inżynierską. Nazywa się minimalizacją danych: zbierać i przetwarzać należy tylko to, co adekwatne, stosowne i ograniczone do tego, co naprawdę niezbędne do konkretnego celu. Brzmi jak formalność, a w rzeczywistości to najlepsza ochrona, jaka istnieje. Danych, których nie zebrałeś i nie wysłałeś, nie da się stracić.

Przełóż to na swoją aplikację z AI. Model ma podsumować skargę klienta? Daj mu treść skargi — ale nie cały profil klienta z adresem, numerem karty i historią zakupów. Trzeba sklasyfikować zgłoszenie? Daj samo zgłoszenie, a nie całą bazę dookoła niego. Za każdym razem, gdy zamierzasz coś wysłać do modelu, zadaj jedno pytanie: czy jest mu to potrzebne do tego konkretnego zadania? Jeśli nie — nie wysyłaj.

Osobna kategoria to dane osobowe. W myśl RODO to każda informacja o zidentyfikowanej lub możliwej do zidentyfikowania osobie: imię, e-mail, numer telefonu, a często też kombinacja pośrednich cech, po których można kogoś rozpoznać. Takie dane lepiej albo w ogóle nie dawać modelowi, albo anonimizować przed wysłaniem — zamieniać imię na „Klient A”, wycinać numery. To nie paranoja. To ta sama minimalizacja, tylko zastosowana do tego, co najwrażliwsze.

Nie jestem prawnikiem i nie udzielam gwarancji prawnych — konkrety dotyczące RODO, danych medycznych czy finansowych konsultuj ze swoim prawnikiem. Ale jako zasada projektowa „dawaj minimum” sprawdza się zawsze, niezależnie od jurysdykcji.

Drugi nawyk: odróżniać „dane do trenowania” od „danych w zapytaniu”

To miejsce, w którym myli się niemal każdy nie-inżynier. I to właśnie stąd wyrasta największy lęk: „Jeśli dam AI swoje dane, to się na nich nauczy, a jutro mój konkurent wyciągnie je z modelu”.

Rozdzielmy te dwa pojęcia, bo to różne wszechświaty.

Dane do trenowania to to, na czym model się uczył. Są w niego „wszyte” na zawsze i kształtują jego wiedzę o świecie. Ten proces dzieje się u dostawcy, na ogromnych zbiorach, i nie ma związku z twoją aplikacją.

Dane w zapytaniu (w prompcie) to to, co wysyłasz modelowi tu i teraz, żeby wykonał zadanie. Model je czyta, odpowiada — i na tym koniec. Nie stają się częścią modelu. To jak różnica między wykształceniem lekarza a tym, co opowiedziałeś mu na wizycie: jedno kształtuje go na zawsze, drugie zostaje w twojej karcie.

A teraz rzecz kluczowa, z potwierdzonego. Dane, które wysyłasz przez oficjalne API dostawców biznesowych — na przykład OpenAI — domyślnie nie są wykorzystywane do trenowania modeli. Twoje zapytanie nie czyni modelu „mądrzejszym” i nie wypłynie w cudzej odpowiedzi. To osobna kwestia od tymczasowego przechowywania: domyślnie dostawca może trzymać logi zapytań do 30 dni na potrzeby kontroli nadużyć, po czym je usuwa — z wyjątkiem sytuacji, gdy dłuższe przechowywanie wymusza prawo. Dla części endpointów enterprise dostępne jest nawet zerowe przechowywanie.

Co z tego wynika w praktyce. Po pierwsze, lęk „model nauczy się na moich danych” przy biznesowym API jest w większości bezpodstawny — ale sprawdzaj warunki dokładnie tego dostawcy i dokładnie tego planu, z którego korzystasz, bo polityki się różnią. Po drugie, darmowe konsumenckie chatboty i API to różne tryby; nie myl tego, co napisano dla jednego, z tym, co obowiązuje dla drugiego. Po trzecie, nawet jeśli dane nie idą do trenowania, i tak gdzieś są wysyłane i gdzieś tymczasowo leżą — dlatego nawyk numer jeden (dawać minimum) nigdzie nie znika.

Trzeci nawyk: trzymać sekrety oddzielnie od kodu i promptów

To najczęstsza i najgłupsza dziura, na jaką trafiam w aplikacjach składanych przez nie-inżynierów. I zarazem najłatwiejsza do naprawienia.

Sekret to klucz API, hasło do bazy, token dostępu. Cokolwiek, co odmyka drzwi. I jest prosta reguła: sekrety nie należą do kodu ani do promptów.

Dlaczego to ważne. Kiedy wpisujesz klucz wprost do kodu, trafia on nie tylko do samego pliku. Idzie do historii gita — i zostaje tam, nawet jeśli go potem „usuniesz”. Wypływa w logach, na zrzutach ekranu, w komunikatach o błędach. Jeden wklejony do czatu fragment kodu z kluczem w środku — i klucz już nie jest twój. A klucz do bramki płatności albo do bazy danych to bezpośrednio pieniądze i dane.

Standardowa praktyka, którą warto przyswoić raz na zawsze: sekrety przechowuje się oddzielnie od kodu — w zmiennych środowiskowych (zwykle jest to plik .env, który nigdy nie trafia do gita) albo w dedykowanym menedżerze sekretów. W samym kodzie odwołujesz się do sekretu po nazwie, a nie po wartości. Kod widzi „daj mi klucz o nazwie OPENAI_KEY”, a sama wartość leży w chronionym miejscu.

I jeszcze jedno, co wielu pomija: jeśli sekret kiedyś już trafił do repozytorium albo gdzieś wyciekł — nie wystarczy go usunąć. Trzeba go unieważnić i wygenerować na nowo. Usunięta linijka wciąż żyje w historii; jedyne pewne posunięcie to uczynić stary klucz nieważnym i wystawić nowy.

Czwarty nawyk: dostępy i role według zasady minimum

Ta sama zasada „tylko niezbędne minimum” działa nie tylko dla danych, ale i dla dostępów.

Kiedy twoja aplikacja z AI łączy się z bazą, z pocztą, z CRM-em — pytanie brzmi nie „czy ma dostęp”, tylko „jak szeroki jest ten dostęp”. Jeśli zadaniem jest czytanie zamówień, daj jej prawo do czytania, a nie prawo do usunięcia bazy. Jeśli integracja ma wysyłać maile, nie dawaj jej przy okazji kluczy do administrowania kontem.

Nazywa się to zasadą najmniejszych uprawnień, a logika jest prosta: gdy (nie „jeśli”) coś pójdzie nie tak — błąd w kodzie, skompromitowany klucz, błędny prompt — skala szkody jest ograniczona do tego dostępu, który nadałeś. Wąski dostęp zamienia katastrofę w przykrość.

Dla nie-inżyniera brzmi to abstrakcyjnie, więc konkretnie: twórz osobne klucze i osobne role pod każde zadanie, z minimalnymi prawami. Nie używaj jednego wszechmocnego klucza administratora wszędzie. Tak, to trochę więcej konfiguracji na starcie. Ale to różnica między „włamali się do jednej funkcji” a „włamali się do wszystkiego”.

Piąty nawyk: weryfikować wygenerowany kod, a nie ufać mu na ślepo

Vibecoding — gdy opisujesz, co trzeba, a AI pisze kod — to cud dla tempa. Sam tak składam prototypy. Ale jest tu uczciwe zastrzeżenie, które zawsze wypowiadam na głos.

Model pisze kod, który wykonuje zadanie. Nie pisze kodu, który wytrzyma atak. To różne cele, a domyślnie optymalizowany jest ten pierwszy. Dlatego wygenerowany kod regularnie przychodzi z typowymi dziurami: zaszyte na sztywno sekrety, brak sprawdzenia tego, co wpisał użytkownik, nadmiarowe uprawnienia, przestarzałe lub podatne zależności, niedbała praca z bazą, do której da się podsunąć szkodliwe zapytanie.

To nie znaczy „nie korzystaj z vibecodingu”. To znaczy: między „działa” a „idzie do prawdziwych danych i płatności” musi stać weryfikacja. Dla prototypu, który kręci się lokalnie na zmyślonych danych, można się tym nie przejmować. Ale gdy tylko aplikacja dotyka prawdziwych klientów, pieniędzy czy danych osobowych — kod musi przejrzeć człowiek, który rozumie bezpieczeństwo. Jeśli takiego człowieka nie masz, to osobna pozycja kosztowa, którą trzeba zaplanować, a nie udawać, że jej nie ma.

Przydatne posunięcie dla nie-inżyniera: poproś sam model, żeby przejrzał własny kod pod kątem podatności, osobnym zapytaniem — „znajdź problemy bezpieczeństwa w tym kodzie”. To nie zastępuje człowieka, ale wyłapuje najgrubsze sprawy. I zaglądaj do otwartych zestawień typowych ryzyk — społeczność OWASP prowadzi takie listy zarówno dla zwykłych aplikacji, jak i osobno dla aplikacji opartych na modelach językowych.

Szósty nawyk: człowiek w pętli przy wrażliwych czynnościach

Im bardziej autonomiczna jest twoja aplikacja z AI, tym ważniejsze staje się pytanie: gdzie ona się zatrzymuje i pyta o zgodę?

Wszystkie czynności dzielę na dwie kupki. Pierwsza — odwracalne i tanie: wygenerować szkic, podsumować tekst, zaproponować wariant, posortować skrzynkę. Tu model może działać sam, bo cena błędu to „napiszemy jeszcze raz”. Druga kupka — nieodwracalne lub kosztowne: wysłać pieniądze, usunąć dane, opublikować coś w imieniu firmy, odpowiedzieć klientowi w delikatnej sytuacji, podpisać dokument. Tu między zamiarem modelu a wykonaniem musi stać człowiek, który kliknie „tak”.

To właśnie jest „człowiek w pętli”. Zasada, którą trzymam w głowie: im droższa lub bardziej nieodwracalna czynność, tym bliżej powinien być człowiek. Nie trzeba stawiać potwierdzenia na każdym kroku — to zabije cały sens automatyzacji. Trzeba je postawić tam, gdzie błędu się nie cofnie.

Dla biznesu to także kwestia zaufania i odpowiedzialności. Kiedy pod delikatną decyzją stoi człowiek, masz kogoś, kto odpowiada i kto może w porę zatrzymać proces. W pełni autonomiczny system, który sam rozsyła pieniądze albo rozmawia z klientami bez nadzoru — to nie odwaga, to nieostrożność.

Siódmy nawyk: kopie zapasowe i wyjście od dostawcy zakłada się na starcie

I na koniec, najnudniejsze — a przez to najczęściej pomijane.

Kopie zapasowe. Jeśli twoja aplikacja z AI coś tworzy lub przechowuje — dane klientów, wygenerowane treści, ustawienia — musisz mieć kopię, odrębną od głównego systemu. Nie dlatego, że włamią się hakerzy, tylko dlatego, że coś przypadkiem się skasuje, skrypt się pomyli, dostawca padnie. Kopia, która leży tam samo, gdzie oryginał, to nie kopia zapasowa. Sprawdzaj, że z kopii naprawdę da się odtworzyć dane; niesprawdzona kopia to obietnica, a nie polisa.

Lock-in dostawcy. Kiedy budujesz na cudzej platformie — na konkretnym modelu, konkretnej usłudze — dobrowolnie się przywiązujesz. Na starcie jest to niewidoczne i wygodne. Boleśnie robi się wtedy, gdy cena wzrosła, warunki się zmieniły albo dostawca zamknął potrzebną funkcję, a ty już nie możesz łatwo odejść. Ochronę zakłada się z wyprzedzeniem: trzymaj swoje dane u siebie i sprawdzaj, że potrafisz je wyeksportować; stawiaj na standardowe formaty i otwarte API, które obsługuje więcej niż jeden dostawca; nie wszywaj logiki tak, by działała tylko w jednym miejscu. Swoboda odejścia to nie zdrada dostawcy, to zdrowa higiena.

Tabela zbiorcza: ryzyko, przykład, co robić

Oto jak trzymam to wszystko na jednym obrazku. Siedem ryzyk, przez które warto przejść, zanim dopuścisz aplikację z AI do prawdziwych danych.

Co z tym wszystkim zrobić, jeśli nie jesteś inżynierem

Nie próbuj zamknąć wszystkiego naraz — tak najłatwiej się poddać. Ja szedłbym po kolei.

Najpierw — dwie decyzje, które nie kosztują nic poza uważnością: dawaj modelowi minimum danych i anonimizuj te osobowe. Potem — sekrety precz z kodu, bo to najczęstsza i najtańsza w naprawie dziura. Następnie — zwęź dostępy. I dopiero kiedy aplikacja wychodzi poza prototyp i dotyka prawdziwych klientów, pieniędzy czy danych osobowych — podłączaj weryfikację kodu, człowieka w pętli przy wrażliwych czynnościach i porządne kopie zapasowe.

Żaden z tych kroków nie wymaga dyplomu inżyniera. Wymagają dorosłego stosunku do tego, co ci powierzono — a to właśnie ono, a nie złożoność, uważam za prawdziwe bezpieczeństwo. I jeszcze raz, uczciwie: dzielę się zasadami, a nie gwarancjami prawnymi. Tam, gdzie w grę wchodzą dane osobowe, RODO i wymogi branżowe, ostatnie słowo należy do twojego prawnika. Moja rola jest taka, żebyś przyszedł do tego prawnika, mając już zrobione rzeczy oczywiste jak należy.