Who This Article Is For
For anyone who’s heard the name “Palantir AIP” but isn’t sure whether it’s a chatbot, a separate product, or how it relates to Foundry and Gotham. If you’ve already wired a general-purpose LLM API (OpenAI, Anthropic, etc.) directly into an internal system, comparing that approach against AIP will help it click faster.
Introduction
Search around Palantir long enough and you keep running into the word “AIP.” It’s short for AI Platform, and the name alone makes it easy to assume it’s a standalone AI tool. In reality, the whole approach is different. AIP isn’t a separate chatbot product — it’s Palantir’s generative-AI platform that sits on top of Foundry or Gotham and lets you plug various LLMs directly into the data, pipelines, and Ontology already inside them. This article covers what AIP is actually made of, and the principles it’s designed around.
The Five Pillars Behind AIP
AIP is built around five design principles.
- Seamless integration: it doesn’t move or duplicate data anywhere — it uses the pipelines, Ontology, and permission structure that are already connected.
- Inherited security and governance: AIP has no separate security system of its own — it inherits the access permissions, markings, and audit logs of whichever Foundry or Gotham instance it’s attached to.
- Model management: an organization can centrally enable or disable LLMs from providers like OpenAI, Anthropic, Google, xAI, and Meta, or register its own model if needed.
- Scalability and performance: it runs on top of Foundry/Gotham’s distributed computing infrastructure, holding up under large workloads, with call volume and latency trackable through observability tools.
- Explainability and transparency: every interaction leaves an audit trail, and evaluation tools like AIP Evals systematically validate model output quality.
These five matter because the real barrier to AI adoption is rarely “model performance” — it’s “how do we run this model safely, on top of the data we already have.” AIP builds the answer to that question into the platform’s design from the start, rather than bolting it on afterward.
What AIP Actually Bundles Together
Several applications live under the single name “AIP.”
| Application | Role |
|---|---|
| AIP Assist | A conversational assistant usable across Foundry — supports data exploration, code writing, and document Q&A |
| AIP Logic | Builds LLM-calling logic through natural language and a block interface, no code required |
| AIP Chatbot Studio | Designs and deploys a conversational chatbot backed by custom content sources |
| AIP Evals | Systematically evaluates the output quality of LLM-based workflows and guards against regressions |
| AIP Threads | Maintains conversation context across multi-step AI interactions |
| Palantir MCP | Lets external AI clients access Foundry data and functionality via the Model Context Protocol |
Beyond these standalone applications, AIP is also woven into the developer toolchain in a lot of smaller places. Pipeline Builder uses it to document transform logic in natural language or help write a regex; Automate uses it to configure automation conditions in natural language; AIP Assist plays a supporting role in Notepad and Scheduler too. It’s less “a separate tool that uses AI” and more “AI woven into the tools you already use.”
How This Differs From Wiring a General-Purpose LLM API Directly
“Couldn’t we just bolt the OpenAI or Claude API onto our internal systems ourselves?” is a fair question. Here’s the difference.
| Direct general-purpose LLM API | AIP | |
|---|---|---|
| Data context | A developer has to manually feed data into the prompt | Structured context is already connected through the Ontology |
| Permission management | Has to be implemented separately in the API-calling code | Inherits Foundry’s existing ACLs and markings directly |
| Audit and tracing | Requires building a separate logging system | Audit trail is built into AIP itself |
| Swapping models | Often requires code changes | Switch by enabling/disabling a model in the Control Panel |
| Quality validation | Needs a separate evaluation pipeline | Systematic regression checking via AIP Evals |
In short: a general-purpose API integration means writing “code that calls AI” yourself, while AIP means “calling AI on top of an environment that already has data, permissions, and audit infrastructure in place.” The benefit of the latter grows with the amount of data, the size of the organization, and how regulated the industry is.
Balancing Supported Models and Security
AIP is model-agnostic by design. An organization can enable or disable available models from the Control Panel, and for enrollments under a georestriction, the range of usable models shifts accordingly. This flexibility isn’t just about convenience — it’s directly tied to security requirements. Palantir’s own AIP security Q&A states that AIP has no separate security system of its own — it inherits the existing access permissions, markings, and encryption of whichever Foundry or Gotham it’s connected to; the service doesn’t store customer data; and data isn’t used to retrain models, except when a customer explicitly runs a private retraining themselves. Third-party providers also have no access to prompt data.
There’s one reason these terms are spelled out so explicitly. The most common reason companies fail to adopt generative AI isn’t “not enough performance” — it’s “anxiety about not knowing where our data is leaking to.” AIP can be understood as an attempt to resolve that anxiety through platform-level contracts and architecture.
Responsible AI: Seven Principles
Palantir lays out seven “Responsible AI” principles for organizations running AIP to reference — fairness, explainability, reliability, traceability, collaboration, accountability, and human-centeredness. Each principle comes paired with corresponding platform features (a sensitive-data scanner, model rollback, data-lineage tracking, approval workflows, and so on). What these all share is that AI governance isn’t left as a policy document — it’s implemented as actual functionality (permission structures, logs, rollback, evaluation tools).
Common Failure Patterns in Practice
- Adopting AIP before the Ontology exists: AIP’s core advantage is that it already has structured context through the Ontology. Bolt AIP onto a weak or missing Ontology, and it ends up not much different from using a general-purpose API directly.
- Picking a model once and never revisiting it: the whole point of a model-agnostic design is being able to swap models as circumstances change. Sticking with whatever model you first picked leaves cost and performance optimization opportunities on the table.
- Deploying without AIP Evals: an LLM-based feature’s quality can keep shifting after deployment (model updates, prompt changes). Deploy without evaluation, and you run in production without ever noticing a regression.
Wrapping Up
Summed up in one line, AIP is “Palantir’s generative-AI platform that sits on top of Foundry or Gotham and lets you plug in multiple LLMs directly, along with a toolset that inherits the underlying platform’s security and governance as-is.” The difference between bolting on a single chatbot and adopting AIP is that the latter brings the data flow, permissions, and audit history along with it.
Reference: Palantir Foundry official documentation — AI Platform (AIP)
What to Read Next
For how AI helps build the Ontology and application and then runs a workflow, see Designing AI Agents and Workflows in AIP. For how to expose AI to users, see 3 Ways to Design AI User Experience in AIP. For connecting an external agent like Claude, see the OMCP practical guide.
Frequently Asked Questions
Q. How is AIP different from just connecting ChatGPT to company data?
A general-purpose LLM API integration requires feeding data into the prompt directly or building your own RAG; AIP inherits the permission structure and schema already defined in the Ontology, producing answers that respect per-user access rights automatically.
Q. Which LLMs can AIP use?
It isn’t locked to one model — you can choose among several commercial models based on your security and performance needs. AIP’s core value comes from Ontology-based context and permission control, more than model choice itself.
Q. What do AIP’s five pillars refer to?
Seamless integration (using your existing pipelines, Ontology, and permission structure as-is), inherited security and governance (inheriting Foundry/Gotham’s access permissions and audit logs), model management (centrally choosing among multiple LLM providers), scalability and performance (running on distributed computing infrastructure), and explainability and transparency (audit trails and AIP Evals).
Q. How do the “Responsible AI” principles affect day-to-day work?
The principle that AI’s decisions and the data behind them must be traceable gets implemented in practice as things like a human-approval step before an Action executes, or regular audit-log reviews.
Q. Do I need an Ontology already built before I can use AIP?
Yes. AIP’s accuracy and safety depend heavily on how well the Ontology is defined, so adopting AIP without an Ontology in place isn’t recommended.