Palantir营收近乎翻倍：企业需要掌握的不只是数据，还有业务本体
2026年8月，Palantir公布第二季度业绩：季度营收约19.35亿美元，同比增长93%；美国商业业务收入约7.64亿美元，同比增长149%。这些数字来自Palantir正式财务披露。需要说明的是，把增长归因于“AI主权”，更多是Palantir对自身业务价值的解释，而不是已经得到整个市场验证的统一结论[1]。但这组数字仍然值得我们停下来想一想。当越来越多的大模型能力可以通过API购买，甚至可以在企业内部部署时，企业为什么还愿意为一套昂贵、复杂、需要深度实施的平台付费？也许答案并不只在模型本身，而在企业是否能够把自己的业务世界，变成一套可被机器理解、被流程调用、又始终由自己掌握的系统。很多企业谈AI控制权，首先想到的是数据不出域、模型私有化和账号权限。这些当然重要。但真实的经营活动并不是一堆静止的数据表。一张客户表里有客户名称和行业，一张订单表里有金额和日期，一张项目表里有进度和负责人。数据都在企业手里，可当管理者问：“哪些战略客户的关键项目正在因为交付风险影响续约？”系统仍然需要知道什么是战略客户、项目与订单如何关联、怎样定义交付风险、什么条件可能影响续约。这些问题已经超出了“数据在哪里”，进入“企业怎样定义自己的业务”。Palantir将Ontology描述为组织的操作层：它把数据集和模型映射到工厂、设备、产品、客户订单、交易等现实对象，并通过对象、属性、关系、行动和函数支撑分析与业务操作[2]。这或许能帮助我们理解，本体并不是给数据换一套更复杂的标签。它要回答的是：企业里有哪些关键对象？客户、产品、项目、合同、设备、人员和风险之间是什么关系？哪些状态意味着异常？谁有权发起行动？行动之后，哪些系统和数据需要同步变化？例如，同一个“客户”可能同时出现在CRM、合同系统、项目台账和售后记录中。没有统一语义时，AI看到的是四组字段；有了本体之后，它看到的才可能是同一个客户，以及这个客户与机会、合同、交付和回款之间的关系。因此，业务本体保存的并不是某个模型的答案，而是企业自己对现实的分类方式、关系结构和行动规则。- 第一是数据控制权。企业知道数据在哪里、谁能访问、供应商是否会二次使用。
- 第二是业务语义定义权。客户、产品、项目、风险等概念由谁定义，同一概念在不同系统中如何对应。
- 第三是规则与流程控制权。判断条件、审批节点、例外处理和责任边界不能只藏在某个供应商的黑箱里。
- 第四是评价与纠偏权。什么结果算正确，哪些错误不可接受，运行记录能否沉淀为企业自己的评价集。
- 第五是迁移与替换权。更换模型、平台或实施方后，企业的对象体系、业务规则、工作流和历史反馈能否继续使用。
私有部署可以减少一部分数据和基础设施风险，却不必然带来业务自主。如果企业的核心流程只能在某一家平台上运行，如果业务规则没有被显性表达，如果提示词、评价标准和运行日志无法迁出，那么即使服务器放在自己的机房里，企业仍可能没有真正掌握这套能力。反过来，一家企业即使使用外部模型，只要关键业务对象、关系、规则、评价集和工作流由自己维护，并且保留替换接口，它仍然可能拥有更强的控制力。所以，我们或许不必把“自建”和“采购”看成两个互斥答案。更值得讨论的问题是：哪些通用能力可以购买，哪些业务定义必须由企业自己掌握，哪些知识和流程应当以可迁移的方式沉淀下来。建设企业本体听起来宏大，但它未必需要从一场覆盖全公司的建模工程开始。也许可以先选一个真实问题：战略客户识别、项目风险预警、招聘匹配、经营计划跟踪，或者行业情报分析。围绕这个问题，梳理关键对象、关系、规则、行动和评价标准，再让AI进入流程。当这些定义能够被业务人员理解、被系统调用、被管理机制持续修正时，企业才开始拥有一种不会随着模型版本更换而消失的能力。Palantir的增长是否足以证明“AI主权”已经成为企业采购的普遍理由，还需要更多市场数据验证。但它至少提出了一个值得共同思考的问题：当模型越来越容易获得，我们是否正在把最难替代的部分——对自身业务的理解和定义——也一起交给外部供应商？[1] Palantir Technologies Inc., “Palantir Reports Q2 2026 U.S. Comm Revenue Growth of 149% Y/Y and Revenue Growth of 93% Y/Y,” Business Wire, 2026-08-02. 财务数据为公司正式披露；“AI主权”属于公司及相关市场叙事，本文不将其视为全行业统一结论。[2] Palantir, “Ontology Building—Overview”及“Core Concepts,” Palantir Foundry Documentation. 官方文档将Ontology定义为连接企业数字资产与现实业务对象的操作层，并以对象、属性、关系、行动和函数支撑决策与工作流。[3] C. Maria Keet, An Introduction to Ontology Engineering；Robert Arp, Barry Smith, Andrew D. Spear, Building Ontologies with Basic Formal Ontology。本文关于业务对象、关系与领域建模的解释同时参考了上述本体工程资料。
