Zapowiedź Gemini Robotics Cloud wprowadza ER 2 do przepływów pracy w przedsiębiorstwach

27 października Google udostępniło publiczną zapowiedź chmurową Gemini Robotics, wprowadzając model rozumowania robotów ER 2 do publicznych testów dla klientów korporacyjnych. Ogłoszenie rozszerza dostęp za pośrednictwem Google Cloud, ale pozostawia klientom obowiązek połączenia modelu z maszynami i zweryfikowania ich działania.

To rozróżnienie ma znaczenie, ponieważ ER 2 zadebiutował już w lipcu. To ogłoszenie dotyczy dostępu korporacyjnego i działalności operacyjnej, a nie pierwszego pojawienia się nowego modelu inteligencji robotycznej. Kluczowe napięcie dotyczy równowagi między adaptacyjnym rozumowaniem a przewidywalnym wykonywaniem zadań, którego firmy potrzebują od sprzętu fizycznego.

Google rozwija tę możliwość obok NVIDIA i Physical Intelligence, które oferują odmienne podejścia do rozwoju robotów. Dla nabywców korporacyjnych natychmiastowe pytanie jest praktyczne: gdzie współdzielona usługa rozumowania ogranicza nakład pracy inżynieryjnej, a gdzie odpowiedzialność pozostaje lokalna?

Co zmienia zapowiedź Gemini Robotics Cloud

Bezpośrednią zmianą jest szerszy dostęp korporacyjny do istniejącego modelu rozumowania za pośrednictwem Google Cloud.

Ogłoszenie Google dotyczące publicznej zapowiedzi robotyki umieszcza ER 2 w ramach platformy korporacyjnej firmy. Wskazuje także na zainteresowanie klientów inspekcjami, danymi treningowymi i automatyzacją laboratoriów. Te przykłady określają możliwe zastosowania, a nie stanowią niezależnie zweryfikowanego dowodu skuteczności wdrożeń.

Tworzy to inną rozmowę zakupową niż demonstracja badawcza. Zespół robotyki oceniający model musi również uwzględnić uprawnienia dostępu, odpowiedzialność operacyjną, ustalenia dotyczące wsparcia oraz sposób, w jaki zmiany trafiają do wdrożonego sprzętu. Dystrybucja korporacyjna przybliża te kwestie do początkowego etapu oceny.

Publiczna zapowiedź nadal jest istotnym zastrzeżeniem. Dostępność umożliwia klientom zbadanie produktu na obowiązujących go warunkach. Nie potwierdza jednak, że konkretna instalacja spełni wymagania nabywcy dotyczące dostępności, bezpieczeństwa lub wsparcia.

Chronologia zapobiega również mylącej interpretacji tej wiadomości. Wprowadzenie ER 2 przez Google pojawiło się 30 lipca 2026 roku. Wydanie to oferowało deweloperom dostęp przez Gemini API i Google AI Studio, a także dostęp w prywatnej zapowiedzi za pośrednictwem platformy korporacyjnej firmy.

ER 2 jest modelem ucieleśnionego rozumowania, co oznacza, że interpretuje fizyczne otoczenie i planuje działania robota. Google opisuje go jako wysokopoziomowy mózg, który deleguje ruch do systemów niższego poziomu. Firma informuje także o śledzeniu postępów na podstawie wideo i koordynacji między robotami.

Te możliwości wyjaśniają zamierzoną rolę modelu, ale nie czynią z niego kompletnego produktu robotycznego. Nabywca nadal potrzebuje odpowiedniego sprzętu, działających mechanizmów sterowania i jasno zdefiniowanego zadania. Usługa rozumowania musi pasować do istniejącego systemu operacyjnego.

Dla przedsiębiorstwa, które już rozważa robotykę, szerszy dostęp obniża barierę oceny. Pozwala zespołowi zbadać, czy wspólna warstwa rozumowania powinna znaleźć się w jego architekturze. Jest to znaczący krok komercyjny, bez sugerowania, że cała architektura jest gotowa.

Zmiana przyspiesza także podjęcie decyzji planistycznej. Nabywcy muszą określić, jakie decyzje mają podejmować modele, a które wymagają stałych reguł. Pozostawienie tej granicy niejasnej utrudniłoby późniejszą interpretację twierdzeń dotyczących wydajności.

