Paradoks AI Microsoftu: nabywca korporacyjny może płacić dwa razy

Google News wyeksponowało niewygodny argument Microsoftu: firmy kupujące AI ryzykują, że zapłacą ponownie wiedzą, która daje im przewagę konkurencyjną. Dyrektor generalny Microsoftu Satya Nadella nazywa ten konflikt odwróconym paradoksem informacji. Jego teza odwraca do góry nogami zwykłą opowieść o wartości AI. Lepsze wyniki wymagają bogatszego kontekstu, lecz może on zawierać lata decyzji, korekt i zastrzeżonych ocen.

To ostrzeżenie ma znaczenie, ponieważ korporacyjna AI wyszła poza odizolowane prompty. Agenci pobierają dziś dokumenty, wywołują narzędzia, obserwują wyniki i zapisują informacje zwrotne w całych przepływach pracy. Każda interakcja może ujawnić, jak firma definiuje jakość, radzi sobie z wyjątkami i podejmuje decyzje. Dostawca modelu zapewnia inteligencję, ale to klient dostarcza wiedzę operacyjną, która czyni ją użyteczną.

Nie oznacza to, że każdy korporacyjny prompt staje się danymi treningowymi. Microsoft, OpenAI, Google i Anthropic publikują zabezpieczenia ograniczające trening na komercyjnych treściach klientów. Głębsze pytanie brzmi, kto kontroluje otaczającą pętlę uczenia się, w tym ewaluacje, ślady przepływów pracy, dostosowane modele i zgromadzone informacje zwrotne.

Google News przekształciło ostrzeżenie Microsoftu w historię o korporacyjnej AI

Najważniejszym wydarzeniem nie jest premiera nowego modelu. Jest nim publiczne uznanie przez Microsoft, że wdrażanie AI może przekazywać strategiczną wiedzę w niewłaściwym kierunku.

Nadella przedstawił odwrócony paradoks informacji w eseju z 12 lipca. Zaadaptował starszy problem ekonomiczny kojarzony z Kennethem Arrowem. W wersji Arrowa sprzedawca musi ujawnić informację, zanim kupujący będzie w stanie ocenić jej wartość, potencjalnie oddając w ten sposób produkt.

Nadella twierdzi, że AI odwraca ten kierunek. Firma już zapłaciła za dostęp do modelu, ale model potrzebuje informacji specyficznych dla firmy, zanim będzie mógł dostarczyć wartość specyficzną dla firmy. Kupujący ujawnia więc wiedzę po zakupie produktu.

Ta wiedza obejmuje więcej niż poufne dokumenty. Może zawierać prompty wypracowane w wyniku wielokrotnych eksperymentów, korekty przekazywane przez specjalistów, wewnętrzne kryteria oceny oraz ślady pokazujące, jak pracownicy wykonują trudne zadania.

„Każda korekta jest destylowana do wiedzy instytucjonalnej” — napisał Nadella w swoim oryginalnym eseju. To stwierdzenie wskazuje centralne napięcie artykułu. Systemy AI stają się użyteczne, obserwując dokładnie te zachowania, których przedsiębiorstwa powinny ostrożnie strzec przed oddaniem.

Temat dotarł do szerszej publiczności dzięki materiałom wyeksponowanym przez Google News, w tym początkowej analizie bezpieczeństwa. Ta dystrybucja ma znaczenie, ponieważ argument można łatwo pomylić z kolejnym ostrzeżeniem przed wklejaniem przez pracowników sekretów do chatbotów.

Obawy Nadelli są szersze. Nawet zatwierdzony system działający na podstawie umowy komercyjnej może tworzyć problem własności wokół wiedzy pochodnej. Surowy dokument może pozostać chroniony, podczas gdy zestaw ewaluacyjny, ślad agenta lub zoptymalizowany przepływ pracy przechwytuje jego znaczenie operacyjne.

Wyobraźmy sobie ubezpieczyciela wykorzystującego agenta AI do analizowania nietypowych roszczeń. Pliki źródłowe zawierają wrażliwe informacje, ale najcenniejszym zasobem może być sekwencja kontroli wykonywanych przez doświadczonych badaczy. Ich korekty uczą system, które niespójności są istotne, a które wyjątki są uzasadnione.

