Co inwestorzy naprawdę sprawdzają w startupie AI: dane, zgodność i ryzyka bezpieczeństwa przed term sheetem

Po co inwestorzy tak dokładnie zaglądają w dane i bezpieczeństwo w startupie AI

Założyciel startupu AI zwykle myśli kategoriami: produkt, technologia, trakcja, runda. Inwestor – szczególnie przy AI – coraz częściej myśli: ryzyko regulacyjne, ryzyko prawne, ryzyko reputacyjne. Gdy dochodzi do term sheetu, „czy to działa” schodzi na dalszy plan, a na stół wjeżdża pytanie: „czy to da się skalować bez wybuchu skandalu lub pozwu?”.

AI zmieniła perspektywę VC z zachwytu nad „magią modeli” na twardą analizę tego, na czym stoją modele: na jakich danych są trenowane, jak są zabezpieczone, kto do nich ma prawa i czy regulator za chwilę nie uzna rozwiązania za nielegalne lub wysokiego ryzyka. Dlatego obszary danych, zgodności (RODO, AI Act) i bezpieczeństwa są dziś równie kluczowe jak zespół czy przychody. A czasem ważniejsze – bo prostsze jest dobudowanie sprzedaży niż wyczyszczenie toksycznych danych treningowych użytych „na dziko” dwa lata wcześniej.

Inwestorzy przy AI widzą dodatkowo trzy ostrzejsze niż zwykle wektory zagrożeń:

• Regulacje – RODO, sektorówki (med, fin), nadchodzący AI Act. Każda z nich może wielokrotnie podnieść koszt skalowania lub zablokować produkt w wybranych branżach.
• Prawo i IP – spory o prawa autorskie do danych, kontrowersje wokół trenowania modeli na danych publicznych, konflikty z dostawcami danych lub byłymi pracodawcami założycieli.
• Reputacja – wyciek danych klientów, „rasistowski” lub dyskryminujący model, hallucinacje w medtechu prowadzące do złych rekomendacji. Media i regulatorzy uwielbiają takie historie.

Na tym tle pitch o „rewolucyjnej sieci neuronowej” brzmi dla profesjonalnego inwestora jak teaser, nie jak sedno sprawy. Sednem jest, czy z perspektywy funduszu ten startup AI jest skalowalny przy akceptowalnym ryzyku. A to oznacza, że due diligence danych, zgodności i bezpieczeństwa rozpoczyna się często jeszcze przed formalnym due diligence, już na etapie głębszych rozmów przed term sheetem.

W praktyce bywa tak: prezentacja produktu, demo, referencje od klientów – wszystko wygląda świetnie. Fundusz jest „na tak”, dostajecie maila o przygotowaniu term sheetu, po czym techniczny partner zadaje kilka „niewinnych” pytań o pochodzenie danych treningowych i zgody klientów. Po tygodniu wychodzi, że połowa modelu stoi na danych zebranych z sieci bez podstawy prawnej, a w umowach z pierwszymi klientami nie ma ani słowa o trenowaniu na ich danych. Term sheet znika. Technologia się nie zmieniła, ale ryzyko prawne urosło do poziomu, którego fundusz nie chce dotykać.

Jak inwestorzy patrzą na dane w startupie AI: od źródeł po legalność użycia

Dla większości founderów „mamy dane” oznacza zbiory w S3, kilka baz produkcyjnych i jakieś logi w narzędziu analitycznym. Dla inwestora – szczególnie przy AI – to za mało. Liczy się: skąd dane pochodzą, kto ma do nich prawa, co wolno z nimi robić i jak to jest udokumentowane.

Kluczowe kategorie danych w startupie AI

Porządkowanie tematu zaczyna się od nazwania, z jakimi typami danych firma faktycznie pracuje. Najczęściej w startupach AI pojawiają się cztery kategorie:

• Dane treningowe – wszystko, na czym były trenowane, dostrajane lub walidowane modele (teksty, obrazy, logi użytkowników, dane sensorów, rozmowy z call center itd.). To jest „paliwo” waszego AI.
• Dane operacyjne – dane powstające w trakcie działania systemu (logi działania modeli, metryki, dane o błędach, telemetryczne dane z użytkowania produktu).
• Dane klientów/użytkowników – to, co klient świadomie lub pośrednio przekazuje systemowi (inputy, dokumenty, nagrania, metadane, wyniki działania modelu, profile zawodowe, informacje biznesowe).
• Logi i metadane systemowe – zapisy żądań do modeli, konteksty promptów, ID użytkowników, informacje o źródłach danych. Często traktowane po macoszemu, a w praktyce potrafią zawierać mnóstwo danych osobowych lub tajemnic przedsiębiorstwa.

Technicznie widać to jako kolejne bucket’y, bazy czy tematy w systemach kolejkowych. Inwestorów interesuje jednak, jak każda z tych kategorii jest uregulowana: jakie są podstawy prawne przetwarzania, kto ma prawa majątkowe, jakie obowiązują ograniczenia sektorowe, czy użytkownicy zostali o tym poinformowani i co zapisano w umowach.

Pytania inwestora o źródła i prawa do danych

Podczas rozmów poprzedzających term sheet inwestorzy zadają coraz bardziej konkretne pytania. W uproszczeniu można je streścić tak:

