Wybór oraz wdrożenie oprogramowania w przedsiębiorstwie stanowi dziś standardowy, a zarazem kluczowy element prowadzenia nowoczesnej działalności gospodarczej. Proces ten nie tylko wspiera efektywność operacyjną, lecz także umożliwia optymalizację procesów biznesowych. Jednocześnie jest to istotne wyzwanie organizacyjno-biznesowe – począwszy od wyboru systemu i jego dostawcy (warto pamiętać, że w przypadku wiodących systemów typu np. ERP, oferowanych przez globalnych producentów, takie wdrożenia mogą być realizowane także przez szereg podmiotów partnerskich) poprzez wdrożenie systemu, aż po jego późniejsze serwisowanie, rozwój i dostosowywanie się do zmieniających się potrzeb (zarówno prawnych jak i organizacyjnych).
Mając na względzie skalę oraz wagę całego przedsięwzięcia, jednym z istotnych ryzyk, które zamawiający powinien brać pod uwagę jest ryzyko powstania tzw. vendor lock-in, czyli sytuacji uzależnienia się od konkretnego dostawcy i świadczonych przez niego usług, związanych z utrzymaniem oraz rozwojem systemu IT w organizacji zamawiającego. Przyczyny powstania vendor lock-in mogą być różne – w dalszej części wskażemy kluczowe elementy, na które należy zwrócić uwagę, a także możliwe środki zaradcze.
Aby lepiej zrozumieć mechanizmy prowadzące do powstania vendor lock-in oraz skutecznie im przeciwdziałać, warto przyjrzeć się temu zjawisku na kilku uzupełniających się poziomach. Każdy z nich – kompetencyjny, prawny, techniczny – pokazuje inny aspekt zależności zamawiającego od dostawcy.
Poziom kompetencji
Jedną z sytuacji, która – choć nie będzie szczegółowo omawiana w ramach niniejszego artykułu – może w praktyce prowadzić do pewnego rodzaju vendor lock-in, jest brak odpowiednich zasobów kadrowych w dziale IT danego zamawiającego. Sprowadza się ona do tego, że mimo iż na płaszczyźnie prawnej posiadamy stosowne uprawnienia do utrzymywania i rozwoju systemu, a także odpowiednio udostępniony kod źródłowy, to w naszej organizacji brakuje kompetencji pozwalających na faktyczne wykonywanie tych uprawnień.
Innymi słowy, dział IT nie jest w stanie rzeczywiście skorzystać z udzielonych uprawnień – i z uwagi na zaawansowanie oraz złożoność systemu, na poziomie czysto kompetencyjnym nie będzie w stanie samodzielnie zastąpić dostawcy i świadczyć w jego miejsce niezbędnych usług.
Analogiczny problem może pojawić się przy wdrażaniu rozwiązań opartych na sztucznej inteligencji. W takich przypadkach brak odpowiednich kompetencji w zakresie analizy danych, walidacji modeli czy ich fine-tuningu może sprawić, że nawet przy zapewnieniu odpowiednich praw i dostępu do narzędzi, organizacja nie będzie w stanie samodzielnie zarządzać wdrożonym systemem AI.
Poziom prawny
Płaszczyzną, która szczególnie nas interesuje w kontekście niniejszego artykułu, jest przypadek w którym vendor lock-inpowstaje na poziomie prawnym – tj. sytuacja, w której nie jesteśmy w stanie podejmować określonych działań w działającym w naszym przedsiębiorstwie systemie (takich jak serwisowanie, rozwijanie itd.) z uwagi na brak stosownych uprawnień.
W tym kontekście warto rozpocząć od ogólnych, choć istotnych uwag – mianowicie, że w zależności od konkretnego przypadku i konfiguracji biznesowej, możliwości uzyskania przez zamawiającego określonego zakresu uprawnień do oprogramowania mogą być bardzo zróżnicowane. Możliwe (i faktycznie występujące w realiach rynkowych) są sytuacje w ramach których cały system jest tworzony na indywidualne potrzeby konkretnego zamawiającego, niejako „szyty na miarę”. W odniesieniu do tego rodzaju systemu dedykowanego możliwe jest przeniesienie autorskich praw majątkowych do całego rozwiązania na zamawiającego.
Dużo częściej występującą sytuacją będzie jednak model w ramach którego zamawiający korzysta z oprogramowania standardowego dostarczonego przez globalnego dostawcę. Tego rodzaju systemy stanowią core działalności takiego podmiotu, a udzielane zamawiającemu uprawnienia ograniczają się zazwyczaj do stosunkowo wąskiej licencji na korzystanie z systemu. W takich przypadkach pole manewru po stronie zamawiającego jest ograniczone, przy czym należy zaznaczyć, że kwestie te są coraz częściej regulowane na podstawie ustandaryzowanych i globalnie stosowanych szablonach umownych (najlepszym przykładem są postanowienia w dokumentach typu EULA, publikowane na stronach producentów).
Wbrew pozorom, nawet w takim modelu istnieje jednak istotne „ale”. Raczej niespotykaną jest sytuacja w której oprogramowanie standardowe dostawcy w postaci prosto „z półki” (COTS) byłoby wystarczające na potrzeby wdrożenia i obsługi procesów biznesowych zamawiającego. W praktyce, w ramach wdrożenia, do standardowego oprogramowania tworzone są liczne modyfikacje (customy) będące dostosowanymi lub dodatkowymi modułami spersonalizowanymi dla danego zamawiającego, adresującymi jego potrzeby i procesy biznesowe. W odniesieniu do tego rodzaju modyfikacji istnieje znacznie większa szansa na uzyskanie szerokiej licencji lub wręcz przeniesienie autorskich praw majątkowych na zamawiającego.
Nie wdając się w szerszą dyskusję na temat różnic między nabyciem praw a licencją, ani też sposobów zabezpieczenia interesów zamawiającego w przypadku udzielenia licencji (co może stanowić temat na odrębne opracowania), skupimy się na możliwym zakresie udzielanych lub nabywanych uprawnień w kontekście vendor lock in.
Vendor lock-in na poziomie prawnym oznacza sytuację, w której nie przysługuje nam określone prawo – np. prawo do modyfikacji wykorzystywanego w przedsiębiorstwie systemu. Przykładowo, dostawca przygotowuje oprogramowanie dedykowane, dostosowane do naszych potrzeb – niezależnie od tego czy jest to cały system czy poszczególne moduły. Nawet jeśli dojdzie do przeniesienia na zamawiającego autorskich praw majątkowych do tego oprogramowania, to w umowie może zabraknąć wskazania odpowiedniego pola eksploatacji umożliwiającego dokonywanie jego modyfikacji. W takiej sytuacji, mimo posiadania wewnętrznego zaplecza kompetencyjnego oraz technicznego (np. dostępu do kodu źródłowego – o czym poniżej) zamawiający nie będzie miał prawnej możliwości dokonywania zmian w systemie. W zakresie jego dalszego rozwoju i modyfikacji, pozostaje zatem zależny od pierwotnego dostawcy.
W przypadku oprogramowania standardowego brak prawa do modyfikacji stanowi powszechną praktykę. Warto mieć przy tym na uwadze, że takie systemy często umożliwiają parametryzację i konfigurację za pomocą udostępnianych przez dostawcę narzędzi – działania te nie stanowią modyfikacji w rozumieniu prawa autorskiego, a tym samym nie wymagają posiadania odrębnych uprawnień w tym zakresie.
Poziom techniczny
Kolejnym poziomem, na którym może dojść do powstania vendor lock-in, jest poziom kodu źródłowego. W tym przypadku zależność od dostawcy sprowadza się do sytuacji, w której mimo przeniesienia na rzecz zamawiającego odpowiednich uprawnień (w szczególności prawa do modyfikacji) – w umowie nie przewidziano wydania kodu źródłowego. Tymczasem to właśnie kod źródłowy stanowi element kluczowy umożliwiający zespołowi IT zrozumienie struktury programu, jego rozwój oraz serwisowanie. Dla uzyskania dostępu do kodu źródłowego niezbędne jest wyraźne uregulowanie tej kwestii w umowie zawieranej przez strony, co potwierdza – choć skromne – dostępne orzecznictwo sądowe dotyczące tej tematyki.
Co więcej, ten poziom zależności może ulec dodatkowemu skomplikowaniu. Równie istotne jak samo przewidzenie wydania kodu źródłowego jest bowiem odpowiednie opisanie w umowie, w jaki sposób kod źródłowy powinien zostać wydany. W praktyce mogą wystąpić sytuacje, w których mimo spełnienia formalnego obowiązku wydania kodu, kod źródłowy jest choćby: niekompletny, nieaktualny, brakuje instrukcji do jego skompilowania czy utrudnione jest jego odczytanie (kod zaciemniony, zaszyfrowany) itd. W takich przypadkach rzeczywiste wykorzystanie kodu źródłowego do celów utrzymania czy dalszego rozwoju oprogramowania może być znacznie utrudnione – lub wręcz nieopłacalne ze względu na nakład pracy, jaki były konieczny do jego rekonstrukcji i zrozumienia.
Vendor lock-in w AI
Coraz bardziej aktualnym zagadnieniem staje się także vendor lock-in w kontekście rozwiązań opartych na sztucznej inteligencji. W tym kontekście, zależność od dostawcy może przybrać nowe, specyficzne formy wynikające ze specyfiki systemów opartych na uczeniu maszynowym oraz dostępu do danych.
Zamawiający, który decyduje się na wdrożenie rozwiązań AI (zwłaszcza tych oferowanych w modelu Software as a Service) może spotkać się z sytuacjami, w których nie uzyskuje kontroli nad algorytmem, który został wytrenowany w toku wdrożenia z wykorzystaniem danych pochodzących z jego własnej organizacji. Brak dostępu do wytrenowanego modelu, jego architektury lub dokumentacji może w praktyce uniemożliwiać migrację rozwiązania do innego dostawcy lub jego dalszy rozwój.
Dodatkowym źródłem zależności jest nieuregulowanie kwestii związanych z dostępem do danych (treningowych, walidacyjnych itd.), które posłużyły do wytrenowania modelu. Brak postanowień gwarantujących zamawiającemu dostęp do tych zbiorów danych oraz brak informacji o zakresie ich przetwarzania, może doprowadzić do sytuacji, w której niemożliwe będzie odtworzenie ani ponowne przetrenowanie modelu (zarówno wewnętrznie jak i za pomocą innego wykonawcy).
Zamawiający może również napotkać ograniczenia licencyjne, które uniemożliwiają modyfikowanie modelu lub jego wykorzystanie poza środowiskiem technologicznym dostawcy. Wiele rozwiązań AI projektowanych jest w sposób silnie zintegrowany z określoną platformą chmurową (np. Amazon SageMaker, Azure ML, Google Vertex AI), co powoduje, że nawet przy dostępie do modelu i kodu źródłowego, ich samodzielne utrzymanie i rozwój poza tym środowiskiem może wiązać się z istotnymi trudnościami lub kosztami nieproporcjonalnymi do potencjalnych korzyści.
Vendor lock-in w kontekście AI nie sprowadza się więc wyłącznie do klasycznych zagadnień związanych z przeniesieniem praw autorskich czy dostępem do kodu, ale obejmuje szerszy zakres zależności wynikający z technicznej specyfiki takich rozwiązań. Zależność ta może wynikać przede wszystkim z brakiem kontroli nad kluczowymi elementami technologicznymi – takimi jak model, dane treningowe, infrastruktura. Dlatego też tak istotne jest, aby kwestie te zostały uregulowane na etapie zawierania umowy. Niedoprecyzowanie tych elementów w umowie może skutkować sytuacją, w której zamawiający nie będzie w stanie efektywnie korzystać z wdrożonego rozwiązania bez dalszego zaangażowania pierwotnego dostawcy.