Настоящий тест Palantir в области ИИ — удержится ли онтология спустя месяцы

Кратко

• Устойчивое техническое утверждение Palantir не в том, что их модели по своей сути лучше моделей конкурентов. Оно в том, что онтология способна достаточно плотно связать данные, логику, права доступа и действия, чтобы чувствительные организации могли превращать беспорядочные операционные факты в повторяемые решения.
• Данные подтверждают реальный перелом в бизнесе: в I квартале 2026 года Palantir отчиталась о выручке в 1,633 млрд долларов, росте на 85 % год к году и стремительном расширении коммерческого бизнеса в США. Это финансовые результаты поставщика, а не доказательство того, что каждое внедрение окупило затраты на очистку данных, аудит и внедрение.
• Важна граница продукта. Palantir поставляет Foundry, Gotham, AIP, инструменты онтологии, приложения для рабочих процессов и услуги по внедрению; заказчики по-прежнему владеют данными, принимают политические решения, несут юридическую ответственность, закупочные риски и операционные процедуры, а также многими подключаемыми моделями и системами.
• Нерешённый вопрос — сопровождение. Palantir выигрывает, если заказчики могут поддерживать онтологии, контроль доступа, журналы действий, оценки и согласования людьми в актуальном состоянии по мере изменения организаций, моделей и процессов. Ценность теряется там, где внедрения становятся чрезмерно зависимыми от услуг, политически ограниченными, сложными для смены поставщика или неспособными доказать, что более быстрые решения были более правильными.

Операционное обещание — управляемое действие, а не более умный ответ

Главная продуктовая история Palantir — это не история про чат-ботов. Чат-бот может ответить на вопрос и при этом оставить организацию неспособной действовать. Больница может спросить, какие операционные можно использовать на следующей неделе, производитель — какой дефицит деталей остановит сборочную линию, военный штаб — какие ресурсы можно переместить, не создав новой уязвимости, а банк — какой клиентский обзор требует эскалации. В каждом случае дорого обходится не только ранжирование вариантов.

Дорого обходится знание того, какие данные авторитетны, кому разрешено их видеть, какие допущения актуальны, какая нижестоящая система будет затронута и какая запись сохранится, когда решение позже будут пересматривать.

Именно поэтому вопрос о Palantir следует начинать с онтологии. В собственномобзоре архитектуры AIPPalantir онтология описывается как слой, который объединяет данные, логику, действия и безопасность в единое представление о принятии решений в предприятии. На той же странице архитектуры подчёркивается наблюдаемость ИИ-процессов, включая мониторинг потоков данных, питающих онтологию, журналирование действий, выполняемых людьми или ИИ-агентами, трассировку цепочек выполнения процессов и отслеживание использования ресурсов. Практическое утверждение состоит в том, что операционный ИИ должен находиться внутри управляемой операционной модели, а не рядом с ней.

Это различие легко потерять на нынешнем рынке ИИ. Поставщики моделей могут улучшать рассуждения, контекстные окна, мультимодальный ввод и использование инструментов, не решая внутреннюю проблему полномочий заказчика. Облачные провайдеры могут предлагать мощные хранилища данных, векторный поиск, оркестрацию процессов и услуги хостинга моделей, не гарантируя, что конкретное операционное действие авторизовано на языке бизнеса. Системные интеграторы могут связывать потоки данных и приложения, но результат может остаться локальным проектом, а не переиспользуемым институциональным слоем.

Ставка Palantir в том, что многим крупным организациям нужен слой с чёткой позицией, который отображает их мир в объекты, связи, приложения и действия, а затем держит эту карту достаточно близко к реальным операциям, чтобы она была полезной.

Этот довод убедителен там, где работа повторяется, стоит дорого и имеет серьёзные последствия. Простая панель показателей может показать задержки поставок. Сама по себе она не может решить, кому разрешено менять приоритет поставки, одобрена ли замена детали, делает ли договорное обещание одного клиента более срочным, чем другого, или почему менеджер переопределил автоматическую рекомендацию. Модель «онтология и действия» Palantir рассчитана именно на эту более тяжёлую территорию.

Здесь же сосредоточен и риск компании: чем больше платформа заявляет, что кодирует смысл и полномочия, тем больший ущерб могут нанести дрейф онтологии, устаревшие права доступа и плохое сопоставление источников.

