Najpierw odporność, potem skala. Co zarząd powinien sprawdzić, zanim wdroży AI

Sztuczna inteligencja jest dokładnie tak skuteczna, jak dane i infrastruktura, na których pracuje. Bez porządku w danych, jasnej odpowiedzialności i przemyślanego cyberbezpieczeństwa transformacja cyfrowa nie zmniejsza ryzyka – tylko je mnoży. O tym rozmawialiśmy podczas panelu IT & AI na VIII Międzynarodowym Forum Gospodarczym. Poniżej rozwijam tezy, z którymi przyszedłem na debatę i ilustruję je przykładami z projektów Resilia.

Organizatorzy postawili panelowi konkretne zadanie: określić, jakie fundamenty technologiczne i organizacyjne muszą powstać, zanim przedsiębiorstwo zacznie skalować rozwiązania AI oraz jak połączyć rozwój technologii z odpornością operacyjną. Partnerem merytorycznym sesji była Grupa Transportowa Sp. z o.o. – co dobrze się złożyło, bo transport to w NIS2 sektor kluczowy, a logistyka to system naczyń połączonych, w którym incydent u jednego uczestnika zatrzymuje dziesiątki innych.

W panelu reprezentowałem perspektywę ryzyka i odporności. Od lat jesteśmy w Resilia wzywani wtedy, gdy coś przestało działać albo wtedy, gdy organizacja chce mieć pewność, że nie przestanie. Z tej perspektywy mam dobrą i złą wiadomość. Dobra: technologia AI jest dziś dostępna dla każdego. Zła: dla atakujących też. Stąd teza, z którą przyszedłem na debatę:

AI nie naprawi bałaganu w organizacji, a jedynie go przyspieszy. Najpierw odporność, potem skala.

Dane są dziś większym problemem niż sama technologia

Model AI można kupić jako usługę i uruchomić w kilka tygodni. Porządek w danych jest efektem decyzji podejmowanych latami albo ich braku.

Co obserwujemy w praktyce? Kiedy rozpoczynamy projekt bezpieczeństwa informacji, wdrożenie ISO/IEC 27001 czy przygotowanie do obowiązków wynikających z ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC), wdrażającej w Polsce wymagania dyrektywy NIS2, pierwsze pytania są zawsze te same: jakie informacje macie, gdzie są przechowywane, kto jest ich właścicielem i kto ma do nich dostęp. W praktyce projektowej często nie otrzymujemy pełnej odpowiedzi. Rejestr aktywów informacyjnych bywa, że nie istnieje bądź jest nieaktualny, a uprawnienia narastają latami – pracownicy zmieniają stanowiska, a dostępy zostają.

Dlaczego to ma znaczenie dla AI? Asystent AI podłączony do poczty, dysków czy CRM może przetwarzać i ujawniać informacje, do których uzyska dostęp w ramach skonfigurowanych uprawnień, integracji i kontekstu użytkownika. Jeśli uprawnienia są nadmiarowe, AI może bardzo szybko wydobyć informacje, których pracownik sam by nie znalazł – umowy, wynagrodzenia, dane osobowe. Nadmiarowe uprawnienia nie oznaczają automatycznie wycieku, ale mogą znacząco zwiększyć skalę i szybkość nieuprawnionego ujawnienia danych; wiele zależy od konfiguracji, rejestrowania zdarzeń i mechanizmów kontroli. Drugi problem to jakość danych: jeśli AI korzysta z niepełnych lub nieaktualnych informacji, jej rekomendacje mogą być błędne, choć sposób ich przedstawienia może sugerować, że są wiarygodne.

Do tego dochodzi „shadow AI”, czyli pracownicy wklejający firmowe dokumenty do publicznych czatbotów. W wielu organizacjach to dziś bardziej prawdopodobny kanał wycieku niż oficjalny projekt AI.

Pięć kroków porządkowania danych przed wdrożeniem AI

