---
title: Wspólna analiza danych medycznych bez jednej bazy
description: "Wspólna analiza danych medycznych i uczenie AI bez centralnej bazy: poznaj metody ochrony, ich ograniczenia oraz warunki wyboru dla kilku placówek."
image: "https://ai4med.pl/img/analiza-bez-wspolnej-bazy.jpg"
date: 2026-10-04
author: Jacek Wyderka
category: Dane i bezpieczeństwo
tags: dane medyczne, prywatność, współpraca placówek, uczenie federacyjne
url: "https://ai4med.pl/dane-i-bezpieczenstwo/analiza-bez-wspolnej-bazy"
inLanguage: pl
---

# Wspólna analiza danych medycznych bez jednej bazy

Kilka polskich przychodni chce wspólnie analizować dane medyczne, ale każda ma powody, by zachować dokumentację u siebie. **Wspólna baza nie zawsze jest potrzebna**: wybór zależy od oczekiwanego wyniku, ochrony wymienianych informacji i możliwości utrzymania rozwiązania — poniżej porównujemy dostępne drogi.

Dotyczy to zarówno statystyk, jak i uczenia modelu **AI (sztucznej inteligencji)**, czyli dopasowywania jego działania na podstawie przykładów. **Pozostawienie zapisów dokumentacji w placówce nie gwarantuje anonimowości** tego, co wysyła jej system. Manager musi więc ustalić z osobą odpowiedzialną za ochronę danych i specjalistą technicznym, jakie informacje mogą opuścić placówkę oraz kto zatwierdzi wspólny wynik.

## Najpierw ustal, czy potrzebujesz statystyki, czy modelu AI

Jeżeli partnerzy chcą porównać odsetek badań powtarzanych z przyczyn technicznych, mogą zacząć od **wspólnie zdefiniowanego zestawienia**. Każda pracownia oblicza go u siebie, a do koordynatora trafiają dopuszczone do udostępnienia wyniki. To propozycja prostego sposobu organizacji pracy, nie opis konkretnego wdrożenia. Najpierw trzeba uzgodnić, co oznacza „powtórzenie” i jaki okres obejmuje raport.

Inne zadanie to uczenie programu przewidującego problem na podstawie wielu cech badania. Wtedy potrzebne może być **wspólne uczenie modelu**, a sama wymiana kilku średnich nie wystarczy. W obu przypadkach należy ocenić możliwość rozpoznania osób w małych grupach; etykieta „statystyka” nie rozstrzyga bezpieczeństwa udostępnienia.