Producent staje przed tym samym problemem, gdy inżynierowie używają asystenta do diagnozowania awarii sprzętu. Instrukcja jest ważna, ale rzadka wiedza tkwi w sposobie, w jaki starsi inżynierowie łączą odczyty czujników, historię konserwacji i subtelne symptomy. Powtarzająca się informacja zwrotna może przekształcić ten osąd w mechanizm nadający się do ponownego użycia.

To rozróżnienie oddziela ochronę danych od kontroli nad wiedzą. Zespoły bezpieczeństwa tradycyjnie pytają, kto może uzyskać dostęp do pliku, jak długo jest on przechowywany i czy jest szyfrowany. Zarządzanie danymi korporacyjnej AI musi również pytać, kto korzysta z uczenia się powstającego, gdy pracownicy używają tego pliku.

Koncepcja zyskała bardziej formalne ujęcie wkrótce potem. Sześciostronicowy artykuł badawczy opublikowany 14 lipca modeluje to, co jego autorzy nazywają odpowiednikiem problemu Arrowa po stronie użytkownika. Ich model ekonomiczny dowodzi, że retencja może być wyższa lub niższa od społecznie pożądanego poziomu, zależnie od tego, jak platformy przechwytują korzyści i internalizują szkody.

To zastrzeżenie jest ważne. Retencja nie jest automatycznie szkodliwa. Wspólne uczenie się może poprawiać bezpieczeństwo, niezawodność i wydajność modeli. Konflikt pojawia się, gdy dostawca przechwytuje te korzyści, podczas gdy klient ponosi niejasną utratę kontroli.

Presja spada na nabywców, a nie tylko na dostawców AI

Nabywcy korporacyjni muszą teraz oceniać AI jako relację opartą na wiedzy, a nie wyłącznie jako zakup oprogramowania.

Bezpośrednia presja spada na dyrektorów ds. informatyki, liderów bezpieczeństwa, zespoły zakupowe i właścicieli biznesowych wdrażających agentów. Muszą oni zdecydować, jakie informacje system może przetwarzać i które artefakty uczenia firma musi zachować.

Tradycyjne umowy dotyczące oprogramowania koncentrują się na dostępności usługi, kontrolach dostępu, wsparciu, poufności i usuwaniu danych. Te kwestie pozostają konieczne. Nie obejmują jednak w pełni systemu AI, który obserwuje korekty użytkowników i zmienia zachowanie poprzez wyszukiwanie, pamięć, dostrajanie lub orkiestrację.

Warstwa orkiestracji to oprogramowanie, które wybiera modele, zestawia kontekst, wywołuje narzędzia i zarządza stanem przepływu pracy. Jeśli dostawca kontroluje tę warstwę, może stać się jedynym miejscem, w którym zgromadzona przez firmę wiedza operacyjna AI działa niezawodnie.

Tworzy to presję nawet wtedy, gdy bazowy model nigdy nie trenuje na promptach klientów. Firma może pozostawać zależna od specyficznego dla dostawcy formatu pamięci, usługi ewaluacyjnej, frameworka agentów lub systemu konektorów. Zmiana modeli oznacza wówczas konieczność odbudowania wokół nich wyuczonego przepływu pracy.

Ewaluacje, zwykle skracane do evals, dobrze ilustrują problem. Eval to ustrukturyzowany test służący do oceny, czy system AI spełnia określony standard. Evals banku mogą kodować to, co uznaje się za akceptowalne dochodzenie w sprawie oszustwa, zgodne z wymogami wyjaśnienie lub decyzję o eskalacji.

Te testy mogą być cenniejsze niż model. Konkurenci mogą licencjonować podobne modele bazowe, ale nie mogą łatwo odtworzyć definicji banku, przykładów, przypadków brzegowych i progów niepowodzenia. Evals reprezentują skompresowane doświadczenie instytucjonalne.

Ta sama logika dotyczy korekt. Prawnik rewidujący analizę umowy wygenerowaną przez AI ujawnia, które klauzule zasługują na uwagę i jakie ryzyko organizacja akceptuje. Kierownik wsparcia zastępujący decyzję agenta ujawnia różnicę między odpowiedzią poprawną technicznie a odpowiedzią, która chroni relację z klientem.

Dlatego korporacyjne dane AI obejmują informacje behawioralne, a także przechowywane treści. Prompt opisuje bieżące zadanie. Korekta wyjaśnia, jak zdaniem organizacji powinno wyglądać właściwe zadanie.