1. Inwentaryzacja – jakie informacje mamy, gdzie powstają, gdzie są przechowywane i do których dostawców wypływają (SaaS, chmura, partnerzy).
2. Klasyfikacja – prosty, 3–4-stopniowy schemat (publiczne / wewnętrzne / poufne / ściśle chronione) wystarczy na start.
3. Właściciel biznesowy każdego zbioru danych – nie dział IT. IT administruje technicznie, ale o tym, kto może korzystać z danych i w jakim celu, decyduje biznes.
4. Porządek w uprawnieniach – zasada minimalnych uprawnień i przegląd dostępów, zanim podłączymy asystenta AI do firmowych zasobów.
5. Cykl życia i retencja – usuwanie danych, których nie potrzebujemy. Mniej danych to mniejsze ryzyko, niższy koszt i lepsza jakość odpowiedzi AI.

Z praktyki Resilia: jedna inwentaryzacja, wiele regulacji. W projektach dla grup kapitałowych nie prowadzimy osobnych projektów zgodności z ustawą o KSC, normą ISO/IEC 27001, unijnym aktem w sprawie sztucznej inteligencji (AI Act) i RODO. Projektujemy jeden rejestr aktywów i jedną metodykę analizy ryzyka, które obsługują wszystkie te wymagania, a w kolejnym kroku także zarządzanie ryzykiem AI. Organizacja raz odpowiada na pytanie „co mamy i kto za to odpowiada”, zamiast robić to osobno dla każdej regulacji i każdego audytora.

Standaryzacja ma tu jeszcze jedną, często pomijaną funkcję. Jednolita klasyfikacja i etykietowanie dokumentów to sygnał, który potrafią odczytać narzędzia – systemy zapobiegania wyciekom, kontrola dostępu i same rozwiązania AI. Dokument oznaczony jako poufny może zostać zatrzymany przed wysłaniem do zewnętrznego modelu. Nieoznaczonego nic nie zatrzyma.

AI jest jak wzmacniacz: wzmacnia porządek, ale tak samo wzmacnia bałagan.

Jak AI zmienia cyberzagrożenia

Skala zagrożeń rośnie szybko. Według raportu rocznego CERT Polska w 2025 r. do zespołu trafiło 658 320 zgłoszeń, a liczba unikalnych incydentów wyniosła 260 783 – o 152% więcej niż rok wcześniej. Oszustwa komputerowe, w tym phishing, stanowiły 97% zarejestrowanych incydentów. W tym obrazie widzimy trzy zmiany, które przyspiesza AI.

Po pierwsze – jakość i skala socjotechniki. Phishing bez błędów językowych, w dowolnym języku, spersonalizowany na podstawie profilu w mediach społecznościowych. Do tego podszywanie się głosem i obrazem pod członków zarządu – klasyczne „oszustwo na prezesa” w wersji deepfake. Dlatego osobno szkolimy kadrę zarządzającą: to ona jest dziś najcenniejszym celem.

Po drugie – szybkość. Automatyzacja rozpoznania i wykorzystania podatności skraca czas od ujawnienia luki do ataku. Okno na łatanie systemów, które kiedyś liczyliśmy w tygodniach, dziś liczy się w dniach.

Po trzecie – nowa powierzchnia ataku, czyli sam system AI. Manipulowanie poleceniami (prompt injection), zatruwanie danych, wyciek informacji przez narzędzia AI, a wkrótce także agenci AI z uprawnieniami do działania w naszych systemach.

Case study: incydent bezpieczeństwa u dostawcy SaaS

Coraz częściej atak nie trafia w nas, tylko w naszego dostawcę. Najświeższy przykład to incydent bezpieczeństwa w Fakturowni. Według oficjalnego komunikatu dostawcy nieuprawniony dostęp trwał od 27 września (ok. 3:20) do 28 września 2026 r. (ok. 17:45); naruszenie stwierdzono 28 września, a dane zostały skopiowane, w tym m.in. dane firm i użytkowników, numery rachunków, kwoty faktur, dane kontrahentów oraz tokeny i klucze integracji. Nasze zalecenia dla firm opisaliśmy w artykule „Wyciek danych z Fakturowni – co się stało i jak powinna zareagować Twoja firma?”.

