Vibe coding w firmie: narzędzia zbudowane z AI a obowiązki z ustawy o KSC

W skrócie: Vibe coding, czyli budowanie aplikacji przez opisywanie ich modelowi AI, sprawił, że w wielu firmach powstały narzędzia, o których dział IT nie wie: kalkulatory ofert, formularze, panele raportowe połączone z CRM. Część z nich przetwarza dane klientów. Badania z lat 2025-2026 pokazują, że większość takich aplikacji ma luki bezpieczeństwa, najczęściej w kontroli dostępu. W firmie objętej ustawą o KSC każde takie narzędzie jest aktywem, które musi trafić do inwentarza i pod kontrolę. Ten tekst wyjaśnia, skąd bierze się ryzyko i jak w sześciu krokach uporządkować narzędzia zbudowane z AI, nie zabraniając ich.

Najważniejsze fakty:

Ustawa o KSC wymaga inwentaryzacji aktywów, kontroli dostępu i obsługi podatności; nie ma w niej wyjątku dla narzędzi zbudowanych przez pracowników.

• W przeglądzie 200 wdrożonych repozytoriów tworzonych z pomocą narzędzi AI 90% miało co najmniej jedną podatność.
• Według Veracode 45% próbek kodu wygenerowanego przez AI nie przeszło testów bezpieczeństwa opartych na OWASP Top 10.
• Skan 5,6 tys. publicznie wdrożonych aplikacji zbudowanych metodą vibe coding wykazał ponad 2 tys. poważnych podatności, ponad 400 ujawnionych sekretów i 175 przypadków ujawnienia danych osobowych.

Vibe coding a bezpieczeństwo: co pokazują badania?

Dane z lat 2025–2026 są spójne: aplikacje zbudowane z AI bez przeglądu bezpieczeństwa mają luki znacznie częściej, niż zakładają ich twórcy.

• Cloud Security Alliance ustaliła, że 62% rozwiązań kodu wygenerowanego przez AI zawiera błędy projektowe lub znane podatności, nawet przy użyciu najnowszych modeli. Ta sama organizacja opisuje przypadek ze stycznia 2026 r., gdy jedna błędna konfiguracja bazy Firebase w platformie zbudowanej z AI ujawniła 406 mln rekordów.
• Veracode przetestował ponad 100 modeli językowych na 80 zadaniach programistycznych; 45% próbek kodu nie przeszło testów bezpieczeństwa opartych na OWASP Top 10.
• Escape przeskanował ponad 5,6 tys. publicznie wdrożonych aplikacji vibe coding i znalazł ponad 2 tys. poważnych podatności, ponad 400 ujawnionych sekretów (kluczy API, haseł do baz) i 175 przypadków ujawnienia danych osobowych.
• W sierpniowym zestawieniu Vibe Coding Security Monthly 180 z 200 wdrożonych repozytoriów (90%) miało co najmniej jedną podatność, najczęściej błędną kontrolę dostępu, a 57% osiągalnych aplikacji opartych na Supabase pozwalało odczytać tabele bez logowania.
• IBM, powołując się na raport GitGuardian, opisuje, że commity tworzone z pomocą jednego z popularnych asystentów AI ujawniały sekrety ponad dwa razy częściej niż commity pisane wyłącznie przez ludzi.

Wniosek nie brzmi „AI pisze zły kod”. Brzmi: AI pisze kod, który działa, a bezpieczeństwo rzadko jest częścią polecenia. Model zbuduje formularz i bazę, ale jeśli nikt nie poprosi o reguły dostępu do tabel, ich nie będzie.

Dlaczego vibe coding w firmie podlega ustawie o KSC?

Ustawa o KSC nie rozróżnia aplikacji napisanych przez software house, kupionych od dostawcy i zbudowanych przez pracownika w przeglądarce. Dla firmy objętej ustawą każda z nich jest aktywem systemu informacyjnego, a ustawa wymaga, żeby firma:

• znała swoje aktywa, czyli miała inwentarz aplikacji i danych, które przetwarzają,
• kontrolowała dostęp do systemów,
• bezpiecznie rozwijała i utrzymywała oprogramowanie, w tym usuwała podatności,
• oceniała dostawców, czyli także platformy, na których narzędzia zostały zbudowane i są hostowane,
• wykrywała i zgłaszała incydenty, także wyciek danych z narzędzia, o którym IT nie wiedziało.

Najważniejsze z perspektywy vibe coding jest to, że do 3 kwietnia 2027 r. podmioty kluczowe i ważne muszą mieć wdrożony system zarządzania bezpieczeństwem informacji. Narzędzie, którego nie ma w inwentarzu, nie jest w nim objęte niczym.

