AI vendor lock-in — gdy model nie jest jedyną zależnością

Lock-in to nie tylko logo na modelu

W klasycznym SaaS uzależnienie od dostawcy często widać w danych, API i umowie. W AI jest bardziej podstępne: model stanowi widoczną część, ale zależność narasta także przez szablony promptów, narzędzia, zestawy testów jakości, wyjątki bezpieczeństwa, wewnętrzne zatwierdzenia i sposób rozliczeń. Firma nie zmienia tylko dostawcy. Zmienia proces pracy, który wyrósł wokół modelu.

Dlatego samo pytanie „który model jest najlepszy” jest niewystarczające. Lepsze pytanie brzmi: co się zepsuje, jeśli za pół roku wymienimy model, chmurę albo platformę agentów?

Gdzie zależność przykleja się do systemu

Pierwsza warstwa jest umowna: zobowiązanie do zakupu usług chmurowych, umowa firmowa, dostępność regionalna i warunki przetwarzania danych. Druga jest techniczna: struktura API, formaty wywołań narzędzi, embeddingi, wyniki dostrajania modeli, izolowane środowisko, logowanie i integracja z systemami wewnętrznymi. Trzecia jest operacyjna: kto zatwierdza zmiany, kto płaci za tokeny, jak mierzy się jakość i jak szybko zespół potrafi zatrzymać incydent.

Zależność techniczna nie jest specyficzna wyłącznie dla generatywnej AI. Badanie Hidden Technical Debt in Machine Learning Systems opisuje, jak powiązania danych, modeli i otaczającego kodu zwiększają koszty utrzymania systemu. Migracja dostawcy może ujawnić te powiązania.

Trudno oszacować zależność, która wygląda jak wygoda. Jeden przycisk, jeden dostawca, jedno konto, jedna integracja. Piękne w pilotażu. Drogie, gdy zmienia się cena, wymagania zgodności lub jakość modelu.

Przenośność nie jest za darmo

Architektura z wieloma modelami brzmi kusząco, ale nie jest magiczną polisą. Każdy model ma inne limity, zachowanie, ceny i sposoby zawodzenia. Jeśli aplikacja tylko przełącza punkt końcowy API, ale nie ma testów jakości, interfejsu narzędzi, danych testowych i ustalonej obsługi błędów, jest raczej przełącznikiem chaosu niż strategią. Model zastępczy nie może po cichu otrzymywać danych, których nie wolno do niego wysłać zgodnie z obowiązującymi zasadami.

Dobra przenośność wymaga możliwości eksportu danych domenowych, własnych testów jakości, interfejsów narzędzi oddzielonych od konkretnego SDK i logów umożliwiających porównanie wyników. Przykładowo MCP standaryzuje połączenia aplikacji z narzędziami i kontekstem. Nie wynika z tego jednak, że różne modele równie dobrze wykonają zadanie. Przenośność trzeba wykazać próbą.

Co powinny sprawdzać zakupy, programiści i prawnicy

Dział zakupów sprawdza cenę, zobowiązania i możliwość zakończenia umowy. Programiści sprawdzają opóźnienia, jakość, API, obserwowalność i obsługę błędów. Zespół prawny i zespół bezpieczeństwa sprawdzają dane, audyt, jurysdykcję, odpowiedzialność i właściwe ograniczenia. Te perspektywy są powiązane: zmiana ceny może zmienić architekturę, a zmiana architektury może zmienić ryzyko.

Praktyczny test jest prosty: czy potrafimy nazwać pięć najdroższych miejsc, w których obecny dostawca AI nas trzyma? Jeśli nie, lock-in może już istnieć, tylko nie ma jeszcze nazwy.

Buduj z wyjściem awaryjnym

Zacznij od krótkiej listy zasad. Krytyczne procesy powinny mieć zestaw testów i dziennik audytowy. Wrażliwe dane nie powinny bez potrzeby trafiać do formatu specyficznego dla dostawcy. Prompty, schematy narzędzi i proces wyszukiwania materiałów powinny być wersjonowane jak kod. Decyzja o modelu powinna mieć datę kolejnego przeglądu, a nie status religii.

Wyjście awaryjne nie oznacza, że każdy system musi działać na pięciu modelach. Oznacza, że wiesz, ile kosztowałoby odejście, co trzeba byłoby przepisać i które zadania są na tyle ważne, że zasługują na drugą opcję. Lock-in nie zawsze jest zły. Zły jest lock-in, o którym zespół dowiaduje się dopiero wtedy, gdy musi z niego wyjść.

Przykład: próbna migracja asystenta wsparcia

Wybierz zatwierdzony zestaw pytań testowych bez danych osobowych i uruchom go na dotychczasowym oraz alternatywnym rozwiązaniu. Porównaj poprawność odpowiedzi, cytowania, błędne wywołania narzędzi, koszt i czas reakcji. Uwzględnij też pracę potrzebną do eksportu dokumentów i przebudowy wyszukiwania. Jeśli potrzebne są nowe embeddingi, zaplanuj ponowne zbudowanie indeksu. Wynikiem ma być lista konkretnych zależności i kosztów, a nie tylko udana odpowiedź API.

Źródła

• Hidden Technical Debt in Machine Learning Systems — zależności systemowe i koszty utrzymania ML.
• MCP: Architecture overview — zakres standaryzacji integracji narzędzi i kontekstu.