---
title: Jak tworzyć syntetyczne dane do testów AI w placówce?
description: Zbuduj pięć fikcyjnych przypadków do testu AI bez kopiowania danych pacjentów. Sprawdź wyjątki, eskalację i zasady akceptacji w placówce.
image: "https://ai4med.pl/img/syntetyczne-dane-ai.jpg"
date: 2026-08-11
author: Jacek Wyderka
category: Dane i bezpieczeństwo
tags: dane syntetyczne, testy AI, bezpieczeństwo danych, pilotaż AI
url: "https://ai4med.pl/dane-i-bezpieczenstwo/syntetyczne-dane-ai"
inLanguage: pl
---

# Jak tworzyć syntetyczne dane do testów AI w placówce?

## Co znajdziesz w tekście?

- Jak odróżnić dane syntetyczne od anonimizacji i zwykłych danych testowych.
- Jak zbudować pięć fikcyjnych przypadków, które sprawdzają nie tylko idealny przebieg, ale też błędy i eskalację.
- Gdzie AI może przygotować warianty testu, a gdzie właściciel procesu, osoba medyczna i IOD muszą zatwierdzić zakres.

Manager placówki nie potrzebuje na początek dziesięciu tysięcy sztucznych rekordów. Potrzebuje **pięciu dobrze opisanych sytuacji**, które pokażą, czy formularz, asystent albo integracja AI zachowuje się poprawnie także wtedy, gdy wejście jest niepełne, sprzeczne lub poza zakresem. Najbezpieczniejszy start to ręczne zbudowanie tych przypadków bez kopiowania dokumentacji pacjentów.

**Dane syntetyczne (fikcyjne rekordy odwzorowujące cechy potrzebne do testu, ale nie historię konkretnego pacjenta)** mogą powstać ręcznie, z reguł albo przy pomocy generatora. W polskiej placówce służą do sprawdzenia procesu w środowisku próbnym: na przykład czy asystent oznaczy brak pola, czy integracja odrzuci błędny format i czy sprawa wymagająca interpretacji trafi do człowieka.

AI może zaproponować dodatkowe warianty, lecz **nie ustala sama oczekiwanego wyniku** i nie rozstrzyga, czy zbiór jest bezpieczny albo klinicznie reprezentatywny. Właściciel procesu opisuje poprawne zachowanie, osoba medyczna zatwierdza granice kliniczne, a IOD włącza się wtedy, gdy sposób tworzenia lub użycia zbioru może dotykać danych osobowych. Ten artykuł pokazuje, jak przygotować taki pierwszy zestaw i czego nie wolno z niego wnioskować.

## Najważniejsze

- **Zacznij od pięciu ręcznych kart**, nie od masowej generacji: przebieg typowy, brak danych, sprzeczność, sytuacja poza zakresem i eskalacja.
- **Każda karta potrzebuje oczekiwanego zachowania i warunku stopu**. Sam fikcyjny rekord bez kryterium oceny niczego nie testuje.
- **Syntetyczne nie znaczy automatycznie anonimowe, prywatne ani reprezentatywne**. Trzeba osobno ocenić pochodzenie, ryzyko ujawnienia i użyteczność dla konkretnego zadania.
- **AI przygotowuje warianty i porządkuje wyniki; człowiek zatwierdza przypadki, interpretuje rozjazdy i decyduje o dalszym teście**.

## Pięć przypadków, które powinny wejść do pierwszego zestawu

Pierwszy zestaw powinien odpowiadać na pytanie: **gdzie proces ma działać płynnie, a gdzie system ma się zatrzymać?** Nie próbuj odwzorować całej przychodni. Wybierz jedną funkcję, na przykład klasyfikację formularza kontaktowego albo przekazanie ustrukturyzowanego zgłoszenia do kolejki rejestracji, i opisz pięć rodzajów wejścia.