Liderzy biznesowi stają również przed problemem pomiaru. Pulpity produktywności często liczą przygotowane podsumowania, zamknięte zgłoszenia lub zaakceptowany kod. Rzadko mierzą, czy wiedza nadająca się do ponownego użycia zgromadziła się wewnątrz przedsiębiorstwa, czy w usłudze kontrolowanej przez dostawcę.

Wdrożenie może więc wykazywać natychmiastowe zyski, jednocześnie osłabiając długoterminową kontrolę. Pracownicy wykonują zadania szybciej, lecz organizacja nie zyskuje przenośnego zapisu tego, dlaczego agent się poprawił. Ekspertyza pozostaje rozproszona po historiach czatów, zastrzeżonych logach lub niedostępnej telemetrii usługi.

Pracownicy wiedzy odczuwają tę presję w mniejszej skali. Ich najlepsze prompty i wzorce przeglądu stają się częścią codziennej pracy, ale wielu z nich nie może eksportować ich jako ustrukturyzowanych zasobów. Gdy zmieniają narzędzia, zgromadzona wiedza często znika.

Kontrolowane podejście do łączenia wiedzy może ograniczyć tę fragmentację, utrzymując kontekst źródłowy połączony z warstwą wiedzy zarządzaną przez użytkownika. Zasada strategiczna jest szersza niż jakikolwiek produkt: ważny kontekst powinien pozostać użyteczny w różnych modelach i przepływach pracy.

Zespoły zakupowe muszą zatem wyjść poza prostą obietnicę dotyczącą danych treningowych. Potrzebują jasnych odpowiedzi na temat retencji, wtórnego wykorzystania, przeglądu przez ludzi, podwykonawców, własności wyników, obsługi informacji zwrotnych, usuwania danych, przenoszalności i dostępu audytowego.

Powinny także rozróżniać edycje produktów. Usługi konsumenckie, biznesowe, API i korporacyjne często działają na odmiennych warunkach. Ochrona dostępna w zarządzanej firmowej przestrzeni roboczej może nie obowiązywać, gdy pracownik loguje się na konto osobiste.

To rozróżnienie czyni shadow AI szczególnie ryzykowną. Shadow AI opisuje narzędzia używane bez zgody lub widoczności organizacji. Pracownik może przesłać wartościowy kontekst do usługi konsumenckiej, ponieważ zatwierdzony system wydaje się wolniejszy lub mniej funkcjonalny.

Firma traci wtedy zarówno granicę techniczną, jak i kontraktową. Może nie wiedzieć, które konto zostało użyte, czy historia była włączona, jak treść była przechowywana ani gdzie wynik trafił do procesu biznesowego.

Wymuszoną odpowiedzią nie jest całkowity zakaz. Zakazywanie użytecznych narzędzi często wypycha aktywność jeszcze dalej poza zarządzane systemy. Trwalszym rozwiązaniem jest zapewnienie pracownikom zatwierdzonych opcji przy jednoczesnym uczynieniu granicy wiedzy widoczną i egzekwowalną.

Rzeczywistym kompromisem jest lepszy kontekst kontra kontrola

Odwrócony paradoks informacji istnieje, ponieważ najbezpieczniejszy system AI jest często gorzej poinformowany, podczas gdy system najlepiej poinformowany może stać się trudniejszy do zarządzania.

Ogólny model może tworzyć rutynowe teksty bez wrażliwych informacji. Nie potrafi jednak niezawodnie wyjaśnić wewnętrznego wyjątku, ocenić prywatnego projektu ani działać w procesie specyficznym dla firmy bez dodatkowego kontekstu.

Generowanie wspomagane wyszukiwaniem, powszechnie nazywane RAG, dostarcza ten kontekst, odnajdując odpowiednie rekordy i wstawiając je do żądania modelu. Agenci idą dalej, używając narzędzi, odczytując stan i wykonując działania w wielu krokach.

Każda z tych możliwości zwiększa potencjalną wartość. Rozszerza też ścieżkę, którą przemieszczają się dane korporacyjnej AI. Żądanie może dotknąć aplikacji, usługi wyszukiwania, punktu końcowego modelu, platformy logowania, podłączonych narzędzi i systemów monitorowania.

Odpowiednia granica bezpieczeństwa wykracza zatem poza dostawcę modelu. Firma musi uwzględnić każdy komponent, który otrzymuje prompty, pobrane fragmenty, pośrednie artefakty rozumowania, wyniki narzędzi lub informacje zwrotne od użytkowników.

