Administracja i Back-office

Trzy ślepe punkty nadzoru AI, które niszczą projekty

Większość firm nie kontroluje AI przed działaniem, lecz po. Poznaj trzy krytyczne luki w nadzorze sztucznej inteligencji i jak je wyeliminować, zanim spowodują…

Redakcja · 27 lipca 2026
Close-up of a modern control panel in an Istanbul office with buttons and switches.
Fot. Ibrahim Boran / Pexels · Pexels License

Nadzór nad sztuczną inteligencją w firmach to nie rejestrowanie tego, co AI zrobiło, lecz zatrzymanie tego, co ma zrobić, zanim to zrobi. Większość firm ma to odwrotnie — kupują narzędzia do monitorowania akcji, które już się wydarzyły, zamiast budować kontrole, które mogą je powstrzymać.

Gartner szacuje, że co najmniej 15% rutynowych decyzji biznesowych będzie podejmowanych autonomicznie przez AI w 2028 roku, w porównaniu z praktycznie żadnymi w 2024 roku. Jednocześnie ponad 40% projektów AI zostanie anulowanych do końca 2027 roku — ale nie dlatego, że modele są złe. Projekty umierają, ponieważ nikt nie zbudował sposobu, aby nimi zarządzać. To kluczowa różnica: problem nie leży w technologii, lecz w braku kontroli ryzyka.

Trzy ślepe punkty nadzoru AI, które większość firm ignoruje

Dyskusje o bezpieczeństwie AI skupiają się na niewłaściwych zagadnieniach. Zespoły spędzają tygodnie na wyborze modelu, a potem podłączają go do poczty, płatności, bazy danych klientów i kodu — bez zatrzymania się, aby zapytać: kiedy ten model coś zrobi, kto obserwuje to i czy ktoś może temu zapobiec?

Pierwszy ślepe punkt: autonomiczne agenty z dostępem do narzędzi

Wszyscy martwią się o autonomiczne agenty — i słusznie. Ale większość ludzi martwi się o niewłaściwą część problemu. Niepokojącą rzeczą w przypadku agenta nie jest to, że rozumie instrukcje. To, że je wykonuje. Agent nie proponuje zwrotu; płaci go. Nie pisze e-maila; wysyła go. Nie sugeruje zmiany w bazie danych; ją zmienia.

Podanie modelowi zestawu narzędzi to podanie mu możliwości dotknięcia prawdziwych systemów i zmiany rzeczy. Pomyłka w tym może skutkować nie tylko niezręcznym zdaniem, ale pieniądzmi wyrzuconymi w błoto lub cichą utratą tabeli z bazy danych. Wstrzyknięcie promtu (prompt injection) znajduje się na samej górze listy ryzyka OWASP dla aplikacji LLM — podanie modelowi niewłaściwego tekstu może spowodować, że zrobi coś, czego nikt nie prosił. Kiedy model może tylko mówić, to niedogodność. Kiedy model może wywołać narzędzia, to atakujący, który trzyma twoje klucze API.

Standardowa odpowiedź to rejestrowanie wszystkiego, co robi agent, i obserwowanie śladów. Ale ślad to opis czegoś, co już się wydarzyło — to nagranie z monitoringu po tym, jak kasa została opróżniona, przydatne do dochodzenia, ale bezużyteczne do powstrzymania kradzieży.

Drugi ślepe punkt: zwykłe wywołania API w kodzie

Drugi punkt ślepy nigdy nie pojawia się na slajdach, ponieważ jest nudny. To zwykłe wywołanie API — nie agent, nie framework, tylko kawałek kodu gdzieś w usłudze, który składa prompt i wywołuje go na modelu. Większość AI w produkcji wygląda dokładnie tak, i jest to najmniej zarządzana część całego stosu, właśnie dlatego, że jest tak zwyczajna.

To żądanie HTTP zakopane trzy warstwy głęboko w jakiejś usłudze, napisanej przez inżyniera, który nigdy nie słyszał o twojej polityce AI i nie wiedziałby, gdzie ją znaleźć. Jedno takie wywołanie może wysłać dane klienta do modelu trzeciej strony lub wywołać akcję w dół strumienia — i nic nie sprawdza, czy powinno, i nic niezależnego nie zapisuje tego, że tak się stało. To jest miejsce, gdzie żyją prawdziwe luki.

Trzeci ślepe punkt: pracownicy wklejający dane do ChatGPT

Trzeci punkt ślepy to ludzie — i dlatego jest to najgorszy. Twoi pracownicy odkryli miesiące temu, że wklejenie zadania do ChatGPT lub Claude powoduje, że jest to robione szybciej, więc robią to cały dzień, zwykle z osobistych kont, których nie możesz zobaczyć. To nie jest hipotetyczne.

Badanie Cyberhaven na rzeczywiste użycie w miejscu pracy wykazało, że znaczna część pracowników wklejła poufne dane firmy do ChatGPT — wiele z nich z kont, na które firma nie ma wglądu. Samsung stanowi ostrzegawczą opowieść: w 2023 roku zakazał generatywnego AI wewnętrznie po tym, jak inżynierowie wkleili własny kod źródłowy do ChatGPT trzy oddzielne razy w ciągu mniej niż miesiąca. Ci ludzie nie byli złymi aktorami. Byli dobrymi inżynierami, którzy starali się debugować szybciej. To jest cała pułapka: wyciek wygląda identycznie jak produktywność. Twoje stare narzędzia do utraty danych nie złapią tego, ponieważ jest to kopiuj-wklej do karty przeglądarki, a nie plik wychodzący z budynku.

