Wysłanie dokumentów do zewnętrznego modelu to przetwarzanie danych przez podmiot trzeci — z całą podstawą prawną, umową powierzenia i oceną transferu poza EOG. Przy danych osobowych, umowach i dokumentacji technicznej bywa to problem wobec RODO i polityki bezpieczeństwa klienta. Model uruchomiony lokalnie usuwa pytanie u źródła: dane nie opuszczają organizacji, więc nie ma czego powierzać.
Co się dzieje, gdy wysyłasz dokument do modelu
Z perspektywy prawnej nie jest to „zapytanie do narzędzia", tylko przekazanie treści innemu podmiotowi. Jeśli w dokumencie są dane osobowe, potrzebna jest podstawa prawna przetwarzania i umowa powierzenia z dostawcą. Jeśli dostawca przetwarza dane poza Europejskim Obszarem Gospodarczym, dochodzi ocena transferu.
Osobna kwestia to tajemnica przedsiębiorstwa. Umowy, wyceny, dokumentacja techniczna i korespondencja handlowa bywają objęte NDA z kontrahentem. Wysłanie ich do zewnętrznego modelu może naruszać ten zapis niezależnie od tego, co mówi RODO — to dwa różne reżimy, które trzeba sprawdzić osobno.
Trzy pytania, które warto zadać przed wdrożeniem
- Czy w danych są dane osobowe? Jeśli tak — podstawa prawna, umowa powierzenia, ocena transferu poza EOG.
- Czy dokumenty są objęte NDA lub tajemnicą przedsiębiorstwa? Zgoda kontrahenta bywa potrzebna nawet wtedy, gdy RODO nie ma zastosowania.
- Czy dostawca uczy modelu na Twoich danych? Warunki bywają różne dla planów darmowych i biznesowych, a zmieniają się w czasie.
Dlaczego wdrożenie lokalne zmienia postać rzeczy
Gdy model działa na Twoim serwerze, powyższe pytania w większości znikają — nie ma podmiotu trzeciego, któremu powierzasz dane, ani transferu poza EOG. Zamiast obudowywać ryzyko zapisami w umowie, usuwasz jego źródło.
Ma to też skutki poza zgodnością: brak opłaty za każde zapytanie i brak zależności od zmian cennika dostawcy. Modele w rozmiarze 4–8 mld parametrów, w kwantyzacji Q4, działają dziś na sprzęcie o poborze poniżej 25 W — a to wystarcza do obsługi wyszukiwania po dokumentach firmowych.
Nie zawsze lokalnie
Wdrożenie lokalne nie jest odpowiedzią na wszystko. Gdy dane są jawne, a zadanie wymaga największych modeli — tłumaczenia literackie, złożone rozumowanie — model w chmurze bywa rozsądniejszy. Rozstrzyga charakter danych, nie ideologia.
Co powinno znaleźć się w dokumentacji
Niezależnie od wybranej architektury, przy kontroli lub w ankiecie dostawcy pytają o te same rzeczy:
- Opis pochodzenia danych — źródło każdego elementu bazy i sposób weryfikacji.
- Klasyfikacja systemu wg AI Act — rola, kategoria ryzyka, obowiązujące artykuły.
- Rejestr ryzyk — zagrożenia, zastosowane środki, status.
- Wyniki testów — mierzalna trafność na zbiorze kontrolnym.
- Plan utrzymania — co i jak często weryfikować.
Te dokumenty powstają najtaniej razem z systemem. Dopisywanie ich do gotowego wdrożenia kosztuje wielokrotnie więcej — bo wymaga odtworzenia decyzji, których nikt nie zapisał.
Tekst ma charakter informacyjny i nie stanowi porady prawnej. Zobacz też: kalendarium terminów AI Act.