Wąska ocena może odpowiedzieć na użyteczne pytanie: czy dodanie ER 2 usprawnia określony przepływ pracy w porównaniu z obecnym podejściem? Szeroka demonstracja odpowiada na coś mniej praktycznego. Pokazuje możliwą interakcję, nie ustalając, czy system może obsłużyć konkretną operację.

Dlatego zapowiedź chmurowa Gemini Robotics zasługuje na uwagę jako wydarzenie związane z dystrybucją korporacyjną. Jej znaczenie polega na ułatwieniu oceny i powiązaniu jej z wymaganiami operacyjnymi. Wyniki wdrożeń będą zależeć od tego, co klienci zbudują wokół tego dostępu.

Dostęp korporacyjny przenosi presję na integratorów robotyki

Współdzielona usługa rozumowania zmienia to, co integratorzy muszą uzasadnić, jednocześnie zwiększając znaczenie ich pracy wokół modelu.

Presja spada przede wszystkim na zespoły łączące sprzęt robotyczny z procesami biznesowymi. Jeśli klienci mogą samodzielnie oceniać ogólny model rozumowania, dedykowane oprogramowanie do rozumowania wymaga wyraźniejszego uzasadnienia. Wiedza w zakresie integracji pozostaje jednak kluczowa dla uczynienia powstałego systemu użytecznym.

Rozważmy hipotetyczne zadanie inspekcyjne obejmujące sprzęt rozmieszczony w całym obiekcie. Rozpoznanie obiektu jest tylko częścią zadania. System musi także ustalić, który zasób skontrolował, czy obserwacja była wystarczająca i dokąd należy przekazać wyjątek.

Model rozumowania mógłby pomóc zinterpretować nieznany widok lub wybrać dodatkową obserwację. Integrator nadal musi połączyć te decyzje z rejestrami sprzętu i procedurami operacyjnymi obiektu. Klient potrzebuje rozliczalnego procesu, a nie odizolowanej odpowiedzi.

To samo rozróżnienie dotyczy hipotetycznej pracy laboratoryjnej. Robot interpretujący wyświetlacz instrumentu potrzebowałby reguł postępowania z nieczytelną wartością. Potrzebowałby również zatwierdzonej reakcji, gdy wyświetlany wynik jest sprzeczny z oczekiwanym stanem eksperymentu.

Przykłady te ilustrują główną kwestię komercyjną. Adaptacyjność ma wartość tylko wtedy, gdy firma może umieścić ją w akceptowalnych ramach operacyjnych. Ramy te obejmują dozwolone działania, dowody je potwierdzające oraz moment, w którym człowiek musi interweniować.

Dla integratorów sugeruje to zmianę akcentów, a nie proste zagrożenie zastąpieniem. Ich wartość może przesuwać się w stronę niezawodnych interfejsów, obsługi wyjątków i dowodów wdrożenia. Klienci powinni pytać, ile pracy staje się wielokrotnego użytku, a ile pozostaje specyficzne dla każdej instalacji.

To rozróżnienie wpływa także na zakupy. Subskrypcja modelu i działająca aplikacja robotyczna to różne zobowiązania. Nabywcy muszą rozumieć, kto jest właścicielem aplikacji, gdy zmienia się kamera, przepływ pracy zostaje rozszerzony lub model nadrzędny zachowuje się inaczej.

Platforma korporacyjna może ułatwić dostęp do modelu w organizacji. Nie może automatycznie rozstrzygnąć tych kwestii własności. Udany pilotaż wymaga zatem porozumienia między zespołem robotyki, personelem operacyjnym, osobami oceniającymi bezpieczeństwo oraz osobami utrzymującymi sprzęt.

To także moment, w którym dokumentacja staje się częścią wdrożenia. Zespoły potrzebują wspólnego rejestru zatwierdzonych zachowań, znanych awarii i warunków towarzyszących każdej ocenie. W przeciwnym razie różne grupy mogą wyciągnąć sprzeczne wnioski z tej samej demonstracji.

W tej pracy koordynacyjnej przeszukiwalna baza wiedzy może pomóc inżynierom połączyć dokumenty techniczne z decyzjami wdrożeniowymi. Wspiera proces kontroli wykonywanej przez ludzi wokół robota, gdzie wyniki testów i założenia operacyjne muszą pozostać dostępne.