Что такое Palantir и чем она не является

Граница компании важна, потому что о Palantir часто говорят так, будто она неразрывно связана с миссиями, которые выполняют её заказчики. Это слишком широкое представление. Palantir продаёт и поддерживает программные платформы и услуги по внедрению: Foundry — для корпоративной интеграции данных и приложений, Gotham — для оборонных и разведывательных процессов, AIP — для процессов с поддержкой ИИ, а также более широкий набор инструментов онтологии, действий, оценки, создания приложений и интеграции. Компания также предоставляет инженеров, работающих непосредственно у заказчика, и трудовые ресурсы для внедрения.

Она не становится автоматически владельцем базовых данных заказчика, правового основания государственной программы, поставщиков моделей, подключённых к AIP, облачной инфраструктуры каждого развёртывания или операционного решения, которое заказчик принимает внутри системы.

Границу иллюстрирует NHS Federated Data Platform. Впояснении к контрактуNHS England говорится, что контракт в ноябре 2023 года получил консорциум во главе с Palantir, с финансированием для до 240 организаций NHS на возможный семилетний срок. Там также указано, что Palantir является обработчиком данных по закону о защите данных, что организации-пользователи NHS контролируют доступ к своим собственным экземплярам платформы, что платформа обеспечивает контроль доступа на основе ролей и целей, и что персональные данные в FDP и среде технологий повышения конфиденциальности хранятся и обрабатываются в дата-центрах Великобритании. Далее в пояснении говорится, что Palantir не может коммерциализировать данные NHS или использовать их для разработки новых продуктов поставщика, например для обучения модели ИИ на данных NHS.

Эти контрактные формулировки не решают, следует ли NHS продолжать работать с Palantir. Они проясняют аналитическую рамку. Если система помогает пациентам быстрее проходить лечение, Palantir может утверждать, что её ПО внесло вклад в улучшение операционного процесса. Если система сталкивается с недоверием общества, оспариваемыми выгодами, низким качеством данных или политическим решением не продлевать контракт, среда заказчика и решения по управлению становятся частью результата. То же разделение действует в оборонных и коммерческих внедрениях.

Продукт Palantir может технически сделать процесс возможным, но полномочия, доктрину, управление данными, поведение персонала и институциональную терпимость к результату обеспечивает заказчик.

Эта граница работает в обе стороны. Она не позволяет делать завышенные заявления о том, что Palantir решила целую государственную или военную проблему одной установкой ПО. Она также не позволяет легко отмахнуться от компании как от просто поставщика панелей показателей. ПО задумано работать вблизи точки, где разрозненные данные превращаются в авторизованное действие. Это более значимая поверхность продукта, чем обычная аналитика, и она требует более строгого стандарта доказательств.

Онтология — экономический рычаг и бремя сопровождения

Онтология Palantir ценна тем, что может превратить сложную локальную интеграцию в переиспользуемый операционный слой. Вобзоре типов действий Foundryдействие — это транзакция, которая изменяет свойства объектов, связи или сопутствующие побочные эффекты согласно заданной пользователем логике. Пример прост, но принцип широк: авторизованный пользователь должен иметь возможность выполнять бизнес-действие в терминах бизнес-цели, а не редактировать разрозненные строки и поля. В документации Palantir говорится, что онтология сопоставляет концепции с реальными данными организации и может фиксировать решения пользователей как правки, которые возвращаются в пользовательские приложения.

В этом и заключается рычаг. Если авиакомпания, больница, завод или военное командование могут определить общий словарь объектов и выставить над ним управляемые действия, приложения становится легче переиспользовать. Планировщик технического обслуживания, руководитель операций, аналитик и специалист по комплаенсу могут работать с одним структурированным представлением, вместо того чтобы сверять локальные таблицы, заявки и панели показателей. К тому же контекстному слою можно подключать новые возможности ИИ.

Поэтому онтология занимает центральное место в коммерческом предложении Palantir: платформа — это не только место для хранения данных, но и место для кодирования институционального смысла.

