Dana: agentowa platforma AI dla pojazdów i robotów

Applied Intuition zaprezentowało 22 lipca 2026 roku Dana — agentową platformę do budowania, testowania, wdrażania i eksploatowania physical AI w pojazdach, robotach oraz maszynach przemysłowych. System ma łączyć dane, wizualizację, narzędzia deweloperskie, ewaluację, traceability i governance w jednym środowisku. Najważniejsza zmiana nie polega na dodaniu czatu do inżynierii: agent ma wykonywać wieloetapowe workflow obejmujące kod, symulację i analizę danych, a zatem musi być traktowany jak uprzywilejowany operator infrastruktury.

Informacje funkcjonalne w tym artykule pochodzą z komunikatu Applied Intuition o Dana. Określenie „pierwsza agentowa platforma dla physical AI” jest pozycjonowaniem producenta, nie wynikiem niezależnego porównania całego rynku. Tak samo deklarowane skrócenie niektórych etapów z miesięcy do dni opiera się na doświadczeniu firmy i wybranych wdrożeń, a nie na publicznym benchmarku obejmującym identyczne projekty.

Czym jest Dana od Applied Intuition

Dana ma stanowić wspólną warstwę dla całego cyklu physical AI: przygotowania danych, budowy oprogramowania, testów w symulacji, analizy wyników, deploymentu i utrzymania. Użytkownik może wydawać polecenia w języku naturalnym lub przez interfejs wiersza poleceń. Platforma ma integrować się z narzędziami pracy, takimi jak Slack i Jira, aby agent uczestniczył w istniejącym obiegu zgłoszeń i decyzji.

Producent wymienia zastosowania w autonomicznych i software-defined vehicles, ADAS, zarządzaniu flotą, robotyce, budownictwie, górnictwie oraz systemach pokładowych. To szeroki zakres, ale wspólny wzorzec jest czytelny: oprogramowanie interpretuje dane ze świata fizycznego, buduje lub ocenia model zachowania, a wynik może ostatecznie wpłynąć na ruch maszyny.

Applied Intuition podaje, że używa Dana wewnętrznie od poprzedniego roku. W ograniczonym early access uczestniczą Komatsu i Isuzu. Isuzu ma korzystać z platformy przy pracach nad autonomią poziomu 4. Są to potwierdzone informacje o uczestnictwie i deklarowanym celu, ale nie oznaczają jeszcze zakończonej homologacji, komercyjnej dostępności autonomicznego pojazdu ani publicznego pomiaru poprawy bezpieczeństwa.

Dlaczego agentowy workflow zmienia tempo pracy

W klasycznym procesie inżynier ręcznie wybiera logi, tworzy scenariusz, uruchamia symulację, czeka na wynik, porównuje metryki, otwiera zgłoszenie i przygotowuje poprawkę. Agent może połączyć te kroki: znaleźć regresję, wygenerować przypadki graniczne, uruchomić serię testów, sklasyfikować niepowodzenia i przygotować raport z odnośnikami do artefaktów. Zysk bierze się z ograniczenia czasu pomiędzy etapami, nie z magicznego zastąpienia fizyki generowanym tekstem.

Warto porównać to z lokalnymi modelami świata, takimi jak NVIDIA Cosmos 3 Edge. Model może rozumieć obraz i proponować akcję, natomiast platforma agentowa organizuje dane, narzędzia i proces oceny wokół wielu modeli. Dana nie jest więc po prostu kolejnym modelem VLA. Jest warstwą orkiestracji, w której problemem bezpieczeństwa staje się nie tylko jakość predykcji, ale również to, jakie narzędzia agent może wywołać i które wyniki uznaje za wystarczające.

Od języka naturalnego do skutku w świecie fizycznym

Polecenie „znajdź sytuacje, w których pojazd zbyt późno hamuje, i przygotuj poprawkę” jest wygodne, lecz pozostawia wiele niejawnych decyzji. Agent musi określić zbiór danych, próg „zbyt późno”, typ scenariuszy, wersję oprogramowania, metrykę sukcesu i dopuszczalny kompromis. Jeżeli sam zmieni te wartości, wynik może wyglądać dobrze bez rzeczywistego ograniczenia ryzyka.

Dlatego każdy workflow powinien mieć maszynowo sprawdzalny kontrakt:

zatwierdzony cel i ownera;
identyfikatory danych, modeli, kodu i konfiguracji;
niezmienne kryteria wejścia oraz wyjścia;
budżet czasu i zasobów;
listę dozwolonych narzędzi;
punkty obowiązkowej akceptacji człowieka;
zasady przerwania oraz rollbacku;
podpisany raport z pełną proweniencją.

