2026 年 9 月，一场 CNBC 访谈把企业 AI 中一个不太体面的问题摆上了台面：你付钱购买的智能，会不会最终削弱你自己的竞争优势？
提出这个问题的是 Palantir 联合创始人兼 CEO Alex Karp。根据访谈报道，他指责模型厂商吸收企业的数据、业务知识和独特经验，让客户的竞争优势流入竞争对手也能使用的模型。他甚至将低价 token 解读为获取企业知识产权的手段。这里转述的是他的指控，并非已经得到独立证实的事实。(访谈报道)
Karp 的措辞激烈，但他触碰到了一个真实的商业矛盾：企业希望模型厂商提供能力，却未必希望它们掌握客户关系、工作流程，以及这门生意最后的定价权。
我们很容易把这个故事理解为「大厂拿走客户的数据，再复制客户的业务」。然而，即使完全没有发生数据滥用，类似的竞争压力仍然可能出现。
看一看 ChatGPT 和 Claude 如何从聊天框走向工作台，再看一看 Figma 所处的位置，就能理解这一点。更早的线索，则藏在三十多年前的办公软件市场里。
数据没有进入训练，不代表业务不会受到威胁 🍅
首先要拆开三个经常被混为一谈的动作：模型读取资料完成任务；厂商保存这些资料；厂商用这些资料训练通用模型。三者并不等价。把一份设计文档放进上下文，不意味着模型参数就因此更新，更不能直接推导出其他客户能读到这份文档。
截至本文写作时，OpenAI 和 Anthropic 都声明，其相关企业或商业产品、API 的客户数据默认不用于训练模型；主动授权、反馈等情形另有规定。因此，不能仅凭 Karp 的访谈，就断言这些厂商普遍在偷偷训练客户的数据。(OpenAI 企业隐私说明、Anthropic 商业产品数据说明)
但「不拿你的数据训练」与「不进入你的市场」，是两件事。
一个模型厂商不需要看到某家设计公司的机密，才知道用户想快速生成网页；也不需要复制某家办公软件的源代码，才知道用户想把一份报告变成演示文稿。公开需求、通用能力和足够好的产品体验，已经可以支撑它进入这些市场。
这正是这场争论里更值得注意的部分：企业面对的风险，既包括知识泄露，也包括供应商与自己争夺同一个用户、同一笔预算、同一段工作时间。前者需要数据治理，后者需要重新审视产品的位置。解决了前者，后者仍然存在。
Figma 面临的压力，从「第一稿在哪里产生」开始 🍅
先把产品名称说清楚。OpenAI 的 Canvas 最初定位于写作和编程协作；Anthropic 的 Artifacts 把代码、文档、网页设计等产物放进独立工作区。它们都不等于完整的专业设计软件，但共同改变了一件事：用户可以在与 AI 交谈的地方，直接创建并修改作品。(Canvas 发布说明、Artifacts 发布说明)
2026 年 4 月，Anthropic 又推出 Claude Design，明确进入原型、视觉设计、演示文稿等任务，并提供设计系统导入、细节修改和向 Claude Code 交接的能力。这比给聊天机器人加一块预览面板更进一步：它试图承接从想法到可用产物的连续过程。(Claude Design 发布说明)
设想一位产品经理要验证一个新功能。
过去，她可能先整理需求，再请设计师在 Figma 中画页面、连接交互，最后拿原型去讨论。如今，她可以先向 AI 描述目标，让它生成一个可点击的版本，现场调整，再决定是否值得投入完整的设计流程。
这是一个说明竞争机制的场景，并不是对所有团队实际工作方式的描述。但它揭示了关键差别：AI 不必在专业设计能力上全面超过 Figma，也能承接一部分原本会流向 Figma 的任务。
对于「下午开会前，让大家看懂这个想法」这样的需求，用户衡量的往往是速度、沟通效果和启动成本。精细的组件管理和复杂的协作机制，在这一刻未必是决定因素。
因此，我认为最先受到挤压的，会是要求相对有限、交付周期很短的草图和原型任务。更深的影响在于：谁生成第一稿，谁就有机会承接接下来的修改。
用户已经在 AI 工作台里解释了需求、补充了资料、否定了两个方向。当她想改第三版时，留在原地通常比重新向另一个工具交代背景更方便。这种优势来自连续上下文，不需要以窃取训练数据为前提。
不过，「第一稿入口」也不自动等于最终控制权。正式交付往往还涉及一致性、边界状态、团队评审和工程约束。Figma 的机会，就在于让这些后续工作值得用户回来。
微软 Office 的历史：竞争单位变了 🍅
这让人想起微软 Office 的崛起。但历史需要讲准确：PowerPoint 并非微软从零创造。它最初由 Forethought 开发，1987 年首先在 Macintosh 上发布，同年随收购进入微软。(计算机历史博物馆档案)
1989 年，微软推出 Macintosh 版 Office，将 Word、Excel、PowerPoint 和 Mail 组合在一起。当时它面对的是已有强劲独立产品的市场：微软自己的历史记录，就记载了当年针对 Lotus 1-2-3 用户开展的 Excel 推广活动。(微软 1989 年历史记录)
文字处理市场的变化尤其鲜明。计算机历史博物馆记载，20 世纪 80 年代，DOS 上的 WordPerfect 曾占据主导位置，而 Word for Windows 在 1989 年推出后迅速崛起。博物馆引用的数据表明，到 1997 年，Word 已获得约九成的文字处理市场收入。这是收入份额，不能直接当成用户份额。(Word 历史资料)
把这一切归结为「微软捆绑销售，所以别人输了」，会遗漏图形界面迁移、产品质量和厂商执行等因素。Office 也不是随 Windows 免费附送的同义词。这里真正值得借鉴的，是竞争单位的改变。
当软件分别出售时，用户逐一比较文字处理、电子表格和演示工具。套件普及后，企业也开始比较整套采购、员工培训、文件交换和技术支持的成本。
于是，一款独立工具即使在某项功能上更好，也要回答一个更困难的问题：已有的整套软件足够完成工作，为什么还要再买你？
AI 工作台可能带来相似的变化。一个人已经为通用 AI 服务付费，如果其中包含基本的原型、文档或演示能力，专业工具就必须解释额外付费的价值。这里的成本不只包括订阅费，还包括再开一个工具、重新输入背景、迁移文件和学习操作。
Office 把多种工具装进同一个套件；AI 工作台则有机会把多种工具原本承担的步骤，合并成一次任务。
这也是两代竞争的重要差别。Office 用户通常仍要自己在 Word、Excel 和 PowerPoint 之间组织工作；AI 工作台更进一步，尝试让用户只提出「把这份分析做成可以汇报的材料」，由系统选择并执行中间步骤。当然，今天的 AI 还不能稳定完成所有这样的任务，但竞争的方向已经发生了变化。
合作不会消除竞争，反而让它更复杂 🍅
Figma 并没有坐等变化发生。
2025 年发布的 Figma Make 已经把自然语言生成与交互原型结合起来，发布时采用 Claude 3.7 Sonnet。到 2026 年 2 月，OpenAI 与 Figma 又宣布深化合作，让 Codex 与 Figma 之间支持代码和可编辑设计的往返。(Figma Make 发布说明、OpenAI 与 Figma 合作公告)
这意味着同一家模型厂商可以同时是能力供应商、分发伙伴和潜在竞争者。这些身份并不互相排斥。
站在 Figma 的位置，引入模型可以让自己的产品更有用；连接 AI Agent，也可以让已有设计资产进入更多工作流。但与此同时，一部分用户可能逐渐习惯从 AI 工作台发起任务，只在需要时调用 Figma。
这是一种值得观察的可能性：Figma 的能力使用量增加了，用户直接打开 Figma 的频率却减少了。
这本身未必是坏事。一个产品完全可以成为高价值的后台基础设施。但它的商业基础会变化：过去按人头出售操作界面，未来可能更多依赖资产管理、协作权限、调用能力和组织级服务来收费。
所以，判断应用公司是否安全，只看「有没有接入 AI」远远不够。还要看接入以后，谁保留了用户关系，谁掌握正式资产，谁有能力决定整个任务使用哪些工具。
模型可以生成页面，但正式版本由谁说了算？ 🍅
「模型越强，应用越不值钱」听起来顺畅，却忽略了企业软件的重要职责：让多人在时间推移中，对同一件事保持一致。
一个模型可以生成十个漂亮页面，但团队仍然需要回答：哪一版经过批准？使用的是不是当前组件？这次调整会影响哪些页面？开发人员应当实现哪个状态？出了问题，谁能追溯当时的决定？
这些问题关乎共同工作的可靠性。生成能力会降低制作成本，却不会自动消除协调成本。
对 Figma 这样的产品，我认为更有价值的防线，是让自己成为设计资产、团队决策与工程实现之间可信的连接点。它可以开放给不同模型调用，同时维持组件、版本、权限和交付状态的一致性。
这也不是永久安全区。Claude Design 已经触及团队设计系统和协作，模型厂商同样会继续补齐这些能力。应用公司必须持续证明：经过自己的系统，工作更可靠、更容易修改和交接，代价也更低。
这里还有一个经常被忽略的反向效应：原型便宜之后，人们可能尝试更多产品。过去根本不会启动的项目，现在可以先做出来，其中一部分最终需要专业设计和团队协作。
因此，Figma 的未来不能只用「被替代多少」来判断，还要看新增需求能带来多少回流。我的判断是，接下来更可能出现的是任务重新分配：简单任务在通用工作台里结束，复杂项目在通用 AI 与专业系统之间往返。比例会随着能力、价格和团队习惯继续变化。
真正值得保留的，是带着经验离开的能力 🍅
回到 Karp 的担忧。对企业来说，仅仅问「我的数据会不会被用于训练」，已经不够了。还应该问：如果明天更换模型供应商，我们今天积累的工作经验还能不能继续使用？
有些经验写在文档里，有些藏在聊天记录里，还有些体现在一次次人工纠错中。供应商没有把它们训练进模型，并不意味着企业自己已经掌握了这些经验。如果它们只能在某个平台的专有项目、记忆或工作流里发挥作用，更换平台时依然可能付出很高成本。
对技术团队而言，这意味着应该把关键业务规则、评估样例、经批准的知识和成功流程，沉淀为自己可管理、可导出、可验证的资产。换一个模型后，仍然能检查答案是否正确、行动是否合规、交付是否达标，才算真正拥有迁移的基础。
换模型也绝不只是改一个 API 地址。工具调用、上下文组织、输出格式和失败模式都可能不同，需要重新评估和适配。可迁移性是一项需要投资的工程能力。
对应用公司，道理类似。一个有用的自测是：如果底层模型明天更强、更便宜，自己的价值会增加，还是减少？
如果产品主要靠弥补模型暂时的短板收费，它就需要不断寻找新的价值来源。如果产品掌握真实业务反馈，能够处理复杂协作、验证结果并完成可靠交付，更强的模型反而可能扩大它能解决的问题。
微软 Office 的历史说明，优秀的单点功能未必能抵挡竞争单位的变化。今天，模型厂商正在把自己的角色从「提供智能」扩展到「组织工作」。应用公司必须重新回答：自己在整件工作中，究竟承担哪一部分不可轻易省略的责任？
Karp 的愤怒让数据归属成为焦点。更长远的问题，是工作完成之后，知识、关系和下一次决策权留在哪里。
当生成第一稿越来越便宜，值得付费的理由，会越来越多地落在后面：谁能把它变成团队信任、持续使用并愿意负责的最终结果。
In September 2026, a CNBC interview put an unflattering question about enterprise AI on the table: can the intelligence you pay for eventually weaken your own competitive edge?
The person asking it was Palantir co-founder and CEO Alex Karp. According to the interview, he accused model vendors of absorbing companies’ data, operating knowledge, and distinctive experience, so that a customer’s advantage flows into models that competitors can also use. He even read cheap tokens as a way to obtain enterprise intellectual property. What follows restates his accusation; it is not an independently verified fact. (interview excerpts)
Karp’s language is fierce, but he touched a real commercial tension: companies want model vendors to supply capability, yet they do not necessarily want those vendors to own the customer relationship, the workflow, or the final pricing power of the business.
It is easy to hear this as a story about big labs taking customer data and cloning customer businesses. Similar competitive pressure can appear even if no data abuse happens at all.
Watch how ChatGPT and Claude have moved from chat boxes toward workbenches, then look at where Figma sits, and the point becomes clearer. An earlier clue is still sitting in the office-software market of more than thirty years ago.
Data not entering training does not mean the business is safe 🍅
First, separate three actions that are often mixed together: a model reading material to complete a task; a vendor storing that material; a vendor using that material to train a general model. They are not equivalent. Putting a design document into context does not mean the model weights were updated, and it certainly does not imply that other customers can read the document.
As of this writing, both OpenAI and Anthropic state that customer data from relevant enterprise or commercial products and APIs is not used to train models by default; explicit opt-in, feedback, and similar cases are treated separately. Karp’s interview alone is not enough to claim that these vendors are generally training on customer data in secret. (OpenAI business data privacy, Anthropic commercial data usage)
But “we do not train on your data” and “we will not enter your market” are two different promises.
A model vendor does not need a design firm’s secrets to know that users want to generate a web page quickly. It does not need the source code of an office suite to know that users want to turn a report into a deck. Public demand, general capability, and a good enough product experience are already enough to enter those markets.
That is the part of the argument worth more attention: the risk companies face includes knowledge leakage, and it also includes a supplier competing for the same user, the same budget, and the same hours of work. The first needs data governance. The second needs a fresh look at where the product sits. Solving the first leaves the second intact.
Figma’s pressure starts with where the first draft is made 🍅
Start with the product names. OpenAI’s Canvas was first positioned around writing and coding collaboration. Anthropic’s Artifacts put code, documents, web designs, and other outputs into a separate workspace. Neither is a full professional design tool. Together they changed one thing: users can create and revise work in the same place they talk to the AI. (Canvas announcement, Artifacts announcement)
In April 2026, Anthropic launched Claude Design, moving explicitly into prototypes, visual design, and presentations, with design-system import, detailed revision, and handoff to Claude Code. That is more than adding a preview pane to a chatbot. It tries to own the continuous path from idea to usable artifact. (Claude Design announcement)
Imagine a product manager who needs to test a new feature.
She might once have gathered requirements, asked a designer to draw screens and wire interactions in Figma, and only then taken a prototype into discussion. Now she can describe the goal to an AI, get a clickable version, adjust it on the spot, and then decide whether a full design process is worth starting.
This is a scene for explaining a competitive mechanism, not a description of how every team actually works. It does show the key difference: AI does not have to beat Figma across professional design capability in order to take on some of the work that used to flow into Figma.
For a need like “help everyone understand this idea before the afternoon meeting,” users often score speed, communicative effect, and startup cost. Fine-grained component management and complex collaboration are not necessarily decisive in that moment.
So I think the first squeeze will fall on sketches and prototypes with relatively limited requirements and short delivery cycles. The deeper effect is this: whoever generates the first draft has a chance to own the revisions that follow.
The user has already explained the need, supplied material, and rejected two directions inside the AI workbench. When she wants a third version, staying put is usually easier than restating the background in another tool. That advantage comes from continuous context. It does not require stolen training data.
Still, owning the first-draft entrance does not automatically mean owning final control. Formal delivery still involves consistency, edge cases, team review, and engineering constraints. Figma’s opening is to make that later work worth coming back for.
The history of Microsoft Office: the unit of competition changed 🍅
This recalls the rise of Microsoft Office. The history has to be told accurately: PowerPoint was not created from scratch by Microsoft. It was first developed by Forethought, released on the Macintosh in 1987, and entered Microsoft the same year through acquisition. (Computer History Museum archive)
In 1989, Microsoft shipped Office for Macintosh, bundling Word, Excel, PowerPoint, and Mail. It entered a market that already had strong standalone products. Microsoft’s own historical record notes that year’s Excel campaign aimed at Lotus 1-2-3 users. (Microsoft history, 1989)
The word-processing market is especially sharp. The Computer History Museum records that WordPerfect dominated DOS in the 1980s, while Word for Windows, launched in 1989, rose quickly. Data cited by the museum indicate that by 1997 Word had about 90 percent of word-processing market revenue. That is a revenue share, not a user share. (Word history)
Reducing all of this to “Microsoft bundled, so everyone else lost” leaves out the shift to graphical interfaces, product quality, and execution. Office is also not a synonym for software given away free with Windows. The lesson worth borrowing is the change in the unit of competition.
When programs were sold separately, users compared word processors, spreadsheets, and presentation tools one by one. After suites spread, companies also began comparing the cost of buying the set, training staff, exchanging files, and getting support.
A standalone tool could still be better at one job and still have to answer a harder question: if the existing suite is enough to finish the work, why buy you as well?
AI workbenches may produce a similar shift. If someone already pays for a general AI service, and that service includes basic prototyping, documents, or decks, a specialist tool has to explain the value of paying extra. The cost is not only the subscription. It also includes opening another tool, restating context, moving files, and learning another interface.
Office put several tools into one suite. An AI workbench can go further and collapse steps that several tools used to own into a single task.
That is an important difference between the two generations of competition. Office users usually still had to organize work themselves across Word, Excel, and PowerPoint. An AI workbench tries to let the user say only “turn this analysis into something I can present,” and then choose and run the intermediate steps. Today’s AI cannot reliably finish every such task. The direction of competition has already changed.
Partnership does not cancel competition; it complicates it 🍅
Figma has not waited for the change to arrive.
Figma Make, released in 2025, already combined natural-language generation with interactive prototypes, and launched on Claude 3.7 Sonnet. In February 2026, OpenAI and Figma announced a deeper partnership so that Codex and Figma can move code and editable designs back and forth. (Figma Make announcement, OpenAI–Figma partnership)
That means the same model vendor can be a capability supplier, a distribution partner, and a potential competitor at once. Those roles do not cancel one another.
From Figma’s position, bringing in models can make the product more useful. Connecting AI agents can also put existing design assets into more workflows. At the same time, some users may grow used to starting work in an AI workbench and calling Figma only when they need it.
That is a possibility worth watching: usage of Figma’s capabilities rises, while the frequency of users opening Figma itself falls.
That is not automatically bad. A product can become valuable back-end infrastructure. Its commercial base would still change: selling a human interface per seat gives way to charging more for asset management, collaboration permissions, invocation, and organization-level services.
So it is not enough to ask whether an application company has “added AI.” After the integration, who keeps the user relationship, who holds the official assets, and who can decide which tools a whole task uses?
A model can generate screens. Who decides the official version? 🍅
“Stronger models make applications worthless” sounds smooth, and it ignores a central job of enterprise software: keeping many people consistent about the same thing as time passes.
A model can generate ten handsome pages. A team still has to answer: which version was approved? Are we on the current components? Which other screens does this change touch? Which state should engineering implement? If something breaks, who can reconstruct the decision?
Those questions are about the reliability of shared work. Generation lowers the cost of making things. It does not automatically erase the cost of coordination.
For a product like Figma, I think the more valuable defense is to become a trusted joint between design assets, team decisions, and engineering delivery. It can stay open to many models while keeping components, versions, permissions, and shipping state consistent.
That is not a permanent safe zone. Claude Design already reaches team design systems and collaboration, and model vendors will keep filling in those capabilities. Application companies have to keep proving that work passing through their system is more reliable, easier to revise and hand off, and cheaper in the ways that matter.
There is also a reverse effect that is easy to miss. Once prototypes are cheap, people may try more products. Projects that would never have started can now be made first, and some of them will later need professional design and team collaboration.
So Figma’s future cannot be judged only by “how much gets substituted.” It also depends on how much new demand flows back. My read is that the nearer outcome is a reallocation of tasks: simple work ends inside a general workbench; complex projects travel between general AI and specialist systems. The mix will keep shifting with capability, price, and team habit.
What is worth keeping is the ability to leave with the experience 🍅
Return to Karp’s worry. For a company, asking only “will my data be used for training” is no longer enough. It should also ask: if we change model vendors tomorrow, can the working experience we have accumulated still be used?
Some of that experience lives in documents, some in chat logs, and some in round after round of human correction. If a vendor has not trained those things into a model, that does not mean the company itself already owns them. If they only work inside a platform’s proprietary projects, memory, or workflows, switching platforms can still be expensive.
For technical teams, that means key business rules, evaluation examples, approved knowledge, and successful procedures should be stored as assets the company can manage, export, and verify. After a model change, if you can still check whether answers are right, actions are compliant, and deliveries meet the bar, you have a real basis for migration.
Switching models is also never just changing an API endpoint. Tool calls, context assembly, output formats, and failure modes can all differ, and they need re-evaluation and adaptation. Portability is an engineering capability that has to be paid for.
The same logic applies to application companies. A useful self-test: if the underlying model becomes stronger and cheaper tomorrow, does our value go up or down?
If the product mostly charges for covering a model’s temporary gaps, it will have to keep finding new sources of value. If it holds real business feedback, can handle complex collaboration, verify results, and complete reliable delivery, a stronger model may expand the problems it can solve.
The history of Microsoft Office shows that excellent point features may not survive a change in the unit of competition. Today, model vendors are stretching their role from supplying intelligence to organizing work. Application companies have to answer again: in the whole job, which part of the responsibility cannot be cheaply skipped?
Karp’s anger put data ownership at the center. The longer question is where knowledge, relationships, and the next decision sit after the work is done.
As first drafts get cheaper to generate, the reasons to pay will fall more and more on what comes after: who can turn that draft into a final result a team trusts, keeps using, and is willing to be responsible for.