To jeden z powodów, dla których zobowiązanie „nie są używane do treningu” nie rozstrzyga problemu. Trening jest jedną z form wykorzystania. Retencja na potrzeby monitorowania nadużyć, przechowywanie historii rozmów, przegląd administracyjny i przetwarzanie przez połączone usługi pozostają odrębnymi pytaniami.

Microsoft twierdzi, że prompty, odpowiedzi i dane dostępne za pośrednictwem Microsoft Graph nie są wykorzystywane do trenowania modeli bazowych stojących za Microsoft 365 Copilot. Jego zabezpieczenia korporacyjne obejmują również użycie organizacyjne istniejącymi komercyjnymi zabezpieczeniami danych.

OpenAI również twierdzi, że domyślnie nie trenuje na danych z produktów biznesowych ani platformy API. Jego dokumentacja dotycząca prywatności biznesowej wskazuje, że kwalifikujące się organizacje mogą konfigurować retencję, w tym zerową retencję danych dla kwalifikującego się użycia API.

Google podaje, że treści używane przez Gemini w Workspace nie są bez zgody wykorzystywane do trenowania ani ulepszania bazowych modeli generatywnych poza Workspace. Jego kontrole Workspace rozróżniają również zarządzane użycie biznesowe, usługi osobiste oraz opcjonalne funkcje udostępniania danych.

Anthropic stwierdza, że dane przechowywane za pośrednictwem jego komercyjnego API nie są wykorzystywane do trenowania modeli bez wyraźnej zgody. Dokumentuje również rozwiązania z zerową retencją danych dla kwalifikujących się produktów, choć dostępność zależy od usługi i umowy.

Te zobowiązania bezpośrednio podważają najmocniejszą wersję ostrzeżenia Nadelli. Jeżeli dostawcy rozwiązań dla przedsiębiorstw nie trenują na treściach klientów, sugerowanie, że każdy prompt automatycznie ulepsza wspólny model bazowy, jest nieprecyzyjne.

Paradoks utrzymuje się w węższej i bardziej uzasadnionej formie. Klient nadal może stracić praktyczną kontrolę nad systemem uczenia zbudowanym wokół modelu, nawet gdy jego surowe treści pozostają wyłączone z ogólnego treningu.

Wyobraźmy sobie firmę programistyczną wdrażającą agenta do programowania. Dostawca nie trenuje modelu bazowego na repozytorium firmy. Jednak wartość agenta zależy od zastrzeżonych instrukcji, zestawów testów, komentarzy z przeglądów, integracji z narzędziami oraz rosnącej historii zaakceptowanych zmian.

Jeśli te zasoby istnieją wyłącznie w środowisku dostawcy, firma nadal jest narażona na uzależnienie od niego. Jest właścicielem kodu, ale niekoniecznie całego procesu, który uczynił agenta skutecznym.

Przenośność modeli pomaga, ale sama nie rozwiązuje problemu. Dwa modele mogą różnie interpretować ten sam prompt. Wywoływanie narzędzi, pamięć, filtry bezpieczeństwa, limity kontekstu i formaty wyników również się różnią. Przeniesienie agenta wymaga zachowania jego zachowania, a nie jedynie zmiany punktu końcowego API.

Firmy potrzebują zatem przenośnych ewaluacji. Powinny móc uruchamiać te same testy biznesowe na wielu modelach i porównywać wyniki według własnych kryteriów. Dzięki temu wybór modelu staje się decyzją operacyjną, a nie nieodwracalną zależnością.

Potrzebują także kontrolowanej informacji zwrotnej. Przycisk „kciuk w dół” może pomóc dostawcy ulepszyć produkt, ale wewnętrzna korekta może mieć wartość strategiczną. Organizacje powinny decydować, która informacja zwrotna opuszcza ich granicę, a która staje się częścią prywatnego rejestru uczenia.

Lokalne systemy wiedzy zapewniają kolejną warstwę kontroli. Utrzymywanie materiałów źródłowych, adnotacji i indeksów wyszukiwania pod nadzorem organizacji może ograniczyć niepotrzebne ujawnianie danych. Ułatwia też zastąpienie modelu, ponieważ warstwa wiedzy nie znika wraz z interfejsem.