Niezależnie od ustawy o KSC działa też RODO. Jeśli kalkulator ofert przechowuje dane kontaktowe klientów w bazie dostępnej bez logowania, wyciek jest naruszeniem ochrony danych osobowych, które trzeba zgłosić do UODO.

Shadow AI: jak rozpoznać, że problem dotyczy twojej firmy?

Shadow AI to narzędzia i aplikacje oparte na AI, których firma używa bez wiedzy i kontroli działu IT. Kilka sygnałów, że w firmie są aplikacje zbudowane metodą vibe coding:

• w kosztach pojawiają się subskrypcje platform takich jak Lovable, Bolt, Replit czy Vercel, opłacane kartą działu,
• pracownicy wysyłają klientom linki do formularzy lub kalkulatorów na domenach, których firma nie zna,
• CRM albo arkusze mają integracje dodane przez osoby spoza IT,
• ktoś mówi „zrobiłem sobie apkę do tego” i nikt nie pyta, gdzie stoi i kto ma do niej dostęp.

Żaden z tych sygnałów nie oznacza złej woli. Oznacza, że ludzie rozwiązują problemy szybciej, niż firma nadąża z zasadami.

Vibe coding w firmie bez ryzyka: 6 kroków

1. Znajdź narzędzia. Krótka, bezkarna ankieta wśród pracowników („co zbudowałeś z AI i do czego tego używasz?”), przegląd subskrypcji w kosztach i logów logowania przez konta firmowe. Bezkarność jest ważna: jeśli ludzie będą się bać, ukryją narzędzia.
2. Oceń ryzyko. Dla każdego narzędzia trzy pytania: jakie dane przetwarza, kto ma do niego dostęp z internetu i z czym się łączy. Narzędzie z danymi klientów, dostępne publicznie i połączone z CRM idzie na początek kolejki.
3. Zabezpiecz to, co najpilniejsze. Włącz reguły dostępu do tabel w bazie (np. Row Level Security w Supabase), wymuś logowanie, zmień klucze API, które mogły trafić do kodu, ukryj publiczne adresy. Do samodzielnej weryfikacji służy lista [12 punktów kontroli bezpieczeństwa aplikacji zbudowanej z AI – link po publikacji w styczniu].
4. Zdecyduj o przyszłości narzędzia. Są trzy wyjścia: przejąć narzędzie do IT i utrzymywać je jak każdą aplikację, przepisać je porządnie, jeśli jest ważne dla firmy, albo wyłączyć, jeśli przestało być potrzebne.
5. Ustal zasady. Lista dozwolonych platform, minimalne wymagania (logowanie przez konto firmowe, brak danych klientów bez zgody IT, przegląd przed udostępnieniem na zewnątrz) i prosta ścieżka zgłoszenia nowego narzędzia.
6. Utrzymuj inwentarz. Nowe narzędzia trafiają do inwentarza aplikacji tak samo jak systemy kupione od dostawców. Raz na kwartał krótki przegląd: co powstało, co przestało być używane.

Zakaz vibe coding zwykle nie działa. Ludzie dalej będą budować narzędzia, tylko przestaną o nich mówić. Lepiej dać im bezpieczną ścieżkę niż pchać problem głębiej w cień.

Jak wygląda przegląd bezpieczeństwa aplikacji z vibe coding?

Przegląd narzędzia zbudowanego z AI nie musi być dużym projektem. Zaczyna się od rozmowy z jego twórcą: do czego służy, skąd bierze dane i komu je pokazuje. Potem programista sprawdza konfigurację platformy i bazy danych, czyli czy tabele mają reguły dostępu, czy logowanie jest wymuszone i czy publiczne adresy nie zdradzają danych. Następnie przegląda kod pod kątem sekretów, zależności z niezałatanymi podatnościami i miejsc, w których aplikacja bezkrytycznie ufa danym od użytkownika.

Wynikiem jest krótka lista: co trzeba naprawić od razu, co można poprawić w kolejnych tygodniach i czy narzędzie w ogóle warto dalej utrzymywać. Dla prostego kalkulatora czy formularza taki przegląd trwa zwykle od jednego do kilku dni. Dla firmy objętej ustawą o KSC ma też drugą wartość: jest dowodem, że narzędzie zbudowane metodą vibe coding zostało ocenione i włączone do systemu zarządzania bezpieczeństwem informacji, a nie pominięte.

Od shadow AI do narzędzi pod kontrolą: inwentaryzacja, przegląd, przejęcie

Sanddev pomaga firmom przejąć kontrolę nad narzędziami zbudowanymi z AI: robimy inwentaryzację i przegląd bezpieczeństwa, naprawiamy luki, a narzędzia ważne dla firmy przepisujemy albo bierzemy do utrzymania. Opisujemy to na stronie o tym, jak wygląda przejęcie aplikacji, której nikt w pełni nie rozumie.

FAQ