Systemy AI coraz częściej nie działają wyłącznie na dokumentach, opisach produktów, wiadomościach klientów czy bazach wiedzy widocznych dla użytkownika. Aby sprawnie wyszukiwać informacje i generować trafne odpowiedzi, w takich systemach tworzone są także tzw. embeddingi – matematyczne reprezentacje treści, które pozwalają porównywać ich podobieństwo znaczeniowe, a nie wyłącznie zgodność słów kluczowych. Z perspektywy prawnej nie jest to neutralny detal techniczny. Embeddingi mogą mieć znaczenie dla ochrony danych osobowych, informacji poufnych, cyberbezpieczeństwa, kontroli nad danymi klienta, zmiany dostawcy oraz odpowiedzialności stron w umowach AI i SaaS.
Co to jest embedding?
Embedding można opisać jako reprezentację semantyczną określonej treści. Mówiąc prościej, jest to zapis liczbowy (wektor liczb), który pozwala systemowi AI rozpoznać, iż dwa fragmenty tekstu są do siebie podobne znaczeniowo, choćby o ile użyto w nich innych słów.
Przykładowo, użytkownik może zapytać: „jak odstąpić od umowy?”, a system powinien odnaleźć dokumenty dotyczące prawa zwrotu, rezygnacji z zakupu albo rozwiązania kontraktu. Klasyczna wyszukiwarka oparta wyłącznie na słowach kluczowych mogłaby pominąć część wyników. System wykorzystujący embeddingi może natomiast rozpoznać podobieństwo sensu, a nie tylko podobieństwo języka.
Embeddingi są jednym z podstawowych elementów systemów wykorzystujących RAG[1], czyli rozwiązania, w którym model AI odpowiada na pytanie użytkownika na podstawie wybranych dokumentów lub baz wiedzy. Taki model nie tworzy odpowiedzi w próżni, ale najpierw wyszukuje odpowiedni kontekst, a dopiero potem generuje odpowiedź. To właśnie na etapie wyszukiwania embeddingi mają zasadnicze znaczenie.
Kluczowe jest to, iż embedding nie jest wyłącznie elementem technicznym. To dodatkowa kategoria informacji powstająca w toku działania systemu – mniej widoczna niż dokumenty źródłowe, logi czy historia zapytań, ale istotna z perspektywy bezpieczeństwa i kontroli nad wdrożeniem.
Warto przy tym odróżnić tworzenie embeddingów od trenowania lub fine-tuningu modelu. W wielu projektach tworzenie embeddingów służy wyłącznie wyszukiwaniu i pobieraniu kontekstu, a nie zmianie wag modelu. To rozróżnienie jest ważne technicznie i prawnie, a także oznacza, iż embeddinginiemożna pominąć w umowie.
Czy embedding to dodatkowa warstwa danych w systemie AI?
W wielu projektach AI uwaga skupia się na tym, jakie dokumenty trafiają do systemu, gdzie są przechowywane i kto ma do nich dostęp. Jest to oczywiście istotne, ale nie wyczerpuje problemu. o ile system na podstawie tych dokumentów tworzy dodatkowe informacje, trzeba zadać pytanie, jaki jest ich status i kto ma nad nimi kontrolę.
Embeddingi mogą powstawać z katalogów produktów, cenników, dokumentacji technicznej, baz wiedzy, umów, zgłoszeń serwisowych, korespondencji z klientami, materiałów marketingowych czy danych dotyczących zachowań użytkowników. Nie zawsze będą to dane osobowe, ale często będą to informacje mające wartość gospodarczą.
W takim ujęciu embeddingi mogą stać się częścią know-how organizacji. Mogą odzwierciedlać sposób opisania produktów, strukturę bazy wiedzy, historię interakcji z klientami albo logikę działania systemu rekomendacyjnego. Pytanie o ich status to pytanie o dane osobowe, poufność, tajemnicę przedsiębiorstwa, odpowiedzialność dostawcy i posiadanie kontroli nad systemem.
Dlaczego embeddingi należy uwzględniać w umowach?
Na pierwszy rzut oka embedding może wydawać się bezpieczny. Nie jest przecież tekstem, który można normalnie przeczytać, nie zawiera imienia i nazwiska w zwykłej postaci, czy też nie wygląda jak klasyczny rekord w bazie danych. Nie oznacza to jednak, iż automatycznie jest neutralny prawnie albo stanowi anonimowe dane.
Jeżeli embedding powstał ze źródła zawierającego dane osobowe, informacje poufne albo dane klienta, pojawia się pytanie, czy przez cały czas można z niego wywieść określone informacje o osobie, sprawie, transakcji lub relacji biznesowej. Ryzyko rośnie zwłaszcza wtedy, gdy można go połączyć z dodatkowymi informacjami: identyfikatorem dokumentu, historią zapytań, kontem użytkownika, metadanymi albo pierwotną bazą dokumentów.
Europejska Rada Ochrony Danych w opinii 28/2024 w sprawie niektórych aspektów ochrony danych związanych z przetwarzaniem danych osobowych w kontekście modeli AI wskazała, iż modeli trenowanych z wykorzystaniem danych osobowych nie można automatycznie uznawać za anonimowe[2]. Ocena wymaga analizy konkretnego przypadku, w tym czy dane osobowe mogą zostać wydobyte z modelu albo uzyskane poprzez zapytania kierowane do systemu. Ten kierunek interpretacyjny ma znaczenie także dla embeddingów, gdyż techniczna postać danych nie przesądza jeszcze o ich anonimowości.
W praktyce problem polega na tym, iż embeddingi często pozostają poza standardowym opisem systemu, mimo iż mogą mieć znaczenie przy audycie, incydencie bezpieczeństwa, migracji do innego dostawcy albo zakończeniu umowy. Brak ich opisania w umowie może prowadzić do sporów o zakres danych klienta, sposób ich usuwania, dopuszczalne cele wykorzystania, prawo do eksportu czy odpowiedzialność dostawcy.
Jakie ryzyka łatwo przeoczyć przy wdrożeniu embeddingu w narzędziu AI?
Największe ryzyko związane z embeddingami polega na tym, iż często pozostają poza głównym polem widzenia stron stosunku prawnego. W umowie precyzyjnie opisuje się dane źródłowe, hosting, dostępność usługi, poziomy wsparcia czy odpowiedzialność za incydenty. Znacznie rzadziej strony zatrzymują się przy pytaniu, co dzieje się z informacjami tworzonymi już w trakcie działania systemu AI. To właśnie tam mogą pojawić się istotne wątpliwości: czy druga strona ma wpływ na ich wykorzystanie, czy może żądać ich usunięcia, czy dane podlegają eksportowi i czy dostawca może przechowywać je po zakończeniu współpracy.
Ryzyko to nie ma wyłącznie charakteru formalnego, gdyż choćby o ile embeddingi nie są łatwe do odczytania, to mogą odzwierciedlać sposób organizacji wiedzy w przedsiębiorstwie, a tym samym powinny być objęte poufnością i odpowiednimi zasadami bezpieczeństwa. Przy wykorzystaniu odpowiednich narzędzi, metadanych, dokumentów źródłowych albo konfiguracji indeksu mogą też pozwalać na wyciąganie wniosków o danych źródłowych.
Istotny jest również wymiar cyberbezpieczeństwa. Ujawnienie bazy embeddingów lub powiązanych z nią metadanych może nie przypominać klasycznego wycieku dokumentów, ale przez cały czas może ujawniać informacje o strukturze danych, sposobie działania systemu, kategoriach przetwarzanych informacji albo powiązaniach między dokumentami. Ryzyka związane z bazami wektorowymi i embeddingamisą dostrzegane także w standardach bezpieczeństwa aplikacji LLM. OWASP (Open Worldwide Application Security Project – branżowa organizacja non-profit zajmująca się bezpieczeństwem aplikacji) wskazuje je jako odrębną kategorię ryzyk, obejmującą m.in. nieuprawniony dostęp, wycieki danych czy ataki polegające na odtwarzaniu informacji z embeddingów[3].
Ryzyka pojawiają się także przy usuwaniu danych. W tradycyjnych systemach często zakłada się, iż usunięcie dokumentu z bazy rozwiązuje problem. W systemach AI sytuacja może być bardziej złożona, bo ślad po dokumencie może pozostawać w jego pochodnych: fragmentach tekstu, embeddingach, indeksach, kopiach roboczych, pamięci podręcznej albo metadanych. o ile umowa i procedury techniczne nie odpowiadają na ten problem, organizacja może usunąć widoczny dokument, ale pozostawić jego techniczną reprezentację w systemie.
Wątek danych osobowych wymaga odrębnej ostrożności. o ile embeddingi powstają z dokumentów zawierających informacje o konkretnych osobach, to należy ocenić, czy mogą zostać powiązane z tymi osobami albo ujawniać informacje na ich temat. Oznacza to potrzebę sprawdzenia celu przetwarzania, zakresu danych, dostępu dostawcy, okresu przechowywania, transferów oraz sposobu realizacji obowiązków związanych z usunięciem danych. Jednocześnie choćby tam, gdzie dane osobowe nie występują, przez cały czas mogą istnieć ryzyka kontraktowe, biznesowe i związane z bezpieczeństwem informacji.
Szczególne znaczenie embeddingi mogą mieć przy zmianie dostawcy. o ile system przez dłuższy czas tworzył bazę wiedzy, porządkował dokumenty, budował wyszukiwanie semantyczne i dostosowywał wyniki do potrzeb klienta, samo przekazanie plików źródłowych może nie wystarczyć do odtworzenia porównywalnej funkcjonalności u nowego dostawcy. W takim przypadku embeddingi lub powiązane z nimi konfiguracje mogą stać się przedmiotem sporu o to, co rzeczywiście powinno zostać udostępnione klientowi, aby migracja była faktyczna, a nie tylko formalna.
Co powinno znaleźć się w umowie na system AI zawierający embedding?
Z perspektywy kontraktowej embeddingi powinny przestać być tematem domyślnym. o ile system AI tworzy reprezentacje wektorowe danych klienta, warto świadomie rozstrzygnąć, czym są one w relacji stron.
W umowach można spotkać różne podejścia. Dostawca może traktować embeddingi jako element techniczny własnej infrastruktury. Natomiast klient może postrzegać je jako pochodną swoich danych, bez której system nie działa zgodnie z celem wdrożenia. Oba stanowiska mogą mieć uzasadnienie, ale brak jasnych postanowień może prowadzić do sporów.
Szczególnego zastanowienia wymagają zasady tworzenia, wykorzystywania, przechowywania, zabezpieczania, usuwania i ewentualnego eksportu embeddingów. Warto także rozstrzygnąć, czy mogą one służyć wyłącznie do świadczenia usługi dla danego klienta, czy również do rozwoju ogólnych modeli, produktów lub funkcjonalności dostawcy.
Istotne jest również odróżnienie tworzenia embeddingów od trenowania modelu. W wielu wdrożeniach dostawca narzędzi AI może argumentować, iż przetwarzanie danych w celu tworzenia embeddingów, wyszukiwania semantycznego i generowania odpowiedzi nie jest trenowaniem modelu. To rozróżnienie może być uzasadnione, ale powinno być jasno opisane w umowie. Najważniejsze jest bowiem to, czy dane, ich pochodne i informacje o użytkownikach nie zostaną wykorzystane poza uzgodnionym celem.
Data Act[4]: kiedy embeddingimogą mieć znaczenie przy dostępie do danych?
Data Act może mieć znaczenie w dwóch sytuacjach, które warto od siebie odróżnić. Pierwsza dotyczy produktów skomunikowanych, czyli takich, które zbierają, generują lub przesyłają dane dotyczące swojego używania albo otoczenia. Mogą to być przykładowo urządzenia IoT, maszyny przemysłowe, pojazdy, sprzęt medyczny lub urządzenia smart home. W kontekście AI istotne będą także usługi powiązane z takim produktem, czyli rozwiązania cyfrowe, które umożliwiają, uzupełniają albo dostosowują jego funkcje, na przykład system analizujący dane z maszyny, przewidujący awarie, rekomendujący działania serwisowe albo optymalizujący pracę urządzenia.
W takim modelu embeddingi mogą mieć znaczenie, o ile powstają na podstawie danych generowanych przez produkt skomunikowany albo danych wykorzystywanych w usłudze powiązanej. Nie chodzi więc o każde narzędzie AI, ale o rozwiązanie funkcjonalnie związane z produktem i przetwarzające dane, które powstają w związku z jego używaniem. Przykładowo, system AI może analizować historię pracy urządzenia, zgłoszenia serwisowe, dokumentację techniczną i instrukcje producenta, a następnie tworzyć embeddingi wspierające diagnostykę lub rekomendacje dla użytkownika.
Druga sytuacja dotyczy usług przetwarzania danych, w szczególności usług chmurowych, SaaS, PaaS i IaaS. W tym obszarze Data Act wzmacnia możliwość zmiany dostawcy i ogranicza bariery techniczne, kontraktowe oraz organizacyjne utrudniające migrację. Przy prostych usługach eksport danych może być stosunkowo łatwy. Przy systemach AI problem jest bardziej złożony, bo samo przekazanie plików źródłowych może nie wystarczyć do odtworzenia działania usługi u nowego dostawcy.
Z perspektywy embeddingów pytanie brzmi więc, czy w konkretnym przypadku są one wyłącznie wewnętrznym elementem technicznym dostawcy, czy też mają znaczenie dla korzystania z danych lub zachowania porównywalnej funkcjonalności po migracji. o ile system przez dłuższy czas budował bazę wiedzy, tworzył embeddingi, porządkował dokumenty i dostosowywał wyszukiwanie do potrzeb klienta, brak tej warstwy może sprawić, iż migracja będzie formalna, ale nie w pełni funkcjonalna.
Nie oznacza to jednak, iż Data Act zawsze będzie prowadził do obowiązku wydania całej warstwy technicznej systemu AI. Dostawcy przez cały czas będą chronić swoją własność intelektualną, tajemnice przedsiębiorstwa i wewnętrzną architekturę rozwiązania. najważniejsze będzie rozróżnienie między tym, co stanowi chronioną technologię dostawcy, a tym co jest potrzebne do korzystania z danych pochodzących z produktu skomunikowanego, usługi powiązanej albo usługi przetwarzania danych. To napięcie warto rozstrzygać już na etapie projektowania i kontraktowania wdrożenia, a nie dopiero gdy pojawi się potrzeba udostępnienia danych lub zmiany dostawcy.
Rozporządzenie nakłada na dostawców usług przetwarzania danych obowiązki ułatwiające zmianę dostawcy, w tym zapewnienie odpowiednich informacji, dokumentacji, wsparcia technicznego oraz – w odpowiednich przypadkach – narzędzi potrzebnych do przeprowadzenia migracji. Przy systemach AI najważniejsze będzie ustalenie, czy embeddingi, indeksy, metadane lub konfiguracje są w danym przypadku elementem danych eksportowalnych klienta, czy raczej pochodną warstwą techniczną rozwiązania dostawcy[5].
Co powinni sprawdzić klienci i dostawcy narzędzi AI przed zawarciem umowy?
Wdrożenie narzędzia AI nie powinno kończyć się na ocenie funkcjonalności i ceny. Warto sprawdzić:
- jakie dane trafiają do systemu,
- czy powstają z nich embeddingi,
- gdzie są przechowywane,
- kto ma do nich dostęp oraz
- czy mogą zostać usunięte albo wyeksportowane.
Szczególną ostrożność powinny zachować organizacje, które wykorzystują AI do obsługi klientów, personalizacji ofert, analizy dokumentów, wyszukiwania w bazach wiedzy, automatyzacji reklamacji, wsparcia działów HR, analizy umów, obsługi pacjentów lub rekomendacji produktów. W tych obszarach embeddingi mogą powstawać z danych, które mają znaczenie prawne i biznesowe.
Warto też pamiętać, iż problem embeddingów nie dotyczy wyłącznie dużych modeli językowych. Może pojawić się w wyszukiwarkach semantycznych, chatbotach, systemach rekomendacyjnych, narzędziach do analizy dokumentów, platformach e-commerce i rozwiązaniach obsługi klienta.
Na ten temat powinni spojrzeć także dostawcy narzędzi AI. o ile ich rozwiązanie tworzy embeddingi z danych klienta, umowa powinna jasno określać, w jakim celu są one tworzone, kto może z nich korzystać, jak długo są przechowywane i co dzieje się z nimi po zakończeniu współpracy. Brak takich postanowień może zwiększać ryzyko sporu z klientem, zwłaszcza przy usuwaniu danych, audycie bezpieczeństwa albo migracji do innego rozwiązania.
Dla dostawców równie ważne jest odpowiednie zabezpieczenie własnej technologii. Umowa powinna odróżniać dane klienta i ich pochodne od know-how dostawcy, jego modeli, architektury systemu, konfiguracji i tajemnicy przedsiębiorstwa. Im bardziej zaawansowana jest usługa AI, tym większe znaczenie ma precyzyjne opisanie tej granicy już na etapie kontraktowania.
Jak ograniczyć ryzyko prawne przy implementacji embeddingów?
Embeddingi są dobrym przykładem tego, iż w projektach AI najważniejsze ryzyka często znajdują się w najmniej widocznej części systemu. Użytkownik widzi odpowiedź, panel administracyjny albo wyszukiwarkę. Istotne może być jednak to, co dzieje się wcześniej: jakie dane są przetwarzane, jakie ich pochodne powstają, kto ma nad nimi kontrolę i co stanie się z nimi po zakończeniu współpracy.
Dla rynku oznacza to konieczność bardziej dojrzałego podejścia do umów AI i SaaS (przy czym należy mieć na uwadze, iż umowy SaaS z komponentem AI wymagają większej ostrożności niż klasyczne SaaS[6]). Ogólna klauzula o danych klienta ani standardowe postanowienia o poufności nie wystarczą. Przy rozwiązaniach, które wykorzystują RAG, wyszukiwanie semantyczne, rekomendacje lub personalizację, warto zrozumieć, jak działa warstwa embeddingów i jakie konsekwencje może mieć dla relacji z dostawcą.
To właśnie na etapie umowy najłatwiej przesądzić, czy embeddingi pozostaną niewidocznym ryzykiem, czy kontrolowanym elementem bezpiecznego wdrożenia AI. Dlatego na etapie przygotowywania dokumentacji istotne jest zmapowanie danych klienta, sposobu ich przetwarzania, miejsca przechowywania i dostępu, a także jasne rozróżnienie kategorii takich jak: Customer Data, Output Data, Model Training Data i Derived Data.
[1] Technika RAG (retrieval-augmented generation), w ramach której model sztucznej inteligencji generuje odpowiedź na zapytanie, odwołując się do zewnętrznych źródeł. Zob. J. Ożegalska-Trybalska, B. Widła [w:] N. Ghazal i in., Komentarz do wybranych przepisów ustawy o prawie autorskim i prawach pokrewnych, [w:] Prawo autorskie. Komentarz do znowelizowanych 26 lipca 2024 r. przepisów ustaw: o prawie autorskim i prawach pokrewnych, o ochronie baz danych, o zbiorowym zarządzaniu prawami autorskimi i prawami pokrewnymi, Warszawa 2025, art. 26(2).
[3] Por. OWASP, LLM08:2025 Vector and Embedding Weaknesses, OWASP Top 10 for LLM Applications 2025. Źródło: https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/.
[4] Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2023/2854 z dnia 13 grudnia 2023 r. w sprawie zharmonizowanych przepisów dotyczących sprawiedliwego dostępu do danych i ich wykorzystywania oraz w sprawie zmiany rozporządzenia (UE) 2017/2394 i dyrektywy (UE) 2020/1828 (akt w sprawie danych) (Dz. U. UE. L. z 2023 r. poz. 2854 z późn. zm.).
[5] Zob. art. 2 pkt 38 oraz art. 30 ust. 1 i 6 Data Act.
[6] Por. BCLP, Reviewing SaaS agreements in the age of AI, 2.02.2024, gdzie wskazano m.in. na potrzebę szczególnej analizy postanowień dotyczących własności i praw korzystania z danych, wykorzystania danych klienta do trenowania AI, audytu, SLA, prywatności i cyberbezpieczeństwa w umowach SaaS obejmujących komponenty AI. Źródło: https://www.bclplaw.com/en-US/events-insights-news/reviewing-saas-agreements-in-the-age-of-ai.html.
