Governance AI dla startupów SaaS wdrażających funkcje AI

Rola, jaką pełnisz, decyduje o tym, jakie zasady obowiązują

AI Act przypisuje obowiązki według roli, nie wielkości firmy. Artykuł 3 definiuje operatorów: provider, deployer, importer, dystrybutor. Dla startupu SaaS liczą się dwa z nich, a granica między nimi to jedyna rzecz, którą naprawdę trzeba dobrze zrozumieć.

Deployer używa systemu AI na własną odpowiedzialność. Provider rozwija system AI albo zleca jego rozwój i wprowadza go na rynek albo do użytku pod własną nazwą lub znakiem towarowym. Większość zespołów SaaS zaczyna jako deployerzy albo downstream integratorzy: wywołujesz OpenAI, Anthropic albo inny hostowany model przez API i owijasz go swoim produktem. W tej pozycji ciężkie obowiązki providera (dokumentacja techniczna, ocena zgodności, system zarządzania jakością) spoczywają na providerze modelu, nie na tobie.

W tej pozycji nie zostajesz przez przypadek. Dwie typowe decyzje produktowe przesuwają cię za granicę, w terytorium providera, i to reguluje Artykuł 25.

Artykuł 25: jak deployer staje się providerem

Artykuł 25(1) wymienia warunki, przy których dystrybutor, importer, deployer albo inna strona trzecia staje się providerem systemu AI wysokiego ryzyka i przejmuje obowiązki providera z Artykułu 16. Trzy z nich są realne dla firmy SaaS:

• Umieszczasz na nim swoją nazwę albo znak towarowy. Artykuł 25(1)(a): jeśli wprowadzasz system AI wysokiego ryzyka na rynek pod własną marką, jesteś jego providerem. White-labelling cudzego modelu jako „Acme AI Assistant" to dokładnie ten scenariusz.
• Istotnie go modyfikujesz. Artykuł 25(1)(b): istotna modyfikacja systemu wysokiego ryzyka, która utrzymuje go w kategorii wysokiego ryzyka, czyni cię providerem. Kwalifikuje się do tego retrenowanie na istotnie innych danych, zmiana architektury modelu albo przesunięcie go do zastosowania, którego pierwotny provider nie zamierzał. Rutynowe łatki, zmiany UI i modyfikacje przewidziane już w dokumentacji technicznej dostawcy się nie kwalifikują.
• Zmieniasz jego przeznaczenie. Artykuł 25(1)(c): jeśli bierzesz system i kierujesz go do zastosowania wysokiego ryzyka, którego pierwotny provider nie zadeklarował, stajesz się providerem dla tego zastosowania.

Dwie rzeczy czynią to ostrym progiem. Po pierwsze, przekwalifikowanie jest automatyczne: nie ma formularza do złożenia; jeśli warunki są spełnione, jesteś providerem z mocy prawa. Po drugie, to nadpisuje twoją umowę. Artykuł 25 obowiązuje „bez uszczerbku dla ustaleń umownych", więc klauzula mówiąca, że provider modelu ponosi całą odpowiedzialność wynikającą z AI Act, nie zmienia oceny regulatora co do tego, kto jest providerem. Umowa rozdziela ryzyko między tobą a dostawcą; nie zmienia roli prawnej. Tam, gdzie stajesz się nowym providerem, pierwotny provider ma obowiązek współpracować i przekazać informacje oraz dostęp techniczny, jakich potrzebujesz, więc umowa nadal ma znaczenie dla wyegzekwowania tego.

To uderza w pełni tylko tam, gdzie system jest wysokiego ryzyka według Artykułu 6 i Załącznika III (obszary takie jak rekrutacja, kredyt, edukacja, usługi podstawowe, biometryka). Ogólny summarizer do treści marketingowych nie jest wysokiego ryzyka. Funkcja AI, która filtruje kandydatów do pracy albo scoruje zdolność kredytową, może być. Praktycznym ruchem jest sklasyfikowanie każdej funkcji AI względem Załącznika III, zanim ją zabrandujesz albo zrobisz na niej fine-tuning, bo to właśnie te działania przesuwają cię za granicę.

Wypuszczanie albo fine-tuning modelu: obowiązki GPAI

Jest drugi sposób, w jaki startup SaaS przejmuje obowiązki podmiotu regulowanego, niezależny od kwestii wysokiego ryzyka: praca z samym modelem AI ogólnego przeznaczenia, a nie tylko konsumowanie go jako usługi.

