Zjawisko ma nazwę: sherlocking. Platforma wchłania funkcję, którą zbudował na niej ktoś inny. W ciągu jednego roku funkcje wydane przez czołowego dostawcę modeli unicestwiły ponad 200 finansowanych startupów. Natomiast popularna teza, że wielcy dostawcy trenują modele na danych firmowych klientów, w przypadku kont biznesowych nie znajduje potwierdzenia — i warto wiedzieć, gdzie leży prawdziwe ryzyko, bo jest ich kilka i są realne.
Mechanizm hipermarketu
Analogia handlowa jest trafna i warto ją rozwinąć, bo dobrze tłumaczy, co się dzieje. Sieć handlowa wpuszcza dostawcę na półkę. Dostawca cieszy się zasięgiem, którego nigdy nie osiągnąłby sam. Sieć w tym czasie zbiera dane: co się sprzedaje, w jakiej cenie, komu. Gdy kategoria okazuje się dochodowa, sieć wypuszcza produkt własnej marki — taniej, na lepszej półce — i nie przedłuża umowy.
Dostawca nie został okradziony. Nikt nie wykradł mu receptury. Po prostu pokazał rynkowi, że kategoria działa — a właściciel półki wyciągnął z tego wnioski.
W oprogramowaniu nazywa się to sherlockingiem. Termin pochodzi od programu Sherlock w systemie macOS, którego funkcje Apple przejęło od niezależnego narzędzia Watson. Dziś dotyczy każdej platformy: Apple, Microsoftu, Google'a — i dostawców modeli AI.
Co się faktycznie wydarzyło
Jeden dzień, dziesiątki firm
Jeden z największych dostawców modeli dodał do swojego czatu możliwość wgrywania plików. Z dnia na dzień straciły rację bytu dziesiątki startupów, których cały produkt polegał na tym, że pozwalały „rozmawiać z dokumentem PDF". Miesiące pracy i rundy finansowania wyparowały wraz z jedną aktualizacją.
Skala zjawiska
Według dostępnych analiz rynkowych funkcje wydane w ciągu jednego roku przez czołowego dostawcę modeli skanibalizowały ponad 200 finansowanych startupów. Wzorzec powtarzał się w kolejnych kategoriach: własne asystenty AI, nakładki sprzedające dostęp zespołowy, narzędzia do analizy obrazu, do analizy danych, do orkiestracji agentów. Za każdym razem ta sama historia — funkcja wchłonięta do produktu głównego, zwykle bezpłatnie.
Gdy inwestor staje się rywalem
Najlepszy dowód, że problem nie dotyczy tylko małych firm. Jeden z gigantów technologicznych zainwestował w laboratorium AI miliardy dolarów — a dziś ich asystenci konkurują o tego samego klienta korporacyjnego. Przejęcia po stronie laboratorium weszły w drogę produktom inwestora, klauzule wyłączności zniesiono, a inwestor równolegle zaczął współpracować z konkurencyjnym laboratorium.
Jeśli największy inwestor w branży musi się zabezpieczać przed spółką, którą współfinansuje, to firma z Olsztyna budująca swój produkt na cudzym API tym bardziej powinna zadać sobie pytanie, co się stanie, gdy dostawca uzna jej niszę za atrakcyjną.
Gdzie teza o trenowaniu na Twoich danych się nie broni
Często słyszę, że wielcy dostawcy trenują modele na danych firmowych klientów, a potem budują z tego własne produkty. Sprawdziłem to, bo zarzut jest poważny — i w odniesieniu do kont biznesowych nie znajduje potwierdzenia:
- U czołowych dostawców dla API oraz kont biznesowych obowiązuje model opt-in: dane domyślnie nie są używane do trenowania, chyba że klient sam to włączy.
- Zmiany polityk dotyczące trenowania, które budziły niepokój w ostatnich latach, obejmowały konta konsumenckie, a klientów komercyjnych wprost z nich wyłączano; retencję logów API skracano, nie wydłużano.
Nie znam udokumentowanego przypadku, w którym czołowy dostawca wytrenował model na danych klienta korporacyjnego i zbudował z nich konkurencyjny produkt. Powtarzanie takiego zarzutu bez dowodów osłabia argumentację — a jest ona i tak wystarczająco mocna bez niego.
Trzy ryzyka, które są prawdziwe
1. Shadow AI — dane wychodzą bocznymi drzwiami
Umowy korporacyjne chronią dane. Darmowe konta pracowników — nie. Na kontach konsumenckich trenowanie bywa domyślnie włączone, a przeciętny pracownik nie czyta regulaminu przed wklejeniem fragmentu kodu.
Głośny przypadek z branży elektronicznej pokazał to dobitnie: w ciągu dwudziestu dni od dopuszczenia publicznego czatu AI doszło w jednej firmie do trzech osobnych incydentów. Inżynier wkleił kod źródłowy, szukając rozwiązania błędu. Ktoś inny wrzucił transkrypcję wewnętrznego spotkania, żeby wygenerować notatkę. Trzeci optymalizował sekwencję testową do wykrywania wadliwych układów. Firma zakazała generatywnej AI na sprzęcie służbowym.
Zwróć uwagę: żaden z tych ludzi nie działał w złej wierze. Wszyscy po prostu chcieli szybciej wykonać swoją pracę.
2. Zależność platformowa
To ryzyko nie wymaga wcale, by ktokolwiek sięgał po Twoje dane. Wystarczy, że dostawca uzna Twoją niszę za wartą wejścia — a widzi jej atrakcyjność choćby po wolumenie zapytań w Twojej kategorii. Im lepiej Ci idzie, tym bardziej jesteś dla niego widoczny.
3. Zmiana zasad w trakcie gry
Polityki nie są wieczne. Zdarzało się, że dostawca zmieniał zasady dla użytkowników konsumenckich: trenowanie stawało się domyślne, a okres przechowywania danych wydłużano do kilku lat dla tych, którzy wyrazili zgodę. Klientów komercyjnych takie zmiany zwykle nie obejmowały — ale sam fakt, że warunki potrafią się zmienić w trakcie korzystania z usługi, jest istotny przy planowaniu na lata.
Co z tym zrobić
Nie chodzi o to, żeby nie używać modeli w chmurze. Są znakomite i dla wielu zastosowań w pełni wystarczające. Chodzi o świadomy podział.
| Zastosowanie | Rekomendacja |
|---|---|
| Treści marketingowe, tłumaczenia, szkice | chmura — brak wrażliwych danych |
| Kod źródłowy, dokumentacja techniczna | lokalnie |
| Umowy, dane osobowe, dokumentacja medyczna | lokalnie — dodatkowo wymogi RODO |
| Rdzeń Twojej przewagi konkurencyjnej | lokalnie, bez wyjątków |
Do tego trzy rzeczy organizacyjne, tanie i skuteczne:
- Zasady korzystania z AI na piśmie. Co wolno wkleić, czego nie i gdzie. Bez tego każdy pracownik decyduje sam — i statystycznie ktoś zdecyduje źle.
- Konta firmowe zamiast prywatnych. Jeśli zespół używa chmury, to na koncie z umową biznesową, a nie na darmowym.
- Możliwość zmiany dostawcy. Warstwa abstrakcji nad modelem sprawia, że zmiana dostawcy jest kwestią konfiguracji, a nie przepisywania systemu od zera.
Dlaczego lokalne wdrożenie zamyka temat
Model uruchomiony na własnym serwerze usuwa wszystkie trzy ryzyka naraz. Dane nie wychodzą poza organizację, bo nie mają dokąd. Dostawca nie widzi Twoich zastosowań, bo nie ma wglądu. Zmiana cennika czy regulaminu Cię nie dotyczy, bo nie ma dostawcy.
Dochodzi argument, który przekonuje zarządy szybciej niż bezpieczeństwo: koszt przewidywalny. Rozliczenie za zapytanie oznacza, że im lepiej narzędzie działa i im częściej zespół go używa, tym więcej płacisz. Sprzęt kupujesz raz.
Nie twierdzę, że lokalnie jest zawsze lepiej — mniejsze modele mają realne ograniczenia i trzeba je znać. Twierdzę, że decyzja powinna być świadoma: to, co stanowi o Twojej przewadze, nie powinno przechodzić przez cudzą infrastrukturę tylko dlatego, że tak było wygodniej na starcie.
Chcesz sprawdzić, gdzie wyciekają dane Twojej firmy?
Przejdziemy przez to, z jakich narzędzi AI faktycznie korzysta zespół i co przez nie przechodzi. Powiem wprost, co można zostawić w chmurze, a co powinno zostać u Was.
Umów bezpłatną konsultację