Это же и бремя. Смысл меняется. Отделы реорганизуются. Цепочки поставок смещаются. Клинические маршруты меняются. Военная доктрина развивается. Регуляторы меняют требования к отчётности. Модель, которая была полезна в одном процессе, становится ненадёжной в другом. Поле, которое было безопасно показывать одной команде, становится чувствительным после слияния или изменения политики. Если онтология не меняется вместе с организацией, пользователи начнут обходить её. Если она меняется без дисциплины, пользователи перестанут ей доверять. Поэтому Palantir должна выиграть долгую игру сопровождения, а не только первую демонстрацию.

Режим отказа не драматичен. Это может быть устаревшее сопоставление с исходной системой. Свойство, которое выглядит точным, но заполняется по-разному на двух площадках. Право доступа, отражающее структуру команды прошлого года. Действие процесса, побочный эффект которого внешняя система больше не принимает. ИИ-ассистент, извлекающий объекты, которые технически релевантны, но операционно устарели. Месяцы спустя у организации всё ещё может быть впечатляющая платформа и слабый ответ на главный вопрос: почему это действие было правомерным?

Права доступа — это не обёртка

Управление правами — одно из мест, где публичная документация Palantir показывает, почему продукт — это больше, чем интерфейс модели. Вобзоре управления разрешениями на объектыресурсы онтологии, такие как типы объектов, типы связей и типы действий, отделены от самих данных, то есть слой определения ресурсов и реальные экземпляры объектов имеют разные вопросы безопасности. В документации поправам на онтологиюговорится, что ресурсы онтологии управляются через проекты, и что пользователь может иметь разрешение просматривать тип объекта, не имея при этом разрешения видеть лежащие в его основе данные. Там же отмечается, что для просмотра самих объектов также требуется доступ к данным через конфигурацию безопасности объекта.

Страницауправления безопасностью объектовидёт дальше: она описывает политики безопасности объектов и свойств, которые могут устанавливать права просмотра на экземпляры объектов и отдельные свойства, включая контроль на уровне строк, столбцов и ячеек. Она также предупреждает, что некоторые значения свойств могут ссылаться на ресурсы вне онтологии, например медиафайлы, хранящиеся в наборе медиа, и что разрешения на эти внешние ресурсы должны настраиваться отдельно. Это важная оговорка. Она показывает тип пограничного случая, способного разрушить стройную историю управления: пользователю может быть закрыто свойство, но он всё равно сможет получить связанный ресурс, если нижележащий ресурс настроен более свободно.

Именно здесь встречаются сила продукта Palantir и нагрузка на заказчика. Детальные средства контроля полезны только тогда, когда организация знает, что нужно защищать, поддерживает актуальность групп идентификации, понимает, где происхождение данных меняет доступ, и проводит аудит исключений. Palantir может предоставить механизмы. Сама по себе она не может решить, какой медсестре, аналитику, инженеру, подрядчику, командиру, аудитору или приложению должно быть разрешено видеть каждый фрагмент данных в любых обстоятельствах. Это решение принадлежит заказчику, и его нужно поддерживать по мере изменения организации.

То же самое относится к прикладному уровню. В документации поразрешениям Workshopговорится, что разрешение на открытие или редактирование модуля отделено от разрешения на доступ к данным, действиям или функциям внутри этого модуля. В документации поразрешениям типов действийговорится, что применение действия зависит от редактируемых типов объектов и связей, возможности пользователя видеть редактируемые ресурсы и источники данных, а также от любых критериев подачи. Эти детали важны, потому что реальные операции редко отказывают только на одном уровне. Процесс может выглядеть доступным, а лежащее в основе действие — нет; пользователь может редактировать модуль, не видя данные, необходимые для его использования; человеку может быть разрешено просматривать запись, но не выполнять действие, которое её изменяет.

Аудитируемость должна выдерживать обычную работу

Публичная документация Palantir по аудиту необычно откровенно говорит о практическом компромиссе в системах аудита. Вобзоре журналов аудитажурналы аудита описываются как полная запись действий в Foundry, но также как сжатая запись, где чрезмерная подробность может затруднить анализ. Там говорится, что журналы аудита отвечают на вопросы, кто выполнил действие, какое действие произошло, когда и где оно произошло, но предупреждается, что журналы аудита могут содержать чувствительную информацию и, возможно, должны анализироваться в собственной системе мониторинга безопасности заказчика.