Artykuły 53 do 55 ustanawiają obowiązki dla providerów modeli AI ogólnego przeznaczenia (GPAI), obowiązujące od 2 sierpnia 2025. Podstawowe obowiązki z Artykułu 53 to: prowadzenie dokumentacji technicznej (Załącznik XI); dostarczanie podmiotom downstream informacji, jakich potrzebują, by zrozumieć model i spełnić własne obowiązki; wdrożenie polityki zgodności z unijnym prawem autorskim, w tym opt-out z eksploracji tekstów i danych na mocy Dyrektywy (UE) 2019/790; oraz publikacja wystarczająco szczegółowego podsumowania treści treningowych według szablonu AI Office.

Dla większości startupów SaaS te obowiązki należą do providera modelu, którego wywołujesz, nie do ciebie. Pytanie brzmi, czy twoja własna praca też czyni cię providerem GPAI. Stanowisko Komisji jest takie, że fine-tuning albo inna modyfikacja istniejącego modelu GPAI może uczynić stronę downstream providerem modelu, ale tylko w zakresie modyfikacji. Orientacyjna granica, jakiej używała Komisja, mówi, że wchodzi to w grę, gdy moc obliczeniowa treningu użyta na twoją modyfikację przekracza mniej więcej jedną trzecią mocy obliczeniowej treningu oryginalnego modelu. Lekki fine-tuning, adaptery albo prompt engineering na hostowanym modelu są dużo poniżej tego progu.

Jeśli go przekroczysz, twoje obowiązki są ograniczone do twojej modyfikacji: dokumentacja i polityka praw autorskich dla tego, co dodałeś, oraz podsumowanie treści treningowych obejmujące dane, których użyłeś. Obowiązki dotyczące ryzyka systemowego (Artykuł 55) dotyczą tylko górnego pułapu, gdzie skumulowana moc obliczeniowa treningu sięga 10^25 FLOP, daleko poza tym, co startup osiąga przez fine-tuning. Realistyczna ekspozycja to podstawowy zestaw z Artykułu 53, uruchamiany przez fine-tuning wystarczająco duży, by się liczyć, albo przez trenowanie czy wypuszczenie własnego modelu. Polityka praw autorskich to obowiązek, który zespoły nie doceniają: jeśli trenujesz albo fine-tunujesz na scrapowanych albo licencjonowanych danych, polityka praw autorskich z Artykułu 53 i publiczne podsumowanie danych treningowych to obowiązki, które powinieneś umieć udokumentować, i pokrywają się z due diligence, o które zapytają twoi kupujący enterprise.

Zasięg eksterytorialny: prawo UE podąża za twoim outputem

Częste założenie mówi, że startup zarejestrowany w USA, UK albo gdziekolwiek poza UE jest poza zasięgiem AI Act. Artykuł 2 mówi co innego.

Artykuł 2(1) obejmuje zakresem: providerów wprowadzających systemy AI albo modele GPAI na rynek unijny, niezależnie od miejsca siedziby; deployerów mających siedzibę w Unii; oraz, w Artykule 2(1)(c), providerów i deployerów mających siedzibę w państwie trzecim, gdzie output wytworzony przez system AI jest wykorzystywany w Unii. Ten ostatni punkt dosięga startup SaaS spoza UE. Jeśli twoja funkcja AI produkuje output (podsumowanie, score, wygenerowany dokument, rekomendację) i ten output jest wykorzystywany przez klienta w UE, możesz być objęty zakresem bez żadnego podmiotu w UE i żadnego biura w UE.

„Wykorzystywany w Unii" to niższa poprzeczka niż celowe targetowanie rynku UE. Sprzedaż korporacji, której zespoły w UE używają twojej funkcji AI, wystarczy, by ją uruchomić. Ekspozycja na UE podąża za twoją bazą klientów, nie za miejscem rejestracji, więc jeśli sprzedajesz funkcje AI firmom z operacjami w UE, planuj spełnienie obowiązków dopasowanych do twojej roli, zamiast zakładać, że geografia cię zwalnia.