Byliśmy w tej sytuacji po obu stronach: jako klient platformy, który sam otrzymał zawiadomienie o naruszeniu, i jako doradca, do którego dzwonili klienci. Wiele organizacji, które nigdy nie myślały o sobie jako o ofierze cyberataku, musiało pilnie ustalić, jakie dane powierzyło dostawcy, czy mogły zostać objęte incydentem i czy naruszenie wymaga zgłoszenia do UODO. Termin 72 godzin z art. 33 RODO dotyczy zgłoszenia naruszenia organowi nadzorczemu, liczonego od jego stwierdzenia przez administratora i tylko wtedy, gdy naruszenie może powodować ryzyko naruszenia praw lub wolności osób, a nie samej analizy sytuacji.

Kłopot w tym, że wiele firm zaczynało tę analizę od ustalania, co w ogóle trzyma u dostawcy. Największym praktycznym zagrożeniem okazało się nie samo ujawnienie danych, ale ich wykorzystanie do bardzo wiarygodnych prób wyłudzenia przelewu „na nowy rachunek” kontrahenta. To dobra lekcja pokory – także dla nas.

Podobny scenariusz obserwowaliśmy w ochronie zdrowia: po incydencie u dostawcy oprogramowania dla gabinetów stomatologicznych przygotowaliśmy dla związku pracodawców z tego sektora instrukcję postępowania dla placówek. Wniosek z obu przypadków jest ten sam: rejestr dostawców i przepływów danych oraz przećwiczony plan reagowania są ważniejsze niż kolejne narzędzie. O tym, co taki plan powinien zawierać, piszemy w artykule „Plan reagowania na incydent cyberbezpieczeństwa”.

Atakujący wdrożyli AI szybciej niż większość firm – i bez komitetu sterującego.

Kto odpowiada za cyberbezpieczeństwo? Kierownik podmiotu – najczęściej zarząd

Prawnie – kierownik podmiotu. Od 3 kwietnia 2026 r. obowiązuje ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (Dz.U. 2026 poz. 252). Nowelizacja przypisuje odpowiedzialność za realizację obowiązków z zakresu cyberbezpieczeństwa kierownikowi podmiotu kluczowego lub ważnego – definiowanemu przez odesłanie do ustawy o rachunkowości. W spółce kapitałowej będzie to co do zasady zarząd. Warto przy tym odróżnić wejście ustawy w życie od terminów wykonania poszczególnych obowiązków, które rozłożono do 2028 r. (zob. kalendarz na końcu artykułu). Podobną logikę odpowiedzialności kierownictwa w sektorze finansowym wprowadza DORA, a w obszarze AI – AI Act.

Operacyjnie – wszyscy, ale w różnych rolach. Właściciele procesów i danych odpowiadają za ryzyko w swoim obszarze. Funkcja bezpieczeństwa (CISO) doradza, mierzy i nadzoruje. Audyt sprawdza. IT wdraża zabezpieczenia, ale nie powinno samo oceniać ich skuteczności, bo to klasyczny konflikt interesów.

Case study: wirtualny CISO u producenta żywności (przykład zanonimizowany)

W wielu średnich organizacjach nie ma etatowego CISO, a obowiązki wynikające z przepisów są takie same jak w dużych firmach. Odpowiedzią jest model wirtualnego CISO (vCISO): doświadczony ekspert na część etatu, który prowadzi program bezpieczeństwa i raportuje do zarządu.

Tak pracujemy dla jednego z ważnych producentów żywności. Podstawy zarządzania bezpieczeństwem zaczęliśmy budować jeszcze przed wejściem w życie nowelizacji ustawy o KSC i tym bardziej przed terminami wykonania wynikających z niej obowiązków. Zamiast zaczynać od zakupów, zaczęliśmy od diagnozy: ocenę stanu bezpieczeństwa przeprowadziliśmy według CIS Controls (wykorzystanych jako rama diagnostyczna, a nie podstawa certyfikacji) na czterech poziomach: organizacyjnym, formalno-proceduralnym, technologicznym i świadomości pracowników. Analizowaliśmy dokumentację, rozmawialiśmy z właścicielami kluczowych procesów i zasobów, prowadziliśmy wizje lokalne. Dopiero na tej podstawie przeszliśmy do pogłębionej analizy potrzeb i rekomendacji zakupowych, a zadania w programie cyberbezpieczeństwa uszeregowaliśmy według ryzyka i kosztu.