1. **Przebieg typowy.** Wszystkie wymagane pola są obecne, format jest poprawny, a prośba mieści się w zakresie funkcji. Ten przypadek sprawdza podstawową ścieżkę, ale nie może być jedynym testem.
2. **Brak danych.** Jednego wymaganego pola nie ma albo pole jest puste. Oczekiwanym zachowaniem może być prośba o uzupełnienie neutralnej informacji lub zatrzymanie przekazania — nigdy dopisanie brakującej treści przez model.
3. **Sprzeczność.** Pole wyboru wskazuje wizytę stacjonarną, a neutralny opis organizacyjny mówi o teleporadzie. System powinien oznaczyć konflikt i przekazać go rejestracji, zamiast samodzielnie wybierać wygodniejszy wariant.
4. **Sytuacja poza zakresem.** Użytkownik prosi asystenta administracyjnego o interpretację wyniku badania. Poprawną reakcją jest odmowa odpowiedzi merytorycznej i skierowanie sprawy do uprawnionej osoby.
5. **Eskalacja.** Wejście spełnia techniczne wymagania, lecz uruchamia ustaloną regułę kontaktu z człowiekiem. Test sprawdza, czy zgłoszenie trafia do właściwej roli i czy model nie wysyła autonomicznej odpowiedzi.

Zestaw powinien obejmowac również niepełne wejście i sytuację poza zakresem. **Właśnie te przypadki odkrywają granice automatyzacji**, których nie widać podczas prezentacji dostawcy prowadzonej po idealnej ścieżce.

## Dane syntetyczne, anonimizacja i dane testowe to różne rzeczy

Te trzy pojęcia bywają używane zamiennie, a prowadzą do innych decyzji. **Dane syntetyczne tworzy się jako nowe rekordy**: ręcznie, według reguł albo za pomocą modelu. Mogą przypominać rozkład lub strukturę prawdziwych danych, lecz nie powinny być kopią historii konkretnej osoby.

**Anonimizacja zaczyna się od danych rzeczywistych** i ma doprowadzić do stanu, w którym osoby nie da się zidentyfikować przy uwzględnieniu realnie dostępnych środków. Samo usunięcie nazwiska, numeru telefonu czy PESEL może nie wystarczyć, co szerzej wyjaśnia tekst o [anonimizacji danych przed użyciem AI](/dane-i-bezpieczenstwo/anonimizacja-danych-ai). Pseudonimizowany eksport nadal może pozostawać danymi osobowymi.

**Dane testowe to pojęcie opisujące cel, nie metodę ochrony.** Zbiór testowy może składać się z ręcznie wymyślonych rekordów, danych syntetycznych z generatora albo — po osobnej analizie prawnej i technicznej — odpowiednio przygotowanych danych rzeczywistych. Etykieta „test” nie zmienia statusu danych i nie daje zgody na wgranie ich do dowolnego narzędzia.

Praktyczna zasada jest prosta: jeśli pierwszy test można wykonać na rekordach utworzonych od zera, **nie zaczynaj od eksportu z EDM**. Ograniczasz wtedy zakres ryzyka i łatwiej sprawdzasz, czy zespół naprawdę rozumie oczekiwane zachowanie systemu.

## Karta przypadku na pierwszy test: jak zapisać sprawdzalny wynik?

Każdy przypadek powinien mieć krótką kartę. **Bez oczekiwanego wyniku test zmienia się w oglądanie demonstracji**, a bez warunku stopu zespół może uznać każdą odpowiedź modelu za „wystarczająco dobrą”.

W karcie zapisz:

- identyfikator przypadku i jedną testowaną funkcję;
- cel: co dokładnie ma zostać sprawdzone;
- fikcyjne wejście oraz potwierdzenie, że nie pochodzi z rekordu pacjenta;
- oczekiwane zachowanie systemu;
- zachowanie zabronione, na przykład dopisanie brakującego faktu lub interpretacja kliniczna;
- rolę człowieka, do której trafia wyjątek;
- dowód wyniku: log, status, zrzut ekranu albo zapis w karcie testu bez danych osobowych;
- wersję modelu, konfiguracji i aplikacji użytej podczas próby.

Dla przypadku „poza zakresem” karta może brzmieć: fikcyjny formularz prosi o interpretację wyniku, asystent ma **nie przygotowywać odpowiedzi medycznej**, oznaczyć sprawę i przekazać ją uprawnionej osobie. Wynik negatywny pojawia się wtedy, gdy model odpowiada merytorycznie, ukrywa potrzebę eskalacji albo nie zapisuje, że proces został zatrzymany.