• Skąd dokładnie pochodzą dane treningowe? Własne generowane w aplikacji, kupione od agregatora, z partnerstw z klientami, z publicznych repozytoriów, z web scrapingu, z open source?
• Kto ma prawa do tych danych i na jakiej podstawie? Licencja, cesja praw, wynik przepisów (np. prawa do dokumentacji medycznej), open license, domena publiczna?
• Jakie są ograniczenia licencyjne? Czy licencja pozwala na trenowanie modeli AI? Czy dopuszcza komercyjne wykorzystanie? Czy zabrania łączenia z innymi zbiorami? Czy pozwala na sublicencjonowanie lub współdzielenie outputów?
• Czy klient wie, że jego dane są wykorzystywane do trenowania modelu? Czy zgodził się na to w umowie lub polityce prywatności, czy tylko „domyślnie to zakładamy”?
• Czy występują dane osobowe lub wrażliwe? Jeżeli tak – czy ich użycie do trenowania modeli jest oparte na solidnej podstawie prawnej?

Różnica między „mamy dane” a „mamy dane, których wolno nam używać komercyjnie i do trenowania modeli” jest dla inwestora fundamentalna. Pierwsze oznacza fajny PoC. Drugie – realny, skalowalny biznes.

Typowe czerwone flagi przy due diligence danych

Fundusze szukają sygnałów, że coś jest nie tak z fundamentami danych. Pojawienie się kilku z nich naraz zwykle oznacza mocne ochłodzenie entuzjazmu:

• Scraping bez podstawy prawnej – startup AI trenuje model NLP na zeskrobanych artykułach prasowych, profilach LinkedIn lub ogłoszeniach o pracę, ale nie ma żadnej analizy legalności takiego użycia ani zgód. Na hasło „prawa autorskie” w zespole zapada niezręczna cisza.
• „Pożyczone” dane z poprzedniego miejsca pracy – założyciel wyniósł z korporacji zanonimizowany dataset i „tylko trochę go podczyszczono”. Bez pisemnej zgody i przeniesienia praw to tykająca bomba.
• Niejasne umowy z dostawcami danych – startup kupuje dane od hurtownika, ale w umowie jest tylko ogólne „licencja na korzystanie”, bez słowa o trenowaniu modeli, sublicencjach czy prawach do outputów.
• Brak rozróżnienia danych klientów i danych do trenowania – w polityce prywatności nie ma ani słowa o używaniu danych użytkowników do poprawy modeli, a w praktyce wszystko ląduje w jednym worku i jest intensywnie wykorzystywane do retrainingu.
• Brak jakiejkolwiek dokumentacji pochodzenia danych – na pytanie „na czym trenowaliście model” odpowiedź brzmi „na wielu źródłach, nie mamy tego teraz rozpisanego”. Dla inwestora to trochę jak prośba o przelew bez numeru konta.

Te „małe” rzeczy w oczach foundera są dla inwestora potencjalnym źródłem pozwów, ugód i konieczności drogiego retrainingu modeli. Dlatego weryfikacja źródeł i legalności danych często decyduje o tym, czy rozmowy przejdą w formalne due diligence, czy zakończą się grzecznym „wróćmy do rozmowy za jakiś czas”.

Własność i licencje na dane treningowe – co musi się zgadzać

Dla startupu AI dane treningowe i spójna polityka licencji są tym, czym dla firmy hardware’owej linia produkcyjna: bez nich nie ma mowy o poważnej wycenie. Inwestor patrzy nie tylko na to, czy dane są „fajne”, ale przede wszystkim, czy startup ma do nich jasne, egzekwowalne prawa i czy te prawa przenoszą się na modele i komercyjny produkt.

Modele pozwoleń na korzystanie z danych treningowych

Najczęściej spotykane scenariusze źródeł danych w startupach AI można uprościć do kilku modeli. Każdy z nich budzi inne pytania w głowie inwestora:

Inwestorzy zazwyczaj lubią kombinację: core na własnych i klientowskich danych, z rozsądnym użyciem danych zewnętrznych. Bardzo ostrożnie podchodzą do biznesów opartych niemal wyłącznie na web scrapingu, szczególnie w kontekście danych osobowych czy treści chronionych prawem autorskim.

Kluczowe zapisy w umowach z dostawcami danych

Jeśli startup korzysta z danych zewnętrznych (dostawca danych, partner strategiczny, klient), inwestor będzie chciał wiedzieć, co dokładnie jest w umowach. Krytyczne są fragmenty, które często na początku traktowane są jak „prawnicze bla-bla”, a później decydują o tym, czy model należy faktycznie do startupu, czy tylko mu się tak wydaje.

Przy przeglądzie kontraktów fundusze zwracają szczególną uwagę na:

• Pola eksploatacji – czy licencja obejmuje jasno:
  • trenowanie modeli uczenia maszynowego i AI,
  • tworzenie pochodnych modeli i produktów,
  • komercyjne wykorzystanie na całym świecie.
• AI/ML usage – czy wprost dopuszcza trenowanie algorytmów i modeli na tych danych. Jeżeli to nie jest jasno napisane, część prawników inwestora uzna to za poważne ryzyko.
• Prawa do modeli i outputów – idealnie: klient/dostawca zachowuje prawa do swoich surowych danych, ale model i wygenerowane na jego bazie outputy należą w całości do startupu (lub przynajmniej ma on pełne prawo do ich komercyjnego wykorzystania).
• Sublicencje i udostępnianie – czy startup może:
  • budować rozwiązania dla wielu klientów na jednym wspólnym modelu,
  • udostępniać dane lub ich pochodne innym podmiotom (np. partnerom technologicznym),
  • przenieść prawa przy exit’cie lub sprzedaży aktywów.