Presja w krótkim terminie jest więc konkretna. Integratorzy muszą pokazać, jak szeroko dostępny model rozumowania staje się aplikacją możliwą do utrzymania. Nabywcy korporacyjni muszą dostatecznie jasno określić sukces, aby odróżnić możliwości modelu od prac inżynieryjnych wymaganych do jego wykorzystania.

Wiarygodna propozycja powinna wyjaśniać, co dzieje się po nieoczekiwanym wyniku, w tym kto prowadzi dochodzenie i kto zatwierdza zmianę. Ta odpowiedź często ujawni więcej o gotowości do wdrożenia niż najsprawniejsza część demonstracji.

Warstwa rozumowania nadal potrzebuje niezawodnego systemu działania

Architektura zapewnia elastyczność przez oddzielenie decyzji o zadaniach od ruchu, co czyni granicę między nimi szczególnie istotną.

Model wizja-język-działanie, czyli VLA, przekształca obserwacje wizualne i instrukcje językowe w działania robota. Pełni inną rolę niż model rozumowania wysokiego poziomu. To rozróżnienie ma znaczenie przy ocenie, co produkt kontroluje, a o co jedynie wnioskuje.

Dokumentacja Google dotycząca orkiestracji zadań opisuje łączenie rozumowania z niestandardowymi interfejsami robotów. API, czyli interfejs programowania aplikacji, udostępnia funkcje oprogramowania, które może wywołać inny system. W takim układzie dostępne funkcje definiują działania, o które może wnioskować warstwa rozumowania.

Ten podział tworzy użyteczną możliwość inżynieryjną. Zespół może potencjalnie dostosować planowanie zadań bez przeprojektowywania każdej umiejętności ruchowej. Może też zachować ustalone mechanizmy sterowania maszyną, oceniając inny sposób wyboru spośród dozwolonych działań.

Możliwość ta zależy od precyzji interfejsu. Polecenie takie jak „umieść próbkę w uchwycie” zawiera założenia dotyczące tożsamości, lokalizacji i zakończenia. Założenia te muszą mieć wspólne znaczenie dla systemu rozumowania i systemu działania.

Hipotetyczne polecenie może zawieść, nie wywołując oczywistego błędu. Robot może wykonać ruch, pozostawiając obiekt w nieprawidłowym położeniu. Następna decyzja musi zależeć od dowodów dotyczących obiektu, a nie od faktu zakończenia działania polecenia.

Dlatego weryfikacja postępów zasługuje na tyle samo uwagi co planowanie. Użyteczny system musi odróżniać zamierzone działanie od zaobserwowanego wyniku. W przeciwnym razie wczesny błąd może stać się zaakceptowanym założeniem, które kształtuje każdą kolejną decyzję.

Powtarzane działania wprowadzają kolejną komplikację. Ponowienie żądania może być nieszkodliwe przy prośbie o kolejny obraz, lecz mieć konsekwencje przy dozowaniu materiału lub przemieszczaniu sprzętu. Otaczające oprogramowanie musi ustalić, czy wcześniejsze działanie nastąpiło, zanim zaakceptuje jego powtórzenie.

Są to kwestie architektoniczne, a nie ustalenia, że ER 2 zawodzi w takich zadaniach. Wyjaśniają, co musi zbadać ocena korporacyjna. Jakość rozumowania modelu i poprawność operacyjna aplikacji odpowiadają na powiązane, ale różne pytania.

Ta sama logika obowiązuje, gdy kilka maszyn współdzieli przepływ pracy. Plan może przypisywać odpowiedzialności, ale aplikacja nadal potrzebuje wiarygodnego zapisu tego, co faktycznie się wydarzyło. Fizyczne przekazania wymagają zgodności zarówno co do własności, jak i stanu.

Użyteczny pilotaż powinien zatem testować granice między komponentami. Powinien badać niejasne obserwacje, niepełne działania, opóźnione odpowiedzi i zmiany w otoczeniu. Warunki te pokazują, czy aplikacja potrafi odzyskać sprawność bez wymyślania wygodnej wersji wydarzeń.

Zapowiedź chmurowa Gemini Robotics czyni takie badanie bardziej dostępnym, ale sam dostęp nie definiuje kontraktu interfejsu. Klienci i integratorzy muszą zdecydować, jakie informacje przekraczają każdą granicę. Muszą także określić, który komponent ma uprawnienia, gdy obserwacje są sprzeczne.

