Firma produkcyjna rozważająca zmianę dostawcy AI musi zachować coś więcej niż dostęp do modelu językowego. Właściwe pytanie brzmi: czy asystent utrzymania ruchu, usługa wsparcia produkcji lub narzędzie do wyszukiwania informacji operacyjnych pozostaną użyteczne, gdy dostawca zmieni warunki, wycofa usługę albo nada produktowi inny kierunek rozwoju?
Uzależnienie od dostawcy przemysłowego AI jest więc kwestią ciągłości działania. Czy możesz zachować wiedzę operacyjną, połączenia z systemami i reguły decyzyjne, które nadają usłudze wartość, a następnie ustalić, czy rozwiązanie zastępcze wykonuje zadania w akceptowalny sposób?
Webinar o suwerenności cyfrowej przedstawia ten cel jako świadome zarządzanie zależnościami, zamiast poddawania się ich kontroli. W przypadku istniejącej usługi AI oznacza to posiadanie realnej alternatywy, a nie wyeliminowanie wszelkich zależności.
Zachowaj usługę, nie tylko połączenie z modelem
Rozważmy asystenta utrzymania ruchu, który odpowiada na pytania na podstawie zatwierdzonych instrukcji, sprawdza dokumentację urządzeń i przygotowuje zgłoszenie serwisowe do weryfikacji. Zmiana połączenia z modelem obejmowałaby tylko część tej usługi. Nadal potrzebne byłyby właściwe dokumenty, identyfikatory urządzeń, reguły dostępu, instrukcje określające działanie asystenta oraz połączenie z systemem utrzymania ruchu.
Rozpatruj przenoszalność w odrębnych obszarach:
- Eksport danych: czy możesz uzyskać i ponownie wykorzystać informacje oraz konfigurację potrzebne do odtworzenia usługi?
- Łączność techniczna: czy aplikacja zastępcza może połączyć się z wymaganymi systemami, korzystając z właściwych uprawnień?
- Równoważność działania: czy rozwiązanie zastępcze wyszukuje odpowiednie materiały źródłowe, odpowiada w granicach swoich zadań i poprawnie korzysta z narzędzi systemów biznesowych?
Sukces w jednym obszarze nie przesądza o pozostałych. Wyeksportowany zbiór dokumentów nie jest działającym asystentem. Przyjęcie żądania nie dowodzi, że odpowiedź jest akceptowalna. Równoważność działania traktuj jako spełnienie tych samych wymagań operacyjnych, a nie odtwarzanie identycznych sformułowań.
Dyskusja o agentach AI i ERP wskazuje przydatne kryterium wyboru: w jakim stopniu rozwiązanie jest związane z konkretnym modelem językowym, jak bardzo jest otwarte i jak dobrze odwzorowuje logikę biznesową. Zastosuj to rozróżnienie do ciągłości działania: opisuj wymagania biznesowe na tyle jednoznacznie, aby móc ocenić inną implementację na ich podstawie.
Zachowaj zasoby potrzebne do odtworzenia usługi
Nie pozwól, aby zapewnienie „jesteś właścicielem swoich danych” zastąpiło szczegółowe ustalenia dotyczące zakończenia współpracy. Pytaj osobno, co możesz odzyskać, w jakiej formie, na jakich warunkach i z jakimi prawami do ponownego wykorzystania. Własność danych wykorzystywanych przez AI w produkcji oraz faktyczną możliwość ich odzyskania należy rozpatrywać dla każdego zasobu oddzielnie.
W przypadku asystenta utrzymania ruchu zachowaj następujące zasoby lub zabezpiecz do nich dostęp:
- Źródłowe dane operacyjne. Wskaż dokumenty, historie urządzeń i rekordy w systemach biznesowych, których potrzebuje usługa. Ustal prawa do korzystania z nich u nowego dostawcy, w tym ograniczenia dotyczące instrukcji należących do podmiotów trzecich.
- Kontekst wyszukiwania do ponownego wykorzystania. Poproś o wersje dokumentów, mapowania urządzeń, metadane dostępu, fragmenty dokumentów i konfigurację wyszukiwania. Osobno uwzględnij embeddingi, czyli reprezentacje liczbowe służące do wyszukiwania według podobieństwa, oraz indeksy. Zapytaj, które zasoby można wyeksportować, a które trzeba odbudować na podstawie materiałów źródłowych.
- Instrukcje aplikacji i logikę przepływu pracy. Zachowaj prompty, opisy narzędzi, reguły kierowania zadań, zasady zatwierdzania i obsługę wyjątków w formie, którą Twój zespół może przeglądać i utrzymywać.
- Przykłady do oceny działania. Przechowuj reprezentatywne pytania, oczekiwane źródła uzasadniające odpowiedź, dopuszczalne i zabronione działania oraz oceny weryfikatorów poza środowiskiem dostępnym wyłącznie u dostawcy.
- Zapisy rozmów i działania usługi. Określ dostęp do odpowiednich wiadomości, wyszukanych fragmentów, wywołań narzędzi, odpowiedzi, błędów i wersji konfiguracji, z uwzględnieniem zasad retencji i kontroli dostępu.
Celem nie jest żądanie wszystkich wewnętrznych elementów produktu dostawcy. Chodzi o rozróżnienie tego, co organizacja musi zachować, od tego, co jest gotowa odtworzyć. Jeśli na przykład indeksu wyszukiwania nie można wyeksportować, ustal, jakie materiały źródłowe i jaka konfiguracja są potrzebne do odbudowy wyszukiwania, a następnie oceń jego działanie po odtworzeniu.
Zapisy działania usługi zasługują na szczególną uwagę. Wymagaj szczegółów wystarczających do zbadania, jak powstała odpowiedź lub skąd wynikło działanie: o co zapytał użytkownik, jakie materiały źródłowe były dostępne, które narzędzie wywołano i co wydarzyło się później. Zachowaj możliwość takiej analizy po zmianie dostawcy, zamiast uznawać transkrypcję do pobrania za pełną historię działania usługi.
Oddziel kontekst przemysłowy od połączeń właściwych dla dostawcy
Architektura AI niezależna od modelu powinna zapewniać jasno określone miejsce dla kontekstu przemysłowego i reguł biznesowych poza połączeniem z pojedynczym modelem. ARC Advisory Group opisuje podejście, w którym organizacja udostępnia wybrane narzędzia i dane telemetryczne bez przekazywania surowej bazy danych lub kodu źródłowego. To użyteczne rozdzielenie kontrolowanego dostępu do wiedzy przemysłowej od posiadania systemów, w których ta wiedza się znajduje.
W przypadku asystenta utrzymania ruchu zdefiniuj operację biznesową, taką jak „pobierz historię utrzymania tego urządzenia”, niezależnie od formatu żądań dostawcy modelu. Udokumentuj identyfikator urządzenia, dozwolone rekordy, pola wynikowe i obsługę błędów. Umieść konwersję właściwą dla danego dostawcy na granicy systemów, zamiast czynić z niej jedyny opis znaczenia tej operacji.
Zastosuj tę samą dyscyplinę do działań. Polecenie „przygotuj zgłoszenie serwisowe” powinno określać, czy wynikiem jest wersja robocza, kto ją weryfikuje i co dzieje się po przekroczeniu limitu czasu lub ponownym wysłaniu żądania. Rozwiązanie zastępcze potrzebuje tych reguł, a nie tylko adresu połączenia.
Sam otwarty protokół nie jest wystarczającym kryterium odbioru. Zapytaj, jakie mechanizmy uwierzytelniania, uprawnienia, znaczenia narzędzi i reguły wykonywania nadal wymagają konfiguracji. Wymagaj, aby rozwiązanie zastępcze zademonstrowało potrzebne operacje przy zachowaniu ustalonych granic dostępu. Wspólna nazwa interfejsu nie powinna zastępować takiego dowodu.
Jeśli szersza decyzja dotyczy zmiany samej platformy ERP, osobno oceń, czy proces wspierany przez AI uzasadnia modernizację ERP. Zachowanie istniejącej usługi AI nie musi stawać się argumentem za wymianą systemu będącego źródłem danych referencyjnych.
Ustal akceptowalne działanie przed zmianą dostawcy
Wróćmy do asystenta utrzymania ruchu. Przekaż rozwiązaniu zastępczemu to samo pytanie technika, kontekst urządzenia i zatwierdzony zbiór dokumentów. Poproś je o wskazanie właściwej procedury i przygotowanie dozwolonej wersji roboczej zgłoszenia. Test nie polega na sprawdzeniu, czy interfejs przyjmuje dane wejściowe. Chodzi o to, czy uzyskane materiały źródłowe, odpowiedź i działanie spełniają wymagania usługi.
Oceniaj wyszukiwanie i korzystanie z narzędzi oddzielnie. Sprawdź, czy znaleziono właściwy fragment, czy odpowiedź pozostała w granicach zawartych w nim informacji oraz czy narzędzie otrzymało poprawny identyfikator urządzenia i szczegóły zgłoszenia. Uwzględnij przypadki, w których asystent musi poprosić o doprecyzowanie lub przerwać działanie. Kwestia tego, czy instrukcja utrzymania ruchu dotyczy danego urządzenia, pozostaje ważna niezależnie od tego, który dostawca generuje odpowiedź.
Zachowaj przykłady służące do oceny obecnej usługi oraz decyzje weryfikatorów, aby wykorzystać je w tym porównaniu. Wymagaj rozstrzygnięcia istotnych różnic przez osobę weryfikującą, zamiast przyjmować płynność wypowiedzi lub działające połączenie za kryterium zmiany dostawcy. Określ sposób obsługi zadań, dla których rozwiązanie zastępcze nie przeszło jeszcze oceny.
Ścisła integracja nadal może być rozsądnym wyborem. Oceń wartość spójnego przepływu pracy, skoordynowanego wsparcia i mniejszej liczby komponentów, które zespół musi połączyć, w zestawieniu z zasobami i mechanizmami kontroli wymagającymi odtworzenia przy odejściu od dostawcy. Podobnie oceń, kto będzie utrzymywał połączenia, uprawnienia i proces oceny w bardziej modułowej architekturze. Wybieraj zależność, którą rozumiesz i którą możesz zarządzać, a nie samą etykietę otwartości.
Pożądanym rezultatem jest usługa, której działanie możesz świadomie kontynuować: zachować to, co istotne, ponownie połączyć jej elementy przy kontrolowanym dostępie i potwierdzić akceptowalne działanie przed przekazaniem odpowiedzialności. Jeśli potrzebujesz pomocy w przeanalizowaniu tych granic, sprawdź usługi Data & AI w kontekście usługi, którą chcesz zachować.