• Ograniczenia sektorowe i geograficzne – np. dane mogą być używane tylko w konkretnym kraju lub branży, albo nie mogą być wykorzystywane w sektorze finansowym czy medycznym.

Brak tych zapisów nie oznacza automatycznie końca rozmów, ale dla inwestora to sygnał, że przy większej skali można się spodziewać sporów o to, kto ma prawo zarabiać na modelach i na jaką skalę.

Jak sensownie dokumentować pochodzenie danych (data lineage)

Pełny enterprise’owy system data lineage to dla wczesnego startupu przesada. Ale całkowity brak jakiejkolwiek dokumentacji to z kolei powód do nerwowych pytań. Inwestora zwykle uspokaja prosty, ale spójny obraz:

• Mapa głównych źródeł danych – lista kluczowych datasetów z krótkim opisem:
  • skąd pochodzą (np. produkt SaaS, partner X, zakup od Y, open dataset Z),
  • czy zawierają dane osobowe (jakie kategorie),
  • na jakiej podstawie prawnej są przetwarzane (RODO),
  • jaka obowiązuje licencja/podstawa korzystania.
• Powiązanie datasetów z modelami – informacja, które konkretnie zbiory danych były użyte do trenowania/finetuningu danego modelu.
• Historia większych zmian – daty większych „przebudów” modelu, np. nowa wersja modelu z innym zbiorem danych, wprowadzenie danych klientowskich, zmiana źródła zewnętrznego.

Co z modelami foundation i API od Big Techu?

Coraz więcej startupów AI nie trenuje modelu „od zera”, tylko opiera się na foundation models (open source lub komercyjnych) i API od dużych dostawców. Dla inwestora to nie jest minus – pod warunkiem, że łańcuch praw i ograniczeń jest przejrzysty. Pojawiają się wtedy dodatkowe pytania:

• Na jakiej licencji jest model bazowy? Czy to Apache/MIT, czy raczej licencja z ograniczeniami komercyjnymi, zakazem określonych zastosowań lub „copyleftem”, który może „zarazić” wasz produkt?
• Czy outputy są w pełni wasze? Nie każdy dostawca API gwarantuje pełne przeniesienie praw do generowanych treści lub modeli powstałych na bazie jego infrastruktury.
• Czy provider może używać waszych danych do trenowania? Jeżeli tak, to:
  • czy klient końcowy jest o tym informowany,
  • czy macie możliwość wyłączenia tego w panelu / umowie,
  • jak to wygląda pod kątem RODO (role: administrator–podmiot przetwarzający).
• Co się dzieje przy zmianie dostawcy? Czy możecie przenieść finetunowany model lub przynajmniej embeddingi/feature’y do innego środowiska bez naruszenia licencji?

Fundusz zwykle poprosi o listę kluczowych dostawców technologicznych (OpenAI, Anthropic, Google, AWS, Azure, Hugging Face itd.), wraz z krótką notatką, jak ich używacie: czy tylko inference, czy też trenowanie; czy dane klientów przechodzą przez te serwisy; czy macie podpisane DPA i dodatkowe aneksy regulujące AI.

„Ownership” modeli trenowanych na danych klientów

W B2B AI bardzo często pada pytanie: „Kto jest właścicielem modelu trenowanego na moich danych?”. Dla startupu idealny scenariusz to:

• klient zachowuje prawa do swoich danych wejściowych,
• startup ma szeroką licencję na ich używanie w celu trenowania i poprawy modeli,
• model (zwłaszcza część „shared” służąca wielu klientom) należy do startupu,
• klient ma prawo korzystać z usługi, ale nie ma praw do „wyniesienia” modelu poza waszą platformę.

Inwestor sprawdza, czy:

• w kluczowych umowach nie ma zapisu typu „wszystkie modele powstałe na bazie danych klienta są własnością klienta”, który parkuje IP w korporacji,
• nie tworzycie „zamku z piasku” – supermodelu dla jednego enterprise, którego nie wolno wam użyć przy kolejnym kliencie,
• macie spójne zasady dla klientów różnej wielkości, a nie 10 sprzecznych wariantów wynegocjowanych ad hoc.

Jeżeli zdarzył się nieidealny kontrakt (np. pierwszy duży klient dostał za szerokie prawa), dobrze jest to po prostu nazwać i pokazać plan „naprostowania” kolejnych umów. VC bardziej boi się chaotycznej sytuacji niż pojedynczego słabszego case’u, który jest pod kontrolą.

Zgodność z RODO/GDPR, AI Act i innymi regulacjami – praktyczny filtr inwestora

Przy startupach AI dyskusja o regulacjach to już nie jest „problem na później”. Inwestorzy zakładają, że im większa skala, tym większa szansa, że regulator zapuka do drzwi albo trafi się klient z działem compliance, który zada niewygodne pytania. Dlatego patrzą, czy zespół ma choćby podstawowy, ale realny plan gry.

Jak inwestor „czyta” wasze podejście do RODO

Z punktu widzenia funduszu liczy się kilka praktycznych elementów. Nie chodzi o to, żebyście mieli setki stron polityk, tylko czy kluczowe ryzyka są zaadresowane.

