Jak zapobiec vendor lock-in w AI: klauzule i plan wyjścia

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

Rozpoznanie vendor lock-inu to dopiero połowa roboty. Rozłożyłem ją osobno na trzy warstwy i dwie pułapki kontraktowe. Ten post jest o drugiej połowie: co realnie zrobić, żeby lock-in się nie zamknął. A da się to zrobić tylko w dwóch momentach: przy podpisywaniu umowy i w projekcie architektury. Nigdy w dniu, w którym chcesz odejść, bo wtedy jest już za późno.

Zapobieganie stoi na dwóch nogach. Pierwsza to umowa: konkretne klauzule, które przenoszą prawo wyjścia z „dobrej woli dostawcy" na papier. Druga to plan wyjścia: operacyjna zdolność do faktycznej migracji, przygotowana zawczasu i przetestowana, a nie wymyślana pod presją. Poniżej obie, gotowe do użycia.

Spis treści

• Dlaczego prawo wyjścia musi być na papierze
• Klauzule kontraktowe, które warto mieć przed MSA
• Plan wyjścia: co przygotować od dnia pierwszego
• Exit drill: dlaczego plan bez próby jest fikcją
• Gdzie on-prem zmienia równanie, a gdzie nie
• Czego tu nie pokrywam
• Disclosure i biases

Dlaczego prawo wyjścia musi być na papierze

Dla podmiotu kluczowego w rozumieniu NIS2 zdolność do zakończenia relacji z dostawcą bez utraty zdolności operacyjnej nie jest wygodą, tylko elementem bezpieczeństwa łańcucha dostaw ocenianym z Art. 21 ust. 1 lit. d. Jeśli nie potrafisz opisać, jak wyszedłbyś od dostawcy AI, masz nieudokumentowane ryzyko compliance, a nie tylko potencjalny kłopot kosztowy.

Kluczowa różnica wobec zwykłego SaaS: w AI to, co chcesz odzyskać, to nie tylko dane wejściowe. To także artefakty pochodne, których dostawca może być domyślnym właścicielem, jeśli umowa milczy: embeddingi całego korpusu, indeksy wektorowe, fine-tune'y, prompty i logi. Milczenie umowy nie jest neutralne. Milczenie umowy działa na korzyść dostawcy.

Klauzule kontraktowe, które warto mieć przed MSA

Poniższa tabela to nie gotowy wzór prawny, tylko lista kontrolna intencji, które prawnik ma przełożyć na język umowy. Każdy wiersz to jedno zabezpieczenie i jedna czerwona flaga, gdy go brak.

Klauzula	Co ma gwarantować	Czerwona flaga, gdy brak
Portability danych i artefaktów	Prawo eksportu danych źródłowych, embeddingów, indeksów i logów w otwartym, udokumentowanym formacie, w trakcie umowy i na wyjściu	„Eksport na życzenie" bez formatu i terminu to brak realnego prawa
Własność artefaktów pochodnych	Jednoznaczne przypisanie Tobie własności fine-tune'ów, embeddingów, promptów i logów	Milczenie umowy oznacza domyślnie kontrolę po stronie dostawcy
Brak opłat karnych za egress	Zero opłat za wyjście danych albo sufit ustalony z góry	Egress liczony per GB dopiero przy odejściu to kara za rezygnację
Notyfikacja i sprzeciw: sub-processor i jurysdykcja	Uprzednia notyfikacja i prawo sprzeciwu wobec zmiany podprocesora lub lokalizacji przetwarzania	Jednostronna zmiana regulaminem przenosi Twój profil ryzyka w ręce dostawcy
Notyfikacja zmiany i deprecjacji modelu	Wyprzedzenie i okno na re-walidację przy zmianie modelu bazowego	Cicha aktualizacja modelu to Twój niezaplanowany koszt re-walidacji pod AI Act
Transition assistance	Zobowiązanie do wsparcia migracji przez ustalony okres po zakończeniu umowy, w cenie lub z cennikiem z góry	„Współpraca w dobrej wierze" bez SLA to pusta obietnica
Zwrot i usunięcie danych	SLA na zwrot oraz potwierdzone usunięcie danych po wygaśnięciu, istotne także pod RODO	Brak klauzuli oznacza, że dane zostają u byłego dostawcy
Escrow konfiguracji	Depozyt wag modelu, konfiguracji i promptów u strony trzeciej na wypadek upadłości dostawcy	Brak przy krytycznym workloadzie to biznesowy pojedynczy punkt awarii
Sufit podwyżki i okno wypowiedzenia	Limit eskalacji ceny plus realne okno wypowiedzenia bez automatycznego przedłużenia	Auto-renewal bez sufitu to lock-in cenowy niezależny od technicznego

Praktyczna kolejność negocjacji: najpierw portability i własność artefaktów, bo bez nich reszta jest teoretyczna. Potem notyfikacje o zmianach sub-processora i modelu, bo to one decydują o Twoim profilu ryzyka w czasie. Transition assistance i escrow zostaw jako klauzule, na których możesz ustąpić w zamian za twardsze zapisy o portability, jeśli negocjacje tego wymagają.

Plan wyjścia: co przygotować od dnia pierwszego

Najlepsza klauzula portability jest bezużyteczna, jeśli w dniu wyjścia nie masz gdzie i czym odebrać danych. Dlatego druga noga zapobiegania jest operacyjna. Plan wyjścia to nie dokument na później, tylko zestaw rzeczy, które utrzymujesz na bieżąco od startu wdrożenia.