Такая постановка полезна. Платформа, которая записывает всё, но не помогает исследователям анализировать записи, всё равно может провалить аудит. На страницекатегорий журналов аудитаописаны категории, позволяющие аналитикам запрашивать действия высокого уровня, такие как загрузка данных, экспорт или попытки аутентификации, без отслеживания каждого имени события конкретного сервиса. Такая абстракция ценна, потому что имена сервисов меняются и появляются новые функции. Это также напоминание о том, что аудитируемость — это проектная цель, а не естественный побочный продукт использования ИИ.

Журналирование действий ближе к операционному ядру продукта. В документации пожурналу действийговорится, что типы объектов журнала действий моделируют подачи как объекты онтологии, чтобы их можно было анализировать и отображать в инструментах, работающих с объектами. Поданное действие может создать объект журнала, связанный со всеми отредактированными объектами, и хранить метаданные, такие как идентификаторы действий, версия типа действия, временная метка, идентификатор пользователя, отредактированные объекты и значения параметров. Страница явно выстраивает временную линию вокруг вопросов: «что изменилось, кто и когда?»

Эти механизмы — именно то, что нужно регулируемой организации, если действие позже будет оспорено. Однако трудность не в существовании функции журнала. Трудность в том, чтобы само действие было корректно определено, релевантный контекст сохранён, правильные пользователи обязаны были дать согласование, исходные данные были актуальны, нижестоящая система получила предусмотренное изменение, а журнал аудита оставался интерпретируемым после пересмотра типа действия. Аудиторская запись, которая фиксирует, что неправильный авторизованный пользователь выполнил плохо определённое действие, — это не успешный контроль.

Это чистая запись слабого процесса.

AIP переносит точку отказа с предсказания на управление изменениями

AIP даёт Palantir возможность подключать большие языковые модели и другие возможности ИИ к онтологии и прикладному слою. Вобзоре AIPговорится, что AIP предоставляет журналы аудита, объяснения и оценки решений моделей, при этом доступность функций зависит от заказчика. В документации поэтике и управлению ИИподчёркиваются поддержка решений на основе онтологии, процессы контроля со стороны человека, процедуры согласования, петли обратной связи, контрольные точки и механизмы отката. Вобзоре AIP Evalsоценки представлены как среда тестирования функций AIP Logic, функций чат-ботов и функций, написанных на коде, предназначенная для работы с недетерминированной природой LLM путём сравнения результатов с тестовыми примерами и предыдущими версиями.

Это правильное направление для операционного ИИ. Ответ модели недостаточно стабилен, чтобы доверять ему только потому, что он звучал правдоподобно. Если модель будет рекомендовать действия, создавать черновики, сортировать работу или вызывать инструменты, организации нужны тестовые примеры, оценочные функции, проверки расхождений, сравнения версий, точки согласования и поведение отката. Документация Palantir признаёт, что производственные ИИ-процессы требуют таких средств контроля.

Но существование AIP Evals не доказывает, что производственный процесс заказчика надёжен. Набор оценочных тестов хорош настолько, насколько хороши его тестовые примеры и пороги отказов. Шаг согласования человеком силён настолько, насколько сильны экспертиза, время и мотивация проверяющего. Петля обратной связи может улучшить процесс или закрепить предвзятое локальное поведение. Механизм отката может сохранить человеческую инициативу или стать редко используемым запасным выходом.

Palantir может предоставить среду, в которой такие средства контроля проще создавать; организация всё равно должна выбирать и поддерживать те из них, которые соответствуют последствиям действия.

Тот же риск проявляется в поиске и подключении внешних инструментов. В документации поконтексту поискаговорится, что чат-боты AIP могут включать онтологический, документальный и функциональный контекст, который детерминированно выполняется с каждым новым сообщением пользователя. В анонсе документации за май 2026 года обOntology MCPговорится, что внешние ИИ-агенты могут подключаться как MCP-клиенты, чтобы читать типы объектов, выполнять предопределённые типы действий и запускать функции запросов в пределах настроенных разрешений. Эти возможности могут сделать ИИ-агентов более полезными в операционной работе. Они также расширяют поверхность контроля. Если внешний агент может видеть типы объектов и выполнять предопределённые действия, ограничение разрешений, описания инструментов, требования к согласованию и мониторинг становятся частью истории надёжности продукта.

Иными словами, AIP не устраняет проблему онтологии. Он увеличивает выгоду от её решения и повышает цену ошибки.

Данные заказчиков показывают, почему важен знаменатель