Kary są wielopoziomowe i dotyczą każdego, kto jest objęty zakresem. Pułapy to 35 milionów EUR albo 7% globalnego rocznego obrotu za praktyki zakazane (Artykuł 5); 15 milionów EUR albo 3% za większość pozostałych naruszeń, w tym obowiązki przejrzystości i GPAI; oraz 7,5 miliona EUR albo 1% za dostarczenie nieprawidłowych albo wprowadzających w błąd informacji. Dla MŚP i startupów obowiązuje niższa z dwóch wartości: kwota stała albo procent.

Uwaga o harmonogramie

Daty, które musisz śledzić, zależą od tego, jaki obowiązek cię dotyczy. Praktyki zakazane i obowiązek kompetencji AI z Artykułu 4 obowiązują od 2 lutego 2025. Obowiązki GPAI obowiązują od 2 sierpnia 2025. Przejrzystość z Artykułu 50 i większość obowiązków wysokiego ryzyka z Załącznika III wchodzą w życie 2 sierpnia 2026, a AI wysokiego ryzyka wbudowane w regulowane produkty z Załącznika I od 2 sierpnia 2027.

Pakiet upraszczający znany jako Digital Omnibus przesuwa daty dla wysokiego ryzyka (Załącznik III na 2 grudnia 2027, Załącznik I na 2 sierpnia 2028). Został przyjęty przez Parlament 16 czerwca 2026 i przez Radę 29 czerwca 2026, a stanie się prawnie wiążący po publikacji w Dzienniku Urzędowym, na lipiec 2026 wciąż oczekującej. Do momentu publikacji obowiązują daty bazowe podane powyżej, a obowiązki przejrzystości i GPAI nie są tym, co przesuwa Omnibus. Planuj według dat bazowych i traktuj przesunięcie jako potwierdzone dopiero po publikacji.

Obowiązki przejrzystości na funkcjach, z którymi stykają się użytkownicy

Artykuł 50 to część AI Act najbardziej bezpośrednio związana z powierzchnią twojego produktu i obowiązuje od 2 sierpnia 2026. Mieści się w progu kar 15 milionów EUR albo 3%.

Trzy z jego obowiązków są typowe dla SaaS:

• Ujawnij interakcję z AI. Jeśli twój system wchodzi w bezpośrednią interakcję z człowiekiem (chatbot, agent głosowy, copilot), musisz zapewnić, że osoba wie, że ma do czynienia z AI, chyba że jest to oczywiste z kontekstu. Ujawnienie musi nastąpić przy pierwszej interakcji, nie zakopane w stopce.
• Oznacz treści syntetyczne. Providerzy systemów generujących syntetyczne audio, obraz, wideo albo tekst muszą oznaczać output w formie maszynowo odczytywalnej, wykrywalnej jako sztucznie wygenerowany albo zmanipulowany. Jeśli twój produkt generuje media, to spada na ciebie jako providera tej funkcji.
• Poinformuj o rozpoznawaniu emocji i kategoryzacji biometrycznej. Jeśli funkcja robi jedno albo drugie, musisz poinformować osoby, które są na to wystawione.

To głównie obowiązki produktowe i UX, tanie do spełnienia, jeśli wbudujesz je wcześnie, i drogie do domontowania później. Komisja opublikowała projekt wytycznych i Kodeks Postępowania w sprawie oznaczania treści wygenerowanych przez AI z praktycznymi metodami; dostosowanie się do nich w miarę ich finalizowania to droga najmniejszego tarcia.

O co naprawdę zapytają twoi kupujący

Regulator to jedno źródło presji. Twoi klienci enterprise to drugie, a dla startupu presja klientów zwykle przychodzi pierwsza, przez procurement. Gdy firma kupuje twoją funkcję AI, stajesz się częścią jej łańcucha dostaw AI, a jej proces vendor risk ma teraz wbudowane pytania specyficzne dla AI.

Spodziewaj się tego w kwestionariuszach bezpieczeństwa i negocjacjach DPA:

• Czy trenujesz na danych klienta? To pierwsze pytanie, a odpowiedź musi być jednoznaczna i spójna w DPA, odpowiedziach na kwestionariusz i zachowaniu produktu. „Nie używamy danych klienta do trenowania modeli" jest prawdą tylko wtedy, gdy potwierdzają to warunki dostawcy modelu i gdy odpowiednio skonfigurowałeś API.
• Którzy providerzy modeli są subprocessorami? Jeśli wywołujesz hostowany model, który przetwarza dane klienta, ten provider jest subprocessorem. Kupujący chcą go widzieć na liście subprocessorów wraz z lokalizacją, tak jak każdego innego subprocessora, i chcą prawa do powiadomienia o zmianach.
• Czy skonfigurowałeś retencję i opt-out z trenowania? Samo wskazanie dostawcy nie wystarczy. Kupujący i audytorzy coraz częściej proszą o dowód, że wyłączyłeś retencję danych i trenowanie na inputach tam, gdzie dostawca to oferuje, oraz że warunki obsługi danych konkretnego modelu, którego używasz, są zgodne z obowiązkami RODO kupującego.
• Jakie jest twoje stanowisko w DPA co do AI? Kompletne DPA, spełniające wymogi Artykułu 28 RODO, z ujawnionymi subprocessorami AI, to standardowe żądanie kupujących enterprise. Standardowe klauzule umowne mogą być potrzebne tam, gdzie provider modelu przetwarza dane poza UE.

Wyprzedzenie tego to głównie kwestia spójności. Najszybciej zamykane są transakcje, w których twoje DPA, strona z subprocessorami, odpowiedzi na kwestionariusz i faktyczna konfiguracja mówią to samo.

Jak AI pojawia się w dokumentacji SOC 2 i ISO

SOC 2 i ISO 27001 nie mają osobnego „modułu AI", ale audytorzy w 2026 testują dowody specyficzne dla AI w ramach istniejących kontroli, a kupujący tego oczekują. Kilka zasad utrzymuje to w porządku:

• Twój raport potwierdza twoje kontrole, nie kontrole dostawcy. Raport SOC 2 albo ISO 27001 providera modelu to element twojej dokumentacji zarządzania dostawcami, nie substytut twojego własnego raportu. Procurement enterprise pyta o oba: audytowaną postawę aplikacji, którą kupują (twoją), oraz dowód, że twoi subprocessorzy sami są audytowani.
• Dostawcy AI podlegają vendor risk. Każdy model firmy trzeciej, który wywołujesz, powinien mieć na koncie ocenę ryzyka dostawcy, tak jak każdy inny subprocessor, wraz z własnym certyfikatem SOC 2 albo ISO providera i twoim zapisem konfiguracji obsługi danych.
• Shadow AI podważa dowody. Jeśli inżynierowie przesyłają dane firmy albo klienta do niezatwierdzonych narzędzi AI, wprowadziłeś niezweryfikowanych subprocessorów, którzy omijają change management i przegląd dostawców. Audytorzy coraz częściej to sprawdzają, więc warto utrzymywać inwentarz tego, które narzędzia AI dotykają jakich danych.
• ISO/IEC 42001 to warstwa specyficzna dla AI. Tam, gdzie ISO 27001 zabezpiecza środowisko informacyjne, ISO/IEC 42001 rządzi systemem zarządzania AI na tym fundamencie. Dla startupu jest opcjonalne, ale czysto mapuje się na kilka obowiązków AI Act i staje się rozpoznawalnym sygnałem w procurement.

Setup governance dopasowany do małego zespołu

Nie potrzebujesz działu governance. Potrzebujesz kilku artefaktów, które są na bieżąco, oraz paru punktów decyzyjnych wbudowanych w to, jak wdrażasz. Działający fundament:

1. Inwentarz funkcji AI i modeli za nimi. Dla każdej funkcji: który model, hostowany czy własny, jakie dane do niego płyną, i wstępna klasyfikacja względem Załącznika III (wysokiego ryzyka albo nie). Każda inna odpowiedź jest budowana z tego.
2. Ustalenie roli dla każdej funkcji. Jesteś deployerem, providerem (bo zabrandowałeś albo istotnie zmodyfikowałeś), czy providerem GPAI (bo fine-tunowałeś powyżej progu albo wypuściłeś model)? Sprawdzaj to ponownie, ilekroć rebrandujesz model albo zaczynasz istotny fine-tuning, to działania wyzwalające.
3. Rejestr dostawców modeli, który jednocześnie jest listą subprocessorów. Dostawca, lokalizacja, warunki obsługi danych, konfiguracja retencji i trenowania, oraz kopia ich raportu SOC 2 albo ISO. To zasila zarówno twoje due diligence pod AI Act, jak i kwestionariusze kupujących.
4. Przejrzystość wbudowana w produkt. Ujawnienie interakcji z AI i oznaczanie treści syntetycznych zaprojektowane przed terminem z Artykułu 50, nie domontowane po tym, jak zgłosi to klient.
5. Spójne stanowisko co do użycia danych. Jedno jasne stwierdzenie o trenowaniu i retencji, odzwierciedlone identycznie w DPA, stronie subprocessorów, odpowiedziach na kwestionariusz i faktycznej konfiguracji.
6. Kompetencje AI dla zespołu. Artykuł 4 wymaga, od 2 lutego 2025, by providerzy i deployerzy zapewnili wystarczający poziom kompetencji AI wśród personelu obsługującego systemy AI. Dla małego zespołu to lekki obowiązek: osoby, które budują i wypuszczają funkcje AI, powinny rozumieć ograniczenia modelu, zasady dotyczące danych i obowiązki ujawnienia.