Najsilniejszym argumentem architektonicznym za współdzieloną warstwą rozumowania jest możliwość ponownego użycia. Argument ten staje się wiarygodny, gdy to samo podejście do planowania działa w różnych instalacjach bez ukrywania rosnącej kolekcji wyjątków. Oceny powinny uwidaczniać te wyjątki od początku.

NVIDIA i Physical Intelligence oferują odmienne punkty odniesienia

Konkurencyjne podejścia do robotyki pomagają wyjaśnić, co oferuje Google, ale nie uzasadniają prostego rankingu wydajności.

NVIDIA pozycjonuje Isaac GR00T jako otwartą platformę obejmującą modele, narzędzia programistyczne, symulację i obliczenia pokładowe. Jej modele VLA przyjmują obserwacje, instrukcje i stan robota, a następnie generują sekwencje działań. Dużą uwagę skupia się więc na połączeniu między wyuczonym zachowaniem a fizycznym wykonaniem.

Oferta Google dotycząca rozumowania dla przedsiębiorstw dotyczy powiązanej części systemu. Kupujący oceniający oba podejścia powinien sprawdzić, gdzie odbywa się planowanie, skąd pochodzą działania oraz które komponenty zespół może modyfikować. Same nazwy produktów nie rozstrzygają tych różnic architektonicznych.

Physical Intelligence stanowi kolejny punkt odniesienia dzięki badaniom nad generalizacją w otwartym świecie. Generalizacja oznacza radzenie sobie z otoczeniami lub obiektami wykraczającymi poza te napotkane podczas treningu. Praca pi0.5 opisuje zadania domowe w wcześniej niewidzianych domach, jednocześnie przyznając, że model nie zawsze odnosi sukces.

To zastrzeżenie ma znaczenie dla oceny w przedsiębiorstwie. System może wykazywać użyteczną zdolność adaptacji, a mimo to wymagać ograniczeń, procedur odzyskiwania sprawności i pomocy człowieka. Kwestia komercyjna dotyczy tego, jak te wymagania wpływają na konkretne zadanie, a nie tego, czy zdolność adaptacji istnieje w zasadzie.

Tych podejść nie należy traktować jako wzajemnie wymiennych pozycji w jednym benchmarku. Kładą one nacisk na różne komponenty i publikują dowody w odmiennych warunkach. Demonstracja zadania jednej organizacji nie może dowodzić wyższości nad modelem innej organizacji bez porównywalnej oceny.

Dystrybucja przez Google Cloud nie oznacza też, że każdy konkurencyjny komponent musi zniknąć. Szersze pytanie architektoniczne brzmi, czy klient zyskuje na połączeniu usługi wysokiego poziomu z osobno dobranymi systemami działań i sprzętu. Odpowiedź będzie zależeć od jakości integracji i ograniczeń operacyjnych.

Dla części kupujących kontrola nad wagami modelu może mieć znaczenie, ponieważ chcą samodzielnie go analizować, dostosowywać lub hostować. Inni mogą przedkładać zarządzany dostęp i administrację organizacyjną. Preferencje te wynikają z potrzeb wdrożeniowych, a nie wskazują uniwersalnego zwycięzcy między modelami rozwojowymi.

Właściwe porównanie zaczyna się zatem od obciążenia roboczego klienta. Jakie obserwacje są dostępne? Jakie działania są dozwolone? Ile lokalnych zasobów obliczeniowych jest dostępnych? Co się dzieje, jeśli zdalna usługa staje się niedostępna? Każda odpowiedź zawęża architekturę wartą oceny.

To samo obciążenie robocze powinno również określać dowody wymagane od dostawców. Kupujący zainteresowany inspekcją potrzebuje odpowiednich wyników inspekcji. Kupujący zainteresowany manipulacją potrzebuje dowodów dotyczących zadania manipulacyjnego, w tym trudnych przypadków i warunków, w których wystąpiła pomoc.

Pozwala to zachować użyteczny kontekst konkurencyjny, nie pozwalając mu zdominować całej historii. Bezpośredni ruch Google rozszerza dostęp przedsiębiorstw do ER 2. NVIDIA i Physical Intelligence pokazują, dlaczego klienci powinni oceniać ten krok w ramach szerszego wyboru architektur oprogramowania dla robotów.

Presja na Google polega na wykazaniu, gdzie jego warstwa rozumowania wnosi mierzalną wartość. Presja na alternatywy polega na równie konkretnym pokazaniu ich własnych zalet integracyjnych i operacyjnych. Porównywalne dowody od klientów będą bardziej miarodajne niż konkurencyjne twierdzenia o ogólnej inteligencji robotów.