Публичные данные о заказчиках достаточно весомы, чтобы показать спрос, но недостаточны, чтобы определить окупаемость инвестиций по всем внедрениям. Ванонсе корпоративного соглашения об обслуживанииU.S. Army от июля 2025 года говорится, что Армия объединила 75 контрактов, включая 15 основных и 60 связанных контрактов, в одно соглашение с потенциальной стоимостью не более 10 млрд долларов на срок до 10 лет. В том же анонсе указано, что эта сумма является максимальной потенциальной стоимостью, а не конкретным обязательством. Эта оговорка — не сноска. Она центральна для оценки экономики Palantir. Большой потолок показывает путь закупок и институциональную уверенность, но реализованная ценность зависит от заказов, внедрения, исполнения контрактов и стоимости реализации.

Данные о Maven Smart System указывают в том же направлении. Ванонсе контрактаDepartment of Defense от мая 2024 года говорится, что Palantir USG получила контракт с фиксированной ценой на 480 млн долларов на прототип Maven Smart System; места работ и финансирование определяются заказами. Breaking Defense сообщила, что новый контракт должен был расширить доступ к Maven с сотен пользователей до тысяч, и процитировала Palantir о необходимости интегрировать системы данных и новые возможности ИИ. Самая показательная строка в этом отчёте — не расширение числа пользователей, а описание рутинной работы за ним: получение доступа к наборам данных, исправление ошибок и артефактов, переформатирование данных и создание устойчивых потоков данных. Это и есть знаменатель. Чем ценнее миссия, тем дороже подготовка данных.

Позже DefenseScoop сообщила, что руководители Пентагона увеличили потолок контракта Maven на 795 млн долларов — почти до 1,3 млрд долларов до 2029 года, ссылаясь на растущий спрос со стороны боевых командований, но отмечая открытые вопросы о планах развёртывания и расширении числа пользователей. Для Palantir это коммерчески привлекательное свидетельство оборонного спроса. Для аналитиков это также напоминание о том, что рост лицензионных мощностей и потолков контрактов не раскрывает операционное качество каждого процесса, доктрину вокруг решений с участием ИИ или нагрузку по обучению пользователей.

Здравоохранение ещё более чувствительно, потому что доверие общества является частью операционной системы. В пояснении NHS England платформа FDP представлена как управляемая платформа с локальным контролем доступа, обработкой в Великобритании и механизмами пересмотра контракта. The Guardian в отчёте за июль 2026 года о парламентской проверке описала межпартийные призывы отказаться от контракта NHS с Palantir, ссылаясь на недоверие общества и медиков, оспариваемые выгоды, опасения по поводу приватности и наличие альтернатив.

Palantir и британские официальные лица ссылались на операционные преимущества, включая дополнительные операции и сокращение задержек, тогда как критики ставили под сомнение доказательства и институциональную совместимость. Факты не сводятся к «ПО работает» или «ПО не работает». Они показывают, что ценностное предложение Palantir неотделимо от легитимности, управления данными и способности заказчика убедительно доказать выгоды.

Финансовая кривая реальна, но это не доказательство повторяемых результатов

Рост Palantir даёт компании основания утверждать, что рынок подтверждает её операционную модель. Впресс-релизе о результатах I квартала 2026 годаPalantir отчиталась о выручке 1,633 млрд долларов, что на 85 % больше год к году и на 16 % больше квартал к кварталу. Выручка в США выросла на 104 % год к году — до 1,282 млрд долларов. Коммерческая выручка в США выросла на 133 % год к году — до 595 млн долларов, а выручка от правительственных заказчиков в США — на 84 % год к году, до 687 млн долларов. Компания также сообщила о 206 сделках на сумму не менее 1 млн долларов, 72 сделках на сумму не менее 5 млн долларов и 47 сделках на сумму не менее 10 млн долларов.

Форма 10-Q за I квартал 2026 года добавляет полезные детали. Выручка от правительственных заказчиков за квартал составила 858 млн долларов, коммерческая — 774 млн долларов, при этом общая выручка выросла на 85 % по сравнению с I кварталом 2025 года. Palantir отчиталась о валовой марже 87 % за квартал, что выше 80 % годом ранее, даже при том, что себестоимость выручки выросла отчасти из-за услуг стороннего облачного хостинга.