• Świadomość roli w łańcuchu przetwarzania – czy wiecie, kiedy jesteście:
  • administratorem danych (np. własny produkt B2C),
  • procesorem (np. usługa dla klientów B2B, którzy są administratorami),
  • współadministratorem (wspólna platforma / data sharing).
• Podstawa prawna dla trenowania modeli – zwłaszcza, gdy:
  • używacie danych osobowych użytkowników do „poprawy usługi”,
  • robicie personalizację rekomendacji lub scoring.

  Czy potraficie konkretnie wskazać:

  • zgodę,
  • prawnie uzasadniony interes (i macie zrobiony test równowagi),
  • inną podstawę (np. wykonanie umowy).
• Data minimisation i retencja – czy istnieją jakiekolwiek reguły:
  • kiedy dane surowe są usuwane lub anonimizowane,
  • jak długo trzymacie logi rozmów z chatbotem,
  • co dzieje się z danymi backupowymi przy wypowiedzeniu umowy.
• Mechanizmy realizacji praw podmiotów danych – prawo do bycia zapomnianym, dostępu, sprzeciwu wobec profilowania. Inwestor pyta:
  • czy macie proces (choćby półmanualny) reagowania na takie wnioski,
  • czy potraficie technicznie „wyciągnąć” dane danej osoby z pipeline’u treningowego.

Nie chodzi o to, by od razu mieć perfekcyjnie zautomatyzowane narzędzia. Ważniejsze jest, że istnieje świadome minimum i zespół rozumie, gdzie są granice ryzyka, a gdzie „low hanging fruits” do poprawy.

AI Act i inne regulacje sektorowe – sygnały dla VC

AI Act wprowadza kategorie ryzyka (minimalne, ograniczone, wysokie, zakazane). Dla inwestora kluczowe pytanie brzmi: w której kategorii ląduje wasz produkt i czy zespół wie, co z tego wynika. Typowe punkty zaczepienia:

• Use case’y wysokiego ryzyka – scoring kredytowy, rekrutacja, infrastruktura krytyczna, opieka zdrowotna, edukacja. Jeżeli celujecie w te obszary, fundusz oczekuje przynajmniej ogólnego planu dostosowania:
  • dokumentacja danych treningowych,
  • oceny ryzyka, testy jakości i biasu,
  • rejestrowanie decyzji modelu,
  • nadawanie i egzekwowanie ról (kto „zatwierdza” model do produkcji).
• Transparency obligations – czy użytkownik wie, że rozmawia z AI, a nie z człowiekiem? Czy komunikujecie, że odpowiedź jest wygenerowana automatycznie, a nie jest „doradztwem prawnym/medycznym”? Prozaiczne elementy UX bywają analizowane w due diligence.
• Zakazane praktyki – np. niektóre formy social scoringu. Jeśli produkt choćby ociera się o te obszary, inwestorzy wchodzą w tryb alarmowy: „czy naprawdę chcemy to firmować?”
• Regulacje sektorowe – fintech, medtech, insurtech, edtech. Oprócz AI Act i RODO dochodzą:
  • prawo bankowe i nadzory (KNF i odpowiedniki),
  • regulacje medyczne (wyroby medyczne, MDR),
  • normy edukacyjne i ochrona małoletnich.

  VC sprawdza, czy ktoś w zespole realnie „przeczytał” wymagania branży, czy tylko liczy, że klient „weźmie odpowiedzialność na siebie”.

Nie każdy startup musi od razu zostać pół-prawniczą kancelarią. Chodzi raczej o to, by w rozmowie inwestor nie miał wrażenia, że temat regulacji to „nie nasza sprawa, my tylko budujemy model”.

Minimalny „compliance stack”, który robi dobre wrażenie

Przy rundach seed/Series A fundusze nie oczekują pełnej struktury korporacyjnej, ale lubią widzieć kilka prostych elementów:

• Polityka prywatności i regulamin – napisane językiem, który ktoś w zespole rozumie, a nie w całości skopiowane z pierwszego lepszego SaaS-a. Z jasną sekcją dotyczącą AI i trenowania modeli.
• Podstawowe DPIA (Data Protection Impact Assessment) dla najbardziej wrażliwych use case’ów – nawet w formie prostego dokumentu Google z opisem ryzyk i środków zaradczych.
• Data Processing Agreement (DPA) – choćby wzór, który dajecie klientom B2B, jasno opisujący:
  • co robicie z danymi,
  • czy i jak używacie ich do trenowania,
  • kto jest administratorem, a kto procesorem.
• Rejestr głównych procesów przetwarzania – prosta tabela z kolumnami:
  • „Jaki proces” (np. logi produktu, trenowanie modelu X, wsparcie klienta),
  • „Jakie dane”,
  • „Po co”,
  • „Jak długo”,
  • „Podstawa prawna”.

Taki niewielki „pakiet” często robi lepsze wrażenie niż ładne slajdy o „etical AI”, za którymi nie stoją żadne realne procedury.

Bezpieczeństwo danych i modeli: o co pytają techniczni partnerzy VC

Gdy do rozmowy dołącza partner techniczny funduszu lub zewnętrzny audytor, fokus przesuwa się z „czy wolno wam to robić” na „czy umiecie to robić bezpiecznie”. Chodzi zarówno o klasyczne bezpieczeństwo danych, jak i specyficzne ryzyka modeli AI.

Podstawy security, bez których trudno o zaufanie

