Jak AI integruje się z Palantir Foundry i co agenci robią z Waszymi danymi i ontologią na własnym serwerze?

Palantir Foundry to platforma, która już spina Wasze dane: zlecenia produkcyjne, stany magazynowe, historię maszyn, dokumenty operacyjne. Podpinamy do niej agentów AI, którzy stoją na Waszym własnym serwerze i obsługują codzienne pytania działów po polsku, bez wysyłania tych danych na zewnątrz. Foundry zostaje tam, gdzie jest. AI pojawia się tuż nad nim, blisko ludzi, którzy z tych danych korzystają.

Co Palantir Foundry robi w firmie i jakie dane tam żyją?

Foundry jest platformą danych. Zbiera dane z różnych źródeł: systemów ERP, sensorów, baz danych operacyjnych, plików Excel, zewnętrznych interfejsów dostawców. Łączy je w jednym miejscu, czyści i udostępnia przez warstwę zwaną ontologią.

Ontologia to semantyczny model danych. Zamiast tabel z tysiącami wierszy widzisz obiekty: WorkOrder (zlecenie pracy), Asset (urządzenie), Employee (pracownik), Shipment (przesyłka). Każdy obiekt ma właściwości i powiązania z innymi obiektami. Foundry wie, że zlecenie ZL-2847 dotyczy maszyny M-12 w hali B, a odpowiada za nie Jan Kowalski ze zmiany popołudniowej. To nie jest prosta tabela: to sieć powiązań.

W typowej instalacji przemysłowej w Foundry żyją:

• obiekty ontologiczne z relacjami między nimi
• dane szeregów czasowych z sensorów i systemów SCADA
• zbiory danych tabelarycznych z ERPu lub MESu
• dokumenty: instrukcje obsługi, protokoły przeglądu, raporty w PDF
• historia zdarzeń: awarie, przestoje, zmiany statusów, alarmy

Problem polega na tym, że dostęp do tych danych wymaga otwierania Foundry, budowania zapytań albo korzystania z gotowych dashboardów. Większość pracowników ma jedno konkretne pytanie i nie chce przeskakiwać przez pięć widoków, żeby dostać odpowiedź. Agent AI może odpowiedzieć na to pytanie po polsku, w ciągu kilku sekund.

Jak podłączamy AI do Foundry: co czytamy i przez jakie interfejsy?

Foundry udostępnia dane przez dwa główne kanały.

Pierwszy to Foundry REST API. Standardowe endpointy, przez które pobieramy dane ze zbiorów danych (Dataset API), przeglądamy pliki (Compass API) i wykonujemy zapytania do obiektów ontologicznych (Object Storage API v2). Każde zapytanie wymaga tokenu usługowego z odpowiednimi uprawnieniami. Token generuje administrator Foundry po naszej stronie i nadaje mu dostęp tylko do wskazanych zasobów.

Drugi to OSDK (Ontology SDK), czyli wygenerowany klient Python lub TypeScript, dopasowany do konkretnej ontologii klienta. Jeśli w Foundry macie zdefiniowany obiekt WorkOrder z polami status, assetId, assignedTo i priority, OSDK daje gotowy interfejs do zapytań po tych polach, bez pisania surowych żądań HTTP. To ważne: agent nie musi "zgadywać" struktury danych, bo ma ją w postaci otypowanego klienta.

Konfiguracja wygląda tak: zakładamy konto usługowe w Foundry, nadajemy mu uprawnienia do odczytu wybranych zbiorów i obiektów, generujemy token i przekazujemy go do serwera RedAI po stronie klienta. Od tej chwili agenci widzą dane z Foundry jak własne i mogą je odpytywać w imieniu użytkownika.

Co agenci AI robią z tymi danymi: pięć scenariuszy z produkcji i utrzymania ruchu

Planista pyta o zlecenia na dziś. Planista produkcji wpisuje w oknie czatu: "Które zlecenia na zmianę poranną mają status oczekujące i priorytet wysoki?" Agent odpytuje obiekty WorkOrder przez OSDK, filtruje po polach status i priority, sortuje po czasie i zwraca czytelną listę. Planista dostaje to, czego potrzebuje, bez wchodzenia do Foundry.

Mechanik pyta o historię maszyny. "Ile razy maszyna M-12 była zatrzymana w tym kwartale i jaka była najdłuższa przerwa?" Agent sięga do obiektu Asset o identyfikatorze M-12, pobiera powiązane zdarzenia z historii awarii i przestojów, liczy i odpowiada. Nie trzeba szukać odpowiedniego widoku w Foundry ani budować filtru w tabeli.

Raport zmiany bez ręcznego pisania. Po zakończeniu zmiany brygadzista klika jeden przycisk. Agent pobiera dane o zleceniach, zdarzeniach i alarmach z ostatnich ośmiu godzin, generuje raport w ustalonym formacie z sekcjami: "Zlecenia zrealizowane", "Zlecenia odłożone", "Zdarzenia nieplanowane", i zapisuje go do katalogu w Foundry albo wysyła na maila do kierownika. U jednego klienta zastąpiło to półgodzinne ręczne wypełnianie szablonu Word po każdej zmianie. Raport wychodzi spójny, zawsze w tej samej strukturze, bez ryzyka pominięcia zdarzenia.