Efekt: zabezpieczenia dobrane do realnych potrzeb zamiast kupowanych „na wszelki wypadek”, usprawnione procesy i procedury, wyższa świadomość zagrożeń i optymalizacja kosztów.

Cyberbezpieczeństwa nie da się delegować. Można delegować zadania, ale nie odpowiedzialność.

Jakiej infrastruktury naprawdę wymaga AI?

Mówiąc o infrastrukturze AI, myślimy zwykle o procesorach graficznych. W praktyce większość firm kupi moc obliczeniową jako usługę. Prawdziwa infrastruktura AI to pięć warstw, o których mówi się znacznie rzadziej:

• Dane – repozytoria, katalog danych, potoki zasilania i kontrola jakości.
• Tożsamość i dostęp – silne uwierzytelnianie i zarządzanie uprawnieniami. AI działa w imieniu użytkownika, więc dziedziczy wszystkie błędy w uprawnieniach.
• Rejestrowanie i obserwowalność – logi zapytań, odpowiedzi i działań agentów AI. AI Act wymaga rejestrowania zdarzeń dla systemów wysokiego ryzyka, a bez logów nie da się obsłużyć incydentu ani zgłosić go we wczesnym ostrzeżeniu w ciągu 24 godzin.
• Bezpieczeństwo – segmentacja sieci, zapobieganie wyciekom, testy odporności modeli na manipulację (red teaming).
• Ciągłość działania – co, jeśli dostawca modelu będzie niedostępny, zmieni warunki albo wycofa model? Potrzebny jest tryb ręczny, alternatywny dostawca i strategia wyjścia.

Najdroższy element infrastruktury AI to nie GPU, tylko brak logów w dniu incydentu.

Chmura czy własne systemy?

Uczciwa odpowiedź brzmi „to zależy”, ale od konkretnych, mierzalnych kryteriów, a nie od mody. To decyzja o ryzyku, nie o technologii. Bierzemy pod uwagę klasyfikację danych, wymagania regulacyjne (DORA: rejestr umów z dostawcami ICT i strategie wyjścia; ustawa o KSC: bezpieczeństwo łańcucha dostaw), lokalizację i suwerenność danych, koszt w całym cyklu życia (przy dużej skali koszt wnioskowania AI w chmurze potrafi zaskoczyć), kompetencje zespołu oraz wymagany czas odtworzenia.

W praktyce najczęściej wygrywa model hybrydowy: dane najbardziej wrażliwe i procesy krytyczne bliżej – w chmurze prywatnej, krajowej lub we własnym środowisku, a reszta w chmurze publicznej. Pracowaliśmy zarówno dla operatorów chmury, w tym Operatora Chmury Krajowej, jak i dla organizacji, które wybrały środowiska własne, więc znamy obie strony tej decyzji.

Jedną rzecz trzeba mówić głośno: chmura działa w modelu współodpowiedzialności. Dostawca odpowiada za bezpieczeństwo chmury, my – za to, co w niej umieszczamy: konfigurację, tożsamości i dane. Większość incydentów chmurowych to nie awarie dostawcy, tylko błędna konfiguracja i przejęte konta.

Chmura nie przenosi odpowiedzialności – przenosi tylko serwery.

10 pytań, które zarząd powinien zadać przed dużym wdrożeniem AI

Jeśli zarząd nie potrafi odpowiedzieć na nie w ciągu godziny, organizacja jest gotowa na pilotaż, ale nie na skalowanie.