Większość tego zwraca się w szybszych transakcjach enterprise, bo te same artefakty odpowiadają zarówno regulatorowi, jak i kupującemu.

Sources

• Article 25: Responsibilities along the AI value chain · https://artificialintelligenceact.eu/article/25/ (warunki przekształcenia deployera w providera, nazwa/znak towarowy, istotna modyfikacja, nadpisanie umowy)
• Article 25: Responsibilities along the AI value chain, AI Act Service Desk (European Commission) · https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-25 (podstawowa nawigacja po warunkach Art. 25 i obowiązkach providera)
• Article 2: Scope · https://artificialintelligenceact.eu/article/2/ (zasięg eksterytorialny, output wykorzystywany w Unii, kategorie operatorów)
• A Practical Guide to the Extraterritorial Reach of the AI Act, William Fry · https://www.williamfry.com/knowledge/a-practical-guide-to-the-extraterritorial-reach-of-the-ai-act/ („used" jako niższa poprzeczka niż targetowanie na mocy Art. 2(1)(c))
• Article 53: Obligations for Providers of General-Purpose AI Models · https://artificialintelligenceact.eu/article/53/ (dokumentacja techniczna, informacje dla podmiotów downstream, polityka praw autorskich, podsumowanie danych treningowych; wyjątek open source)
• General-Purpose AI Models in the AI Act, Questions and Answers (European Commission) · https://digital-strategy.ec.europa.eu/en/faqs/general-purpose-ai-models-ai-act-questions-answers (fine-tuning downstream jako provider, orientacyjne kryterium jednej trzeciej mocy obliczeniowej treningu)
• Article 50: Transparency Obligations · https://artificialintelligenceact.eu/article/50/ (ujawnienie interakcji z AI, oznaczanie treści syntetycznych, rozpoznawanie emocji; obowiązuje od 2 sierpnia 2026)
• Code of Practice on marking and labelling of AI-generated content, Shaping Europe's digital future (European Commission) · https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content (praktyczne metody oznaczania z Art. 50)
• Council and Parliament agree to simplify and streamline rules, Consilium (Council of the EU) · https://www.consilium.europa.eu/en/press/press-releases/2026/05/07/artificial-intelligence-council-and-parliament-agree-to-simplify-and-streamline-rules/ (wstępne porozumienie w sprawie Digital Omnibus, 7 maja 2026; od tego czasu przyjęte przez Parlament 16 czerwca i Radę 29 czerwca 2026)
• EU AI Act Omnibus Agreement, Gibson Dunn · https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/ (przesunięcie na 2 grudnia 2027 / 2 sierpnia 2028; do publikacji w Dzienniku Urzędowym obowiązują daty bazowe)
• What Security Questionnaires Should Ask AI Vendors, Delve · https://delve.co/blog/what-security-questionnaires-should-ask-ai-vendors (pytania kupujących o trenowanie, subprocessorów, retencję)
• SOC 2 for AI Companies (2026): What Auditors Test First · https://soc2auditors.org/insights/soc-2-for-ai-companies/ (dowody SOC 2 specyficzne dla AI; providerzy LLM jako subprocessorzy; SOC 2 dostawcy to nie substytut; shadow AI)
• ISO 42001 vs SOC 2 vs ISO 27001, AI Vendor Compliance Comparison, Knowlee · https://www.knowlee.ai/blog/iso-42001-vs-soc2-vs-iso-27001-comparison (jak ISO 42001 nakłada się na ISO 27001 i SOC 2 w governance AI)
• The SaaS DPA Guide, Secure Privacy · https://secureprivacy.ai/blog/data-processing-agreements-dpas-for-saas (wymogi DPA z Artykułu 28 RODO, listy subprocessorów, SCC)