Przeszukiwalna techniczna baza wiedzy może zachować pochodzenie danych obok pobranego kontekstu. Ma to znaczenie, gdy inżynierowie muszą zweryfikować, dlaczego pojawiła się dana odpowiedź i który dokument ją potwierdzał.

Żaden z tych środków nie eliminuje kompromisu. Firma, która udostępnia zbyt mało kontekstu, otrzymuje ogólne odpowiedzi i słabą automatyzację. Firma, która udostępnia wszystko, zyskuje wydajność kosztem większej ekspozycji, zależności i pracy związanej z zarządzaniem.

Właściwa granica będzie różnić się zależnie od procesu. Tworzenie publicznych tekstów marketingowych wiąże się z innym ryzykiem niż analiza dokumentów dotyczących fuzji. Streszczanie zatwierdzonej polityki różni się od pozwalania agentowi na modyfikowanie infrastruktury produkcyjnej.

Strategicznym zadaniem jest dopasowanie zakresu ujawniania danych do wartości i odwracalności działania. Wysokowartościowe, zastrzeżone procesy wymagają ściślejszej izolacji, czytelniejszych logów, większej przenośności i bardziej rozważnego zatwierdzania niż administracyjne zadania niskiego ryzyka.

Argument Microsoftu dotyczy również Microsoftu

Ostrzeżenie Nadelli jest wiarygodne właśnie dlatego, że Microsoft nie może stać poza opisywanym przez siebie konfliktem.

Microsoft sprzedaje modele, copiloty, infrastrukturę chmurową, narzędzia do tworzenia agentów, platformy danych oraz usługi bezpieczeństwa. Zyskuje, gdy klienci przenoszą więcej pracy i kontekstu do jego systemów.

Ta pozycja nie unieważnia odwróconego paradoksu informacyjnego. Czyni jednak Microsoft częścią mapy przeciwników. Napięcie nie przebiega między Microsoftem a inną firmą AI. Chodzi o obietnicę dostawcy dotyczącą pomocnej inteligencji i potrzebę kupującego, by zachować niezależną wiedzę.

Zabezpieczenia Microsoftu dla przedsiębiorstw odnoszą się do ważnych aspektów tej obawy. Ograniczają trenowanie modeli bazowych na promptach organizacji oraz łączą Copilot z istniejącymi mechanizmami tożsamości, zgodności i kontroli danych.

Mimo to firma może stosować się do tych zabezpieczeń i pozostać zależna od środowiska Microsoftu. Jej agenci mogą polegać na uprawnieniach Microsoft Graph, przepływach Copilot Studio, zasadach Purview, zastrzeżonych konektorach lub narzędziach ewaluacyjnych specyficznych dla dostawcy.

OpenAI, Google i Anthropic podlegają równoważnej kontroli. Wszystkie chcą, aby klienci korporacyjni podłączali głębsze źródła, wdrażali bardziej zdolnych agentów i zwiększali zakres obsługiwanych procesów. Cele te wymagają od klientów zaufania do coraz rozleglejszej powierzchni technicznej.

Konkurencja wywiera użyteczną presję. Dostawcy reklamują obecnie wyłączenia z treningu, kontrole administracyjne, szyfrowanie, opcje retencji oraz funkcje zgodności. Kupujący mogą porównywać te obietnice i negocjować silniejsze warunki.

Jednak dokumentacja produktu nie może zastąpić weryfikacji na poziomie systemu. Dostawca może chronić własny punkt końcowy, podczas gdy konektor zewnętrznego dostawcy przechowuje prompty. Wewnętrzne narzędzie logujące może rejestrować pełne odpowiedzi. Źle skonfigurowana warstwa wyszukiwania może ujawniać rekordy między działami.

Agentowa AI podnosi stawkę, ponieważ działania generują nowe dane. Agent analizujący dokument tworzy podsumowanie. Agent realizujący proces tworzy sekwencję decyzji, wywołań narzędzi, błędów, ponowień i zatwierdzeń.

Ta sekwencja może ujawniać więcej niż oryginalny dokument. Pokazuje, jak organizacja przekształca informacje w działanie. Dla konkurentów wiedza o tym procesie może być trudniejsza do zdobycia niż dane leżące u jego podstaw.

Ryzyka bezpieczeństwa wykraczają również poza sposób wykorzystania danych przez dostawcę. Prompt injection występuje, gdy złośliwe instrukcje trafiają do systemu AI poprzez dane wejściowe użytkownika lub pobraną treść. Instrukcje te mogą próbować przekierować agenta, ujawnić poufny kontekst lub niewłaściwie wykorzystać podłączone narzędzia.