Компания также сообщила о 8,0 млрд долларов денежных средств, их эквивалентов и краткосрочных казначейских ценных бумаг США на 31 марта 2026 года, об отсутствии непогашенных долговых обязательств и о 899 млн долларов операционного денежного потока за квартал.

Это сильные финансовые показатели для софтверной компании. Они не отвечают на вопрос о качестве внедрений. Высокая валовая маржа может сочетаться с большими затратами заказчика на внедрение. Быстрый рост коммерческой выручки в США может сочетаться с неравномерными результатами по отраслям. Большое число сделок может включать расширения, пилоты, закупочные механизмы и многолетние обязательства с разными профилями риска. Финансы доказывают, что Palantir нашла спрос и монетизацию в масштабе.

Они не доказывают, что каждая онтология остаётся точной, каждое действие остаётся аудитируемым, каждый пользователь осваивает процесс или каждый заказчик превосходит совокупную стоимость альтернатив.

Годовой отчёт сохраняет это различие. Вформе 10-K за 2025 годPalantir сообщила об общей оставшейся стоимости сделок в 11,2 млрд долларов на 31 декабря 2025 года, включая 6,8 млрд долларов от коммерческих заказчиков и 4,4 млрд долларов от правительственных. Компания также раскрыла, что многие контракты предусматривают условия расторжения, включая расторжение по инициативе заказчика, и что опционы по контрактам с U.S. federal government не могут быть реализованы более чем за год вперёд. Отдельно Palantir сообщила, что ей были присуждены контракты IDIQ на общую сумму 12,3 млрд долларов, которые не вошли в оставшуюся стоимость сделок, поскольку финансирование не было определено или гарантировано.

Эта формулировка важна, потому что коммерческий вопрос для Palantir не в том, «интересуются ли заказчики». Ответ очевидно да. Вопрос в том, перевешивают ли более быстрые операционные решения и переиспользуемые приложения затраты на инженеров у заказчика, очистку данных, сопровождение онтологии, закупки, лицензирование, проверку моделей и смену поставщика с течением времени. Во многих ситуациях с высокой ценностью ответ может быть да. Но его всё равно нужно зарабатывать внедрение за внедрением.

Труд по оказанию услуг — часть продукта, даже когда маржа выглядит как у ПО

Модель Palantir с инженерами у заказчика — это сила, потому что целевым заказчикам компании трудно обслуживаться только с помощью self-service ПО. У чувствительных организаций есть унаследованные системы, нестандартные определения данных, закрытые или регулируемые среды, политические стейкхолдеры, ограничения безопасности и отраслевые эксперты, которые не говорят на языке таблиц баз данных. Обычного роста за счёт продукта недостаточно. Кто-то должен понять операционную проблему, сопоставить данные, построить онтологию, спроектировать действия, связать приложения, управлять разрешениями и убедить пользователей изменить рутину.

Эта работа может создать ров вокруг бизнеса. Хорошо построенная онтология встраивает знания заказчика так, что конкурентам трудно быстро их вытеснить. Приложения, построенные поверх неё, могут стать переиспользуемыми. Если инженеры Palantir помогают заказчику перейти от разовой панели показателей к управляемой операционной модели, заказчик может расширяться, а не уходить. Рост выручки I квартала от существующих заказчиков, описанный в 10-Q как внедрение продуктов и услуг внутри организаций, согласуется с этой моделью.

Она же может стать тормозом. Если каждое высокоценное внедрение требует индивидуальной инженерии, воркшопов с заказчиком, исправления данных, споров об управлении и постоянного сопровождения, платформа может выглядеть как ПО в отчётности Palantir, но в реальных затратах заказчика быть тяжёлой на услуги. От этого бизнес не становится плохим. Это увеличивает знаменатель. Производитель может сэкономить достаточно за счёт меньшего числа простоев линии, чтобы оправдать затраты. Больница может сэкономить достаточно мощностей, если процессы планирования и выписки действительно улучшатся.

Оборонное ведомство может оправдать затраты, если объединение данных изменит операционный темп. Но ценность нужно измерять против общей стоимости программы, а не только цены лицензии.

