Czy AI zastąpi admina i programistę? Kto odpowiada, gdy AI się pomyli

To artykuł do odcinka na kanale Praktycznie o informatyce. Tym razem bez komend i konfiguracji: to stanowisko praktyka, który utrzymuje serwery i codziennie korzysta z modeli językowych. Ten tekst też powstał z pomocą modelu, a podpisuję się pod nim ja. Modele zmieniają się co kilka miesięcy, więc traktuj to jako moje zdanie na dziś. W filmie zobaczysz źródła na ekranie, a tu masz wersję do czytania, z linkami i listą błędów, do której łatwo wrócić.

Raport przygotowany z AI: Katowice w „północnym centrum Polski”

Katowice leżą w północnym centrum Polski. Takie zdanie znalazło się w raporcie o wizerunku Polski, który od końca 2025 roku wisiał na stronie fundacji. Ten sam raport pisał o „zaledwie pięciorgu” polskich noblistach, choć jest ich co najmniej siedmioro. A przypisy po numerze 3 przeskakiwały do 41 i 517.

Autorka przyznała, że przy raporcie korzystała z AI. Kiedy sprawa wybuchła w sierpniu 2026 roku, była już pełnomocniczką rządu do spraw promocji marki Polska. Po niecałym miesiącu na stanowisku podała się do dymisji.

Model językowy nie stracił stanowiska i nie musiał tłumaczyć się w telewizji. Odpowiedzialność poniósł człowiek, który się pod tekstem podpisał. Uważam, że to dziś najważniejsze zdanie w całej dyskusji o tym, czy AI zastąpi informatyków.

Nie oceniam autorki i nie dokładam się do hejtu, który ją spotkał. Pokazuję mechanizm, bo dotyczy każdego, kto wkleja do swojej pracy to, co wygenerował model: do raportu, do kodu albo do konfiguracji serwera.

W czym AI jest lepsze od administratora i programisty

Zacznę od tego, w czym z tezą „AI zastąpi informatyków” się zgadzam. Zgadzam się z większą jej częścią, niż można by się spodziewać po kimś, kto żyje z administracji serwerami. Z modeli korzystam codziennie i widzę nad sobą trzy ich przewagi.

Szybkość. Model w kilka sekund przegląda plik konfiguracyjny, który ja czytałbym kwadrans. Tak samo z logiem na kilka tysięcy linii albo z cudzym skryptem bez komentarzy.

Cierpliwość. Model nie jest zmęczony o drugiej w nocy i nie pomija linijki dlatego, że już mu się nie chce. Dziesiąty raz czyta tak samo uważnie jak pierwszy.

Szerokość wiedzy. Model zna składnię języków i narzędzi, po które ja sięgam raz w roku. Nie muszę pamiętać każdego przełącznika, wystarczy, że rozumiem, co robi polecenie, które dostałem.

Człowiekowi rzeczy umykają. Modelowi umykają rzadziej. Z tym nie ma co dyskutować, a najlepszy dowód przyszedł w październiku 2026 roku.

PHP2Shell: błąd, który przeleżał w PHP około 14 lat

21 października 2026 roku twórcy PHP wydali awaryjne poprawki dwóch krytycznych błędów, CVE-2026-109618 i CVE-2026-109619, nazwanych PHP2Shell. Poprawione wersje to 8.2.35, 8.3.36, 8.4.27 i 8.5.12, a szczegóły są w liście zmian PHP 8. Gałęzie bez wsparcia, czyli 8.1 i starsze, oficjalnych poprawek nie dostały.

PHP to język, w którym działa ogromna część stron internetowych, między innymi WordPress. Ten błąd nie siedział w żadnej konkretnej stronie, tylko w samym silniku języka. Podatna była więc nawet strona, która wyświetla jedynie napis „Hello World”.

Błąd siedział w PHP od wersji 5.4 z 2012 roku, czyli około 14 lat. Przez ten czas kod czytali doświadczeni programiści z całego świata i nikt go nie zauważył. Badacze, którzy w końcu go znaleźli, w tym zespół Wiz Research, pracowali z pomocą modeli AI.

W szukaniu błędów AI bywa więc lepsze od ludzi i nie mam z tym problemu. Ciekawsze jest to, co działo się po publikacji poprawek.

Kto wstaje w nocy: exploit w dniu wydania poprawki

W Holandii i Finlandii zapobiegawczo wyłączono część rządowych stron. Zrobiono to, zanim ktokolwiek się włamał. W Australii na jakiś czas zniknęła nawet strona rządowej agencji od cyberbezpieczeństwa.