1. Cel i miara: Jaki problem biznesowy rozwiązujemy i jak zmierzymy efekt?
2. Dane: Jakie dane zasilą system, kto jest ich właścicielem i czy mamy prawo ich użyć (RODO, umowy, tajemnica przedsiębiorstwa)?
3. Kategoria ryzyka wg AI Act: Jak oceniamy zastosowanie i klasyfikację systemu według kategorii ryzyka AI Act (praktyka zakazana, system wysokiego ryzyka, obowiązki przejrzystości, pozostałe)? Czy jesteśmy dostawcą, czy podmiotem stosującym?
4. Analiza ryzyka: Czy przeprowadziliśmy analizę ryzyka, w tym ocenę skutków dla ochrony danych (DPIA), a dla systemów wysokiego ryzyka – ocenę wpływu na prawa podstawowe?
5. Odpowiedzialność: Kto jest właścicielem systemu AI i kto sprawuje nadzór człowieka nad jego decyzjami?
6. Dostawca: Gdzie są przetwarzane dane, czy służą do trenowania modelu, jakie certyfikaty (ISO/IEC 27001, ISO/IEC 42001), SLA, prawo audytu i strategia wyjścia?
7. Bezpieczeństwo: Czy mamy testy, kontrolę uprawnień, rejestrowanie zdarzeń i scenariusze nadużyć?
8. Ciągłość działania: Co robimy, gdy AI przestanie działać albo zacznie się mylić? Jaki jest tryb awaryjny i akceptowalny czas przestoju?
9. Kompetencje: Czy podejmujemy działania wspierające kompetencje w zakresie AI personelu korzystającego z systemów AI (art. 4 AI Act – od 2 lutego 2025 r., od 27 lipca 2026 r. w brzmieniu zmienionym przez Digital Omnibus)?
10. Polityka i rejestr: Czy mamy politykę korzystania z AI i rejestr używanych narzędzi – także tych, które pracownicy wprowadzili sami?

Warto pamiętać, że pakiet „Digital Omnibus” nie zwalnia z obowiązków przejrzystości (art. 50 AI Act), które co do zasady obowiązują od 2 sierpnia 2026 r. – przesunięcie do 2 grudnia 2026 r. dotyczy jedynie oznaczania treści generowanych przez systemy wprowadzone na rynek przed tą datą. Omnibus przesunął natomiast terminy dla systemów wysokiego ryzyka (dla systemów z załącznika III – na 2 grudnia 2027 r.). Pisaliśmy o tym w artykule „Digital Omnibus nie zwalnia z obowiązków przejrzystości”. Kary przewidziane w AI Act sięgają 35 mln euro lub 7% światowego obrotu za praktyki zakazane oraz 15 mln euro lub 3% obrotu za naruszenie innych wymagań.

Zarząd nie musi rozumieć, jak działa model. Musi wiedzieć, co się stanie, gdy przestanie działać.

Lekcja z wdrożeń, które nie poszły zgodnie z planem

Organizatorzy zachęcali panelistów, by mówili także o projektach, które nie zakończyły się tak, jak zakładano. To cenne, bo na błędach uczymy się szybciej niż na sukcesach.

Widzieliśmy wdrożenia, które zaczynały się od dokumentacji (polityk, procedur i rejestrów) zanim w organizacji było jasne, kto jest właścicielem procesów i danych. Dokumenty powstawały, audyt formalnie wypadał dobrze, ale przy pierwszym prawdziwym incydencie nikt nie czuł się właścicielem decyzji. Procedury „nie żyły”.

Wniosek, który stosujemy dziś w każdym projekcie: najpierw ludzie i odpowiedzialności, potem papier. Zaczynamy od mapy właścicieli i ćwiczenia scenariusza incydentu z zarządem – dokumentacja jest skutkiem, a nie celem. Ta lekcja wprost przekłada się na AI: firmy piszą dziś polityki korzystania z AI, ale nie wyznaczają właściciela systemu AI i nie ćwiczą scenariusza „AI podało klientowi błędną informację”.

Dwie rekomendacje: dla biznesu i dla regulatorów

Dla przedsiębiorców: test gotowości przed skalą

Rekomenduję, aby przejście projektu AI z pilotażu do produkcji wymagało trzech elementów zatwierdzonych przez zarząd:

1. rejestru danych z właścicielami;
2. analizy ryzyka obejmującej cel i zakres zastosowania, dane, dostawcę, bezpieczeństwo, prywatność, ciągłość działania i nadzór człowieka – wraz z oceną zastosowania i klasyfikacji systemu według kategorii ryzyka AI Act oraz wynikających z niej obowiązków informacyjnych;
3. planu awaryjnego na wypadek awarii lub błędu systemu.

To propozycja zasady nadzoru (governance), a nie wymóg prawny, ale w praktyce oszczędza kosztownych powrotów do etapu pilotażu.

Dla regulatorów: jeden incydent – jedno zgłoszenie