Warunki wersji zapoznawczej i ograniczenia modelu mają znaczenie w pracy fizycznej

Dostęp dla przedsiębiorstw otwiera drogę do oceny; nie przenosi odpowiedzialności za zachowanie robota na platformę.

Dokumentacja modelu robotycznego Google określa ER 2 jako ofertę w wersji zapoznawczej, potencjalnie z ograniczonym wsparciem. Zezwala na użycie produkcyjne lub komercyjne zgodnie z obowiązującymi warunkami. Zgoda na komercyjne użycie wersji zapoznawczej pozostaje czymś odrębnym od gwarancji dotyczącej konkretnego zastosowania.

Dokumentacja wskazuje również ograniczenia związane z nieprawidłowymi wynikami, jakością promptów, czasem przetwarzania i wymaganiami obliczeniowymi. Wyraźnie przypisuje klientom odpowiedzialność za utrzymanie bezpiecznego środowiska wokół ich robotów. Te zastrzeżenia powinny znaleźć się w rozmowie o wdrożeniu obok deklaracji dotyczących możliwości.

Praktyczna konsekwencja jest prosta. Firma musi zdecydować, co system powinien zrobić, gdy nie ma wystarczających dowodów, by podjąć działanie. Dopuszczalna odpowiedź może obejmować kolejną obserwację, ograniczoną procedurę odzyskiwania sprawności lub eskalację do operatora.

Decyzja ta powinna zależeć od konsekwencji. Błędne rozpoznanie obiektu na ekranie przeglądu i skierowanie sprzętu w stronę niewłaściwego obiektu stwarzają różne ryzyka operacyjne. Wspólny model może uczestniczyć w obu przepływach pracy, ale otaczające go mechanizmy kontroli powinny odzwierciedlać tę różnicę.

Czas przetwarzania również wymaga interpretacji specyficznej dla danego obciążenia roboczego. Opóźniona odpowiedź może być akceptowalna podczas przeglądania ukończonego nagrania z inspekcji. To samo opóźnienie może być nieodpowiednie dla decyzji wpływającej na trwający ruch. Ocena powinna ustalić, które decyzje mogą czekać, a które wymagają obsługi lokalnej.

Podobnie dobra odpowiedź nie stanowi automatycznie bezpiecznego upoważnienia. Model może poprawnie interpretować scenę, nie mając jednak informacji o ograniczeniu konserwacyjnym lub osobie poza zasięgiem kamery. Zastosowanie potrzebuje zasad dostępu i ograniczeń operacyjnych wykraczających poza interpretację wizualną.

Prywatność zasługuje na podobną uwagę, gdy kamery i mikrofony trafiają do miejsca pracy. Istotne pytania obejmują zakres zbieranych danych, osoby mające do nich dostęp oraz czas ich dostępności. Decyzje te powinny towarzyszyć projektowi pilotażowemu, a nie następować po wdrożeniu.

Żadne z powyższych nie dowodzi, że ER 2 nie nadaje się do robotyki przedsiębiorstw. Pokazuje natomiast, że robotyka przedsiębiorstw wymaga dowodów na poziomie zastosowania. Ogłoszenie wersji zapoznawczej daje klientom możliwość zebrania tych dowodów we własnych warunkach operacyjnych.

Użyteczna ocena rejestrowałaby porażki obok sukcesów i zachowywała okoliczności towarzyszące każdemu wynikowi. Powinna odróżniać autonomiczne ukończenie zadania od takiego, które wymagało korekty człowieka. To rozróżnienie zapobiega przekształceniu obiecującej demonstracji w przesadzone twierdzenie operacyjne.

Uzasadnienie biznesowe powinno również uwzględniać pracę otaczającą robota. Konfiguracja, nadzór, odzyskiwanie sprawności i konserwacja wpływają na użyteczność. Zastosowanie, które wykonuje zadanie, może mimo to rozczarować, jeśli obciążenie związane z jego obsługą przewyższa pracę, którą eliminuje.

Sceptyczne stanowisko jest zatem węższe niż odrzucenie technologii. Google rozszerzyło dostęp do modelu o zgłaszanych, istotnych możliwościach. Klienci wciąż potrzebują dowodów, że ich kompletne zastosowanie zachowuje się akceptowalnie, także wtedy, gdy model jest niepewny lub się myli.