Именно здесь следует проверять риторику компании о «несущих» программных системах. Несущие системы оценивают не по демо. Их оценивают по скучной надёжности: работающие передачи дел, видимые исключения, обновляемые права доступа, журналируемые действия, пользователи, не ведущие параллельные таблицы, и отработанные пути восстановления. Собственная документация Palantir указывает на многие из этих средств контроля. Публичные данные редко показывают, насколько хорошо заказчики их поддерживают.

Суверенитет данных — функция продукта, только если его соблюдает вся цепочка

Заданная тема включает суверенитет и локализацию данных, и клиентская база Palantir делает это неизбежным. Медицинские системы, оборонные ведомства и критически важные отрасли не могут относиться к ИИ-процессам как к обычным облачным функциям. Им нужно знать, где хранятся данные, кто может получить к ним доступ, какая юрисдикция применяется, могут ли поставщики переиспользовать данные и как чувствительные атрибуты перемещаются внутри системы.

Пояснение к контракту NHS даёт один публичный пример: хранение и обработка персональных данных в FDP и среде технологий повышения конфиденциальности только в Великобритании, договорные ограничения на использование данных NHS компанией Palantir и локальный контроль со стороны организаций-пользователей NHS. Документация Palantir по безопасности объектов даёт пример со стороны продукта: политики объектов и свойств, политики источников данных и предупреждения о внешних связанных ресурсах.

Документация по архитектуре AIP добавляет идею о том, что гарантии интеграции, безопасности и происхождения данных должны оставаться согласованными в пакетном, потоковом режиме и режиме реального времени.

Риск в том, что суверенитет может быть сведён к заявлению о хостинге. Расположение хостинга важно, но это не вся цепочка контроля. Процесс может по-прежнему раскрывать данные через неправильно настроенное приложение, производный набор данных, ссылку на медиа, излишне разрешительное действие, инструкцию модели, путь экспорта, внешний инструмент или человеческий процесс вне платформы. Заказчик может также соблюдать правила локализации данных и при этом потерять доверие общества, если люди считают поставщика или государственную программу неуместными.

Преимущество Palantir на чувствительных рынках зависит от того, насколько управление понятно и техническим администраторам, и институциональным стейкхолдерам.

Анонс Ontology MCP за май 2026 года заостряет этот момент. Внешние ИИ-агенты могут быть полезны, если работают через инструменты с ограниченной областью действия и предопределённые действия. Они также создают новые вопросы управления, потому что граница между внутренним приложением, внешним агентом и операционным действием усложняется. Релевантный вопрос не в том, современен ли MCP. А в том, может ли организация точно доказать, что агент мог видеть, что мог делать, какие согласования требовались, какие журналы создавались и какие средства контроля отказывали в безопасном режиме.

Альтернативы совершенствуются, но решают другую первую задачу

Palantir конкурирует не только с одной компанией. Она конкурирует с внутренними командами платформ данных, облачными стеками ИИ, ПО для рабочих процессов, системными интеграторами, оборонными подрядчиками, аналитическими платформами, хранилищами данных, lakehouse-платформами и решением ничего не делать. Каждая альтернатива исходит из другой предпосылки. Облачный провайдер может исходить из инфраструктуры и доступа к моделям. Поставщик lakehouse — из управляемых данных и аналитики. Поставщик ПО для процессов — из автоматизации бизнес-процессов. Системный интегратор — из заказной поставки.

Внутренняя команда — из институциональных знаний и меньшей зависимости от поставщика.

Преимущество Palantir — интеграция этих задач вокруг операционного действия. Если заказчику нужны в основном хранение, отчётность или хостинг моделей, Palantir может выглядеть тяжёлой и дорогой. Если заказчику нужно соединить беспорядочные данные с полномочиями, процессом, журналированием действий и отраслевыми приложениями, вес Palantir может стать преимуществом. Компания сильнее всего там, где решения повторяются, носят межфункциональный и чувствительный характер и стоят достаточно дорого, чтобы оправдать бремя сопровождения онтологии.

Вопрос зависимости от поставщика следует естественно. Онтология, действия, приложения и операционные процедуры заказчика могут оказаться глубоко связаны с Palantir. Это может быть приемлемо, если платформа становится устойчивым операционным слоем, а экономика контракта остаётся разумной. Это становится риском, если заказчик не может перенести процессы, историю аудита, бизнес-логику или отраслевые модели без высоких затрат на переход. В пояснении NHS England отмечается, что NHS владеет заказанной канонической моделью данных и созданными продуктами или компонентами, тогда как Palantir сохраняет права на саму Foundry.