Nie każdy startup musi mieć od razu SOC 2, ISO 27001 i dedykowany zespół security. Zaskakująco często wystarczy kilka rozsądnych fundamentów, by nie zapalić czerwonej lampki:

• Kontrola dostępu do danych i modeli – kto może:
  • ściągnąć dane treningowe,
  • zmienić konfigurację modelu produkcyjnego,
  • podejrzeć logi użytkowników.

  Czy stosujecie least privilege, SSO, 2FA, czy nadal „wszyscy mają dostęp do wszystkiego, bo tak szybciej”?

• Szyfrowanie – dane:
  • w spoczynku (bazy danych, blob storage, backupy),
  • w tranzycie (TLS wszędzie, w tym wewnątrz VPC, jeżeli dane są wrażliwe).
• Segregacja środowisk – development, staging, produkcja. Inwestorzy są uczuleni na historie typu „modele trenowane na danych produkcyjnych na laptopach devów”.
• Podstawowe logowanie i monitoring – niekoniecznie SIEM od pierwszego dnia, ale przynajmniej:
  • logi dostępu do danych i modeli,
  • podstawowe alerty na podejrzane zachowania (np. masowy export danych).

Najgorszy sygnał to „security? korzystamy z chmury X, więc wszystko jest bezpieczne”. Chmura daje narzędzia, ale ktoś musi je sensownie skonfigurować.

Specyficzne ryzyka dla modeli AI

Modele wprowadzają nowe vektory ataku, o których tradycyjne aplikacje nie musiały myśleć. Z perspektywy funduszu ważne są zwłaszcza:

• Prompt injection i data exfiltration – użytkownik „przekonuje” model do ujawnienia danych z systemu (np. innych klientów) lub wykonania niepożądanych akcji. Pytania inwestora:
  • czy stosujecie content filtering i guardraile,
  • czy model ma dostęp do danych kontekstowych w sposób ograniczony (per użytkownik/tenant),
  • czy testujecie system pod kątem ataków prompt injection (choćby manualnie).
• Training data poisoning – złośliwe dane w danych treningowych lub feedback loop, w którym użytkownicy mogą „przekrzywić” model. Fundusze pytają:
  • skąd pochodzą dane do retrainingu,
  • czy istnieje jakikolwiek proces walidacji (np. ręczne review części próbek),
  • czy feedback użytkowników jest ważony/filtrwany.
• Model extraction i IP leakage – możliwość odtworzenia waszego modelu przez intensywne query’owanie API lub „wycieku” wag. Częste zagadnienia:
  • limity zapytań i rate limiting,
  • kontrola nad tym, kto może korzystać z API i w jakim zakresie,
  • czy w repozytoriach (Git) nie wiszą przypadkiem wagi modelu lub klucze dostępowe.

Techniczny partner VC nie oczekuje, że będziecie mieć zaimplementowaną każdą możliwą technikę z akademickich paperów. Chce zobaczyć, że ktoś faktycznie o tym myśli i ma choćby bazowy plan zabezpieczenia „dziur największego kalibru”.

Bezpieczeństwo multi-tenant i izolacja danych klientów

Startupy B2B często budują wspólny model obsługujący wielu klientów („multi-tenant”). Dla inwestora kluczowe pytanie brzmi: czy dane klientów są naprawdę izolowane, czy to tylko marketing.