Alert przy opóźnieniu dostawy. Agent monitoruje obiekty Shipment w Foundry. Gdy pole estimatedArrival przesuwa się o więcej niż zdefiniowany próg, agent automatycznie przygotowuje wiadomość do planisty z informacją: które dostawy, o ile godzin, których zleceń produkcyjnych to dotyczy. Nie czeka, aż ktoś zajrzy do widoku z przesyłkami.

Odpowiedzi na pytania o instrukcje i procedury. W Foundry leżą pliki: instrukcje obsługi, karty BHP, procedury awaryjne. Agent czyta je przez Compass API i odpowiada na pytania w stylu "Co robić przy alarmie E47 na sprężarce S-3?" lub "Kto zatwierdza protokół przeglądu dla kategorii A?" Nie trzeba szukać właściwego pliku w drzewie katalogów ani pamiętać, gdzie leży aktualna wersja dokumentu.

Jak wygląda wdrożenie krok po kroku?

Zaczynamy od audytu danych w Foundry. Razem z Waszym administratorem sprawdzamy, jakie obiekty i zbiory danych są dostępne, jakie pola zawierają i kto ma do nich uprawnienia. Zazwyczaj jedno spotkanie techniczne wystarczy, żeby mieć pełny obraz.

Następnie:

• zakładamy konto usługowe w Foundry z uprawnieniami wyłącznie do odczytu wskazanych zasobów
• stawiamy serwer RedAI na Waszej infrastrukturze: on-premise lub w Waszej prywatnej chmurze
• konfigurujemy łącznik do Foundry REST API lub OSDK, zależnie od struktury ontologii
• definiujemy agentów dla konkretnych działów: osobny dla planowania, osobny dla utrzymania ruchu, osobny dla logistyki
• przeprowadzamy testy na realnych danych z Foundry razem z użytkownikami końcowymi
• szkolimy użytkowników: jak pytać agenta, co działa dobrze, jak przekazać informację zwrotną, jeśli odpowiedź jest nieprecyzyjna

Czas do uruchomienia pierwszych scenariuszy zależy od tego, ile obiektów i zbiorów wchodzi do zakresu i czy ontologia jest już dobrze udokumentowana. Jeśli Foundry jest u Was od niedawna i ontologia jeszcze się kształtuje, zaczynamy od zbiorów tabelarycznych dostępnych przez Dataset API: te działają niezależnie od stanu ontologii i wystarczą do obsługi pierwszych przypadków.

Co zostaje w firmie i dlaczego dane nie wychodzą poza serwer?

Serwer RedAI stoi na Waszej infrastrukturze. Pytanie pracownika trafia do agenta na tym serwerze. Agent odpytuje Foundry przez sieć wewnętrzną. Model językowy, który generuje odpowiedź, też działa na Waszym sprzęcie lub w Waszej prywatnej chmurze.

Żaden fragment danych z Foundry, żadne zlecenie, żaden identyfikator maszyny, żaden plik, nie trafia do serwerów OpenAI, Anthropica ani żadnej innej zewnętrznej usługi. To istotne szczególnie tam, gdzie w Foundry żyją dane objęte NDA z klientami, dane wrażliwe na konkurencję albo dane osobowe pracowników.

Uprawnienia do danych w Foundry zostają bez zmian. Konto usługowe widzi tylko to, co mu nadaliście. Jeśli chcecie, żeby agent planisty nie widział danych kadrowych, wystarczy, że konto usługowe planisty nie ma dostępu do obiektów Employee. Granulacja uprawnień jest po stronie Foundry, nie po stronie agenta.

Audyt logów jest możliwy po obu stronach: Foundry rejestruje każde zapytanie API od konta usługowego, a logi serwera RedAI pokazują, kto pytał i o co. To przydaje się przy wykazywaniu zgodności i przy debugowaniu, gdy agent odpowie coś nieoczekiwanego.

Od czego zaczynamy, jeśli macie Foundry?

Najlepszy punkt startowy to jeden dział i jedno pytanie, które ludzie zadają najczęściej. Nie trzeba od razu podpinać wszystkich zbiorów i wszystkich działów. Zaczynamy od jednego scenariusza, sprawdzamy, czy agent odpowiada dobrze, zbieramy feedback od rzeczywistych użytkowników i dopiero potem rozszerzamy zakres.

Jeśli chcecie zobaczyć, jak podobne podejście działa w praktyce, zajrzyjcie na realne wdrożenia. A żeby sprawdzić, które dane z Waszego Foundry nadają się do obsługi jako pierwsze, umówcie się na bezpłatny audyt: przychodzimy z listą pytań, Wy pokazujecie, co macie w ontologii, i razem ustalamy, od czego sensownie zacząć.