Perspektywa opublikowana 24 września 2026 roku w *npj Digital Medicine* opisuje współpracę bez centralizacji danych, ale wiąże wybór metody z dostępnymi zasobami i celem analizy. **To propozycja kierunków rozwoju, nie dowód gotowości każdej przychodni do wdrożenia.** Dla managera wynika z niej użyteczna zasada: poprosić o najprostszy sposób uzyskania potrzebnego wyniku, zanim zamówi rozbudowane środowisko AI. [Publikacja Li i współautorów](https://www.nature.com/articles/s41746-026-03284-z_reference.pdf).

## Uczenie federacyjne zostawia dokumentację w placówkach, ale wysyła zmiany modelu

**Uczenie federacyjne** to wspólne uczenie modelu na danych przechowywanych przez uczestników projektu. W typowym wariancie koordynator rozsyła bieżący model, każda placówka uczy go lokalnie, a następnie przesyła wyliczone zmiany. Koordynator łączy je i przekazuje kolejną wersję. Cykl może powtarzać się wielokrotnie. Taką organizację opisuje [NIST, amerykański instytut standardów i technologii](https://www.nist.gov/blogs/cybersecurity-insights/protecting-model-updates-privacy-preserving-federated-learning).

**Przesyłane zmiany to liczby opisujące działanie modelu**, a nie gotowe karty pacjentów. Nie oznacza to jednak, że są obojętne dla prywatności. W określonych warunkach można z nich odtworzyć informacje o danych użytych podczas uczenia. Ryzyko może dotyczyć także gotowego modelu, nawet gdy sam proces uczenia został zabezpieczony. [NIST opisuje oba rodzaje ataków](https://www.nist.gov/blogs/cybersecurity-insights/privacy-attacks-federated-learning).

Federacja wymaga ponadto **uzgodnienia znaczenia danych i sposobu udziału placówek**. Różne urządzenia, nieporównywalne oznaczenia badań czy odmienne grupy pacjentów mogą utrudniać wykorzystanie wspólnego modelu. Przegląd z *Frontiers in Digital Health* z 17 sierpnia 2026 roku wskazuje również koszty komunikacji i integracji z istniejącymi systemami. Lokalizacja danych jest dopiero jednym elementem projektu. [Przegląd Ay i współautorów](https://www.frontiersin.org/journals/digital-health/articles/10.3389/fdgth.2026.1726771/full).

## Szyfrowanie obliczeń i prywatność różnicowa chronią inne elementy

**Bezpieczne obliczenia wielostronne** pozwalają uczestnikom obliczyć uzgodniony wynik bez ujawniania sobie nawzajem danych użytych do obliczeń. Dostawca powinien jednak wyjaśnić, czy zabezpieczenie wytrzyma sytuację, w której część uczestników połączy swoje informacje, aby odczytać cudze dane. Skuteczność ochrony może zależeć od tego, ilu uczestników działa wspólnie. Osobna metoda, **szyfrowanie homomorficzne**, umożliwia wykonywanie działań na zaszyfrowanych wartościach. Trzeba wtedy ustalić, kto posiada klucze i które wyniki może odszyfrować. Obie techniki opisuje [perspektywa w npj Digital Medicine](https://www.nature.com/articles/s41746-026-03284-z_reference.pdf).

**Prywatność różnicowa** ogranicza to, ile wynik może ujawnić o udziale konkretnej osoby w analizowanych danych. Jednym ze sposobów jest dodanie do wyniku celowo dobranej losowej zmiany — na przykład opublikowana liczba przypadków może być większa lub mniejsza od rzeczywistej. Nie wystarczy samodzielnie zaokrąglić tabeli: specjalista musi dobrać metodę i poziom ochrony dla całej analizy. **Silniejsza ochrona może zmniejszać dokładność**, co szczególnie utrudnia ocenę małych grup. Zestawiając kolejne odpowiedzi, odbiorca może wywnioskować więcej o osobach niż z pojedynczego wyniku. Dlatego specjalista musi ocenić łączne ryzyko zaplanowanej serii raportów. [Wytyczne NIST SP 800-226](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-226.pdf).

Dlatego dostawca powinien wyjaśnić **co dokładnie chroni każda proponowana metoda**: dane podczas obliczeń, wkład pojedynczej placówki czy informacje możliwe do odczytania z wyniku. Zestaw kilku nazw technologii w ofercie nie odpowiada jeszcze na to pytanie. Manager potrzebuje opisu zagrożenia, warunku skuteczności i kosztu zabezpieczenia w swoim projekcie.

## Dane na miejscu nadal wymagają kontroli wyników i aktualizacji

Najtrudniejszy kompromis widać wtedy, gdy koordynator ma otrzymywać wyłącznie wspólny model, ale do jego zbudowania zbiera osobne zmiany od każdej placówki. **Dane źródłowe pozostają lokalnie, a informacje o nich mogą ujawniać przesyłane zmiany.** Bezpieczne sumowanie zmian, nazywane agregacją, może ukryć wkład poszczególnych uczestników przed koordynatorem. Tę ochronę opisuje [NIST w materiale o aktualizacjach modeli](https://www.nist.gov/blogs/cybersecurity-insights/protecting-model-updates-privacy-preserving-federated-learning).

To nadal nie rozstrzyga, **co ujawnia wspólny wynik**. Jeżeli system udostępnia wiele szczegółowych odpowiedzi, trzeba ocenić również informacje możliwe do wywnioskowania z ich zestawienia. Przy prywatności różnicowej trzeba więc zaplanować ochronę całej serii analiz. **Prośba o bardziej szczegółowy raport wymaga ponownego uzgodnienia ochrony** z odpowiedzialnym specjalistą. Nie należy zmieniać ustawień wyłącznie po to, by uzyskać dokładniejszy wynik. To praktyczny wniosek z [wytycznych NIST dotyczących kolejnych analiz](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-226.pdf).

**Manager powinien zapytać także o zwykłe utrzymanie.** Kto sprawdza program uruchamiany u uczestników? Kto zatwierdza jego nową wersję? Czy zapis przebiegu zadania zawiera tylko identyfikator operacji i wynik kontroli, czy również fragmenty danych? Takie informacje pomocnicze, czyli metadane, też wymagają oceny. Przegląd *Frontiers* wskazuje, że ochrona musi obejmować konfigurację, integrację i utrzymanie przez cały czas pracy. Wyłączenie centralnej bazy nie usuwa tych obowiązków. [Przegląd ograniczeń wdrożeniowych](https://www.frontiersin.org/journals/digital-health/articles/10.3389/fdgth.2026.1726771/full).

## Porównaj cztery sposoby współpracy placówek

Poniższa macierz jest **propozycją rozmowy przed projektem**, nie rankingiem bezpieczeństwa technologii. Wybierz wiersz odpowiadający potrzebnemu wynikowi i sprawdź warunek w ostatniej kolumnie. Brak spełnionego warunku oznacza potrzebę ograniczenia zakresu albo odłożenia projektu.

| Wariant | Kiedy go rozważyć | Warunek ograniczenia ryzyka |
| --- | --- | --- |
| **Centralny zbiór** | Wspólna analiza rzeczywiście wymaga pracy na uzgodnionych zapisach dokumentacji | Uzasadniony zakres, dopuszczalność udostępnienia i kontrola dostępu do kopii |
| **Obliczenia w placówkach** | Wystarczą wspólne wskaźniki lub uzgodniona analiza statystyczna | Jednakowe definicje oraz ocena ujawnianych wyników i małych grup |
| **Wspólne uczenie modelu** | Projekt wymaga modelu korzystającego z doświadczeń wielu ośrodków | Ochrona zmian i gotowego modelu, zgodne dane oraz utrzymanie u uczestników |
| **Węższy zakres lub rezygnacja** | Koszt ochrony przewyższa korzyść albo brakuje odpowiedzialnej osoby | Jawna decyzja, czego projekt nie obejmie i co pozwoli wrócić do niego później |

**Centralny wariant pozostaje realną opcją**, jeśli jest dopuszczalny i odpowiada potrzebie. Rozproszenie warto wybrać wtedy, gdy ogranicza nazwane ryzyko, a uczestnicy potrafią obsłużyć jego wymagania. Sposób organizacji obliczeń nie stanowi jednak oceny prawnej ani potwierdzenia [anonimowości przekazywanego materiału](/dane-i-bezpieczenstwo/anonimizacja-danych-ai).

## Przed startem uzgodnij wynik, utrzymanie i wycofanie placówki

**Pierwszy krok: opisz jeden oczekiwany wynik i informacje potrzebne do jego uzyskania.** Manager przekazuje ten opis administratorowi danych, czyli podmiotowi decydującemu o celu i sposobie ich wykorzystania, oraz osobie odpowiedzialnej za technikę. Wspólnie ustalają, kto może zobaczyć wkład placówki, kto otrzyma końcowy wynik i jakie zdarzenie zatrzyma obliczenia. Takie ustalenie, porządkuje rozmowę o kosztach.

Administrator konsultuje się z **IOD (inspektorem ochrony danych)** i ustala dopuszczalność przetwarzania oraz potrzebę oceny skutków dla ochrony danych. Ta ocena opisuje planowane przetwarzanie, ryzyka dla ludzi i środki ograniczające te ryzyka. **UODO (Urząd Ochrony Danych Osobowych)** przypomina, że obowiązek jej przeprowadzenia spoczywa na administratorze; nie można przenieść go na inspektora. Urząd wskazuje też, że anonimowość modelu należy oceniać indywidualnie. [Wskazówki UODO](https://www.uodo.gov.pl/pl/598/3617).

Przed podpisaniem umowy warto doprecyzować **koszt obsługi każdej placówki**, zasady zapisów przebiegu zadań i wprowadzania nowych wersji. Potrzebny jest też opis wyjścia ze współpracy: jak zatrzymać kolejne obliczenia, odebrać dostęp i rozliczyć już udostępnione wyniki. Wycofania uczestnika nie należy utożsamiać z automatycznym usunięciem jego wpływu z istniejącego modelu. Wymaga to osobnego ustalenia z wykonawcą. Utrzymanie potrzebuje wspólnego harmongramu i wskazanej osoby do kontaktu.

**Zacznij projekt, gdy partnerzy potrafią wskazać wynik, zasady ochrony i osobę odpowiedzialną za obsługę.** Nie zaczynaj projektu, gdy jedynym zapewnieniem dostawcy jest hasło „dane nigdzie nie wychodzą”. AI może wyliczać propozycje i wspierać analizę, lecz uprawnieni ludzie zatwierdzają udostępnienie wyników oraz dalsze zastosowanie modelu; decyzje kliniczne pozostają przy personelu medycznym.

## Źródła

- [Li i współautorzy — Enabling equitable global health AI with privacy-enhancing technologies](https://www.nature.com/articles/s41746-026-03284-z_reference.pdf) — perspektywa naukowa opublikowana 24.09.2026; metody współpracy bez centralizacji i bariery zasobów. Wczesna wersja przyjętego artykułu, nie badanie polskich placówek. Sprawdzono: 2026-09-27.
- [Ay, Topaloglu i Zhang — Safeguarding biomedical AI](https://www.frontiersin.org/journals/digital-health/articles/10.3389/fdgth.2026.1726771/full) — przegląd z 17.08.2026; ograniczenia, integracja i utrzymanie metod ochrony prywatności. Sprawdzono: 2026-09-27.
- [NIST — Protecting Model Updates in Privacy-Preserving Federated Learning](https://www.nist.gov/blogs/cybersecurity-insights/protecting-model-updates-privacy-preserving-federated-learning) — 21.03.2024, tło techniczne: przebieg uczenia i ochrona zmian modelu. Sprawdzono: 2026-09-27.
- [NIST — Privacy Attacks in Federated Learning](https://www.nist.gov/blogs/cybersecurity-insights/privacy-attacks-federated-learning) — 24.01.2024, tło techniczne: ryzyko ujawnienia danych przez aktualizacje i gotowy model. Sprawdzono: 2026-09-27.
- [NIST SP 800-226 — Guidelines for Evaluating Differential Privacy Guarantees](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-226.pdf) — finalne wytyczne z marca 2025; parametry ochrony, dokładność i łączne ryzyko kolejnych analiz. Sprawdzono: 2026-09-27.
- [UODO — Kiedy trzeba przeprowadzić ocenę skutków dla ochrony danych?](https://www.uodo.gov.pl/pl/598/3617) — publikacja 31.03.2025, aktualizacja 30.04.2026; polskie źródło urzędowe o odpowiedzialności administratora i anonimowości modeli. Sprawdzono: 2026-09-27.
- Okładka: [Pavel Danilyuk na Pexels](https://www.pexels.com/photo/close-up-shot-of-a-laboratory-equipment-8442034/)