Obserwuj dowody od klientów, zobowiązania usługowe i możliwość ponownego użycia

Kolejne użyteczne sygnały dotyczą wyników operacyjnych, dojrzałości komercyjnej usługi oraz tego, czy integracje stają się łatwiejsze do powielania.

Pierwszym sygnałem są dowody od klientów dotyczące zdefiniowanych obciążeń roboczych. W nadchodzących miesiącach raporty powinny wskazywać, jakie zadanie wykonywano, w jakich warunkach i jak często interweniowali ludzie. Jasne opisy awarii i odzyskiwania sprawności znacząco zwiększyłyby użyteczność tych raportów.

Takie dowody wzmocniłyby argument dla przedsiębiorstw, gdyby klienci wykazali konsekwentne korzyści wykraczające poza wyreżyserowaną demonstrację. Osłabiłyby go, gdyby opublikowane przykłady pomijały warunki operacyjne lub pozostawiały niewyjaśnioną pracę wykonywaną wokół systemu. Rozpoznawalna nazwa klienta nie może zastąpić tych szczegółów.

Drugim sygnałem jest zmiana zobowiązań usługowych lub dostępności. Kupujący powinni obserwować aktualizacje statusu wydania, wsparcia i udokumentowanych warunków wdrożenia. Aktualizacje te wyjaśniłyby, jak organizacje mogą planować wokół usługi, nawet bez zmiany jej podstawowych możliwości rozumowania.

Szersze zobowiązanie komercyjne wspierałoby planowanie większych wdrożeń. Utrzymanie statusu wersji zapoznawczej nadal pozwalałoby na ocenę, ale kupujący musieliby uwzględnić obowiązujące ograniczenia. Żadnego z tych wyników nie należy mylić z dowodami dotyczącymi wydajności w zadaniach fizycznych.

Trzecim sygnałem jest możliwość ponownego użycia w integracjach klientów. Obietnica architektoniczna staje się silniejsza, jeśli zespoły mogą zastosować warstwę rozumowania na innej maszynie lub w innym przepływie pracy bez przebudowywania otaczającego zastosowania. Ponowne użycie powinno obejmować zachowanie podczas odzyskiwania sprawności i rejestry operacyjne, a nie tylko udane wywołanie modelu.

Dowody na powtarzalną integrację wspierałyby pozycję Google jako współdzielonej warstwy rozumowania dla przedsiębiorstw. Dowody, że każde wdrożenie wymaga rozległej specjalnej obsługi, zawęziłyby tę pozycję. Model mógłby nadal być wartościowy, ale jego wartość wyglądałaby na bardziej specyficzną dla danego zastosowania.

Łącznie te sygnały utrzymują uwagę na zmianie, którą Google faktycznie ogłosiło. Firma uczyniła ER 2 bardziej dostępnym za pośrednictwem swojej chmurowej oferty dla przedsiębiorstw. Nierozstrzygnięte pytania dotyczą tego, jak ten dostęp przekłada się na niezawodne zastosowania i możliwe do zarządzania obowiązki operacyjne.

Dla programistów szansą jest ocena komponentu rozumowania względem istniejącego punktu odniesienia. Dla nabywców korporacyjnych priorytetem jest połączenie tej oceny z jasnym wymaganiem operacyjnym. Obie grupy zyskują, oddzielając zgłaszaną zdolność modelu od zweryfikowanych wyników zastosowania.

Chmurowa wersja zapoznawcza Gemini Robotics zasługuje na skoncentrowaną ocenę powiązaną z pracą, którą organizacja już rozumie. Wybierz ograniczone zadanie, udokumentuj jego obecną wydajność i określ, jakie decyzje model może podejmować. Uwzględnij w ocenie niejasne obserwacje, niekompletne działania i przekazania operatorowi. Zachowaj wystarczający kontekst, aby inny recenzent mógł zrozumieć, dlaczego każdy wynik uznano za sukces lub porażkę. Następnie porównaj kompletny przepływ pracy, w tym nadzór i odzyskiwanie sprawności, z istniejącym podejściem. Te dowody pomogą ocenić, gdzie ER 2 zasługuje na miejsce w zastosowaniu. Przed rozszerzeniem pilotażu zadaj jedno konkretne pytanie: jaki wynik uzasadniałby powierzenie temu systemowi odpowiedzialności za kolejne zadanie?