Это различие важно, но практический выход зависит не только от формулировок об интеллектуальной собственности. Он зависит от документации, экспорта данных, переносимости процессов, навыков персонала и доступных замен.

Именно поэтому внедрение Palantir следует проверять как живую операционную модель, а не как завершённую программную установку. Доказательная база указывает на страницы оценок, страницы документации по действиям, материалы по продукту AIP, раскрытия заказчиков и объяснения контроля в госсекторе, но эти источники в основном описывают механизмы и отдельные результаты.

Покупатель всё равно должен проверить обычную работу после запуска: кто изменил группу разрешений, какое поле источника питало действие, какая оценка покрывала пересмотренный процесс, как была записана отклонённая рекомендация и могут ли сотрудники на передовой объяснить применяемое правило. Именно на таких будничных выборках операционная платформа либо заслуживает доверие, либо становится непрозрачной.

Доказательства, которые могли бы изменить оценку

Публичные данные подтверждают ограниченный тезис: Palantir построила серьёзную операционную платформу для ответственной работы «от данных к действию», и заказчики покупают её во всё больших масштабах. Те же данные не доказывают, что платформа стабильно проходит свои самые сложные тесты на сопровождение. Чтобы решительно изменить оценку, внешним наблюдателям понадобились бы дополнительные свидетельства уровня отдельных внедрений.

Во-первых, нужны показатели «до и после», привязанные к знаменателям: время цикла, частота ошибок, стоимость обслуживания, часы персонала, время восстановления, результаты аудитов, внедрение пользователями и объём исключений, а не только истории или валовые показатели активности. Во-вторых, нужны доказательства того, что процессы с ИИ оцениваются на реалистичных крайних случаях, а покрытие тестами обновляется после изменений моделей, данных и процессов. В-третьих, нужны доказательства того, что изменения прав доступа, организационные изменения и изменения исходных систем быстро отражаются в онтологии и нижестоящих приложениях.

В-четвёртых, нужны выборки аудита, показывающие, что записи действий остаются интерпретируемыми после пересмотра типов действий и изменений систем. В-пятых, нужны заслуживающие доверия свидетельства о выходе и переносимости, особенно для госсекторных внедрений, где демократический контроль и доверие общества являются частью операционных требований.

Часть этих доказательств никогда не станет публичной, потому что Palantir работает в чувствительных средах. Это ограничение не должно использоваться для предположения о провале. Его не следует использовать и для некритичного принятия заявлений поставщика. На чувствительных рынках непрозрачность иногда необходима, но она поднимает планку для независимого управления, контроля со стороны заказчика и осторожных публичных заявлений.

Самая консервативная трактовка: технология Palantir хорошо соответствует проблеме, которую компания заявляет решать, тогда как реальная стоимость и надёжность каждого внедрения остаются специфичными для заказчика. У компании сильная архитектурная документация, быстро растущая выручка, публичные обязательства заказчиков и убедительные продуктовые примитивы для аудитируемости, разрешений, действий и оценок. Нерешённый риск — сохранят ли эти примитивы дисциплину после того, как первоначальная команда внедрения уйдёт, организация заказчика изменится, а слой ИИ станет более агентным.

Итог

Сложная задача Palantir — не генерация ответа. У рынка много способов генерировать ответы. Сложная задача Palantir — сохранять операционное представление заказчика правдивым, авторизованным и проверяемым ещё долго после первого успешного процесса. Это означает поддержание онтологии, происхождения данных, безопасности объектов, определений действий, согласований людьми, оценок, журналов аудита и поведения пользователей по мере изменения организации.

Если Palantir способна делать это многократно, её продукты становятся редкой категорией корпоративной инфраструктуры: ПО, которое превращает разрозненные данные в управляемые действия для организаций, которые не могут позволить себе небрежную автоматизацию. Если нет — та же архитектура становится источником хрупкой зависимости, высоких затрат на переход и политической уязвимости. Имеющиеся данные говорят в пользу того, чтобы относиться к Palantir серьёзно, но не принимать её сильнейшие заявления на веру.

Правильный тест — можно ли объяснить действие месяцы спустя, после того как изменились модель, права доступа и процесс, а организация всё ещё должна отвечать за решение.