Po pierwszym przebiegu zespół zapisuje **różnicę między zachowaniem oczekiwanym a rzeczywistym**, zamiast wystawiać modelowi ogólną ocenę. Dzięki temu wiadomo, czy trzeba poprawić dane wejściowe, regułę procesu, konfigurację narzędzia czy samą decyzję o jego użyciu.

## Co syntetyczny zestaw może wykazać — a czego nie udowodni?

Aktualne publikacje pokazują, że tworzenie danych syntetycznych stało się łatwiejsze, ale ocena ich jakości nadal wymaga osobnego zadania. Opisana 29 czerwca 2026 r. platforma SyntheaWeb ułatwia generowanie i interaktywną inspekcję syntetycznych kohort oraz selektywny eksport. **Dostępny interfejs nie jest jednak walidacją lokalnego procesu placówki** — nadal trzeba zdefiniować, co system ma zrobić z konkretnym przypadkiem.

W pracy DualAlign z lipca 2026 r. autorzy pokazali, że kliniczne ugruntowanie generowanego tekstu w cechach persony i przebiegu objawów poprawiło wyniki badanego zadania względem niekontrolowanych syntetycznych baz. Badanie dotyczyło narracji elektronicznej dokumentacji w chorobie Alzheimera i klasyfikacji objawów, więc **nie dowodzi jakości formularza ani asystenta w polskiej przychodni**. Daje za to użyteczną lekcję: struktura i pokrycie scenariuszy mają znaczenie; płynnie brzmiący tekst to za mało.

Badanie opisane 11 czerwca 2026 r. przez BIH at Charité przynosi drugie ostrzeżenie. Syntetyczne dane roszczeniowe mogły wyglądać wiarygodnie, a mimo to przesuwały kluczowe estymacje ryzyka w analizie bezpieczeństwa leków. **Zbiór może więc przypominać oryginał i nadal nie nadawać się do konkretnego wniosku.** Autorzy wskazują potrzebę walidacji końcowych konkluzji na danych oryginalnych.

Dla placówki oznacza to rozdzielenie czterech pytań: czy zbiór nie ujawnia osoby, czy ma odpowiednią strukturę techniczną, czy obejmuje potrzebne wyjątki oraz czy wynik testu jest wystarczający do danej decyzji. **Zielony wynik na pięciu kartach potwierdza tylko zachowanie w tych pięciu sytuacjach**. Nie potwierdza bezpieczeństwa wszystkich danych, reprezentatywności pacjentów, skuteczności klinicznej ani zgodności produktu z wymaganiami dla wyrobu medycznego.

## Kto zatwierdza dane przed uruchomieniem testu?

Odpowiedzialność warto rozdzielić przed pierwszym kliknięciem. **Właściciel procesu** wybiera funkcję, definiuje pięć przypadków i opisuje oczekiwane zachowanie. **Osoba odpowiedzialna medycznie** zatwierdza granice wtedy, gdy narzędzie dotyka komunikacji klinicznej, dokumentacji lub podpowiedzi widzianej przez lekarza.

**IOD ocenia sposób utworzenia i użycia zbioru**, jeżeli generator był uczony lub zasilany danymi placówki, rekordy mogą pozwalać na powiązanie z osobą albo środowisko testowe przetwarza dane osobowe. UODO w materiale z 16 czerwca 2026 r. wymienia dane syntetyczne jako narzędzie ochrony prywatności, ale jednocześnie podkreśla testy reidentyfikacji, rozliczalność i rolę IOD. To ważna granica: „syntetyczne” nie jest samodzielnym werdyktem prawnym.

**Administrator techniczny lub dostawca** potwierdza izolację środowiska, dostęp, logowanie, retencję, wersję narzędzia i sposób usunięcia materiału po teście. AI może przygotować warianty opisów lub pogrupować wyniki, lecz człowiek sprawdza, czy nie powstały dane zbyt podobne do rekordu źródłowego i czy każdy wyjątek prowadzi do właściwej roli.

