OpenAI for Healthcare: GPT-5.2 i dane medyczne

8 stycznia 2026 roku OpenAI zaprezentowało OpenAI for Healthcare: ChatGPT for Healthcare oraz ofertę API przeznaczoną do systemów medycznych. Produkty oparto na rodzinie GPT-5.2, a wśród zastosowań wymieniono syntezę dokumentacji, koordynację opieki, wypisy, dokumentację ambient i umawianie wizyt. Najważniejszą zmianą nie był sam model, lecz warstwa kontroli: role, SAML SSO, SCIM, logi audytowe, opcjonalne klucze szyfrujące klienta i możliwość zawarcia Business Associate Agreement.

BAA nie oznacza automatycznej zgodności z HIPAA. OpenAI udostępnia ją uprawnionym klientom, aby wspierać zgodne użycie. Organizacja medyczna nadal musi zdefiniować cel przetwarzania, minimalizować PHI, ograniczyć użytkowników, ocenić dostawców i monitorować realne przepływy. Dla podmiotu w Polsce dochodzą RODO, tajemnica medyczna i lokalne wymagania dokumentacyjne; amerykański termin „HIPAA-ready” nie zastępuje europejskiej analizy prawnej.

Co OpenAI podało o jakości

Firma poinformowała, że przez dwa lata ponad 260 licencjonowanych lekarzy z 60 państw oceniło ponad 600 tys. odpowiedzi w 30 obszarach. Produkt przeszedł red teaming prowadzony przez lekarzy, a odpowiedzi mogą pobierać dowody z publikacji i wytycznych z tytułem, czasopismem oraz datą. To wartościowe mechanizmy, ale liczby są raportem producenta. Benchmark nie jest odsetkiem bezbłędnych diagnoz i nie dowodzi bezpieczeństwa każdego lokalnego workflow.

Najbezpieczniejsze wdrożenia zaczynają od zadań, które człowiek łatwo zweryfikuje: redagowanie listu, streszczenie z odsyłaczami, przystępniejsza instrukcja dla pacjenta. Znacznie wyższe ryzyko ma autonomiczne ustalanie terapii, dawkowania lub triage bez zatwierdzenia klinicysty.

Architektura danych medycznych

Przed produkcją trzeba rozrysować, gdzie pojawia się PHI: prompt, plik, narzędzie retrieval, log aplikacji, ślad debugowania i system analityczny. Wyłączenie treningu na treści nie oznacza braku przechowywania lub kopii operacyjnych. Retencję, rezydencję i usuwanie należy potwierdzić kontraktowo oraz testem.

Minimalny model bezpieczeństwa obejmuje:

• osobny workspace medyczny i role zgodne z obowiązkami,
• DLP przed wysłaniem treści oraz po otrzymaniu odpowiedzi,
• szyfrowanie i klucze zarządzane przez organizację tam, gdzie wymagane,
• log audytowy bez nadmiarowego PHI,
• ewaluację na lokalnych przypadkach i procedurach,
• obowiązkową akceptację człowieka dla decyzji klinicznych.

Prompt injection może wejść przez dokument pacjenta lub źródło RAG. Model nie powinien samodzielnie wykonywać zmian w EHR tylko dlatego, że tekst poprosił o użycie narzędzia. Rozdziel odczyt od zapisu, stosuj allowlistę funkcji i ponowne potwierdzenie przy działaniach wrażliwych. Szerzej opisujemy to w przewodniku bezpiecznego chatbota AI.

OpenAI for Healthcare obniża barierę organizacyjną, ale nie zmienia podstawowej zasady: model jest systemem wspomagającym, a nie źródłem prawdy. BreachRoad może przeprowadzić threat modeling, test RAG i kontrolę dostępu przed uruchomieniem.

Ewaluacja lokalna zamiast wiary w wynik ogólny

Zbuduj zbiór przypadków odpowiadający specjalizacjom, językowi i procedurom placówki. Każdy przykład powinien mieć oczekiwane zachowanie, niedopuszczalne ryzyko i rubricę ocenianą przez klinicystę. Osobno mierz poprawność faktów, jakość cytowania, ujawnianie niepewności, zgodność z lokalną ścieżką i czytelność dla pacjenta.

Test musi zawierać niepełną dokumentację, sprzeczne wyniki, leki o podobnych nazwach, jednostki i wartości graniczne. Sprawdź, czy system prosi o brakujące dane zamiast pewnie zgadywać. Porównuj wersje modelu przed wdrożeniem, ponieważ upgrade może poprawić średni wynik, a pogorszyć jeden krytyczny workflow.

Kontrola cytowań i aktualności wiedzy

Cytowanie nie gwarantuje, że źródło wspiera zdanie. Warstwa retrieval powinna przechowywać identyfikator dokumentu, wersję wytycznej, fragment użyty do odpowiedzi i datę dostępu. Wycofana procedura musi zniknąć z indeksu, a odpowiedź powinna preferować politykę instytucji przed ogólnym materiałem, o ile nie ma konfliktu wymagającego eskalacji.

Klinicysta potrzebuje szybkiego podglądu oryginalnego akapitu, nie tylko wygenerowanego streszczenia. W przypadku braku dowodu model powinien to powiedzieć, a aplikacja zablokować automatyczne wprowadzenie treści do dokumentacji.

Scenariusz incydentu AI w placówce

Plan powinien obejmować wyciek PHI, błędną odpowiedź powtarzaną wielu pacjentom, zatrute źródło RAG i przejęty token integracji. Zdefiniuj możliwość natychmiastowego odłączenia narzędzia bez zatrzymania opieki, zachowania trace bez niepotrzebnego powielania PHI oraz powiadomienia właściciela klinicznego.

Czy lekarz zatwierdzający odpowiedź zdejmuje ryzyko? Nie. Automation bias może zmienić pobieżną akceptację w formalność. Interfejs powinien wymuszać pokazanie źródeł i zmian, a KPI nie może nagradzać wyłącznie szybkości.

Kryterium gotowości do produkcji

Wdrożenie jest gotowe dopiero wtedy, gdy ma właściciela klinicznego i technicznego, zatwierdzony zakres, lokalną ewaluację, BAA lub właściwą podstawę umowną, kontrolę PHI oraz plan wycofania. Pilotaż powinien działać w trybie sugestii, bez autonomicznego zapisu. Przejście do szerszego użycia wymaga mierzalnego spadku obciążenia bez wzrostu błędów i incydentów.

---

Źródła pierwotne: OpenAI — Introducing OpenAI for Healthcare, HHS — HIPAA Security Rule.