Budujesz na cudzym modelu: gdzie kończy się Twoja odpowiedzialność
Startupy i firmy SaaS budujące produkt na modelu językowym dostępnym przez API (OpenAI, Anthropic, Google i inni) są w specyficznej sytuacji na tle AI Act: nie tworzą modelu od podstaw, ale też nie są zwykłym, biernym stosującym gotowego narzędzia jak firma korzystająca z ChatGPT do pisania maili. Budują coś pomiędzy: własny produkt na cudzej infrastrukturze modelowej. To rozróżnienie ma bezpośrednie znaczenie dla tego, jakie obowiązki spadają na dostawcę modelu, a jakie na Ciebie.
Model ogólnego przeznaczenia a Twoja aplikacja: dwie różne warstwy
AI Act rozdziela obowiązki dotyczące modeli AI ogólnego przeznaczenia (tzw. GPAI, general-purpose AI, jak GPT czy Claude) od obowiązków dotyczących konkretnych systemów AI zbudowanych na ich bazie. Dostawca modelu bazowego, czyli OpenAI, Anthropic czy inny podmiot udostępniający model przez API, ma własny zestaw obowiązków dotyczących samego modelu: dokumentację techniczną, informacje o danych treningowych w określonym zakresie, ocenę ryzyka systemowego dla największych modeli. Pełne omówienie tej warstwy znajdziesz w artykule GPAI: modele ogólnego przeznaczenia.
Twoja aplikacja, zbudowana na tym modelu przez API, to osobny system AI w rozumieniu rozporządzenia, ze swoim własnym poziomem ryzyka, zależnym od tego, do czego faktycznie służy, nie od tego, jakiego modelu bazowego używasz pod maską.
Kiedy jesteś stosującym, a kiedy dostawcą
To jest kluczowe pytanie dla każdego SaaS budowanego na API. Ogólna zasada z AI Act: jesteś dostawcą, jeśli tworzysz system AI i wprowadzasz go na rynek pod własną marką, niezależnie od tego, czy sam wytrenowałeś model, czy zbudowałeś produkt na cudzym. Sam fakt korzystania z API OpenAI czy Anthropic nie czyni Cię automatycznie dostawcą modelu bazowego (tym pozostaje OpenAI czy Anthropic), ale bardzo często czyni Cię dostawcą Twojej własnej aplikacji, czyli konkretnego systemu AI, z którym styka się Twój użytkownik końcowy. Pełne wyjaśnienie tego podziału ról opisuje artykuł Dostawca vs stosujący.
W praktyce oznacza to, że typowy startup SaaS budujący produkt na API modelu językowego jest jednocześnie: stosującym względem modelu bazowego (korzysta z gotowego API, nie buduje modelu) i dostawcą względem własnej aplikacji (wprowadza na rynek własny produkt pod własną marką).
Najczęstszy błąd startupów SaaS to założenie, że “skoro nie trenujemy własnego modelu, to nie jesteśmy dostawcą niczego”. W praktyce sama aplikacja, którą budujesz i sprzedajesz klientom, to odrębny system AI, za który odpowiadasz jako jego dostawca, niezależnie od tego, czyj model działa pod spodem.
Co zmienia Twoja własna nakładka
Poziom ryzyka i zakres Twoich obowiązków zależy przede wszystkim od tego, do czego służy Twoja aplikacja, nie od samego faktu korzystania z API:
| Typ produktu SaaS | Poziom ryzyka | Uwaga |
|---|---|---|
| Asystent do pisania treści marketingowych | Zwykle minimalne | Narzędzie wspomagające, nie ocenia ludzi |
| Chatbot obsługi klienta jako produkt B2B | Ograniczone | Obowiązek przejrzystości wobec użytkowników końcowych |
| Narzędzie do automatycznej oceny kandydatów w rekrutacji | Wysokie | Profilowanie i ocena osób, patrz AI Act w rekrutacji |
| Narzędzie do scoringu klientów dla firm finansowych | Wysokie | Ocena zdolności kredytowej lub podobna funkcja |
Kluczowy wniosek: to, co Twoja aplikacja robi z odpowiedziami modelu, decyduje o kategorii ryzyka znacznie bardziej niż to, jakiego dostawcy API używasz.
Obowiązki, które realnie na Tobie spoczywają
Dla większości produktów SaaS budowanych na API, mieszczących się w niższych kategoriach ryzyka, kluczowe obowiązki to:
- Przejrzystość wobec użytkowników końcowych, jeśli produkt to chatbot albo generuje treści prezentowane jako informacja, zgodnie z art. 50.
- Kompetencje zespołu (art. 4): osoby projektujące i utrzymujące produkt powinny rozumieć ograniczenia modelu, na którym budują, w tym ryzyko halucynacji i błędnych odpowiedzi.
- Jasna komunikacja do własnych klientów B2B, że produkt korzysta z modelu AI zewnętrznego dostawcy, i jakie to niesie konsekwencje dla nich jako stosujących Twojego produktu.
Jeśli budujesz coś bliżej wysokiego ryzyka (ocena, scoring, rekrutacja), dochodzi znacznie szerszy zestaw obowiązków, opisany w artykułach dla rekrutacji i sektora finansowego.
Zmiana modelu bazowego: kiedy warto zaktualizować ocenę ryzyka
Startupy SaaS regularnie zmieniają albo aktualizują model bazowy, na którym działa produkt (np. przechodzą na nowszą wersję GPT czy Claude, albo dodają drugiego dostawcę jako zapasowego). Każda taka zmiana to dobry moment, żeby ponownie sprawdzić, czy klasyfikacja ryzyka Twojej aplikacji się nie zmieniła, zwłaszcza jeśli nowy model ma inne możliwości (np. dodaje funkcję analizy obrazu albo głosu, której wcześniej nie było). Traktowanie oceny ryzyka jako jednorazowego zadania na starcie projektu, a nie powtarzalnego procesu przy każdej istotnej zmianie produktu, to częsty błąd szybko rozwijających się zespołów technicznych.
Co zrobić w praktyce
- Określ, w jakiej kategorii ryzyka mieści się Twoja aplikacja na podstawie tego, co faktycznie robi z danymi i odpowiedziami użytkownika, nie na podstawie modelu bazowego.
- Sprawdź warunki API dostawcy modelu (OpenAI, Anthropic) pod kątem tego, co dostawca gwarantuje, a czego nie, w kontekście zgodności z AI Act.
- Zbuduj minimalną dokumentację własnego produktu: co robi, jakich danych używa, jakie ma ograniczenia.
- Jeśli sprzedajesz produkt firmom (B2B), przygotuj krótką informację dla klientów, jasno rozdzielającą Twoją rolę jako dostawcy aplikacji od roli dostawcy modelu bazowego.
Jeśli chcesz sprawdzić, jak wypadają elementy przejrzystości na stronie Twojego produktu, przydatny będzie audyt strony.
Najczęściej zadawane pytania
Czy korzystanie z API OpenAI albo Anthropic czyni mnie dostawcą ich modelu?
Nie. Dostawcą modelu bazowego pozostaje firma, która go stworzyła i udostępnia przez API. Możesz jednak stać się dostawcą własnej aplikacji zbudowanej na tym modelu, co jest odrębną kategorią w rozporządzeniu.
Czy muszę informować użytkowników, jakiego modelu bazowego używam pod spodem?
AI Act tego wprost nie wymaga. Obowiązek przejrzystości dotyczy głównie informowania, że w ogóle mają do czynienia z systemem AI (np. chatbotem), nie konkretnej marki modelu, na którym działa.
Czy mała nakładka na API (np. prosty asystent do jednego zadania) też podlega tym samym zasadom?
Tak, zasady są te same niezależnie od skali produktu. W praktyce zakres realnych obowiązków dla prostego, niewielkiego narzędzia niskiego ryzyka jest jednak znacznie mniejszy niż dla rozbudowanego systemu oceniającego ludzi.
Co jeśli mój produkt tylko przekazuje zapytania do modelu bez własnej logiki?
Nawet w takim przypadku Twoja aplikacja jako produkt, z którym styka się użytkownik końcowy, pozostaje odrębnym systemem AI. Zakres Twoich obowiązków zależy głównie od tego, do czego produkt służy i jaki poziom ryzyka niesie jego zastosowanie.