Profil AI NIST wskazuje prompt injection, prywatność, bezpieczeństwo i zarządzanie danymi jako ryzyka, którymi organizacje powinny zarządzać. Wzmacnia to kluczową tezę: umowne ograniczenia treningu nie zapobiegają wykorzystaniu przez atakującego nadmiernie połączonego systemu.

Sceptyczne odczytanie eseju Nadelli ma zatem dwie części. Po pierwsze, usługi dla przedsiębiorstw już oferują zabezpieczenia, które komplikują ideę jednokierunkowego uczenia. Po drugie, Microsoft ma interes komercyjny w przedstawianiu prywatnej infrastruktury przedsiębiorstwa jako rozwiązania.

Proponowany przez niego kierunek jest zgodny z ofertą Microsoftu. Firmy, które chcą kontrolowanych granic danych, prywatnej ewaluacji, adaptowalnych modeli i nadzorowanych agentów, mogą kupić więcej usług chmurowych i bezpieczeństwa. Diagnoza oraz interesy biznesowe Microsoftu mogą być jednocześnie rzeczywiste.

Pozostaje jeszcze jedna niepewność. Nie każdy ślad ani korekta tworzą istotną przewagę konkurencyjną. Wiele promptów jest powtarzalnych, niskiej jakości lub specyficznych dla jednego zadania. Traktowanie wszystkich danych interakcyjnych jako korporacyjnego skarbu może prowadzić do kosztownych kontroli bez proporcjonalnych korzyści.

Organizacje potrzebują klasyfikacji, a nie mitologii. Korekta dokonana przez specjalistę ds. zgodności wobec regulowanej decyzji może być bardzo wartościowa. Prośba o przeformatowanie notatek ze spotkania prawdopodobnie taka nie jest.

Zespoły powinny określić, gdzie w systemie faktycznie pojawia się zastrzeżony osąd. Mogą następnie chronić ewaluacje, przykłady, ślady i decyzje powiązane z tymi procesami, bez umieszczania każdej interakcji AI za tą samą barierą.

Powinny także testować przenośność dostawcy przed podjęciem zobowiązania na dużą skalę. Twierdzenie o neutralności wobec modelu niewiele znaczy, jeśli firma nie potrafi odtworzyć zachowania gdzie indziej. Kupujący potrzebują dowodów, że prompty, narzędzia, pamięć, ewaluacje i logi mogą być przenoszone razem.

Najmocniejszą odpowiedzią nie jest pełny self-hosting dla każdego obciążenia. Uruchamianie modeli wewnętrznie wprowadza obciążenia związane z infrastrukturą, bezpieczeństwem, zatrudnieniem i zarządzaniem modelami. Może też pozostawić zespoły ze słabszymi możliwościami lub wolniejszymi aktualizacjami.

Bardziej prawdopodobna jest architektura mieszana. Standardowe zadania mogą korzystać z usług zarządzanych z ochroną umowną. Wrażliwe procesy mogą wykorzystywać odizolowane środowiska, węższe wyszukiwanie, prywatną ewaluację i bardziej rygorystyczną retencję.

Równowaga powinna pozostawać otwarta na korekty. W miarę ulepszania modeli mniejsza ilość kontekstu może wystarczyć do osiągnięcia tego samego rezultatu. W miarę jak agenci zyskują większy dostęp, konsekwencje skompromitowanej interakcji mogą rosnąć.

Na co czytelnicy Google News powinni zwrócić uwagę w następnej kolejności

O kolejnej fazie zdecydują przenośne ewaluacje, egzekwowalne mechanizmy kontroli retencji oraz dowody, że uczenie przedsiębiorstwa pozostaje po stronie kupującego.

Pierwszym sygnałem będzie to, czy główni dostawcy AI uczynią przenośność ewaluacji standardową funkcją dla przedsiębiorstw. Klienci powinni móc eksportować przypadki testowe, reguły oceniania, rejestry błędów i korekty dokonywane przez ludzi w udokumentowanych formatach.

Jeśli tak się stanie, diagnoza Nadelli zyska poparcie, a ryzyko uzależnienia od dostawcy osłabnie. Dostawcy uznają, że warstwa uczenia należy do klientów, i będą konkurować wydajnością modeli, a nie zamkniętą infrastrukturą ewaluacyjną.

