Polski lekarz rodzinny używa dziś ChatGPT, by szybciej notować wywiad z pacjentem. Pod każdą odpowiedzią dostaje jednak ten sam dopisek: to nie jest porada medyczna, skonsultuj się ze specjalistą. Tymczasem od połowy 2025 roku Google ma w bibliotece otwartych modeli MedGemmę. Równolegle niezależna grupa badawcza utrzymuje BioMistral, otwarty model oparty na Mistral 7B i dostrojony na danych biomedycznych. Mimo to żaden duży dostawca AI nie sprzedaje dziś publicznego API z etykietą “medyczny LLM”. Ta luka nie wzięła się z braku technicznych możliwości. Big Tech omija ją świadomie. Przecięcie regulacji, odpowiedzialności prawnej i ryzyka reputacji robi z medycznego API biznes zupełnie inny niż konsumencki chatbot. Polskie startupy zdrowotne stoją z kolei przed nieprzyjemnym wyborem. Albo same wezmą na siebie obowiązki dostawcy wyrobu medycznego, albo będą wkleinać symptomy do ogólnego modelu i udawać, że disclaimer wystarcza.
Modele istnieją – publicznego API nie ma
Trzeba zacząć od czystego stanu rynku, bo wokół tematu narosły mity, jakoby medyczne LLM były ciągle “dopiero w badaniach”. Tak nie jest. MedGemma jest publikowana co najmniej w wariantach 4B multimodalnym oraz 27B tekstowym, a Google rozwija też 27B multimodalny – całość dostrojona do tekstów medycznych, raportów obrazowania i notatek klinicznych. BioMistral, pochodzący od niezależnych autorów oparty na Mistral 7B i trenowany na PubMed Central, wyciąga lepsze wyniki niż ogólny Mistral w zadaniach biomedycznych. Open BioLLM od Saamy oferuje natomiast warianty oparte na Llamie z naciskiem na artykuły z PubMed. Wszystkie te modele są publicznie dostępne jako wagi, co oznacza, że firma chętna do ich uruchomienia może to zrobić we własnej infrastrukturze.
Z perspektywy dewelopera różnica jest jednak fundamentalna. Wagi modelu to surowiec, nie produkt. Aby zaoferować je klientowi, trzeba samodzielnie postawić infrastrukturę inferencji, opracować politykę bezpieczeństwa, zarządzanie danymi osobowymi i ograniczenia treści. Big Tech zwykle zdejmuje z klienta to wszystko jednym wpisem do faktury. Tu natomiast wprost odmawia. Ani Anthropic, ani OpenAI nie mają modelu z etykietą “medyczny”, a Google publikuje MedGemmę jako otwarte wagi, ale nie udostępnia jej w Vertex AI z gwarancją medyczną. Cel komunikatu jest jednoznaczny. Firma chce, byś rozumiał, że odpowiedzialność za wdrożenie zostaje po Twojej stronie.
Trzy powody, dla których Big Tech tego nie tknie
Argument za otwarciem medycznego API jest pozornie nieodparty. Rynek opieki zdrowotnej to natomiast wielokrotność rynku konsumenckiego AI, polski sektor zdrowia konsumuje rocznie ponad dwieście miliardów złotych, a nieefektywności w dokumentacji są pożywką dla narzędzi automatyzujących pracę. Dlaczego więc dostawcy zostawiają to startupom? Powody są trzy i wszystkie idą w tym samym kierunku.
Regulacje uderzają w sam fundament modelu cenowego
Najpoważniejszy ciężar idzie po linii klasyfikacji regulacyjnej. W Unii Europejskiej wyrób medyczny opisany jest jako produkt służący do diagnostyki, monitorowania albo terapii. Software jako wyrób medyczny (SaMD) musi przejść certyfikację zgodnie z rozporządzeniem MDR. To proces, w którym dostawca musi udowodnić, że jego produkt jest klinicznie skuteczny i bezpieczny. Dodatkowo AI Act, czyli unijne rozporządzenie o sztucznej inteligencji, klasyfikuje narzędzia medyczne jako wysokiego ryzyka. Pisaliśmy o szerszych konsekwencjach przy interpretacji AI Act dla agentów AI w Brukseli. W efekcie Big Tech, który zarabia w modelu “weź API i zapłać za tokeny”, musiałby tu wziąć na siebie obowiązki notyfikowanej procedury, dokumentacji klinicznej i nadzoru rynkowego. To zupełnie inny rachunek niż abonament za chatbota.
Odpowiedzialność prawna nie ma sufitu
Tuż obok regulacji stoi klasyczna ekspozycja odpowiedzialności. Jeśli model w ogólnym chatbotcie się pomyli, użytkownik traci czas i ewentualnie zaufanie. Jeśli model w medycznym API podpowie złą dawkę leku, konsekwencje są wymierne w ludzkim zdrowiu i w wielomilionowych pozwach. Anglosaski system orzecznictwa od dawna toleruje wysokie odszkodowania za błędy medyczne. W Polsce system jest natomiast bardziej rygorystyczny niż polski lekarz zwykle podejrzewa. Z tego powodu duzi dostawcy chłodno kalkulują, że jedna głośna wpadka z publicznego API zniweczy zyski z całego segmentu na lata.
Strach przed wpadką PR jest nie mniej dotkliwy
Na koniec tej sekwencji siedzi reputacja. Każde duże laboratorium pamięta historię wpadek z wcześniejszych eksperymentów medycznych. Watson Health od IBM zakończył się sprzedażą biznesu po latach niespełnionych obietnic. Babylon Health zwijał operację w Wielkiej Brytanii po pytaniach o skuteczność i sposób księgowania. W tle wisi też debata o moderacji AI, w której nadgorliwe modele odsyłają do specjalisty nawet przy pytaniu o zdrowie psychiczne. Każda firma rozważająca otwarcie medycznego API ma przed oczami nie tyle szansę, ile pamięć kolejnej okładki w poniedziałek rano.
Kto próbuje wypełnić tę lukę
Skoro Big Tech się nie pcha, lukę próbują wykorzystać startupy specjalistyczne. Hippocratic AI z Doliny Krzemowej buduje rozmówców medycznych z naciskiem na zadania niediagnostyczne. Chodzi tu o przygotowanie pacjenta do zabiegu albo wsparcie po wypisie ze szpitala. Firma deklaruje wprost, że jej agenci nie diagnozują ani nie przepisują leków. K Health łączy LLM z ludzkimi lekarzami w modelu, w którym ostateczna decyzja zawsze leży po stronie człowieka. Suki AI dostarcza natomiast skrypty medyczne dla amerykańskich lekarzy, pracując bardziej na warstwie dokumentacji niż diagnostyki. Łączy je jedna rzecz. Każda z tych firm wzięła na siebie obowiązki, których Big Tech nie chciał ruszyć. W zależności od zastosowania muszą mierzyć się z HIPAA w Stanach albo RODO w Europie, walidacją kliniczną i ewentualną kwalifikacją do SaMD, a na pytania regulatorów są przygotowane.
W Europie podobną drogę wybierają konkretne startupy zdrowotne. Doctolib we Francji idzie w automatyzację dokumentacji pacjenta. Infermedica z Polski rozwija od lat silnik triage objawowego, dziś już z komponentami LLM. Telemedi i DocPlanner pracują z kolei nad warstwą obsługi pacjenta. Wszystkie zwracają jednak uwagę na ten sam paradoks. Stoją w kolejce po regulacyjną certyfikację, którą dostawca API mógłby zdjąć z ich barków za rozsądną opłatą. Tymczasem dostają od Big Techu tylko surowy model językowy i wiadomość, że dalej radzą sobie sami.
Polski medtech bez gotowego narzędzia
Dla polskiego sektora zdrowia ten brak ma konsekwencje praktyczne. Najpierw szpitale wojewódzkie, kliniki prywatne i sieć przychodni POZ nie mogą po prostu wpiąć w swój system jednego API od Anthropic, OpenAI albo Google z gwarancją zgodności medycznej. Każdy projekt AI w tej branży staje się natomiast indywidualnym przedsięwzięciem regulacyjnym, w którym uczestniczą Urząd Ochrony Danych Osobowych, Centrum e-Zdrowia, prawnicy specjalizujący się w MDR i dostawca infrastruktury IT. Z tego powodu nawet relatywnie proste wdrożenie, takie jak asystent notujący wywiad z pacjentem, ciągnie za sobą koszty, których konsumenckie startupy nie znają.
Następnie sami lekarze pracujący w polskim systemie używają dziś ogólnych modeli na własny rachunek. To prywatne kanapowe rozwiązania, w których ChatGPT, Claude albo Gemini pomaga zredagować odpowiedź pacjentowi, podsumować artykuł albo rozważyć rzadką diagnostykę różnicową. Mimo dopisków o braku porady medycznej takie korzystanie rodzi pytania o zgodność z RODO, ponieważ symptomy konkretnego pacjenta wpadają do chmury dostawcy. W tle stoi rosnąca presja regulatora, która coraz mocniej idzie w stronę identyfikacji użytkownika i weryfikacji ryzykownych zastosowań. Pisaliśmy o tym wątku przy okazji wprowadzenia weryfikacji tożsamości w Claude przez Anthropic.
Na koniec polski medtech ma jednak realną szansę w tej luce. Ponieważ Big Tech nie schodzi na poziom certyfikowanego API, regionalni gracze z udokumentowaną znajomością systemu zdrowia mają tu przewagę. Startupy, które zrobią certyfikację wyrobu medycznego, dogadają się z NFZ i Centrum e-Zdrowia oraz zbudują integrację z polskim e-zdrowiem, mogą przez kilka lat operować w przestrzeni, której amerykańscy konkurenci po prostu nie obsługują. Identyczny scenariusz powtarza się dziś w temacie łatania bibliotek open source przez modele AI po stronie obrony. Big Tech otwiera segment ogólny, a specjaliści budują ofertę pod konkretną branżę.
Pierwsza Misja AI · Kodożercy
Rozumiesz zagrożenia AI, gdy rozumiesz jak naprawdę działa.
Kurs Pierwsza Misja AI ma dedykowaną lekcję o ciemnej stronie AI: halucynacje, deepfakes, manipulacja. Zanim zaczniesz się bać – zacznij rozumieć.
Poznaj pełny program →
Podsumowanie
Brak medycznego API u dużych dostawców nie jest dziurą w ofercie. To natomiast świadoma kalkulacja, w której regulacje, odpowiedzialność prawna i pamięć poprzednich wpadek przeważają nad pokusą nowego segmentu. Dla polskiego sektora zdrowia oznacza to dalsze życie w hybrydzie. Z jednej strony konsumencki LLM z dopiskiem o braku porady medycznej, z drugiej specjalistyczne narzędzia od startupów, które przyjęły na siebie ciężar certyfikacji. Polski medtech może w tej luce zbudować silną pozycję, ale tylko jeśli rozumie, że produkt zaczyna się od zgodności, a dopiero kończy na modelu. Big Tech ten porządek już sobie ułożył. Pytanie tylko, kto pierwszy z polskich graczy zrobi to samo.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
