Android XR i agenci na urządzeniach: zmiana, nie gadżet

Dyrektor operacyjny wraca z konferencji przekonany, że następnym interfejsem dla pracowników w terenie będą okulary. IT odpowiada, że firma działa na telefonach innego dostawcy i nie ma zarządzania urządzeniami dla niczego, co ma kamerę na czyjejś twarzy. HR pyta, kto wytłumaczy ludziom, że asystent będzie teraz widział to, co oni. Po tygodniu rozmowa przestaje dotyczyć okularów.

I dobrze. Android XR to platforma Google dla gogli XR, okularów z wyświetlaczem i okularów audio, z Gemini jako warstwą asystenta, rozwijana razem z Samsungiem i Qualcommem. Pierwszym urządzeniem były gogle Samsung Galaxy XR; XREAL Aura to pierwsze wycenione okulary z wyświetlaczem; Samsung zapowiedział własne okulary z Gemini na listopad 2026. Na majowym Google I/O firma pokazała okulary audio współpracujące z telefonem, z Androidem albo iOS, w których agent wykonuje w tle na telefonie zadania wieloetapowe, a okulary są jego głosem i kamerą.

Mówiąc wprost: agent nie mieszka już w karcie przeglądarki. Mieszka na urządzeniu, które pracownik nosi przy sobie, potrafi działać, a platforma pod nim należy do jednego dostawcy. To zmiana organizacyjna i warto ją tak traktować.

Gdzie firmy się mylą

Urządzenie wybiera się przed platformą. Pilotaż kupuje te okulary, które akurat są dostępne, a zanim się skończy, firma po cichu wybrała system operacyjny, sklep z aplikacjami, asystenta i dostawcę tożsamości. Żadnej z tych decyzji nie podjęto świadomie.

Uprawnienia agenta traktuje się jak uprawnienia do kamery. Znane pytanie brzmi: czy aplikacja może używać kamery. Nowe: co agent może zrobić w imieniu użytkownika — otworzyć aplikację, wysłać wiadomość, wypełnić formularz, złożyć zamówienie. To działania i potrzebują zasad, tak jak dostępy nowego pracownika.

To, gdzie dzieje się praca, przyjmuje się na wiarę. Nie znaleźliśmy publicznego rozpisania, ani od Google, ani od XREAL, ile pracy agenta dzieje się na urządzeniu, na telefonie, a ile w chmurze. Może się to różnić między funkcjami i zmieniać z aktualizacjami. Dopóki nie macie tego na piśmie, zakładajcie, że wszystko, co łapią kamera i mikrofon, może opuścić budynek.

Ludziom się ogłasza, zamiast ich pytać. Osoba, która czuje się obserwowana przez własnego asystenta, albo koledzy, którzy czują się filmowani, znajdą sposób, żeby z niego nie korzystać. Zaufanie nie jest tu zadaniem komunikacyjnym na koniec, tylko ograniczeniem projektowym na start.

Zależność od dostawcy odkrywa się przy odnowieniu umowy. Aplikacje zbudowane pod jednego asystenta, dane w chmurze jednego dostawcy, procesy przepisane pod jedno urządzenie: każda z tych rzeczy osobno jest rozsądna, razem decydują o Waszych najbliższych latach.

Co ustalić zamiast tego

Rozstrzygnijcie pytanie o platformę jako pytanie o platformę. Do kogo należą tożsamość, dane i dystrybucja aplikacji? Jak wygląda wyjście: które części pracy dałoby się przenieść na okulary innego dostawcy, a które trzeba by zbudować od nowa? Spiszcie wyjście przed wejściem. Ten sam argument stawiamy w tekście o testowaniu platformy na własnych danych i dotyczy on także urządzeń.

Piszcie zasady dla agentów, nie tylko dla aplikacji. Wypiszcie działania, które agent może podjąć sam, te, które może przygotować do zatwierdzenia przez człowieka, i te, których nie może podjąć nigdy. Prowadźcie zapis tego, co zrobił. Za wynik odpowiada człowiek, jak przy każdym innym narzędziu.

Zacznijcie od ludzi, którzy będą to nosić. Zapytajcie ich, gdzie asystent by pomógł, a gdzie by przeszkadzał. Umówcie się na widoczne sygnały, takie jak dioda prywatności, i na miejsca, w których urządzenia się zdejmuje. Zasady dotyczące niekontrolowanego użycia narzędzi AI z tekstu o tym, że ludzie już używają AI, działają i tutaj: dozwolona droga wygrywa z zakazem.

Trzymajcie własną logikę poza urządzeniem. Wiedzę o procesie, polecenia i integracje, które żyją w Waszych systemach, da się później skierować na inną platformę. Logiki wbudowanej w asystenta jednego dostawcy — nie.

Test, który zrobicie bez kupowania sprzętu

Żeby dowiedzieć się większości tego, czego nauczyłby pilotaż, nie potrzebujecie okularów. Android XR SDK ma emulator okularów, a dla aplikacji na okulary oferuje Jetpack Projected: aplikacja działa na urządzeniu-gospodarzu, na przykład telefonie, i przesyła doświadczenie do okularów. Jetpack Compose Glimmer służy do interfejsów na wyświetlacze przezierne, a Device Availability API mówi aplikacji, czy okulary są w tej chwili noszone.

To wystarczy na dwutygodniowe ćwiczenie. Weźcie jedno zadanie, zbudujcie albo zasymulujcie przebieg w emulatorze z telefonem jako gospodarzem i pokażcie go ludziom, którzy tę pracę wykonują. Zapiszcie, które kroki agent zrobiłby sam, jakich danych by potrzebował i dokąd by je wysyłał. Jeśli nie umiecie odpowiedzieć na te trzy pytania na papierze, sprzęt nie odpowie na nie za Was.

Stronę sprzętową tej samej decyzji opisuje drugi tekst, czy pilotować okulary XR z agentem AI. Nie sprzedajemy urządzeń ani platform; jak mówi strona główna, naszą pracą jest diagnoza, działający pilotaż i zmiana, która się przyjmuje.

Pytanie na ten tydzień

Zadajcie po jednym pytaniu osobie odpowiedzialnej za IT i osobie odpowiedzialnej za ochronę danych: jeśli jutro agent AI na urządzeniu wykonałby działanie w systemie klienta, skąd byśmy o tym wiedzieli i kto by za to odpowiadał? Jeśli żadna z nich nie zna odpowiedzi, pierwszym projektem nie jest pilotaż. Są nim zasady.