Vendor lock-in w AI: trzy warstwy, dwie pułapki kontraktowe

Czas czytania: ~7 min · Klaster: Vendor evaluation · Poziom: CISO / CIO

[OBRAZ — cover w treści do wygenerowania: schematyczny, trzy warstwy „dane / model / integracje" z dwoma znacznikami pułapek. Nie stock.]

Lock-in w AI rzadko wygląda jak jedna zła decyzja. Najczęściej to suma kilkunastu rozsądnych kroków: wybrałeś dostawcę, bo miał najlepszy model, dorzuciłeś integrację z ERP, bo akurat była gotowa, przeszkoliłeś zespół na jego interfejs. Każdy krok z osobna był racjonalny. Razem złożyły się na sytuację, w której zmiana dostawcy oznacza przepisanie połowy procesu.

Dla podmiotu kluczowego w rozumieniu NIS2 to nie jest tylko problem kosztowy. Zdolność do zakończenia relacji z dostawcą bez utraty zdolności operacyjnej to element bezpieczeństwa łańcucha dostaw — a ten podlega ocenie z Art. 21 ust. 1 lit. d. Innymi słowy: lock-in, którego nie potrafisz opisać i zmitygować, jest również ryzykiem compliance.

Poniżej rozbijam lock-in w AI na trzy warstwy i pokazuję dwie pułapki, które najczęściej przeoczają nawet doświadczone zespoły — bo siedzą nie w architekturze, lecz w umowie.

Spis treści

• Dlaczego lock-in w AI różni się od lock-inu w SaaS
• Warstwa 1: dane
• Warstwa 2: model
• Warstwa 3: integracje i workflow
• Pułapka kontraktowa 1: portability i data egress
• Pułapka kontraktowa 2: sub-processor i change-of-terms
• Mini-checklist przed MSA
• Co tu nie pokrywam
• Disclosure i biases

Dlaczego lock-in w AI różni się od lock-inu w SaaS

W klasycznym SaaS lock-in jest w miarę policzalny: dane siedzą w bazie, eksport to CSV albo API, koszt migracji da się oszacować. W AI dochodzą trzy rzeczy, których w SaaS nie ma.

Po pierwsze, część „danych" nie jest danymi wejściowymi, tylko wytworzonymi artefaktami — embeddingami, indeksami wektorowymi, fine-tune'ami. Te artefakty są związane z konkretnym modelem i nie przenoszą się 1:1. Po drugie, zachowanie systemu zależy od warstwy, której zwykle nie kontrolujesz: modelu, który dostawca może wersjonować, deprecjonować albo podmienić. Po trzecie, AI wnika głęboko w workflow — wpina się w ERP, MES, DMS i tożsamość — więc koszt wyjścia rośnie z każdą integracją, często niewidocznie.

Dlatego ocenę lock-inu warto prowadzić warstwami, a nie jako jedno pytanie „czy łatwo zmienić dostawcę".

Warstwa 1: dane

To warstwa, którą zespoły rozumieją najlepiej — i wciąż nie doceniają.

Realny problem nie dotyczy dokumentów źródłowych (te zwykle masz u siebie), tylko artefaktów pochodnych: embeddingów całego korpusu, indeksów wektorowych, logów konwersacji i pętli feedbacku. Jeśli dostawca liczy embeddingi własnym, zamkniętym modelem, to przy migracji nie eksportujesz embeddingów — musisz przeliczyć cały korpus od nowa innym modelem. Dla bazy wiedzy liczonej w setkach tysięcy dokumentów to realny koszt czasu i mocy obliczeniowej, a nie formalność.

Pytania kontrolne do tej warstwy:

• W jakim formacie możesz wyeksportować embeddingi i indeks wektorowy — i czy są one użyteczne poza stackiem dostawcy?
• Kto jest właścicielem logów konwersacji i feedbacku? Czy są używane jako dane treningowe?
• Czy są opłaty za egress danych przy wyjściu?

On-prem nie usuwa tej warstwy automatycznie. Dane mogą fizycznie stać u Ciebie, a i tak być uwięzione w zamkniętym formacie indeksu. Kontrola fizyczna to nie to samo co portowalność.

Warstwa 2: model

Tu lock-in jest najbardziej podstępny, bo zachowanie systemu jest zestrojone z konkretnym modelem.

Prompty, guardraile i logika RAG są strojone pod jeden model. Fine-tune'y są związane z jego wagami i nieprzenośne. A samo wersjonowanie leży po stronie dostawcy — deprecjacja albo cicha aktualizacja modelu bazowego potrafi zmienić wyniki i wymusić ponowną walidację całego rozwiązania. Dla podmiotu, który dokumentuje system pod AI Act, taka zmiana to nie wygoda dostawcy, tylko Twój koszt re-walidacji.

On-prem mityguje tę warstwę najmocniej (kontrolujesz, kiedy i czy aktualizujesz model), ale jej nie zeruje — zostaje zależność od konkretnego stacku inferencyjnego i optymalizacji pod dany sprzęt. Pytanie brzmi nie „czy mam lock-in modelowy", tylko „jak głęboki i kto decyduje o zmianie wersji".

Warstwa 3: integracje i workflow

Najgłębsza i najmniej widoczna warstwa. Nie zobaczysz jej w architekturze referencyjnej — zobaczysz ją dopiero, gdy spróbujesz odejść.

Składają się na nią: konektory do ERP/MES/DMS, integracja z tożsamością (SSO), pipeline'y danych, proprietary framework orkiestracji albo agentów, oraz — rzecz najczęściej pomijana — ludzie przeszkoleni na konkretny interfejs. Każda z tych rzeczy z osobna jest mała. Razem tworzą koszt przełączenia, który po roku potrafi przewyższyć wszystkie pozostałe warstwy łącznie.

Praktyczna obrona: trzymaj logikę biznesową (prompty, reguły, mapowania) w warstwie, którą kontrolujesz, a nie wewnątrz proprietary orkiestratora dostawcy. Im więcej Twojej logiki żyje w przenośnym formacie, tym płytszy ten poziom lock-inu.

Dla porządku — trzy warstwy w jednym widoku:

Warstwa	Co Cię trzyma	Czy on-prem pomaga?	Pierwszy test
Dane	Embeddingi, indeksy, logi jako dane treningowe	Częściowo (format ≠ lokalizacja)	Czy eksport jest użyteczny poza stackiem dostawcy?
Model	Fine-tune'y, strojenie pod jeden model, wersjonowanie	Mocno (kontrolujesz aktualizacje)	Kto decyduje o zmianie wersji modelu?
Integracje	ERP/MES/SSO, orkiestracja, przeszkoleni ludzie	Słabo (to Twoja strona)	Ile Twojej logiki żyje poza dostawcą?

Pułapka kontraktowa 1: portability i data egress

Tu zaczyna się część, którą najłatwiej przeoczyć, bo nie jest techniczna.

Możesz mieć idealną architekturę on-prem i wciąż być uwięziony — jeśli MSA milczy o wyjściu. Klasyczny zestaw braków: brak klauzuli o prawie do eksportu w otwartym formacie (i to regularnie, nie tylko przy rozwiązaniu umowy), brak SLA na zwrot i usunięcie danych po zakończeniu, niejasna własność fine-tune'ów i embeddingów, oraz auto-renewal sprzężony z eskalacją cen.

Co warto mieć zapisane, zanim podpiszesz:

• Prawo do eksportu danych i artefaktów pochodnych w udokumentowanym, otwartym formacie — dostępne w trakcie trwania umowy, nie tylko na jej koniec.
• Jednoznaczne przypisanie własności fine-tune'ów, embeddingów i logów.
• SLA na zwrot oraz potwierdzone usunięcie danych po wygaśnięciu (istotne także pod RODO).
• Brak automatycznego przedłużenia bez okna wypowiedzenia i bez sufitu na podwyżkę.

Dla podmiotu kluczowego NIS2 ta klauzula nie jest „nice to have". Zdolność do zakończenia relacji z dostawcą bez utraty zdolności operacyjnej to wprost element bezpieczeństwa łańcucha dostaw z Art. 21.

Pułapka kontraktowa 2: sub-processor i change-of-terms

Druga pułapka dotyczy nie tego, co podpisujesz dziś, lecz tego, co dostawca może zmienić jutro jednostronnie.

Typowe ryzyka: dostawca dodaje lub zmienia sub-processora, przenosi przetwarzanie albo inferencję do innej jurysdykcji, albo podmienia model bazowy — wszystko bez Twojej zgody i czasem bez notyfikacji. Dla zwykłej firmy to niedogodność. Dla podmiotu kluczowego NIS2 to bezpośrednie ryzyko łańcucha dostaw (Art. 21 ust. 1 lit. d), a przy zmianie modelu — także koszt ponownej walidacji pod AI Act.

Czego szukać w umowie:

• Prawo do uprzedniej notyfikacji i sprzeciwu wobec zmiany sub-processora lub lokalizacji przetwarzania.
• Zobowiązanie do informowania o zmianie/aktualizacji modelu bazowego z wyprzedzeniem.
• Zakaz przenoszenia przetwarzania poza uzgodniony obszar bez Twojej zgody.

Brak tych klauzul oznacza, że Twój profil ryzyka compliance jest w rękach dostawcy — i może się zmienić e-mailem o zmianie regulaminu.

Mini-checklist przed MSA

Sześć pytań, które warto zadać, zanim cokolwiek podpiszesz:

1. W jakim formacie eksportuję dane i artefakty pochodne — i czy są użyteczne poza stackiem dostawcy?
2. Kto jest właścicielem fine-tune'ów, embeddingów i logów?
3. Kto i kiedy decyduje o zmianie wersji modelu?
4. Ile mojej logiki biznesowej żyje poza orkiestratorem dostawcy?
5. Jakie mam prawo notyfikacji/sprzeciwu wobec zmiany sub-processora lub jurysdykcji?
6. Jakie jest SLA na zwrot i usunięcie danych po zakończeniu umowy?

Jeśli na trzy z tych pytań odpowiedź brzmi „nie wiem", masz lock-in — tylko jeszcze go nie wyceniłeś.

// co tu nie pokrywamCo tu nie pokrywam

Świadomie nie wchodzę tu w: pełny framework scoringu vendora (osobny, większy materiał), szczegóły conformity assessment pod AI Act, regulacje sektorowe (energia, zdrowie, finanse) oraz taktykę negocjacji cenowych. To notatka o rozpoznaniu lock-inu, nie kompletny przewodnik po ocenie dostawcy.

// disclosure i biasesDisclosure i biases

Piszemy z perspektywy zespołu, który buduje systemy on-prem AI, a nie sprzedaje w tym tekście konkretnego produktu. To może przechylać naszą ocenę w stronę rozwiązań dających kontrolę nad warstwą modelu i danych. Tam, gdzie ta stronniczość mogłaby zaważyć na wnioskach, staramy się to zaznaczać inline.

---

Powiązane notatki

• Public cloud LLM a NIS2: szybka analiza Art. 21 ust. 1 lit. d — wspólne: NIS2, Art. 21, sub-processor
• DIY, productized czy managed: trzy modele on-prem AI i kto je utrzymuje — wspólne: vendor risk
• Bare-metal, colo czy appliance: gdzie postawić on-prem AI
• AI on-prem w europejskiej produkcji 2026: kompletny przewodnik architektoniczny
• GPU sizing dla Llama 3.1 70B inference: liczby z benchmarków — kontekst warstwy modelu

Następny krok

Ten portal nie sprzedaje — notuje. W międzyczasie obserwuj nas na LinkedIn: linkedin.com/in/fryderykpryjma