Agent może przygotować zmianę, ale nie powinien samodzielnie redefiniować kryterium bezpieczeństwa, zatwierdzać własnego testu i publikować wyniku do pojazdu. Separation of duties jest szczególnie ważne, gdy jedna platforma obejmuje cały cykl.

Trzy warstwy, których nie wolno mieszać

Bezpieczna architektura physical AI rozdziela warstwę eksperymentu, warstwę wydania i warstwę wykonawczą. Eksperyment pozwala agentowi generować kod, modyfikować scenariusze i uruchamiać symulacje na syntetycznych danych. Warstwa wydania weryfikuje podpisy, testy, zgodność i zatwierdzenia. Warstwa wykonawcza na pojeździe lub robocie uruchamia wyłącznie artefakt dopuszczony przez kontrolowany proces.

Połączenie Slacka lub Jiry nie może stać się tylnym wejściem do deploymentu. Wiadomość w kanale jest niezaufanym wejściem: może zawierać prompt injection, link do złośliwego pliku albo polecenie od przejętego konta. Agent powinien odczytywać treść przez broker, który weryfikuje nadawcę i klasyfikuje dane, a operacje o skutkach trwałych powinny wymagać silnego uwierzytelnienia poza samą rozmową.

Prompt injection w agentach CI/CD pokazuje ten sam problem w kodzie. W physical AI potencjalny skutek jest szerszy, ponieważ zła zmiana może przejść od repozytorium do urządzenia wykonawczego. Konieczne są podpisane artefakty, przypięte zależności, dwie niezależne akceptacje i możliwość natychmiastowego wycofania wersji.

Symulacja jest dowodem, ale nie całym dowodem

Platforma może automatycznie tworzyć tysiące scenariuszy i odkryć warunki, których człowiek nie zapisał ręcznie. To duża wartość, lecz wynik zależy od zgodności symulatora z rzeczywistością. Błąd czujnika, tarcie, oświetlenie, opóźnienie magistrali, zachowanie człowieka i mechaniczna awaria mogą być odwzorowane niedokładnie. Agent optymalizujący pod jeden benchmark może nauczyć się wykorzystywać jego uproszczenia.

Proces walidacji powinien przechodzić od software-in-the-loop przez hardware-in-the-loop do kontrolowanych testów fizycznych. Każdy etap ma własne kryteria i niezależny zestaw danych. Nie wolno stroić modelu na zamkniętym zbiorze bezpieczeństwa używanym później jako ostateczny egzamin. Incydent z agentem OpenAI i benchmarkiem ExploitGym pokazuje, dlaczego odpowiedzi testowe muszą pozostawać poza zasięgiem agenta.

Deterministyczne zabezpieczenia pozostają obowiązkowe

Model generatywny nie powinien być jedynym elementem decydującym, czy ruch jest bezpieczny. Niezależny safety controller musi egzekwować ograniczenia prędkości, przestrzeni roboczej, siły, temperatury, odległości i stanu urządzenia. Jego kod powinien być mniejszy, deterministyczny, możliwy do formalnego albo bardzo dokładnego przetestowania i odporny na polecenia agenta.

Jeżeli Dana sugeruje akcję albo publikuje artefakt, runtime powinien sprawdzić podpis, wersję, kompatybilność, politykę i stan maszyny. Naruszenie bariery prowadzi do bezpiecznego stanu: zatrzymania, ograniczonego trybu lub przejęcia przez operatora — zależnie od systemu. „Human in the loop” nie wystarcza, jeśli człowiek dostaje setki decyzji na sekundę albo nie ma czasu zareagować.

Tożsamość i uprawnienia agenta Dana

Każda sesja powinna otrzymać oddzielną tożsamość agenta AI. Uprawnienia do odczytu danych, uruchomienia symulacji, utworzenia zgłoszenia, zmiany kodu i przygotowania deploymentu muszą być rozdzielone. Token nie może dziedziczyć wszystkich praw użytkownika, który napisał wiadomość w Slacku.

Przykładowa polityka pozwala agentowi czytać zanonimizowane logi wybranej floty, tworzyć scenariusze w projekcie testowym i otwierać pull request. Nie pozwala mu usuwać danych, modyfikować zamkniętego zestawu ewaluacyjnego, zatwierdzać PR ani komunikować się bezpośrednio z pojazdem. Uprawnienie produkcyjne jest wydawane dopiero kontrolerowi deploymentu po spełnieniu bram jakości.

Tokeny powinny być krótkotrwałe i związane z audience. Wszystkie działania muszą mieć wspólny identyfikator workflow, aby obserwowalność agentów AI łączyła polecenie z datasetem, wersją modelu, wykonanym kodem i końcowym artefaktem. Log audytowy znajduje się w systemie, którego agent nie może zmienić.

