Manager przychodni otwiera raport z małego programu napisanego z pomocą AI (sztucznej inteligencji): plik się wczytał, liczba wizyt jest na ekranie, żaden komunikat nie sygnalizuje problemu. Przed przyjęciem raportu trzeba jednak porównać wynik z samodzielnie ustaloną liczbą i sprawdzić ponowne wczytanie tego samego pliku; jeden fikcyjny przykład pokaże, jak trzy wizyty mogą zmienić się w sześć.

Tekst jest dla managera polskiej placówki, który ma użyć takiego zestawienia do decyzji administracyjnej, oraz osoby opiekującej się programem. AI pomogła napisać kod, czyli instrukcje wykonywane przez program. Samo późniejsze zliczanie wizyt może już odbywać się bez udziału modelu AI. Podział pracy jest prosty: manager ustala, co liczba ma oznaczać, a opiekun techniczny sprawdza, czy program liczy zgodnie z tym ustaleniem.

Cztery wiersze i trzy wizyty: przykład modelowy

Przykład modelowy — przychodnia, plik i przebieg próby poniżej są wymyślone przez redakcję. Liczby ilustrują błąd zliczania, nie opisują rzeczywistego wdrożenia ani częstości błędów programów tworzonych z AI. Wiersze nie pochodzą z dokumentacji pacjentów.

Przychodnia chce wiedzieć, ile wizyt odbyło się w wybranym miesiącu. Opiekun programu przygotowuje osobną wersję próbną, bez połączenia z systemem placówki, i wpisuje do pliku cztery fikcyjne wiersze. Każdy oznacza inną wizytę, wszystkie należą do tego samego miesiąca. Numer rozpoznaje wizytę, a nie pacjenta. Na potrzeby tego raportu manager przyjmuje, że odwołanych wizyt nie wliczamy.

Najpierw policz w poniższej tabeli pozycje ze statusem „odbyta”. Ten wynik zapisz przed uruchomieniem programu i porównuj z każdym kolejnym odczytem; ostatnia kolumna pokazuje przyjętą regułę.

Numer wizytyStatus w plikuWliczamy do raportu?
W01odbytatak
W02odbytatak
W03odwołananie
W04odbytatak

Oczekiwany wynik to 3 odbyte wizyty. Po pierwszym wczytaniu program pokazuje 3. Gdyby próba skończyła się w tym miejscu, manager zobaczyłby zgodność między własnym rachunkiem a ekranem. Nie wiedziałby jeszcze, co się stanie, gdy ktoś ponownie wybierze ten sam plik.

Do tej próby wystarczą ręcznie wymyślone wiersze. Nie potrzeba nazwisk, opisów wizyt ani eksportu rzeczywistej dokumentacji do narzędzia AI. Szersze zasady przygotowania takich prób opisujemy w tekście o tworzeniu syntetycznych danych do testów w placówce.

Ponowne wczytanie pliku podwaja wynik

Opiekun techniczny ponownie wczytuje dokładnie ten sam plik, nie zmieniając numerów ani statusów. W naszym przykładzie program dopisuje jego zawartość do wcześniej zapisanej listy. Ponieważ przy liczeniu nadal pomija wizytę odwołaną, dodaje trzy do wcześniejszych trzech. Na ekranie pojawia się 6. Program nie przerywa pracy: wykonał instrukcję dopisywania, ale naruszył zasadę liczenia jednej wizyty tylko raz.

Dla tego konkretnego raportu wynik po powtórnym wczytaniu powinien nadal wynosić 3. Drugi odczyt nie oznacza, że odbyły się trzy nowe wizyty. To rozbieżność, którą można wskazać bez zaglądania do kodu: manager zna wejście i oczekiwany rachunek. Sześć jest podstawą do wstrzymania raportu, nawet jeśli ekran wygląda poprawnie.

Osoba naprawiająca program ma odtworzyć problem i ustalić, jak rozpoznaje on wcześniej wczytaną wizytę. W tym przykładzie służy do tego jej stały numer. Poprawione zachowanie może polegać na pominięciu niezmienionych, już zapisanych wierszy albo na odmowie ponownego wczytania pliku z czytelnym komunikatem. W obu wariantach raport zachowuje trzy wizyty, a użytkownik dowiaduje się, co program zrobił.

Nie wystarczy podzielić błędnego wyniku przez dwa. Taki zabieg zamaskuje akurat tę próbę, lecz nie wyjaśni, które pozycje dopisano i ile razy. Równie mylące byłoby sprawdzenie poprawki wyłącznie na pustej liście: pierwsze wczytanie działało przecież prawidłowo także przed naprawą. Trzeba powtórzyć całą sekwencję, od pustej wersji próbnej przez pierwsze wczytanie aż po drugie.

Manager ustala, co ma oznaczać liczba wizyt

Błąd programu da się wykazać dlatego, że wcześniej uzgodniliśmy znaczenie licznika. W przykładzie liczymy odbyte wizyty, każdą tylko raz. Nie liczymy wszystkich rezerwacji ani liczby osób. Dwie odrębne wizyty tej samej osoby pozostają dwiema wizytami; usuwanie powtórzeń na podstawie samego pacjenta zmieniłoby sens raportu.