Jeśli ewaluacje nadal będą trudne do wyeksportowania, paradoks stanie się bardziej konkretny. Klient może być właścicielem swoich dokumentów, ale nie mieć praktycznego sposobu na przeniesienie standardów definiujących akceptowalne zachowanie AI.

Drugim sygnałem będzie rozszerzenie weryfikowalnych mechanizmów kontroli retencji. Zapisy umowne mają znaczenie, ale kupujący potrzebują również ustawień administracyjnych, logów, dowodów usunięcia, regionalnych opcji przetwarzania oraz wyraźnych granic monitorowania nadużyć.

Zerowa retencja danych zasługuje na szczególną uwagę, choć etykieta ta wymaga uważnej interpretacji. Może dotyczyć kwalifikującego się ruchu API, jednocześnie wyłączając interfejsy produktów, rejestry związane z bezpieczeństwem lub usługi połączone.

Jeśli dostawcy rozszerzą te mechanizmy kontroli na agentów i aplikacje do pracy, najsilniejsza obawa dotycząca przekazywania informacji w górę osłabnie. Jeśli wyjątki będą się mnożyć wraz ze wzrostem możliwości agentów, liderzy bezpieczeństwa będą potrzebować bardziej odizolowanych wzorców wdrożenia.

Trzecim sygnałem będzie to, czy przedsiębiorstwa raportują wartość AI poprzez zasoby wiedzy możliwe do ponownego wykorzystania. Same statystyki produktywności nie pokażą, kto kontroluje proces uczenia. Firmy powinny mierzyć zakres przenośnych ewaluacji, udokumentowane korekty, czas przełączania modeli oraz udział procesów wysokiego ryzyka działających w zatwierdzonych granicach.

Poprawa tych wskaźników wspierałaby opisywany przez Nadellę model uczenia kontrolowanego przez kupującego. Dalsza zależność od pulpitów dostawców i nieprzejrzystych historii sugerowałaby, że inteligencja gromadzi się poza skuteczną kontrolą klienta.

Google News prawdopodobnie nadal będzie nagłaśniać ten spór, ponieważ łączy on kilka aktualnych obaw: bezpieczeństwo AI, prywatność, własność intelektualną, koncentrację dostawców i zarządzanie agentami. Czytelnicy powinni unikać sprowadzania go do twierdzenia, że każdy model komercyjny trenuje na każdym prompcie.

Bardziej użyteczne pytanie jest węższe: po tym, jak system AI wykona rok pracy specyficznej dla firmy, jaką wiedzę możliwą do ponownego wykorzystania posiada firma, której wcześniej nie miała?

Nabywcy korporacyjni powinni móc odpowiedzieć czymś więcej niż zapisanymi transkrypcjami czatów. Powinni dysponować przenośnymi ewaluacjami, zarządzanym kontekstem, udokumentowanymi procesami, możliwymi do prześledzenia korektami oraz opcją zmiany modeli bez odrzucania zgromadzonej wiedzy.

Deweloperzy powinni pytać, gdzie przechowywane są prompty, wyniki narzędzi i ślady działania agentów. Zespoły ds. bezpieczeństwa powinny zmapować każdy podmiot przetwarzający dane w ramach procesu. Pracownicy wiedzy powinni wiedzieć, które konto i zasady obejmują przekazywane przez nich informacje.

Odwrócony paradoks informacji nie dowodzi, że hostowanej AI nie można ufać. Ostrzega jednak, że obietnice dotyczące prywatności obejmują tylko część tej wymiany. Chroniony prompt może nadal uczestniczyć w systemie, którego użyteczne uczenie się pozostaje trudne do posiadania lub przeniesienia.

W miarę jak przyszłe relacje Google News będą śledzić polityki dostawców i wdrożenia korporacyjne, warto wypatrywać dowodów na rzeczywistą przenośność. Czy klienci mogą eksportować to, czego nauczyli się ich agenci, uruchamiać testy w innym miejscu i zachowywać kontekst stojący za ważnymi decyzjami?

Jeśli odpowiedź stanie się twierdząca, korporacyjna AI będzie mogła dostarczać zewnętrzną inteligencję bez przejmowania tożsamości klienta. Jeśli odpowiedź pozostanie niejasna, druga opłata nie pojawi się na fakturze. Pojawi się wtedy, gdy firma spróbuje odejść.