Deklaracja podejścia do zgodności z EU AI Act Rozporządzenie UE 2024/1689
Ostatnia aktualizacja: 23 lipca 2026 r. · Wersja: 2.0
1. Dostawca i charakter systemu
Dostawcą i podmiotem wdrażającym system jest Serwis erecept.pl. ChatErecept opiera się na otwartych, lokalnie uruchamianych modelach generatywnych (rodzina Gemma, silnik llama.cpp) i pełni funkcję systemu wspomagania decyzji klinicznych w zakresie informacji o lekach, dawkowaniu, wytycznych i dokumentacji.
2. Klasyfikacja ryzyka — kwestia kluczowa i otwarta
Wcześniejsze wersje dokumentu traktowały system wyłącznie jako objęty obowiązkami przejrzystości (art. 50). Jest to podejście niewystarczające. Uczciwa ocena wygląda następująco:
System prawdopodobnie kwalifikuje się jako system AI wysokiego ryzyka. Oprogramowanie wspomagające
decyzje o lekach i dawkowaniu może zostać zakwalifikowane jako system wysokiego ryzyka na podstawie
Załącznika III AI Act i/lub jako element/wyrób powiązany z przepisami harmonizacyjnymi (wyroby medyczne).
Kwalifikacja ta wymaga formalnej oceny prawnej. Do czasu jej przeprowadzenia Operator zakłada
ostrożnościowo, że mogą mieć zastosowanie obowiązki dla wysokiego ryzyka.
Jeżeli klasyfikacja wysokiego ryzyka się potwierdzi, zastosowanie znajdą m.in. obowiązki z art. 9–15 AI Act:
- System zarządzania ryzykiem (art. 9) — ciągła identyfikacja i ograniczanie ryzyk klinicznych.
- Zarządzanie danymi (art. 10) — jakość i adekwatność danych.
- Dokumentacja techniczna (art. 11) oraz rejestrowanie zdarzeń / logi (art. 12).
- Przejrzystość i informacja dla użytkownika (art. 13).
- Nadzór ludzki (art. 14) oraz dokładność, odporność i cyberbezpieczeństwo (art. 15).
3. Powiązanie z rozporządzeniem o wyrobach medycznych (MDR 2017/745)
Ryzyko kwalifikacji jako wyrób medyczny. Oprogramowanie przeznaczone do wspomagania decyzji
terapeutycznych (np. sugestie dotyczące leków lub dawkowania) może stanowić wyrób medyczny w rozumieniu
rozporządzenia MDR (UE) 2017/745, co pociąga za sobą obowiązki oceny zgodności, klasyfikacji i oznakowania.
Operator wskazuje konieczność przeprowadzenia oceny MDR i, do czasu jej zakończenia, nie deklaruje statusu
wyrobu ani jego braku — jest to kwestia otwarta wymagająca opinii specjalisty.
4. Dokładność i decyzja o kwantyzacji (art. 15)
Model działa w konfiguracji ze skwantyzowanymi wagami (q4_0 QAT) oraz skwantyzowaną pamięcią podręczną (KV-cache q4_0). Jest to świadoma decyzja wydajnościowa, która może wpływać na precyzję generowanych odpowiedzi.
AI Act wymaga dla systemów wysokiego ryzyka adekwatnego poziomu dokładności i odporności. Operator traktuje wpływ kwantyzacji na jakość jako element podlegający monitorowaniu i ewaluacji, a nie jako rozstrzygnięty. Nie deklarujemy, że obecna precyzja spełnia wymagany dla wysokiego ryzyka poziom — podlega to weryfikacji.
5. Nadzór ludzki (art. 14)
- System nie podejmuje autonomicznie żadnych decyzji terapeutycznych, administracyjnych ani prawnych.
- Każda decyzja o ordynacji leku, dawkowaniu lub diagnozie wymaga bezpośredniej weryfikacji i zatwierdzenia przez wykwalifikowanego lekarza (human-in-the-loop).
- Odpowiedzi mają charakter sugestii informacyjnych, wyraźnie oznaczonych jako wygenerowane przez AI.
6. Przejrzystość i oznaczanie treści (art. 50)
- Użytkownik jest jednoznacznie informowany, że wchodzi w interakcję z systemem AI.
- Treści generowane przez model są oznaczane wizualnie (m.in. ikona AI oraz bloki rozumowania
💡 Rozumowanie).
- Tok rozumowania modelu jest zawsze widoczny dla użytkownika — sprzyja to przejrzystości i krytycznej ocenie odpowiedzi.
7. Wyjaśnialność i zakotwiczenie wiedzy (grounding)
W celu ograniczania ryzyka błędnych odpowiedzi (halucynacji) system stosuje mechanizmy zakotwiczenia i walidacji:
- Weryfikacja domenowa — nazwy leków sprawdzane w Rejestrze Produktów Leczniczych (RPL), kontrola cyfry kontrolnej PESEL.
- Sięganie do źródeł — funkcje wyszukiwania wiedzy (m.in. piśmiennictwo, wytyczne) wspierają odpowiedzi kontekstem.
Bez przeceniania. Mechanizmy grounding zmniejszają, lecz nie eliminują ryzyka błędu. Nie zastępują
weryfikacji lekarskiej i nie stanowią gwarancji poprawności. Zakres źródeł i skuteczność walidacji podlegają
dalszemu rozwojowi i ewaluacji.
8. Rejestrowanie zdarzeń (logi)
System prowadzi dziennik audytowy zdarzeń (audit_log: kto, co, kiedy, z jakiego IP), co wspiera wymóg rejestrowania zdarzeń i rozliczalności. Zakres logowania będzie dostosowywany do wymagań właściwych dla ostatecznej klasyfikacji ryzyka.
9. Wykorzystanie danych i modele lokalne
Dane wprowadzane przez lekarzy nie są przekazywane zewnętrznym dostawcom chmurowym w celu trenowania ich modeli — w obecnej konfiguracji system w ogóle nie korzysta z modeli chmurowych. Ewentualne wykorzystanie zanonimizowanych/pseudonimizowanych próbek do wewnętrznego dostrajania lokalnych modeli wymaga odrębnej podstawy, oceny ryzyka reidentyfikacji oraz zgodności z RODO i AI Act; nie jest deklarowane jako obecnie prowadzone bez tych zabezpieczeń.