Takiej decyzji nie podejmuje model. Podejmuje ją człowiek, który wie, że jutro będzie się z niej tłumaczył. Albo z tego, że wyłączył strony urzędów, albo z tego, że ich nie wyłączył.

Dlaczego tak szybko? Bo dziś nie wolno bagatelizować żadnej podatności. Kiedyś exploit, czyli program wykorzystujący taką dziurę, umiała napisać garstka specjalistów. Dziś model językowy pomaga porównać poprawkę ze starym kodem i zobaczyć, co producent załatał. A skoro wiadomo, co załatano, wiadomo też, gdzie była dziura. Model pomoże w tym także komuś, kto sam by tego nie potrafił.

Przy PHP2Shell pierwsze exploity krążyły już w dniu wydania poprawek, a kilka dni później potwierdzono ataki w praktyce. To samo narzędzie, które pomaga obrońcom szukać błędów, skraca drogę atakującym. Dlatego czas na reakcję liczy się dziś w godzinach, a nie w tygodniach.

I tu jest sedno. Model nie odbierze telefonu o trzeciej w nocy. Nie porozmawia z klientem, któremu wyciekły dane, i nie stanie przed zarządem, żeby wytłumaczyć, dlaczego tak się stało.

Zainstalowana poprawka to jeszcze nie załatany serwer

Tego samego dnia przeszedłem przez wszystkie serwery z PHP w utrzymywanej przeze mnie infrastrukturze. Znalazłem dwie rzeczy, których żaden automat by mi nie zgłosił.

Najpierw dwa słowa o tym, jak serwer się aktualizuje. Pobiera programy z repozytorium, czyli z czegoś w rodzaju sklepu z oprogramowaniem. Każda paczka ze sklepu ma podpis, a serwer sprawdza go kluczem, tak jak sprawdza się pieczątkę na dokumencie.

Mój własny błąd: repozytorium bez klucza. Na jednym z serwerów brakowało pliku z kluczem do jednego z repozytoriów. System uznawał to repozytorium za niezaufane i po cichu je pomijał. Byłem przekonany, że ten serwer aktualizuje PHP sam, a on od dawna tego nie robił.

Stary kod w pamięci. Na dwóch innych serwerach paczka z poprawką była zainstalowana, ale serwer stron dalej wykonywał stary kod. Stara wersja siedziała w pamięci aż do restartu. Na papierze wszystko było załatane.

Pokazuję ten błąd celowo, bo na błędach najlepiej się uczy. Po każdej krytycznej poprawce sprawdzam teraz trzy rzeczy.

Pierwsza: wynik odświeżenia listy pakietów. Na Debianie i Ubuntu ostrzeżenie z „NO_PUBKEY” albo „is not signed” po poleceniu apt update oznacza, że któreś repozytorium jest pomijane. Taki komunikat łatwo przeoczyć, bo aktualizacja i tak kończy się bez błędu.

Druga: restart usługi, która wykonuje PHP. Chodzi o PHP-FPM albo o serwer WWW z wbudowanym modułem PHP. Dopiero po restarcie do pamięci trafia nowy kod.

Trzecia: wersja na działającej stronie. Liczy się wersja PHP, którą zgłasza strona, a nie tylko wersja zainstalowanej paczki.

Na serwerach produkcyjnych miałem włączone automatyczne aktualizacje. Ale sam automat nie wystarczy, bo domyślnie nie obejmuje każdego repozytorium i nie zawsze restartuje to, co trzeba. Jak to ustawić, pokażę w osobnym odcinku, jeśli pod filmem zbierze się dość komentarzy z taką prośbą.

Łańcuch zaufania bez właściciela

Przy jednej stronie internetowej pracuje zwykle kilka osób. Programista ufa, że administrator dobrze zabezpieczył serwer. Administrator ufa, że programista napisał bezpieczny kod. Obaj ufają, że twórcy języka nie zostawili w nim dziury. Każdy robi najlepszą robotę, jaką potrafi, i każdy zakłada, że reszta też.

Nazywam to łańcuchem zaufania bez właściciela. Działa, dopóki nic się nie dzieje. Kiedy coś pęknie, wszyscy patrzą na siebie nawzajem, a klient pyta, kto za to odpowiada.

AI tego problemu nie stworzyło, ale go pogłębia. Coraz częściej na serwer trafia kod, którego w całości nie przeczytał nikt. Napisał go model, a człowiek go tylko wkleił. W łańcuchu pojawia się kolejne ogniwo, które niczego nie podpisuje.

Śluza: jak pracuję z AI bez dostępu SSH do serwerów

