Klient zapytał, gdzie będą przechowywane dane pacjentów.
To było jedno z pierwszych spotkań przy nowym projekcie medycznym. System miał przetwarzać dokumentację kliniczną z pomocą AI — OCR, analiza, strukturyzacja danych. Brzmi jak coś, co można postawić na dowolnym cloudzie w trzy godziny.
Tylko że za tym pytaniem stało kilka innych. Kto ma dostęp do tych danych? Co się stanie, jeśli dojdzie do wycieku? Czy właściciel danych — placówka medyczna — rzeczywiście ma nad nimi kontrolę? I co z RODO przy przetwarzaniu danych osobowych przez zewnętrzny serwis AI?
To właśnie te pytania wyeliminowały większość popularnych podejść. I doprowadziły do decyzji, która na początku wydawała się technicznie trudniejsza: system musi działać lokalnie, bez wysyłania danych medycznych na zewnątrz.
Problem z chmurą w kontekście danych medycznych
Kiedy myślisz o AI jako usłudze — OpenAI, Azure AI, Google Cloud AI — domyślny model jest następujący: wysyłasz dane do API, dostajesz wynik. Szybkie, skalowalne, tanie w utrzymaniu.
W przypadku tekstu ogólnego to działa. W przypadku danych pacjentów — już nie, albo przynajmniej nie bez znacznego skomplikowania całej architektury.
Dane medyczne w Polsce podlegają RODO, ale też ustawie o prawach pacjenta i szeregowi wymagań dotyczących przetwarzania dokumentacji medycznej. Wysłanie danych pacjenta do zewnętrznego serwisu AI to w uproszczeniu powierzenie przetwarzania podmiotowi trzeciemu. Trzeba podpisać umowę powierzenia. Trzeba mieć pewność, że dane nie są używane do trenowania modeli. Trzeba wiedzieć, gdzie fizycznie są serwery. I tak dalej.
Można to zrobić. Część dużych dostawców oferuje odpowiednie umowy i certyfikacje. Ale małe i średnie placówki medyczne — a to jest najczęstszy klient takich systemów w Polsce — często tego nie przejdą. Albo nie mają zasobów prawnych do oceny ryzyka. Albo po prostu nie chcą, żeby dane pacjentów opuszczały ich serwery.
Co to znaczy edge w tym kontekście
Edge computing w uproszczeniu oznacza: przetwarzanie danych tam, gdzie dane powstają — zamiast wysyłania ich do centralnego serwera. W MedTech to znaczy najczęściej: serwer fizycznie w placówce lub przynajmniej w kontrolowanym środowisku klienta.
Model AI działa lokalnie. Dane pacjenta nie opuszczają sieci placówki. Wynik analizy pozostaje tam, gdzie dane — na serwerze klienta.
To zmienia kilka rzeczy naraz. Po pierwsze: placówka jest administratorem danych w pełnym znaczeniu tego słowa, bo dane nigdy nie wychodzą poza jej infrastrukturę. Po drugie: nawet jeśli zewnętrzny serwis AI zostanie zhakowany, danych klienta tam nie ma. Po trzecie: system działa niezależnie od dostępności zewnętrznych API — co ma znaczenie w środowisku klinicznym, gdzie ciągłość działania jest wymaganiem, nie opcją.
Ale lokalne AI to brzmi jak ogromny serwer
Tak myślą prawie wszyscy na początku. Lokalne AI kojarzy się z centrum danych, kartami GPU za sto tysięcy złotych i zespołem MLOps do utrzymania. W 2023 roku to by była prawda. Dziś — już niekoniecznie.
Pojawiła się klasa modeli, które nazywa się SLM — Small Language Models. Modele zoptymalizowane pod konkretne zadania, potrafiące działać na znacznie skromniejszym sprzęcie niż ich wielkie odpowiedniki. Do zadań takich jak OCR, klasyfikacja dokumentów, ekstrakcja strukturyzowanych danych z tekstu medycznego — sprawdzają się dobrze. Nie mają możliwości dużego GPT-4, ale też nie potrzebują jego zasobów obliczeniowych ani nie pociągają za sobą jego problemów z prywatnością danych.
Połącz to z konteneryzacją i nowoczesnym podejściem do infrastruktury, a nagle okazuje się, że system AI działający lokalnie — na normalnym serwerze w serwerowni klienta — jest realny i dostępny też dla mniejszych placówek.
Trudniejsza część: infrastruktura, nie model
W tym typie projektu najtrudniejszą częścią nie jest zwykle model AI. To infrastruktura wokół niego.
Serwer trzeba postawić, zabezpieczyć i utrzymać. Połączenie między systemem a aplikacją klienta musi być szyfrowane. Dostępy trzeba kontrolować. Monitoring musi działać — bo jeśli serwer pada o trzeciej w nocy, ktoś powinien o tym wiedzieć zanim pierwsza zmiana zacznie pracę. Backupy muszą być testowane, nie tylko robione. I cały system musi być udokumentowany tak, żeby po roku — kiedy pierwotny wdrożeniowiec jest już gdzie indziej — ktoś inny potrafił to ogarnąć.
To jest dług techniczny, który bardzo łatwo zaciągnąć w projektach MedTech. Zwłaszcza kiedy nacisk jest na dostarczenie funkcjonalności AI, a nie na solidną warstwę infrastrukturalną pod spodem.
Widziałem systemy, które przetwarzały dane medyczne na serwerach bez monitoringu, bez polityki backupu, z dostępami SSH dla kilku osób i hasłem zapisanym w mailu. Wszystko działało. Do pierwszej awarii.
Jedno pytanie które warto zadać na początku każdego projektu medycznego z AI
Nie: „Który model AI wybrać?"
Tylko: „Gdzie fizycznie będą dane pacjentów i kto ma do nich dostęp?"
Jeśli nie masz na to pytanie pewnej odpowiedzi — nie masz jeszcze architektury. Masz prototyp, który może działać lokalnie, ale nie jest gotowy do wdrożenia w środowisku klinicznym.
To brzmi jak szczegół prawny. W praktyce to decyzja architektoniczna, która determinuje wszystko inne: jak model jest wdrożony, gdzie działa, jak są zorganizowane dostępy, jaka jest polityka backupu, i czy system w ogóle może trafić do konkretnej placówki.
Pytania, które warto sobie zadać zanim zaczniesz
Jeśli projektujesz lub wdrażasz system AI dla placówki medycznej:
Czy dane pacjentów w ogóle mogą opuścić serwery klienta? Czy placówka ma prawników, którzy to ocenią, czy ta decyzja spadnie na Ciebie?
Czy wybrany model AI może działać lokalnie? Czy jest wersja do samodzielnego wdrożenia, czy tylko API?
Jak wygląda plan na awarię serwera? Nie jeśli — kiedy. W środowisku klinicznym ciągłość działania to wymaganie.
Co się stanie z projektem za rok, kiedy kogoś z zespołu nie będzie? Czy dokumentacja i infrastruktura są na tyle przejrzyste, żeby ktoś inny mógł to przejąć?
To nie są pytania, na które trzeba mieć odpowiedź na pierwszym spotkaniu. Ale na etapie projektowania architektury — już tak.