AI miało dać firmom przewagę. Może też stworzyć nową zależność
Jeszcze kilka lat temu rozmowa o vendor lock-in dotyczyła przede wszystkim chmury, systemów ERP, baz danych czy kluczowych platform technologicznych.
Firmy zadawały sobie pytania: Czy możemy przenieść aplikację do innego cloud providera?, Czy możemy zmienić bazę danych?, Czy możemy odejść od konkretnego systemu?
Dziś do tej listy dochodzi kolejny element - sztuczna inteligencja.
Organizacje coraz częściej budują systemy wykorzystujące modele językowe, generatywną AI, rozwiązania RAG, automatyzację procesów i agentów AI. Modele stają się częścią aplikacji, procesów sprzedażowych, obsługi klienta, analizy dokumentów, systemów decyzyjnych i codziennej pracy zespołów.
W praktyce oznacza to, że firma może zacząć być zależna nie tylko od konkretnego oprogramowania, ale również od konkretnego dostawcy inteligencji wykorzystywanej przez jej systemy.
I tutaj pojawia się problem. Bo czym innym jest korzystanie z usługi AI. A czym innym jest uzależnienie od niej.
To właśnie różnica między świadomą zależnością technologiczną a vendor lock-in.
Czym właściwie jest AI Vendor Lock-in?
Vendor lock-in oznacza sytuację, w której organizacja jest tak silnie związana z jednym dostawcą technologii, że przejście do konkurencyjnego rozwiązania staje się trudne, kosztowne, czasochłonne lub ryzykowne.
W świecie AI może przyjmować znacznie więcej form niż klasyczne uzależnienie od jednego API.
Firma może być zależna od:
- konkretnego modelu AI,
- konkretnego dostawcy API,
- określonego formatu komunikacji,
- funkcji dostępnych wyłącznie u jednego dostawcy,
- systemu agentowego,
- infrastruktury chmurowej,
- sposobu przechowywania danych,
- konkretnego mechanizmu embeddingów,
- określonego systemu RAG,
- sposobu wywoływania narzędzi przez agentów,
- promptów zoptymalizowanych pod konkretny model,
- kompetencji zespołu związanych z jednym ekosystemem.
Dlatego pytanie: "Czy korzystamy z OpenAI?"
jest zdecydowanie zbyt proste.
Lepsze pytanie brzmi: "Jak trudna byłaby dla nas zmiana dostawcy AI, gdybyśmy musieli zrobić to za sześć miesięcy?"
Jeśli odpowiedź brzmi: "Nie wiemy." - to może być pierwszy sygnał ostrzegawczy.
OpenAI, Anthropic, Google - czy wybór dostawcy ma znaczenie?
Na rynku funkcjonuje dziś kilka bardzo silnych ekosystemów modeli i usług AI, między innymi rozwiązania oferowane przez OpenAI, Anthropic i Google.
Każdy z tych dostawców rozwija własne modele, API, narzędzia i dodatkowe usługi.
Problem nie polega na tym, że któryś z nich jest "zły". Wręcz przeciwnie.
Korzystanie z gotowych, wysokiej jakości modeli jest często najlepszym rozwiązaniem biznesowym. Nie każda firma powinna trenować własny model. Nie każda potrzebuje własnej infrastruktury GPU. Nie każda powinna budować od podstaw cały stos AI.
Korzystanie z zewnętrznego dostawcy pozwala szybciej wejść na rynek, ograniczyć koszty początkowe i skorzystać z technologii, której samodzielne stworzenie byłoby poza zasięgiem większości organizacji.
Problem zaczyna się wtedy, gdy firma przestaje traktować dostawcę jako wymienny komponent, a zaczyna projektować cały produkt tak, jakby wybrany dostawca miał istnieć w niezmienionej formie przez kolejne 10 lat.
A tego nie można zagwarantować...
Modele są aktualizowane, starsze wersje są wycofywane, ceny się zmieniają, limity się zmieniają, API się zmieniają, pojawiają się nowe modele, zmieniają się warunki licencyjne, zmieniają się możliwości konkurencji.
To normalna część rynku technologicznego.
Dlatego architektura AI powinna uwzględniać nie tylko pytanie: "Który model jest najlepszy dzisiaj?"
ale również: "Jaką cenę zapłacimy, jeśli za rok będziemy chcieli używać innego?"
Największa pułapka - "przecież zmienimy API"
Na pierwszy rzut oka migracja może wydawać się banalna.
Mamy aplikację. Aplikacja wysyła zapytanie do modelu. Model odpowiada. Zmieniamy dostawcę. Gotowe...
W rzeczywistości sytuacja może wyglądać zupełnie inaczej.
Wyobraźmy sobie aplikację, która przez dwa lata była rozwijana wokół jednego modelu.
W tym czasie zespół:
- stworzył setki promptów,
- zoptymalizował ich treść,
- dostosował format odpowiedzi,
- zbudował system RAG,
- skonfigurował tool calling,
- stworzył agentów,
- zaprojektował workflow,
- przygotował testy,
- nauczył użytkowników pracy z systemem.
Po dwóch latach okazuje się, że model przestaje być dostępny w dotychczasowej wersji.
Albo jego cena rośnie, albo konkurencyjny model jest wyraźnie lepszy, albo firma chce przenieść część danych do innego środowiska.
Teoretycznie wystarczy zmienić API. - praktycznie może się okazać, że trzeba ponownie przetestować całą logikę systemu.
Dlaczego?
Bo modele nie są identyczne:
- Różnią się sposobem interpretacji instrukcji.
- Różnią się jakością odpowiedzi.
- Różnią się zachowaniem w długim kontekście.
- Różnią się sposobem korzystania z narzędzi.
- Różnią się obsługą structured output.
- Różnią się multimodalnością.
- Różnią się szybkością.
- Różnią się ceną.
- Różnią się także zachowaniem w sytuacjach brzegowych.
Dlatego migracja między modelami może być bardziej podobna do migracji całego komponentu biznesowego niż do zwykłej podmiany URL-a.
Pięć poziomów AI Vendor Lock-in
Warto spojrzeć na vendor lock-in szerzej.
1. Lock-in modelu
Najprostszy poziom.
Aplikacja została zoptymalizowana pod konkretny model.
Prompt działa świetnie z jednym modelem, ale gorzej z innym.
System opiera się na specyficznych możliwościach danego modelu.
Zmiana oznacza konieczność ponownego strojenia.
2. Lock-in API
System korzysta bezpośrednio z funkcji konkretnego dostawcy.
Im więcej specyficznych funkcji wykorzystujemy, tym trudniejsza może być migracja.
Nie chodzi tylko o samo generowanie tekstu.
Znaczenie mają również:
- structured outputs,
- function calling,
- tool calling,
- multimodalność,
- zarządzanie kontekstem,
- mechanizmy bezpieczeństwa,
- systemy agentowe.
3. Lock-in danych
Dane mogą być przechowywane w sposób mocno związany z konkretnym ekosystemem.
Dotyczy to również:
- embeddingów,
- indeksów wektorowych,
- metadanych,
- historii interakcji,
- konfiguracji RAG.
Migracja może wymagać nie tylko przeniesienia danych, ale także ich ponownego przetworzenia.
4. Lock-in architektury
To poziom znacznie poważniejszy.
Cała aplikacja została zaprojektowana wokół jednego dostawcy.
Jego mechanizmy są obecne w wielu miejscach systemu.
W takim przypadku nie wymieniamy jednego komponentu.
Przebudowujemy fragment architektury.
5. Lock-in organizacyjny
To często najbardziej niedoceniany problem.
Zespół zna jeden ekosystem.
Wszystkie kompetencje skupiają się wokół jednego rozwiązania.
Dokumentacja, procedury, testy i know-how są związane z jednym dostawcą.
Nawet jeśli technicznie można zmienić model, organizacja nie ma ludzi, którzy potrafią przeprowadzić taką zmianę.
I wtedy vendor lock-in przestaje być wyłącznie problemem technologicznym.
Staje się problemem biznesowym.
Czy Multi-Model rozwiązuje problem?
Naturalną odpowiedzią jest: "Skoro jeden dostawca to ryzyko, używajmy kilku."
To jednak nie zawsze jest najlepsza strategia.
Architektura multi-modelowa ma swoje koszty.
Trzeba zarządzać:
- wieloma API,
- różnymi limitami,
- różnymi modelami cenowymi,
- różnymi poziomami jakości,
- różnymi formatami odpowiedzi,
- testami,
- monitoringiem,
- bezpieczeństwem.
System staje się bardziej złożony.
Dlatego celem nie powinno być: "Musimy korzystać z pięciu dostawców."
Celem powinno być: "Musimy mieć możliwość zmiany dostawcy, jeśli biznes będzie tego potrzebował."
To zasadnicza różnica.
Nie każda firma potrzebuje Multi-Model.
Każda firma powinna jednak wiedzieć, jak wyglądałaby migracja do innego modelu.
AI Gateway i Model Gateway - warstwa, która oddziela aplikację od dostawcy
Jednym ze sposobów ograniczenia zależności jest zastosowanie warstwy pośredniej.
Może ona pełnić funkcję AI Gateway lub Model Gateway.
W uproszczeniu architektura może wyglądać tak:
Aplikacja biznesowa
↓
Warstwa abstrakcji AI
↓
Routing modeli
↓
Adapter dostawcy
↓
OpenAI / Anthropic / Google / model open-weight / model lokalny
Dzięki temu logika biznesowa aplikacji nie musi bezpośrednio znać szczegółów każdego dostawcy.
Możemy mieć własną warstwę odpowiedzialną za:
- wybór modelu,
- routing,
- fallback,
- kontrolę kosztów,
- monitoring,
- logowanie,
- polityki bezpieczeństwa,
- zarządzanie limitami.
W przypadku awarii jednego dostawcy system może spróbować wykorzystać inny model.
W przypadku wzrostu cen możemy zmienić routing.
W przypadku pojawienia się lepszego modelu możemy przeprowadzić testy i zdecydować o migracji.
Nie oznacza to, że zmiana będzie zawsze bezbolesna.
Oznacza jednak, że została zaprojektowana jako realna możliwość.
Model Router - AI nie musi zawsze wybierać tego samego modelu
Jeszcze ciekawszym rozwiązaniem jest routing modeli.
Wyobraźmy sobie system, który otrzymuje różne zadania.
Proste zadanie: "Podsumuj ten tekst."
Może zostać przekazane do szybkiego i taniego modelu.
Bardziej skomplikowane zadanie: "Przeanalizuj dokument i przygotuj szczegółową rekomendację."
Może trafić do mocniejszego modelu.
Zadanie wymagające analizy obrazu może trafić do modelu multimodalnego.
System może więc dynamicznie dobierać model do konkretnego zadania.
To pozwala optymalizować:
- koszty,
- jakość,
- czas odpowiedzi,
- dostępność.
W takim podejściu dostawca AI przestaje być integralną częścią logiki biznesowej.
Staje się jednym z elementów infrastruktury.
I właśnie to jest bardzo ważna zmiana architektoniczna.
Abstrakcja nie oznacza, że wszystkie modele są takie same
Tutaj trzeba uważać na jedną pułapkę.
Można stworzyć własną funkcję: generateText() i uznać, że problem został rozwiązany.
Nie został.
Modele nie są zamiennymi klockami LEGO.
Jeżeli aplikacja wykorzystuje specyficzne możliwości danego modelu, prosta abstrakcja może tylko ukryć problem.
Dobra architektura powinna więc abstrahować od dostawcy, ale jednocześnie świadomie zarządzać różnicami między modelami.
W praktyce oznacza to, że warstwa AI powinna wiedzieć, że model może mieć różne:
- możliwości,
- limity,
- koszty,
- poziomy jakości,
- funkcje,
- konteksty,
- parametry.
Dlatego projektowanie "provider-agnostic" nie powinno oznaczać udawania, że każdy model jest taki sam.
Powinno oznaczać, że system potrafi świadomie korzystać z różnic między modelami.
Evals - bez nich migracja AI jest zgadywaniem
Jednym z najważniejszych elementów architektury odpornej na zmianę są evals, czyli systematyczne testy jakości działania modeli.
Załóżmy, że mamy 1000 rzeczywistych przypadków użycia. Uruchamiamy je na obecnym modelu. Następnie uruchamiamy na nowym. Porównujemy wyniki.
Sprawdzamy:
- jakość,
- poprawność,
- kompletność,
- halucynacje,
- zgodność z wymaganiami,
- czas odpowiedzi,
- koszt.
Dopiero wtedy możemy powiedzieć: "Nowy model jest wystarczająco dobry."
Bez evals migracja może wyglądać jak eksperyment. Z evals staje się procesem inżynierskim.
Dlatego firma wykorzystująca AI powinna budować własne zestawy testowe. Nie tylko testować API. Testować własny przypadek biznesowy. To ogromna różnica.
Prompt też może być źródłem vendor lock-in
Prompty często traktujemy jak tekst. W praktyce mogą stać się elementem logiki biznesowej.
Jeżeli przez wiele miesięcy zespół optymalizuje instrukcje pod konkretny model, prompt może zacząć działać jak fragment kodu.
Powinien więc być:
- wersjonowany,
- testowany,
- dokumentowany,
- monitorowany.
Warto również wiedzieć, które prompty są krytyczne dla działania systemu. Jeżeli zmiana modelu powoduje pogorszenie ich skuteczności, musimy wiedzieć, gdzie szukać problemu.
Dlatego prompt engineering w dojrzałych systemach AI powinien być traktowany coraz bardziej jak element inżynierii oprogramowania.
Open-weight i własne modele - czy to ucieczka od vendor lock-in?
Modele open-weight i możliwość uruchamiania modeli we własnej infrastrukturze zwiększają kontrolę nad technologią.
Ale nie oznacza to automatycznie pełnej niezależności.
Jeżeli przeniesiemy model do własnej infrastruktury, nadal potrzebujemy:
- GPU,
- infrastruktury,
- MLOps,
- monitoringu,
- bezpieczeństwa,
- aktualizacji,
- kompetencji.
Możemy więc ograniczyć zależność od dostawcy modelu, ale jednocześnie zwiększyć zależność od dostawcy infrastruktury. Możemy też korzystać z chmury do uruchamiania modeli open-weight. Wtedy problem częściowo wraca na innym poziomie. Dlatego warto patrzeć na niezależność technologicznie szerzej.
Nie istnieje system całkowicie pozbawiony zależności.
Istnieje natomiast system, w którym zależności są:
- znane,
- kontrolowane,
- mierzalne,
- możliwe do zastąpienia.
Najgroźniejszy vendor lock-in może być w głowach zespołu
Wyobraźmy sobie firmę, która korzysta z jednego dostawcy AI.
Technicznie może zmienić model. Ale nikt w firmie nie wie, jak to zrobić.
Zespół nie zna alternatyw.
Nie ma benchmarków.
Nie ma evals.
Nie ma testów.
Nie ma doświadczenia z innymi modelami.
Wszystkie rozwiązania zostały zbudowane wokół jednego ekosystemu.
To jest lock-in organizacyjny.
Dlatego odporność na vendor lock-in wymaga również inwestowania w kompetencje.
Zespół powinien rozumieć:
- jak działają modele,
- jakie są różnice między dostawcami,
- jak budować warstwy abstrakcji,
- jak testować modele,
- jak mierzyć jakość,
- jak zarządzać kosztami,
- jak przeprowadzać migrację.
Nie chodzi o to, aby każdy programista znał każde API.
Chodzi o to, aby organizacja nie była technologicznie ślepa poza jednym ekosystemem.
Kiedy vendor lock-in może być akceptowalny?
Vendor lock-in nie zawsze jest zły.
Czasami świadoma zależność jest rozsądną decyzją biznesową.
Jeżeli:
- dostawca oferuje wyjątkową funkcję,
- rozwiązanie znacząco skraca czas wdrożenia,
- koszt migracji jest znany,
- ryzyko jest akceptowalne,
- alternatywy są słabsze,
- biznes potrzebuje szybkości,
to silniejsze związanie z jednym dostawcą może być uzasadnione.
Problemem nie jest sam lock-in. Problemem jest nieświadomy lock-in.
Firma powinna wiedzieć:
- od czego jest zależna,
- dlaczego jest zależna,
- ile kosztowałaby zmiana,
- ile trwałaby migracja,
- jakie są alternatywy.
Dopiero wtedy można mówić o świadomej decyzji architektonicznej.
Jak ocenić AI Vendor Lock-in w swojej firmie?
Warto przeprowadzić prosty audyt.
Zadajmy sobie pytania:
Czy możemy zmienić model bez przebudowy całej aplikacji?
Czy logika biznesowa jest niezależna od dostawcy AI?
Czy prompty są wersjonowane?
Czy mamy własne evals?
Czy mamy testy regresji dla najważniejszych przypadków użycia?
Czy dane możemy wyeksportować i przenieść?
Czy możemy zmienić dostawcę embeddingów bez utraty danych?
Czy agenci korzystają z warstwy orkiestracji, czy są bezpośrednio związani z konkretnym ekosystemem?
Czy mamy możliwość zastosowania alternatywnego modelu?
Czy mamy fallback?
Czy wiemy, ile kosztowałaby migracja?
Czy wiemy, ile trwałaby migracja?
Czy mamy ludzi, którzy potrafią ją przeprowadzić?
Im więcej odpowiedzi "nie", tym większa zależność.
Można również stworzyć własny AI Portability Score. Przykładowo oceniać organizację w pięciu obszarach:
Architektura - czy dostawca jest wymienny?
Dane - czy możemy je przenieść?
Modele - czy mamy alternatywy?
Ewaluacja - czy potrafimy porównać modele?
Kompetencje - czy zespół potrafi przeprowadzić migrację?
Taki wynik nie musi być formalnym standardem. Może być jednak bardzo dobrym narzędziem zarządczym.
Bo czasami największym problemem nie jest vendor lock-in. Największym problemem jest to, że firma nie wie, że go ma.
Jak projektować architekturę AI odporną na zmiany?
Nie istnieje jedna uniwersalna architektura. Można jednak przyjąć kilka praktycznych zasad.
Zasada 1 - oddziel logikę biznesową od dostawcy AI
Nie buduj całego systemu bezpośrednio wokół jednego API.
Zasada 2 - stosuj warstwę abstrakcji tam, gdzie ma to sens
AI Gateway lub Model Gateway może ograniczyć zależność aplikacji od konkretnego dostawcy.
Zasada 3 - wersjonuj prompty
Traktuj je jak element systemu, a nie luźne teksty.
Zasada 4 - buduj evals
Nie zakładaj, że "nowy model działa".
Sprawdź to.
Zasada 5 - testuj alternatywy
Nie musisz używać ich produkcyjnie.
Warto jednak wiedzieć, jak radzą sobie z Twoimi przypadkami użycia.
Zasada 6 - kontroluj dane
Nie pozwól, aby Twoje dane biznesowe stały się zakładnikiem jednej platformy.
Zasada 7 - dokumentuj zależności
Wiedza o tym, gdzie system jest związany z konkretnym dostawcą, jest częścią dokumentacji architektonicznej.
Zasada 8 - nie abstrahuj na siłę
Nie ukrywaj różnic między modelami tylko po to, aby uzyskać pozorną przenośność.
Zasada 9 - mierz koszt migracji
Nie wystarczy powiedzieć:
"Kiedyś możemy zmienić dostawcę."
Trzeba wiedzieć:
"Potrzebujemy na to trzech miesięcy i pięciu osób."
Albo:
"Nie jesteśmy w stanie tego zrobić bez przebudowy systemu."
Zasada 10 - podejmuj decyzje świadomie
Czasami najlepszym rozwiązaniem będzie silne związanie z jednym dostawcą.
Ale powinno to być świadome ryzyko.
Nie przypadek.
Pytanie, które każdy CTO powinien zadać
Wyobraźmy sobie, że jutro dostawca AI:
- podwaja ceny,
- wycofuje używany przez nas model,
- zmienia limity,
- ogranicza funkcję, od której zależy nasz produkt,
- przestaje spełniać nasze wymagania compliance.
Co robimy?
Jeżeli odpowiedź brzmi: "Zmienimy dostawcę."
kolejne pytanie powinno brzmieć: "Jak długo nam to zajmie?"
Dzień?
Tydzień?
Miesiąc?
Pół roku?
A może nie wiemy?
To właśnie jest miara naszej odporności technologicznej.
Podsumowanie - nie chodzi o to, żeby nie mieć dostawcy
Budowanie systemu całkowicie niezależnego od zewnętrznych dostawców AI może być nieopłacalne, niepotrzebne albo wręcz niemożliwe.
Nie o to chodzi.
Celem nie jest brak zależności. Celem jest świadome zarządzanie zależnościami.
Możemy korzystać z OpenAI. Możemy korzystać z Anthropic. Możemy korzystać z Google. Możemy korzystać z modeli open-weight. Możemy łączyć różne rozwiązania.
Najważniejsze jest jednak to, aby wiedzieć, gdzie przebiega granica między: "korzystamy z technologii" a "jesteśmy od niej uzależnieni".
W świecie AI ta granica może być szczególnie trudna do zauważenia. Bo vendor lock-in nie powstaje w jeden dzień. Powstaje stopniowo. Najpierw integrujemy API. Potem budujemy funkcję. Potem dokładamy RAG. Potem agentów. Potem automatyzujemy proces. Potem cały zespół zaczyna pracować według tego systemu. I nagle okazuje się, że zmiana modelu nie jest już zmianą modelu - jest zmianą części organizacji.
Dlatego architektura AI powinna być projektowana z myślą nie tylko o tym, co działa dzisiaj, ale również o tym, co stanie się, gdy świat technologii zmieni się jutro.
Nie musisz budować systemu, który działa bez OpenAI, Anthropic czy Google. Powinieneś jednak budować system, który potrafi działać również wtedy, gdy któregoś z nich zabraknie.
To właśnie jest różnica między korzystaniem z AI a świadomym projektowaniem technologii AI.