Pokażę, jak to wygląda u mnie. Nie mówię, że tak trzeba. Wielu administratorów robi inaczej i wpuszcza na serwery agentów AI, czyli modele, które nie tylko podpowiadają, ale same wpisują polecenia. To jest moje zdanie na dziś.

Najpierw jedno pojęcie. SSH to zdalny terminal, czyli klawiatura do serwera, która działa przez internet. U mnie obowiązują trzy zasady.

Pierwsza zasada: model nie ma klucza SSH do żadnego mojego serwera. Nie łączy się z nimi i nie wpisuje poleceń sam.

Druga zasada: każde polecenie od modelu wklejam na serwer ja. Wcześniej je czytam i sprawdzam, co zrobi. Wynik wklejam z powrotem i interpretuję go sam, na tyle, na ile pozwala mi czas.

Trzecia zasada: podejrzane pliki i logi analizuję na osobnej maszynie odłączonej od sieci. Ta maszyna nie ma kluczy do żadnego innego serwera.

Nazywam to śluzą. Trochę przypomina piaskownicę, czyli zamknięte miejsce, w którym model nie może nic zepsuć. Ale w śluzie jest jeszcze człowiek. Każde polecenie, które trafia na serwer, przechodzi przez moją głowę i moje ręce. Jest wolniej, ale jeśli coś padnie, wiem dokładnie, że to polecenie wpisałem ja.

Klient zadzwoni do mnie, nie do modelu. Dlatego to ja decyduję, co model może zrobić.

Air Canada: firma odpowiada za to, co powiedział jej chatbot

Sądy patrzą na to tak samo. W lutym 2024 roku sprawę rozstrzygał kanadyjski trybunał, Civil Resolution Tribunal z Kolumbii Brytyjskiej. Klient leciał na pogrzeb babci i zapytał chatbota linii Air Canada o zniżkę dla osób w żałobie. Chatbot odpowiedział, że bilet może kupić od razu, a o zniżkę wystąpić po podróży.

To była nieprawda, bo linia nie przyznawała tej zniżki po fakcie. Kiedy klient poprosił o zwrot, linia odmówiła i tłumaczyła, że za słowa chatbota nie odpowiada. Trybunał uznał, że odpowiada, i kazał jej oddać klientowi różnicę w cenie. Pełne orzeczenie to Moffatt v. Air Canada, 2024 BCCRT 149.

Chatbot jest tu tylko jednym z kanałów, przez które firma mówi do klienta, tak jak strona internetowa czy pracownik infolinii. To, że odpowiedź napisał model, niczego nie zmienia. Odpowiada ten, kto go postawił przed klientem.

Ustawa o KSC i NIS2: kierownik odpowiada osobiście

Podobną zasadę zapisano dziś w polskim prawie. Od 3 kwietnia 2026 roku obowiązuje znowelizowana ustawa z 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa, w skrócie KSC. Nowelizacja została opublikowana w Dz.U. 2026 poz. 252 i wdraża unijną dyrektywę NIS2.

Od razu uczciwie: ani NIS2, ani ustawa o KSC nie wymagają wprost, żeby to, co wygeneruje AI, sprawdzał ktoś bardziej doświadczony. Wymagają jednak dwóch rzeczy, które prowadzą w to samo miejsce.

Zarządzanie ryzykiem. Firma objęta ustawą musi wiedzieć, co dzieje się w jej systemach, i umieć to udowodnić. Kod albo konfiguracja, których nikt nie przeczytał, to ryzyko, którego nikt nie ocenił.

Osobista odpowiedzialność kierownika. Za cyberbezpieczeństwo odpowiada kierownik podmiotu, także wtedy, gdy te obowiązki powierzy komuś innemu (art. 8c). Kara może sięgnąć 300% jego wynagrodzenia, a w podmiocie publicznym 100% (art. 73a).

Przekazanie obowiązków człowiekowi kierownika nie zwalnia. Przekazanie ich modelowi tym bardziej. Ustawa nie pyta, czy błąd zrobił człowiek, czy model. Pyta, kto za to odpowiada, i zawsze wskazuje człowieka.

Zasada czterech oczu dla AI

Dlatego mam jedną propozycję. To nie jest przepis, tylko moja zasada: wszystko, co wygeneruje model, sprawdza ktoś bardziej doświadczony niż autor, zanim trafi na serwer, do klienta albo do publikacji. To zasada czterech oczu, znana od lat z banków i z wdrożeń. Dziś obejmuje także AI.

Ważne jest słowo „bardziej doświadczony”. Autor, który sprawdza sam siebie, widzi to, co chciał napisać, a nie to, co napisał. Model, który sprawdza model, nie bierze odpowiedzialności za żaden z wyników.