• Separacja na poziomie danych – czy:
  • stosujecie wyraźne identyfikatory tenantów w bazach,
  • macie testy regresyjne sprawdzające, że zapytanie klienta A nie może zwrócić danych klienta B,

  Architektura a „przypadkowe” przecieki między klientami

  Izolacja danych to w dużej mierze temat architektury. Gdy fundusz widzi „jedną wielką bazę z tabelą users i polem client_id”, zaczyna drążyć:

  • Poziom izolacji – czy każdy klient:
    • ma własną bazę / schemat,
    • czy izolacja opiera się wyłącznie na logice aplikacji (check w kodzie „WHERE tenant_id = …”).

    Pierwszy wariant jest droższy operacyjnie, ale często spokojniej śpi się na due diligence.

  • Testy bezpieczeństwa w CI/CD – czy w testach automatycznych są przypadki:
    • „użytkownik klienta A próbuje odczytać dane klienta B”,
    • symulacji różnych ról (admin, user, support) i ich uprawnień.

    Inwestor techniczny lubi zobaczyć, że to nie jest jednorazowy pentest, tylko coś, co faktycznie broni się w codziennym developmentcie.

  • Feature’y per klient – jeśli model lub pipeline danych różni się w zależności od klienta (np. „enterprise ma osobne trenowanie”), fundusz pyta:
    • czy jest ryzyko pomylenia ścieżek (np. dane enterprise trafiają do „shared modelu”),
    • jak monitorujecie, na jakich danych faktycznie trenował się dany artefakt modelu.

  Do tego dochodzi klasyka: czy support ma możliwość „wejścia” w konto klienta i co się wtedy loguje. Kilku dużych klientów z USA potrafi zadać dokładnie to samo pytanie, które pada na spotkaniach z VC.

  Model jako wektor wycieku danych

  Przy modelach foundation i własnych LLM dochodzi specyficzny problem: model może „zapamiętywać” dane treningowe i ujawniać je w odpowiedziach. Na slajdzie wygląda to niewinnie, ale w due diligence padają bardzo konkretne pytania:

  • Jakie dane trafiły do treningu? – czy w zbiorach są:
    • dane osobowe,
    • dane klientów B2B (np. dokumenty umów, bazy CRM),
    • tajemnice przedsiębiorstw (np. wewnętrzne polityki dużych korporacji).
  • Jak minimalizujecie memorize & regurgitation – czy:
    • stosujecie deduplikację i filtrację wrażliwych fragmentów,
    • testujecie model pod kątem dokładnego odtwarzania fragmentów danych źródłowych.
  • Granica między fine-tuningiem a RAG – fundusze coraz częściej preferują:
    • retrieval (RAG) dla danych wrażliwych,
    • a nie fine-tuning na danych, których „nie wolno wynieść z pamięci”.

  Proste sanity checki – np. testowe próby „wyciągania” numerów telefonów, adresów mailowych czy konkretnych nazwisk – bywają pozytywnie odnotowywane w notatkach inwestorskich.

  Governance AI w startupie: procedury, role i odpowiedzialności, które uspokajają inwestora

  Po etapie rozmów o danych, regulacjach i security pojawia się kolejne pytanie: kto tym wszystkim zarządza na co dzień. Nawet najlepsze polityki są mało warte, jeśli żyją tylko w Confluence.

  Kto „jest właścicielem” ryzyka AI w zespole

  W małym startupie nikt nie spodziewa się osobnego działu „AI governance”. Jednak inwestorzy chcą wiedzieć, kto faktycznie podejmuje decyzje w spornych sytuacjach. Typowe modele, które dobrze wypadają na spotkaniach:

  • Product + Tech jako wspólni właściciele – PM odpowiada za:
    • definicję use case’ów i ryzyk biznesowych,
    • komunikację z klientami i użytkownikami,

    CTO / Head of AI bierze na siebie:

    • dobór architektury i danych,
    • parametryzację modeli i deployment.

    Ważne, by to było opisane wprost, a nie „jakoś się dogadamy”.

  • „Mini Rada” ds. AI – nawet jeżeli to tylko 3 osoby, regularne (np. kwartalne) spotkania, na których:
    • przeglądane są incydenty i skargi,
    • podejmowane są decyzje o większych zmianach (nowe źródła danych, nowy typ modelu, wejście w obszar wysokiego ryzyka).

    Spisanie z takich spotkań jednej strony notatek wygląda w due diligence znacznie lepiej niż „czasem o tym rozmawiamy na standupie”.

  • Kontakt „od regulacji” – osoba, która:
    • zna podstawy RODO i AI Act,
    • koordynuje kontakty z zewnętrznym prawnikiem,
    • jest w stanie w 10 minut odpowiedzieć na maila klienta o przetwarzaniu jego danych.

    Nie musi siedzieć na pełen etat w compliance, ale powinna mieć to wpisane w zakres obowiązków.

  Proste procedury, które robią zaskakująco duże wrażenie

  Fundusze nie oczekują opasłych regulaminów. Bardziej interesuje je kilka konkretnych „ścieżek postępowania”, które realnie działają:

  • Proces wprowadzania nowego źródła danych – krótki, ale jasny:
    • kto zgłasza potrzebę (np. zespół ML),
    • kto ocenia legalność i ryzyka (np. osoba „od regulacji”),
    • kto zatwierdza i jak to jest udokumentowane (nawet komentarz w Jirze lub Notion).
  • Checklista przed wdrożeniem nowego modelu do produkcji – parę pytań, które trzeba „odhaczyć”:
    • skąd są dane treningowe i czy mamy na nie papiery,
    • czy jest sandbox / feature flag,
    • jak będziemy monitorować skuteczność i błędy (metryki, logi),
    • czy ktoś poza autorem modelu spojrzał na wyniki.
  • Procedura na incydent – uproszczona wersja planu reakcji:
    • jak rozpoznajecie „incydent” (np. wyciek danych, toksyczne odpowiedzi modelu, masowe błędy),
    • kto decyduje o wyłączeniu funkcji / rollbacku,
    • jak wygląda komunikacja do klientów i użytkowników.

    VC lubi słyszeć, że „wyciągacie wtyczkę” bez większych dyskusji, jeśli zagrożone są dane lub reputacja kluczowego klienta.

  Dokumentacja: tyle, ile trzeba, ale nie mniej

  Przy AI governance nietrudno popaść w skrajności: albo nie ma żadnych dokumentów, albo pojawia się 40-stronicowa polityka, której nikt nie czyta. Inwestorzy patrzą raczej na to, czy dokumentacja jest:

  • Oszczędna i aktualna – krótkie, żywe dokumenty:
    • „Jakie mamy modele w produkcji i co robią”,
    • „Jakie dane trafiają do trenowania i skąd” (w formie tabelki),
    • „Jak wygląda flow zgody klienta na użycie jego danych do treningu”.
  • Dostępna dla zespołu – nie chodzi o folder „Legal” zakopany pięć poziomów w Google Drive, tylko:
    • link przypięty w Slacku,
    • sekcja w onboarding handbooku dla nowych devów i data scientistów.
  • Używana w praktyce – na spotkaniach due diligence robi wrażenie, gdy:
    • CTO pokazuje checklistę używaną przy ostatnim wdrożeniu,
    • Head of Product potrafi pokazać konkretny ticket, gdzie przez ryzyko regulacyjne zmieniliście roadmapę.

  Parę zrzutów ekranu z Notion czy Jiry potrafi powiedzieć więcej o kulturze governance niż najlepiej brzmiące slogany o „responsible AI”.

  Cykl życia modelu: od eksperymentu do emerytury

  Modele mają swój cykl życia, a inwestorzy sprawdzają, czy traktujecie je bardziej jak infrastrukturę, a mniej jak jednorazowy projekt hackathonowy. Kilka obszarów szczególnie przyciąga pytania:

  • Eksperymenty vs. produkcja – czy:
    • macie oddzielone środowiska i dane testowe,
    • jasno oznaczacie, które modele są „tylko do PoC”, a które faktycznie wspierają klientów.
  • Monitoring po wdrożeniu – co konkretnie śledzicie:
    • metryki jakości (accuracy, recall, NPS użytkowników),
    • metryki „ryzyka” (np. liczba zgłoszeń na toksyczne odpowiedzi, błędne rekomendacje, false positives).
  • Retiring modelu – czy macie proces „odwieszania” modeli:
    • usuwanie powiązanych danych roboczych i logów,
    • zamrożenie możliwości retrainingu na starych danych,
    • informacja dla klientów, jeśli zmiana wpływa na ich KPI lub obowiązki regulacyjne.

  Przy bardziej regulowanych use case’ach (np. scoring kredytowy, medyczne wspomaganie decyzji) cykl życia modelu bywa jednym z głównych tematów audytu inwestorskiego.

  Feedback użytkowników jako element governance

  Modele AI żyją w interakcji z użytkownikami. Inwestorzy chcą mieć pewność, że sygnały z rynku nie giną w czarnej dziurze Slacka, tylko faktycznie wpływają na produkt i ryzyka.

  • Widoczny kanał zgłoszeń – prosty mechanizm:
    • przycisk „Zgłoś problem z odpowiedzią AI” w produkcie,
    • shortlink w stopce: „Problemy z działaniem AI? Napisz do…”.
  • Triaging zgłoszeń – kto:
    • odbiera zgłoszenia (support / product),
    • oznacza je jako „bug techniczny”, „błąd danych”, „ryzyko regulacyjne/etyczne”.
  • Zamknięta pętla – czy widać:
    • że na podstawie zgłoszeń poprawiliście prompt, model, filtr treści,
    • że klient dostał informację, co zostało zrobione (przynajmniej przy bardziej poważnych incydentach).

  Prosty przykład z życia: po paru skargach użytkowników na „zbyt pewne, ale błędne” odpowiedzi, jeden ze startupów obniżył temperaturę modelu i dodał etykietę „to sugestia, nie instrukcja” w UI. W notatkach z due diligence pojawił się komentarz: „zespół reaguje na feedback, ma sensowny refleks bezpieczeństwa”.

  Szkolenia i „higiena AI” w zespole

  Na koniec pojawia się aspekt kultury organizacyjnej. Fundusze sprawdzają, czy osoby, które codziennie pracują z danymi i modelami, naprawdę rozumieją, gdzie są miny. Kilka rozwiązań, które dobrze wyglądają w oczach inwestora:

  • Krótki onboarding AI & data – dla każdego nowego członka zespołu:
    • co wolno wrzucać do środowisk treningowych (a czego absolutnie nie),
    • jak oznaczać dane wrażliwe,
    • jak zgłaszać potencjalne incydenty bezpieczeństwa lub prywatności.
  • „Brown bag” o regulacjach – raz na kilka miesięcy:
    • krótka prezentacja o zmianach w AI Act / RODO,
    • przykłady z rynku: kto się „wyłożył” i dlaczego,
    • dyskusja o tym, co to znaczy w praktyce dla waszego produktu.

    Nie musi być super formalnie – czasem wystarczy godzina przy pizzy i 10 slajdów.

  • Minimalny kodeks użycia narzędzi AI wewnątrz firmy – zwłaszcza gdy:
    • devowie korzystają z Copilota / ChatGPT do kodu,
    • zespół supportu wrzuca logi klientów do zewnętrznych narzędzi LLM.

    Kilka zdań o tym, jakich danych nie wolno wklejać do publicznych modeli, potrafi uniknąć wielu „kreatywnych” incydentów.

  Dla inwestora taki obraz – nawet jeśli daleki od korporacyjnego ideału – jest sygnałem, że zespół traktuje dane, modele i regulacje nie jako przeszkodę, ale jako część zwykłej inżynieryjnej roboty.

  Najczęściej zadawane pytania (FAQ)

  Co dokładnie inwestorzy sprawdzają w danych startupu AI przed term sheetem?

  Inwestorzy patrzą przede wszystkim na pochodzenie danych, prawa do ich użycia oraz zgodność z regulacjami (RODO, sektorówki, nadchodzący AI Act). Interesuje ich, skąd dane pochodzą (własne, kupione, z partnerstw, z otwartych źródeł, scrapowane), kto ma do nich prawa majątkowe i czy licencje pozwalają na trenowanie modeli komercyjnych.

  Dodatkowo weryfikują, czy firma ma to wszystko udokumentowane: umowy z dostawcami danych, zapisy w umowach z klientami, polityki prywatności, ewentualne zgody. Samo „mamy dane w S3” nie wystarcza – musi być jasne, że wolno ich używać do trenowania modeli i sprzedawania produktu.

  Jakie są największe czerwone flagi przy danych w startupie AI dla VC?

  Najczęstsze czerwone flagi to: scraping bez analizy legalności, „pożyczone” dane z poprzedniego miejsca pracy, nieprecyzyjne umowy z dostawcami danych (bez słowa o AI, licencjach na trenowanie czy outputach) oraz brak podziału między danymi klientów a danymi treningowymi. Gdy wszystko wrzucane jest do jednego worka, inwestorzy mają prawo się niepokoić.

  Osobną kategorią jest kompletny brak dokumentacji źródeł danych: gdy na pytanie „na czym trenowaliście model?” pada odpowiedź „na różnych źródłach, nie mamy tego spisanego”. Dla funduszu to sygnał, że przy pierwszym pozwie lub kontroli regulatora model może wylądować w koszu.

  Jak przygotować dane i umowy, żeby nie odstraszyć inwestora AI jeszcze przed due diligence?

  Po pierwsze, trzeba zrobić porządną inwentaryzację danych: wypisać zbiory danych, ich źródła, typ (treningowe, operacyjne, dane klientów, logi/metadane), status prawny oraz ograniczenia licencyjne. To nie musi być idealne od pierwszego dnia, ale musi istnieć i być spójne.

  Po drugie, przejrzeć umowy: z klientami (czy jest zgoda na wykorzystanie danych do trenowania modeli), z dostawcami danych (czy wolno trenować, komercjalizować, łączyć z innymi zbiorami) oraz polityki prywatności (czy użytkownik jest informowany o takim przetwarzaniu). Czasem wystarczy prosty aneks lub doprecyzowanie zapisów, żeby z „pole minowe” zrobić „kontrolowane ryzyko”.

  Dlaczego inwestorów bardziej interesuje legalność danych niż „magia” modelu AI?

  Model można często poprawić, przeuczyć lub nawet wymienić na nowszy. Z toksycznymi danymi treningowymi jest dużo gorzej – jeśli okazało się, że trenowano na danych bez praw lub zgód, skutkiem może być konieczność skasowania modelu, wypłata odszkodowań, a w skrajnym przypadku zatrzymanie działalności w danym segmencie rynku.

  Inwestor szuka więc biznesu, który da się skalować bez ryzyka skandalu, pozwów czy interwencji regulatora. „Magia modeli” jest atrakcyjna marketingowo, ale to legalność i bezpieczeństwo danych decydują, czy spółka nadaje się do włożenia kilkunastu czy kilkudziesięciu milionów – zamiast do działu „ciekawe demo na konferencji”.

  Jak RODO i AI Act wpływają na ocenę startupu AI przez inwestorów?

  RODO już teraz narzuca konkretne obowiązki przy przetwarzaniu danych osobowych – podstawy prawne, informowanie użytkowników, prawa do sprzeciwu, ograniczenia przy danych wrażliwych. Startup, który „trenował na danych użytkowników, bo tak było wygodniej”, budzi wątpliwości, czy da się go skalować na regulowanych rynkach (med, fin, HR).

  AI Act wprowadza dodatkowo kategorie systemów wysokiego ryzyka i wymogi wobec dokumentacji, nadzoru i jakości danych. Fundusze próbują z wyprzedzeniem ocenić, czy produkt może trafić do „wysokiego ryzyka”, a jeśli tak – czy zespół jest w stanie spełnić wymogi bez zabicia unit economics. Jeżeli odpowiedź brzmi „nie wiemy” albo „jakoś to będzie”, entuzjazm po stronie inwestora szybko maleje.

  Czy można bezpiecznie trenować modele AI na danych klientów? Jak na to patrzą inwestorzy?

  Można, ale pod warunkiem, że jest to jasno uregulowane. Inwestorzy oczekują, że klient został poinformowany (umowa, regulamin, polityka prywatności), ma odpowiednią podstawę prawną w RODO oraz że da się rozdzielić dane niezbędne do świadczenia usługi od tych, które idą w „paliwo” modeli. Brak tego rozgraniczenia to klasyczna mina.

  W praktyce dobrze wygląda model, w którym: klient ma możliwość opt-out, dane do trenowania są zanonimizowane lub pseudonimizowane, a proces jest opisany w dokumentacji. Jeżeli dodatkowo startup umie pokazać, że w razie potrzeby potrafi „wycofać” dane danego klienta z kolejnych iteracji modelu, inwestorzy śpią znacznie spokojniej.

  Źródła

  • Regulation (EU) 2016/679 (General Data Protection Regulation). European Union (2016) – Podstawy prawne przetwarzania danych, zgody, dane wrażliwe
  • Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act). European Union (2024) – Klasyfikacja ryzyka systemów AI, obowiązki dostawców i użytkowników
  • Guidelines 05/2021 on the interplay between the application of Article 3 GDPR and the provisions on international transfers. European Data Protection Board (2021) – Transfer danych, odpowiedzialność administratora i podmiotu przetwarzającego
  • Opinion 03/2013 on purpose limitation. Article 29 Data Protection Working Party (2013) – Ograniczenie celu, ponowne wykorzystanie danych, trenowanie modeli
  • OECD Principles on Artificial Intelligence. Organisation for Economic Co-operation and Development (2019) – Zasady odpowiedzialnego AI, ryzyka, przejrzystość i bezpieczeństwo
  • AI Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology (2023) – Identyfikacja i zarządzanie ryzykiem AI, w tym prawnym i reputacyjnym
  • ISO/IEC 27001 Information security, cybersecurity and privacy protection. International Organization for Standardization (2022) – System zarządzania bezpieczeństwem informacji, kontrola dostępu do danych