Manager powinien ustalić z opiekunem programu, który numer w używanym pliku trwale rozpoznaje tę samą wizytę. Numer wiersza nie musi spełniać tej roli: po innym sortowaniu wizyta może znaleźć się wyżej lub niżej. Jeśli nie wiadomo, jak rozpoznać tę samą wizytę przy kolejnym wczytaniu, nie da się jeszcze potwierdzić poprawności takiego sposobu łączenia plików.

W krótkiej notatce, wystarczy zapisać okres raportu, uwzględniane statusy i zasadę jednokrotnego liczenia wizyty. To manager potwierdza, że te ustalenia odpowiadają pytaniu placówki. Technik może poprawnie policzyć wszystkie rezerwacje, a mimo to dostarczyć złą odpowiedź, jeśli pytanie dotyczyło wizyt odbytych.

Ta próba dotyczy niezmienionego pliku. Gdy późniejszy plik poprawia status istniejącej wizyty, pojawia się osobne pytanie: czy nowy wpis ma zastąpić stary i który status jest aktualny. Wynik 3 po dwukrotnym odczycie nie potwierdza, że program obsługuje również takie korekty. Przed użyciem funkcji aktualizacji trzeba uzgodnić i sprawdzić jej własną regułę.

Opiekun programu sprawdza więcej niż uruchomienie

Problem pozornie działającego kodu pojawił się w rozmowie MobiHealthNews z Aronem Szanto, opublikowanej 4 września 2026 r. Szanto, szef technologii Redesign Health, opisuje trudne do zauważenia błędy kodu tworzonego z AI i przedstawia Argus, narzędzie do jego przeglądu. To wypowiedź przedstawiciela firmy rozwijającej rozwiązanie, nie niezależny test jego skuteczności. Nie wynika z niej, że kontrola przez kolejną AI wykryje każdy błąd. Nasz przypadek wizyt jest autorskim przykładem i nie pochodzi z tego wywiadu.

Opiekun techniczny potrzebuje zarówno przeglądu instrukcji programu, jak i prób jego działania. Starszy dokument NIST SP 800-218, wydany w lutym 2022 r. przez amerykański instytut normalizacji i technologii, opisuje praktyki ograniczania podatności oprogramowania, czyli słabości, które mogą umożliwić atak na program. Stanowi tu tło kontroli technicznej, a nie polski obowiązek ani instrukcję liczenia wizyt. Poprawności naszej liczby nie rozstrzyga powołanie się na standard, lecz porównanie z ustalonym wynikiem.

Przy zgłoszeniu błędu opiekun zachowuje fikcyjny plik, oczekiwane 3, uzyskane 6 oraz oznaczenie wersji programu, na której wystąpił problem. Po naprawie powtarza próbę i zapisuje nowy wynik. Dzięki temu wiadomo, czy sprawdzono poprawioną wersję, czy tylko usłyszano zapewnienie, że błąd usunięto.

Jedna udana próba ma wąski zakres. Potwierdza zachowanie na tych czterech wierszach i przy takim ponownym wczytaniu. Nie dowodzi poprawności wszystkich miesięcy, kompletności danych ani bezpieczeństwa całego programu. Gdy placówka chce użyć innych statusów lub zmienić sposób łączenia plików, opiekun musi sprawdzić także te sytuacje.

Kiedy manager może przyjąć raport wizyt

Pierwszy krok to umówienie krótkiego sprawdzenia z osobą, która opiekuje się programem, i zapisanie oczekiwanego rachunku przed pokazaniem wyniku aplikacji. W opisanej próbie manager potwierdza trzy odbyte wizyty, a technik wykonuje oba wczytania na fikcyjnym pliku. Same ustalenia na spotkniu nie zastępują sprawdzenia poprawionej wersji.

Jeżeli po drugim wczytaniu nadal jest 6 albo nie można wyjaśnić różnicy, manager wstrzymuje użycie raportu i przekazuje błąd do poprawy. Nie przepisuje ręcznie trójki na ekranie i nie uznaje, że skoro różnica jest znana, można już korzystać z programu. Jeżeli nie ma osoby zdolnej wyjaśnić i poprawić jego działanie, zestawienie pozostaje nieprzyjęte.

Gdy poprawiona wersja utrzymuje 3 po obu odczytach, można uznać tę próbę za zaliczoną. Przed przyjęciem rzeczywistego raportu manager musi jeszcze potwierdzić, że obejmuje on właściwy okres, właściwe statusy oraz komplet wizyt z uzgodnionego źródła. Opiekun techniczny przelicza raport poprawioną wersją i wyjaśnia różnice względem poprzedniego zestawienia. Dopiero zgodność rachunku i znaczenia raportu pozwala wykorzystać go do zaplanowanej decyzji administracyjnej; test fikcyjnego pliku sam w sobie nie zatwierdza rzeczywistych liczb.

Źródła