Raport, od którego zacząłem, wisiał w sieci przez wiele miesięcy. Wystarczyłby jeden uważny czytelnik przed publikacją.

Jeśli prowadzisz firmę, zadaj swojemu informatykowi jedno pytanie: kto u nas sprawdza to, co wygenerowało AI, zanim trafi na serwer albo do klienta? Jeśli odpowiedź brzmi „nikt”, odpowiedzialność i tak na kogoś spadnie. Najpewniej na ciebie.

Senior to nie ten, kto pisze najszybciej

Od seniorów zaczyna się cała ta dyskusja. Mit brzmi tak: senior to ktoś, kto pisze kod szybciej niż junior. Gdyby tak było, model rzeczywiście by go zastąpił, bo pisze szybciej od obu.

Ale senior nigdy nie był od szybkiego pisania. Senior patrzy na kod albo na konfigurację i widzi, co może pójść źle. I bierze to na siebie. Ta rola z AI nie znika, tylko rośnie, bo tekstu do sprawdzenia jest więcej niż kiedykolwiek.

Zostaje jedno pytanie, na które nie znam odpowiedzi. Senior uczył się, będąc juniorem. Popełniał błędy na małych rzeczach, zanim dostał duże. Jeśli firmy zamiast juniorów zatrudnią dziś model, to kto za dziesięć lat będzie seniorem, który ten model sprawdza?

Moje stanowisko w czterech punktach

Po pierwsze, model jest szybszy ode mnie i bywa dokładniejszy. Przy PHP2Shell pomógł znaleźć błąd, którego ludzie nie widzieli przez lata.

Po drugie, model nie bierze odpowiedzialności. Telefon w nocy, dymisja i kara z ustawy trafiają do człowieka.

Po trzecie, łańcuch zaufania potrzebuje właściciela. Ktoś musi wiedzieć, co trafiło na serwer i kto to sprawdził.

Po czwarte, sprawdza ktoś bardziej doświadczony niż autor. Bez względu na to, czy autorem jest człowiek, czy model.

Częste błędy i pułapki

Wklejanie kodu z modelu bez czytania. Kod działa, testy przechodzą, więc trafia na produkcję. Problem w tym, że nikt nie wie, co jeszcze robi. Przeczytaj każdą linijkę, zanim ją uruchomisz, a jeśli jej nie rozumiesz, poproś model o wyjaśnienie, zamiast wklejać dalej.

Agent AI z kluczem SSH i pełnymi uprawnieniami. Agent, który sam wpisuje polecenia, myli się tak samo pewnym tonem, jakim ma rację. Jeśli już go wpuszczasz, ogranicz mu uprawnienia i zapisuj każde polecenie, które wykonał. Ja wybrałem śluzę: model podpowiada, a polecenia wpisuję ja.

Uznanie, że zainstalowana paczka to załatany serwer. Serwer stron potrafi wykonywać stary kod z pamięci aż do restartu. Po krytycznej poprawce zrestartuj usługę, która wykonuje PHP, i sprawdź wersję na działającej stronie.

Ślepa wiara w automatyczne aktualizacje. Automat domyślnie nie obejmuje każdego repozytorium i nie zawsze restartuje to, co trzeba. Repozytorium bez klucza bywa po cichu pomijane, a aktualizacja i tak kończy się bez błędu. Przejrzyj ostrzeżenia po odświeżeniu listy pakietów.

Odkładanie krytycznej poprawki do okna serwisowego. Przy PHP2Shell exploity krążyły już w dniu wydania poprawek. Model pomaga atakującym zrozumieć poprawkę tak samo, jak pomaga obrońcom. Krytyczną dziurę łata się w godzinach, a nie przy najbliższej okazji.

Przekonanie, że przekazanie obowiązków zdejmuje odpowiedzialność. Ustawa o KSC mówi wprost, że kierownik odpowiada także wtedy, gdy powierzy obowiązki komuś innemu. Ani firma zewnętrzna, ani model nie przejmą tej odpowiedzialności.

Autor sprawdza sam siebie. Kto pisał tekst albo prosił model o kod, widzi to, co chciał uzyskać. Druga para oczu musi należeć do innej osoby, najlepiej bardziej doświadczonej niż autor.

Analiza podejrzanych plików na maszynie z kluczami do innych serwerów. Jeśli coś pójdzie źle, napastnik dostaje drogę dalej. Podejrzane pliki i logi analizuj na osobnej maszynie, odłączonej od sieci i bez kluczy do czegokolwiek.

FAQ — najczęściej zadawane pytania