Governance danych physical AI

Dane z pojazdów i robotów mogą zawierać twarze, tablice rejestracyjne, głos, lokalizację, tajemnice zakładu, parametry procesu i informacje o pracownikach. Centralna platforma ułatwia analizę, ale zwiększa wartość celu. Potrzebne są klasyfikacja, minimalizacja, kontrola regionu przetwarzania, retencja oraz oddzielenie tenantów i projektów.

Agent powinien otrzymywać wynik zapytania, nie nieograniczony dostęp do surowego jeziora danych. Widoki mogą usuwać identyfikatory, obniżać rozdzielczość i ograniczać zakres czasowy. Eksport danych musi przechodzić DLP. Jeżeli model zewnętrzny uczestniczy w workflow, organizacja musi znać miejsce przetwarzania, zasady retencji, użycie danych do treningu i mechanizm usunięcia.

Rejestr modeli AI powinien łączyć wersję z kartą modelu, licencją, danymi treningowymi, znanymi ograniczeniami, testami, ownerem i statusem dopuszczenia. Dla physical AI ten sam rejestr musi obejmować także mapę kompatybilnych urządzeń, firmware i ograniczeń operacyjnych.

Threat modeling integracji i łańcucha dostaw

Dana łączy wiele systemów, więc jej wartość i ryzyko powstają na integracjach. Rozpocznij modelowanie zagrożeń od przepływu danych: pojazd, brama, chmura, magazyn, agent, repozytorium, CI, symulator, system zgłoszeń i deployment. Dla każdej krawędzi zapisz tożsamość, szyfrowanie, możliwość replay, schemat danych i ownera.

Szczególnie sprawdź pluginy, paczki, obrazy kontenerów oraz modele pobierane przez agentów. Atak na łańcuch dostaw oprogramowania może podmienić narzędzie, któremu platforma ufa. Wymagaj SBOM, podpisów, pinowania digestów, skanowania i izolowanego builda. Model i dataset także są artefaktami łańcucha dostaw, nawet jeśli nie wyglądają jak tradycyjny pakiet.

Jak ocenić Dana przed zakupem

Demo pokazujące jedno polecenie i szybki raport nie wystarcza. Poproś o architekturę wdrożenia, granice tenantów, model odpowiedzialności, listę subprocessors, regiony danych, RTO/RPO i procedurę incydentową. Zespół techniczny powinien uzyskać odpowiedzi na następujące pytania:

czy klient może wymusić brak publicznego egressu;
jak agent uzyskuje i traci uprawnienia;
czy log audytowy jest niezmienny i eksportowalny;
jak wersjonowane są prompty, modele, dane i narzędzia;
które akcje zawsze wymagają akceptacji człowieka;
czy platforma potrafi odtworzyć workflow deterministycznie;
jak izolowane są niezaufane dane oraz kod;
jaki jest mechanizm podpisu i promocji artefaktu;
jak działa awaryjne zatrzymanie oraz rollback;
jakie testy penetracyjne i raporty assurance można przejrzeć.

Proof of concept powinien używać własnych negatywnych scenariuszy. Wprowadź prompt injection przez zgłoszenie, wadliwy dataset, niedostępny symulator, fałszywą metrykę i próbę przekroczenia uprawnień. Sprawdź nie tylko, czy agent odmówił, lecz również czy polityka technicznie zablokowała operację i zostawiła czytelny ślad.

Co ogłoszenie Dana oznacza dla rynku

Agentowe platformy przenoszą generatywne AI z warstwy porad do warstwy wykonywania pracy inżynierskiej. Dana pokazuje, że ten kierunek obejmuje już pojazdy, roboty i maszyny. Jeżeli deklarowane skrócenie cyklu potwierdzi się w szerszych wdrożeniach, przewagą będzie szybsze przejście od danych do zweryfikowanego artefaktu. Warunkiem jest jednak zachowanie niezależnych bram bezpieczeństwa.

Organizacja rozważająca physical AI nie powinna wybierać pomiędzy szybkością a kontrolą. Powinna zaprojektować proces, w którym agent automatyzuje pracę powtarzalną, ale nie może samodzielnie zwiększyć swoich uprawnień, zmienić kryterium bezpieczeństwa ani wydać własnego wyniku na produkcję. Potrzebujesz oceny architektury lub audytu bezpieczeństwa AI? Skontaktuj się z BreachRoad, zanim agent zostanie połączony z systemem mającym wpływ na świat fizyczny.

Źródła

Applied Intuition: Dana, the agentic platform for physical AI