Rola dotyczy konkretnego systemu
Organizacja może pełnić różne role w AI Act dla różnych systemów. Zakup gotowego narzędzia często oznacza rolę podmiotu stosującego. Rozwój lub zlecenie rozwoju systemu pod własną nazwą może oznaczać rolę dostawcy. Użycie zewnętrznego modelu nie usuwa automatycznie odpowiedzialności za zbudowany na nim system.
Podstawowe role
| Rola | Istotne rozróżnienie w art. 3 |
|---|---|
| Provider — dostawca | Rozwija lub zleca rozwój systemu/modelu i wprowadza go na rynek lub oddaje do użytku pod własną nazwą albo znakiem towarowym. |
| Deployer — podmiot stosujący | Używa systemu pod swoją odpowiedzialnością, poza osobistym użyciem pozazawodowym. |
| Upoważniony przedstawiciel | Podmiot w UE posiadający pisemne upoważnienie dostawcy do wykonywania określonych obowiązków. |
| Importer | Podmiot w UE wprowadzający na rynek system oznaczony nazwą lub marką podmiotu z państwa trzeciego. |
| Dystrybutor | Podmiot w łańcuchu dostaw, inny niż dostawca i importer, udostępniający system na rynku UE. |
Znaczenie mają pełna definicja i faktyczne działania. Brak przedstawiciela dostawcy nie sprawia, że sprzedawca automatycznie staje się jego upoważnionym przedstawicielem — ta rola wymaga pisemnego umocowania.
Obowiązki dostawcy systemu wysokiego ryzyka
Art. 16 i powiązane przepisy obejmują zgodność z wymaganiami systemowymi, identyfikację dostawcy, zarządzanie jakością, przechowywanie dokumentacji i logów, ocenę zgodności, deklarację, oznakowanie, właściwą rejestrację, działania korygujące oraz współpracę z organami.
Zakres prac zależy od systemu i dostępnych dowodów. Nie ma uniwersalnego czasu wdrożenia ani pakietu konsultingowego, który potwierdza zgodność każdego MŚP.
Obowiązki podmiotu stosującego system wysokiego ryzyka
Art. 26 obejmuje korzystanie z systemu według instrukcji, zapewnienie kompetentnego nadzoru człowieka, odpowiednią jakość kontrolowanych danych wejściowych, monitorowanie działania i reakcję na ryzyko lub incydenty. Odnosi się również do logów pozostających pod kontrolą podmiotu, z określonymi warunkami retencji, oraz wskazanych obowiązków informacyjnych i rejestracyjnych.
Wykorzystanie w pracy, przez podmiot publiczny lub przy decyzjach dotyczących osób może uruchamiać dodatkowe wymagania. Trzeba ustalić obowiązki dla rzeczywistego zastosowania, zamiast kopiować ogólną listę do umowy zakupowej.
Kiedy rola może się zmienić
Art. 25 określa sytuacje, w których inny podmiot staje się dostawcą systemu wysokiego ryzyka. Należą do nich wskazane przypadki oznaczenia systemu własną marką, istotnej modyfikacji i zmiany przeznaczenia prowadzącej do wysokiego ryzyka.
Przystosowanie narzędzia do usługi rankingu kandydatów pod własną marką wymaga oceny powstałego systemu. Samo dostrajanie modelu nie jest uniwersalnym testem prawnym; trzeba uwzględnić system, zmianę i przeznaczenie łącznie.
Ocenę należy wykonać przed modyfikacją rozwiązania dostawcy. Umowa powinna określać dostęp do dokumentacji i współpracę, ale nie może po prostu usuwać obowiązków wynikających z prawa.
Model ogólnego przeznaczenia to odrębna warstwa
Art. 53–55 dotyczą dostawców modeli GPAI, z dodatkowymi wymaganiami dla modeli z ryzykiem systemowym oraz kwalifikowanymi wyjątkami dotyczącymi części modeli open source. Firma korzystająca z modelu potrzebuje informacji odpowiednich do budowy i eksploatacji swojego systemu; nie oznacza to otrzymania wszystkich szczegółów treningu dostawcy.
Wewnętrzny asystent, chatbot dla klientów i system zdolności kredytowej zbudowane na tym samym modelu mogą podlegać różnym obowiązkom. Marki takie jak Copilot lub GPT nie określają klasyfikacji każdego wdrożenia. Korzystanie z API może współistnieć z rolą dostawcy powstałego systemu. Obowiązki przejrzystości z art. 50 trzeba przypisać do konkretnej interakcji i odpowiedzialnej strony.
FRIA i DPIA
Art. 27 przewiduje ocenę wpływu na prawa podstawowe dla wskazanych podmiotów stosujących określone systemy wysokiego ryzyka. Dotyczy między innymi podmiotów prawa publicznego, prywatnych podmiotów świadczących usługi publiczne oraz wybranych zastosowań kredytowych i ubezpieczeniowych, z uwzględnieniem zakresu i wyłączeń przepisu. Nie jest to automatyczny obowiązek każdego pracodawcy używającego AI.
Ocena skutków dla ochrony danych z RODO ma odrębne przesłanki i zawartość. Można wykorzystać wspólne dowody, ale jedna ocena nie spełnia automatycznie wymagań drugiej. Trzeba ustalić osoby objęte wpływem, ryzyka, nadzór, drogę skarg i właściwy tryb powiadomienia.
O co zapytać dostawcę
Ustal, kto jest dostawcą modelu, dostawcą systemu i podmiotem stosującym. Zapisz przeznaczenie, wpływ planowanych zmian na klasyfikację, dostępne instrukcje, logi i dowody oceny. Określ, kto monitoruje działanie i odpowiada za incydenty.
Wynik rozmowy powinien mieć właściciela i dokumentację. Przy zmianie modelu lub zastosowania trzeba wrócić do oceny ról, klasyfikacji oraz właściwych terminów.
Wymagania w projekcie oprogramowania
Wymagania bezpieczeństwa, dokumentacji i nadzoru trzeba określić dla konkretnego zastosowania oraz roli organizacji. Ocenę prawną należy powiązać z decyzjami technicznymi i organizacyjnymi.
Q-Dev to software house QA10. Projektujemy oprogramowanie według uzgodnionego zakresu; cenę i harmonogram ustalamy dla konkretnego projektu. Prawa do kodu przechodzą na klienta po rozliczeniu całego projektu.
Źródło prawne
AI Act — rozporządzenie (UE) 2024/1689 w EUR-Lex. Artykuł wyjaśnia ramy przyjętego aktu. Przy decyzji dotyczącej wdrożenia trzeba sprawdzić aktualny tekst, zmiany, przepisy przejściowe i fakty dotyczące konkretnego systemu.