Czy AI zastąpi programistów?

Moim zdaniem na dziś zastąpi część pisania kodu, ale nie zastąpi odpowiedzialności za ten kod. Model pisze szybciej od juniora i od seniora, tylko że senior nigdy nie był od szybkiego pisania. Jest od tego, żeby zobaczyć, co pójdzie źle, i wziąć to na siebie. Ta rola z AI rośnie, bo kodu do sprawdzenia jest więcej.

Czy AI zastąpi administratora serwerów?

Model świetnie czyta konfigurację, logi i podpowiada polecenia. Nie odbierze jednak telefonu o trzeciej w nocy, nie zdecyduje, czy wyłączyć stronę klienta, i nie wytłumaczy się przed zarządem. Przy PHP2Shell to ludzie decydowali, które serwery łatać od razu, a które wyłączyć.

Kto odpowiada, gdy AI się pomyli?

Człowiek, który podpisał się pod wynikiem, albo firma, która model udostępniła. Pokazują to dymisja po raporcie przygotowanym z pomocą AI i wyrok w sprawie Moffatt v. Air Canada z 2024 roku, w którym linia odpowiadała za obietnicę swojego chatbota.

Czy ustawa o KSC wymaga sprawdzania tego, co wygeneruje AI?

Nie wprost. Ustawa o krajowym systemie cyberbezpieczeństwa nie wspomina o weryfikacji wyników AI. Wymaga jednak zarządzania ryzykiem i czyni kierownika osobiście odpowiedzialnym za cyberbezpieczeństwo, także po powierzeniu obowiązków innym. Sprawdzanie wyników AI wynika więc z tych obowiązków, a nie z osobnego przepisu.

Jaka kara grozi kierownikowi według ustawy o KSC?

Według art. 73a znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa kara dla kierownika może sięgnąć 300% jego wynagrodzenia. W podmiocie publicznym górna granica to 100%. Przepisy obowiązują od 3 kwietnia 2026 roku.

Czy dawać agentowi AI dostęp SSH do serwera?

To decyzja każdego administratora i wielu z nich tak robi. Ja nie daję: model nie ma klucza SSH do żadnego mojego serwera, a każde jego polecenie czytam i wklejam sam. Jest wolniej, ale zawsze wiem, kto wpisał polecenie, które coś zepsuło.

Co to jest PHP2Shell i czy mój serwer jest podatny?

PHP2Shell to dwa krytyczne błędy w silniku PHP, CVE-2026-109618 i CVE-2026-109619, obecne od PHP 5.4. Poprawki wyszły 21 października 2026 roku w wersjach 8.2.35, 8.3.36, 8.4.27 i 8.5.12. Jeśli strona zgłasza starszą wersję, serwer jest podatny, nawet gdy nowa paczka jest już zainstalowana, ale usługa nie została zrestartowana.

Na czym polega zasada czterech oczu dla AI?

Wszystko, co wygeneruje model, sprawdza ktoś bardziej doświadczony niż autor, zanim trafi na serwer, do klienta albo do publikacji. To nie jest przepis, tylko moja propozycja, przeniesiona z banków i wdrożeń, gdzie działa od lat.

Czy warto dziś zaczynać w IT jako junior?

Na to pytanie nie znam odpowiedzi. Wiem tylko, że każdy senior uczył się na błędach jako junior. Jeśli firmy zamiast juniorów zatrudnią model, za dziesięć lat zabraknie ludzi, którzy będą umieli ten model sprawdzić.

Co dalej — film i kolejne odcinki

Całe stanowisko zobaczysz w odcinku na kanale: AI nie odbierze telefonu o trzeciej w nocy. Czy AI zastąpi admina i programistę? Są w nim źródła na ekranie, plansze z łańcuchem zaufania i trzema zasadami śluzy oraz pytanie dla właściciela firmy.

A jak ty pracujesz z AI? Dajesz mu dostęp do serwerów czy trzymasz je za śluzą? Napisz to w komentarzu pod filmem. Jeśli chcesz odcinek o tym, jak ustawić automatyczne aktualizacje, żeby naprawdę łatały także PHP, też napisz. Jeśli takich komentarzy będzie dużo, zrobię go na labie.

Wcześniejsze odcinki opisałem w artykułach o liście ostrzeżeń CERT na MikroTiku i o backupie SQL Servera na Proxmoxie. Kanał możesz wspierać na Patronite, już od 4 zł miesięcznie.

W następnym odcinku wracam do konsoli i do konkretów. Jeśli chcesz go zobaczyć, subskrybuj kanał Praktycznie o informatyce.