Dziś jeden incydent może wymagać zgłoszenia do CSIRT przez System S46 (ustawa o KSC), do UODO (RODO), do KNF (DORA), a w przyszłości także do organu nadzoru rynku w przypadku poważnych incydentów systemów AI wysokiego ryzyka w różnych terminach i na różnych formularzach. W pierwszych 24 godzinach kryzysu firmy zajmują się sprawozdawczością zamiast obroną. Potrzebujemy jednego punktu zgłoszeń z automatycznym przekazaniem informacji do właściwych organów.

Kalendarz, który warto mieć przed oczami

• 2 lutego 2025 r. – AI Act – zakaz praktyk niedozwolonych i obowiązek dotyczący kompetencji w zakresie AI (art. 4)
• 12 września 2025 r. – Data Act – stosowanie przepisów, m.in. dotyczących udostępniania danych i zmiany dostawcy chmury
• 3 kwietnia 2026 r. – Wejście w życie nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252)
• 27 lipca 2026 r. – Wejście w życie Digital Omnibus on AI – m.in. nowe brzmienie art. 4 AI Act i przesunięcie terminów dla systemów wysokiego ryzyka
• 2 sierpnia 2026 r. – AI Act – obowiązki przejrzystości (art. 50); oznaczanie treści generowanych przez systemy wprowadzone na rynek przed tą datą – do 2 grudnia 2026 r.
• 3 października 2026 r. – Ustawa o KSC – termin złożenia wniosku o wpis do wykazu podmiotów kluczowych i ważnych (minął)
• 3 kwietnia 2027 r. – Ustawa o KSC – termin wdrożenia obowiązków (m.in. systemu zarządzania bezpieczeństwem informacji) przez podmioty spełniające kryteria w dniu wejścia w życie nowelizacji
• 2 grudnia 2027 r. – AI Act – stosowanie wymagań dla systemów wysokiego ryzyka z załącznika III (po zmianie przez Digital Omnibus)
• 3 kwietnia 2028 r. – Ustawa o KSC – pierwszy audyt podmiotów kluczowych; od tej daty możliwe kary administracyjne za większość obowiązków
• Na bieżąco – Incydenty poważne zgłaszane przez System S46: wczesne ostrzeżenie w 24 h, zgłoszenie w 72 h, raport końcowy w ciągu miesiąca

Do 3 kwietnia 2027 r. zostało niespełna sześć miesięcy. Przy rzetelnym podejściu to niewiele – wdrożenie systemu zarządzania bezpieczeństwem w średniej organizacji to kilka miesięcy pracy. Więcej o obowiązkach rejestracyjnych piszemy w artykule „System S46 i Wykaz KSC”.

Najczęściej zadawane pytania

Podsumowanie

Debata na VIII Międzynarodowym Forum Gospodarczym potwierdziła to, co widzimy w projektach: przewagę w AI zbudują nie firmy, które najszybciej kupią model, ale te, które najpierw uporządkują dane, odpowiedzialność i plany awaryjne. Regulacje – ustawa o KSC, NIS2, DORA, AI Act – nie są hamulcem innowacji. Zmuszają do odpowiedzi na pytania, które i tak trzeba zadać. Firmy, które to zrobiły, wdrażają AI szybciej, bo nie muszą się cofać.

Dziękuję organizatorom z Europejskiego Ośrodka Rozwoju Gospodarki oraz współpanelistom za rozmowę, która była prawdziwą wymianą doświadczeń.

Sprawdź gotowość swojej organizacji na AI i nowe wymagania ustawy o KSC.

Pomagamy zarządom ocenić gotowość organizacji, uporządkować dane i odpowiedzialności, wdrożyć wymagania ustawy o KSC (NIS2), DORA i AI Act oraz zbudować plany ciągłości działania.

Skontaktuj się z nami na adres [email protected] lub poprzez formularz na dole strony. Możesz również zadzwonić do nas na +48 22 243 39 37.

Autor: Marcin Marczewski – Prezes Zarządu Resilia Sp. z o.o. Od lat doradza organizacjom z sektorów energetycznego, finansowego, ochrony zdrowia, produkcji i administracji w zakresie zarządzania ryzykiem, ciągłości działania, cyberbezpieczeństwa i wdrażania regulacji, w tym ustawy o KSC (NIS2), DORA i AI Act.