Jak naprawić nadzór AI: cztery konkretne kroki

Siedź przed akcją, a nie za nią

Obserwowalność i zarządzanie to nie to samo słowo. Pulpit, który informuje cię, że agent przeniósł 40 000 funtów wczoraj, to raport strat. Coś, co może zatrzymać ten transfer, aby człowiek mógł go obejrzeć zanim wyjdzie, to kontrola. Jeśli twoje ustawienie może tylko powiedzieć ci, co się stało, nie masz nadzoru. Masz tylko wgląd wsteczny. To jest całą grą.

Użyj jednego punktu kontrolnego, a nie jednego na narzędzie

Agenci, wywołania API i pracownicy wklejający do chatbota wydają się trzema oddzielnymi problemami, więc firmy kupują trzy oddzielne narzędzia i kończą z trzema zestawami luk między nimi. Złe rzeczy żyją w tych lukach. Wszystko, co robi AI, niezależnie od tego, skąd pochodzi, powinno przejść przez tę samą bramkę. Jedna bramka dla agentów, API i pracowników — to zmniejsza powierzchnię ataku i eliminuje luki między systemami.

Zachowaj dziennik, który AI nie może przepisać

Jeśli system, który robi coś, jest również jedynym systemem, który rejestruje, że to zrobił, nie masz rekordu. Masz dziennik, który pozwala mu edytować. Wymóg dotyczący prowadzenia dziennika w rozporządzeniu AI UE (artykuł 12) istnieje, aby to, co zrobił system o wysokim ryzyku, mogło być odtworzone przez kogoś innego niż system. W praktyce oznacza to dziennik prowadzony poza rzeczą, która jest rejestrowana — jeden, który nie może być cicho zmieniony po fakcie.

Umieść człowieka na wielkich, nieodwracalnych połączeniach

Nie wszystko — ludzie utoną w zatwierdzeniach, aż wszystko zaakceptują. Ale połączenia, których nie można cofnąć (przenosząc pieniądze, eksportując dane, kasując rekordy), powinny zatrzymać się i czekać. Rozporządzenie AI UE już nakazuje nadzór ludzki dla systemów o wysokim ryzyku (artykuł 14). Chwyt, który warto pamiętać: nadzór ma znaczenie tylko wtedy, gdy osoba ma czas i kontekst, aby naprawdę powiedzieć nie. Zatwierdzenie, które nikt nie czyta, to tylko teatr.

Co to oznacza dla małej firmy

Żaden z tych trzech ślepych punktów nie jest przypadkiem. Są to zwykły sposób, w jaki większość firm używa AI teraz — cicho, bez sieci bezpieczeństwa. Zespoły, które przetrwają przez następne kilka lat bez brzydkiego incydentu, nie będą tymi z najładniejszymi wykresami. Będą tymi, które zdecydują się wcześnie, że wszystko, co robi ich AI — agent, wywołanie API, wklejony akapit — przechodzi przez jedną bramkę zanim się wydarzy, a nie potem.

Jeśli chcesz szybki test swojego ustawienia, odpowiedz szczerze na dwa pytania: Z tych trzech powierzchni (agenty, API, pracownicy), ile możesz naprawdę zobaczyć? A z tych, które możesz zobaczyć, ile możesz powstrzymać? Dla wielu firm szczera odpowiedź na to drugie pytanie to zero. To jest liczba, którą trzeba najpierw naprawić.

Najczęstsze pytania

Jak kontrolować AI w małej firmie bez dużych nakładów?

Zamiast kupować osobne narzędzia dla agentów, API i pracowników, wdrożyć jedną bramkę, przez którą przechodzą wszystkie akcje AI. Dodać dziennik niezależny od systemu i człowieka na operacjach nieodwracalnych (transfer pieniędzy, usunięcie danych). To podstawa, którą można rozbudowywać.

Jakie są najczęstsze wyciek danych przez AI w firmach?

Pracownicy wklejają poufne dane do ChatGPT z osobistych kont — Samsung miał taki wyciek kodu źródłowego trzy razy w miesiąc. Zwykłe API w kodzie wysyłające dane klientów do modeli trzeciej strony bez kontroli. Autonomiczne agenty z dostępem do baz danych i płatności, które wykonują akcje bez zatwierdzenia człowieka.

Czy logging (rejestrowanie) akcji AI wystarczy do bezpieczeństwa?

Nie. Logging to tylko raport strat — mówi ci, co się stało wczoraj. Rzeczywisty nadzór to zatrzymanie akcji przed jej wykonaniem, aby człowiek mógł ją przejrzeć. Jeśli system rejestrujący może być zmieniony przez ten sam system, który rejestruje, nie masz bezpiecznego dziennika.

Czy mała firma musi się martwić autonomicznymi agentami AI?

Tak, ale przede wszystkim martwić się trzeba zwykłymi wywołaniami API w kodzie — większość AI w produkcji to proste żądania HTTP zakopane w usługach, które nikt nie kontroluje. Agenty to bardziej widoczny problem, ale drugie ślepe miejsce jest bardziej rozpowszechnione i niedostrzegane.

Co mówi rozporządzenie AI UE o nadzorze?

Artykuł 12 wymaga dziennika dla systemów wysokiego ryzyka, prowadzonego poza systemem, który jest rejestrowany. Artykuł 14 nakazuje nadzór człowieka dla systemów wysokiego ryzyka — ale tylko wtedy, gdy osoba ma czas i kontekst, aby naprawdę powiedzieć nie.

Na podstawie: Unite.AI. Tekst opracowany redakcyjnie.