Nie zaczynaj, dopóki nie wiadomo, kto może przerwać test. **Brak właściciela wyjątku jest wynikiem negatywnym jeszcze przed uruchomieniem modelu**, nawet jeśli sam zestaw nie zawiera danych osobowych.

## Od pięciu kart do bezpiecznego środowiska próbnego

Pierwszy krok można zamknąć w krótkim spotkaniu właściciela procesu z osobą, która będzie odbierać wyjątki. Wybierz jedną funkcję i opisz pięć kart bez nazwisk, identyfikatorów, diagnoz oraz fragmentów prawdziwej dokumentacji. Potem poproś osobę medyczną o sprawdzenie granic odpowiedzi, a IOD o ocenę wtedy, gdy źródło lub sposób generacji może wiązać się z danymi osobowymi.

Uruchom test na zapisanej wersji narzędzia i przy każdej karcie odnotuj trzy rzeczy: **wynik rzeczywisty, rozjazd względem oczekiwania oraz decyzję człowieka**. Jeśli model dopisuje brakujące informacje, odpowiada poza zakresem albo omija eskalację, zatrzymaj ten przypadek i popraw proces przed dodaniem kolejnych rekordów.

**Metryką startową jest odsetek pięciu kart, w których system zachował się dokładnie zgodnie z opisem — osobno zapisz liczbę prawidłowych eskalacji i przypadków zatrzymanych po odpowiedzi poza zakresem.** Przy tak małym zestawie nie udawaj statystyki populacyjnej: wynik 5/5 oznacza tylko, że pięć jawnych reguł zadziałało w zapisanej wersji.

**Warto iść dalej, gdy** wszystkie pięć kart ma właściciela, oczekiwane zachowanie, ślad testu i jasny warunek stopu, a zespół potrafi powtórzyć wynik. **Zatrzymaj projekt, gdy** generator wymaga eksportu danych z EDM bez zatwierdzonej podstawy, nie da się wskazać pochodzenia rekordów, system nie ujawnia wersji albo człowiek nie może przejąć sprawy.

Jednego takiego zestawu, nie warto od razu skalować na wszystkie procesy. Najpierw popraw przypadki, które ujawniły rozjazd, potem dodaj warianty graniczne dla tej samej funkcji. Dopiero gdy placówka potrafi wyjaśnić, **co test udowodnił i czego nie sprawdzał**, może rozważyć większy generator albo kontrolowane porównanie z danymi rzeczywistymi.

## Źródła

- [UODO — Jak dowieść nieodwracalności anonimizacji danych?](https://uodo.gov.pl/pl/531/4431) — oficjalny polski materiał z 16 czerwca 2026 r.; omawia dane syntetyczne jako narzędzie ochrony prywatności, testy reidentyfikacji, rozliczalność i rolę IOD. Sprawdzono: 2026-08-09.
- [PubMed — SyntheaWeb: A Web-Based Platform for the Generation and Interactive Inspection of Synthetic Healthcare Data](https://pubmed.ncbi.nlm.nih.gov/42393946/) — publikacja z 29 czerwca 2026 r. opisująca generowanie, inspekcję i selektywny eksport syntetycznych kohort danych zdrowotnych. Sprawdzono: 2026-08-09.
- [ACL Anthology — DualAlign: Generating Clinically Grounded Synthetic Data](https://aclanthology.org/2026.findings-acl.1405/) — praca z lipca 2026 r.; pokazuje znaczenie klinicznego ugruntowania syntetycznych narracji i ograniczenie niekontrolowanej generacji. Sprawdzono: 2026-08-09.
- [BIH at Charité — Between data protection and research: New study puts two approaches to the test](https://www.bihealth.org/en/notices/between-data-protection-and-research-new-study-puts-two-approaches-to-the-test) — materiał z 11 czerwca 2026 r.; porównuje anonimizację i syntezę oraz pokazuje, że wiarygodny wygląd zbioru nie zastępuje walidacji konkretnego wniosku. Sprawdzono: 2026-08-09.
- Okładka: [Pavel Danilyuk na Pexels](https://www.pexels.com/photo/medical-equipment-in-laboratory-8442027/)