Krok planu wyjścia	Co przygotować	Właściciel	Kiedy
Rejestr zależności	Mapa: jakie dane, artefakty, integracje i przeszkoleni ludzie wiążą Cię z dostawcą	Architekt / CISO	Od dnia 1, aktualizacja kwartalna
Logika biznesowa poza dostawcą	Prompty, reguły i mapowania trzymane w repozytorium po Twojej stronie, nie w orkiestratorze dostawcy	Zespół AI	Na bieżąco
Regularny eksport artefaktów	Cykliczny zrzut embeddingów, indeksu i logów w otwartym formacie	Ops	Miesięcznie lub kwartalnie
Zidentyfikowany model zapasowy	Alternatywny model i stack inferencyjny, na który można się przenieść	Architekt	Przegląd co pół roku
Runbook migracji	Krok po kroku: przelicz embeddingi, przełącz konektory, zwaliduj wyniki, przełącz ruch	Zespół AI + Ops	Gotowy przed podpisaniem MSA
Exit drill	Próba migracji na środowisku testowym, mierzona w czasie	Zespół AI	Raz w roku

Sednem tego planu jest jedna zasada: im więcej Twojej logiki i Twoich artefaktów żyje w formacie, który kontrolujesz, tym płytszy jest każdy poziom lock-inu. Warstwy danych i modelu opisałem szerzej w poście o trzech warstwach; tutaj chodzi o to, żeby dla każdej z nich mieć przygotowaną drogę wyjścia, zanim będzie potrzebna.

Exit drill: dlaczego plan bez próby jest fikcją

Plan wyjścia, którego nigdy nie wykonano, ma taką samą wartość jak backup, którego nigdy nie odtworzono: zerową, dopóki się nie okaże, że nie działa, i to w najgorszym momencie. Exit drill to kontrolowana próba migracji raz w roku, na środowisku testowym, z ograniczonym korpusem.

Co realnie mierzysz podczas takiej próby: czy eksport artefaktów faktycznie da się zaczytać innym stackiem, ile trwa przeliczenie embeddingów zapasowym modelem, czy konektory do ERP i MES przełączają się bez przepisywania, i ile jakości tracisz na modelu zapasowym względem produkcyjnego. Wynik drillu to nie tylko potwierdzenie, że wyjście jest możliwe. To liczba: realny koszt i czas migracji, którym możesz się posłużyć w negocjacjach i w dokumentacji ryzyka NIS2.

Jeśli pierwszy drill pokaże, że migracja jest niewykonalna w rozsądnym czasie, to najtańszy moment, w którym możesz się o tym dowiedzieć. Znacznie tańszy niż dzień, w którym dostawca podniesie cenę albo zmieni model bazowy bez pytania.

Gdzie on-prem zmienia równanie, a gdzie nie

On-prem mityguje lock-in najmocniej w warstwie modelu, bo to Ty decydujesz, kiedy i czy aktualizujesz model, i w warstwie danych fizycznie, bo korpus stoi u Ciebie. Ale nie zeruje lock-inu automatycznie. Dane mogą fizycznie leżeć w Twojej serwerowni, a i tak być uwięzione w zamkniętym formacie indeksu. Kontrola fizyczna to nie to samo co portowalność, a przeszkoleni na jeden interfejs ludzie i proprietary orkiestrator wiążą Cię niezależnie od tego, gdzie stoi sprzęt.

Dlatego klauzule i plan wyjścia z tego posta dotyczą także wdrożeń on-prem. Zmienia się ich ciężar, nie ich potrzeba: przy on-prem mniej martwisz się o egress i jurysdykcję, a bardziej o własność artefaktów, otwartość formatów i to, ile Twojej logiki żyje poza stackiem dostawcy. Kto ocenia oferty on-prem w przetargu, ten znajdzie komplementarne kryteria w teście suwerenności.

// co tu nie pokrywamCzego tu nie pokrywam

Świadomie nie wchodzę tu w pełny framework scoringu dostawcy, który prowadzę osobno w szkielecie RFP na 24 pytania i w vendor security review na 12 pytań przed MSA. Nie omawiam też szczegółów umowy powierzenia, które rozbieram w poście o 8 klauzulach DPA, ani conformity assessment pod AI Act, ani taktyki negocjacji cenowych. To notatka o zapobieganiu lock-inowi w umowie i w architekturze, nie kompletny przewodnik po ocenie dostawcy.

// disclosure i biasesDisclosure i biases

Piszę z perspektywy zespołu, który buduje systemy on-prem AI, więc naturalnie przechylam ocenę w stronę rozwiązań dających kontrolę nad warstwą modelu i danych. Starałem się to równoważyć: powyżej wprost piszę, że on-prem nie zeruje lock-inu i że własne artefakty potrafią być uwięzione w zamkniętym formacie mimo fizycznej kontroli nad sprzętem. Ten tekst nie jest poradą prawną. Listę klauzul traktuj jako intencje do przełożenia przez prawnika na język konkretnej umowy i jurysdykcji.

Powiązane notatki

• Rozpoznanie: Vendor lock-in w AI: trzy warstwy, dwie pułapki kontraktowe — jak w ogóle rozpoznać lock-in, zanim zaczniesz mu zapobiegać.
• Ocena dostawcy: RFP dla AI vendora compliance: szkielet 24 pytań — pełniejszy framework scoringu oferty.
• Bezpieczeństwo: Vendor security review AI: 12 pytań przed podpisaniem MSA — co sprawdzić po stronie security, nim podpiszesz.
• Umowa: DPA dla AI vendora: 8 klauzul, których brak wywróci audyt — powiązane zapisy w umowie powierzenia.
• Przetargi: Test suwerenności w przetargach: jak ocenić ofertę on-prem — komplementarne kryteria dla wdrożeń on-prem.