面向受监管企业的自动化运维平台，让它们在没有专业基础设施团队的情况下运行境内部署的专用 AI 集群。

1. Dapple 在 2026 年 6 月完成 $30M 种子轮，说明机构投资人已经验证了专用、境内部署企业 AI 基础设施这个市场，需求浪潮就是现在开始。
2. 企业已经明确拒绝把 AI 工作负载继续放在共享型超大规模云里，这给共享云厂商从未真正搭建过的运维工具层腾出了空间。
3. Dapple 把自己称为“AI 基础设施的操作系统”，等于点破了真正没被解决的痛点：资源开通、策略管理和生命周期运维。这一层在硬件之上，也不是硬件厂商擅长补的。
4. 境内部署要求正在全球收紧（GDPR 执法、India PDPB、Saudi PDPL），让受监管企业成了专用 AI 基础设施增长最快、也最急着买合规自动化工具的一群买家。

催化因素。 Dapple 的 $30M 种子轮确认，专用、境内部署 AI 基础设施的市场现在就开始打开了。企业在共享云合规上已经撞墙，于是对硬件之上的自动化层立刻有了需求。

一个 SaaS + agent 平台，自动化覆盖专用、境内部署 AI 集群的全生命周期：基于经批准的硬件配置一键开通；按 GDPR、PDPA、PDPB、PDPL 和行业专属框架持续扫描合规；生成可供监管审查的不可变审计日志；再用声明式策略引擎在工作负载层强制执行数据驻留约束。产品接入现有 SSO 和 SIEM 工具，并给 CISO 与外部审计方提供实时合规看板。与 Dapple 不同，这个平台不绑定基础设施：无论是厂商提供、机房托管，还是本地自建的专用硬件，都能跑在上面，从而避开厂商锁定，守住纯软件毛利。

差异化。 Dapple 把硬件和 OS 打包成专用云卖，而这个产品是厂商中立的软件层，直接叠在任何专用 GPU 硬件之上。对已经在机房托管或本地跑集群的客户来说，不用换硬件供应商就能接入。它从合规优先出发，抓住了纯基础设施厂商很难彻底解决的买方痛点——监管审计风险，因此能跑出软件毛利模型，而不是变成重资本硬件生意。自动化证明引擎还能把今天需要顾问忙上数周的工作，压缩成一个持续、可审计、单看板可见的工作流，直接给 CISO 和监管方看结果。

待完成任务

flowchart LR
  Regulator[Regulator / Auditor] -->|Exam finding or mandate| Bank[Regulated Enterprise]
  Bank -->|Procures dedicated GPU cluster| Cluster[On-Prem / Colo GPU Cluster]
  Cluster -->|Managed by| Platform[Sovereign Cluster Autopilot]
  Platform -->|Provisions and hardens| Cluster
  Platform -->|Continuous compliance scan| Dashboard[Compliance Dashboard]
  Dashboard -->|Attestation report| Bank
  Dashboard -->|Audit evidence| Regulator

高管要点

• 基础设施这一层已经很拥挤，但专用 AI 集群之上的合规证明层，产品化程度仍然不高。
• 最佳滩头市场，是那些监管已经在严查云外包和 AI 治理的地方；这里真正触发预算的不是 GPU 访问权，而是证据产出。
• 现有厂商赢在算力和区域覆盖；而提议中的切口能赢，前提是它成为现有私有集群上最快拿到可审计、厂商中立、策略合规证明的路径。

市场定义

面向受监管企业的专用、境内部署 AI 集群软件控制平面：在私有 GPU 基础设施之上提供资源开通、策略执行、审计证据和持续合规。

用户与买方

主要用户是 AI 平台或基础设施负责人；一旦审计暴露或外包风险让主权控制变得紧迫，真正拍板的经济买方通常是 CISO 或基础设施负责人。

购买触发点

• ECB / DORA 式的云外包审查，会把监控、可审计性和退出计划上的缺口，直接变成重要银行有预算的整改项目。 [2][5]
• AI 已经嵌进银行日常运营，所以治理预算越来越不是花在沙盒实验，而是花在如何管住已经上线的生产系统。 [4][10]
• 数据驻留和主权要求，正在变成公有云和主权云采购里的显性标准，迫使买方转向那些既有本地控制、又留得下证据轨迹的架构。 [13][17][18][20][26]

支付意愿

只要买方本来就在承担咨询、审计和第三方风险成本，预算就很可能存在。相对多年的私有云投入，如果一层六位数年费的软件能显著缩短证据收集时间、降低合规人力，定价是站得住的。 [2][11][16]

品类动态

增长信号 高双位数扩张阶段（方向性判断，依据调查，不是基于厂商中立 CAGR 数据）

验证信号

• Dapple 的种子轮融资以及其企业生产客户的表述，验证了专用 AI 环境存在真实在线需求。
• EBA 指出，AI、云、钱包、大数据分析和生物识别已经广泛进入 EU 银行业，而且多数银行整合这些技术已超过 5 年。
• CSA 在 2026 年金融服务调查里称，62% 的机构已经部署 AI agent，85% 预计自治 AI 驱动的金融交易会快速增长。
• 香港监管方在最新月报里列出 175 家授权机构，说明单一滩头市场里就有很高密度的受监管买方。

监管与技术约束

• 金融行业买方必须持续监控和审计外包云服务，而不是只在采购阶段批准一次。
• 数据保护和 AI 治理义务要求合法处理、留存文档化控制，并能解释敏感数据和模型是如何被处理的。
• 沙特等 GCC 本地化制度会带来显著实施差异，无法靠一套全球模板抽象掉。
• 可行产品必须把 policy-as-code、infrastructure-as-code、运行时检测和访问控制证据串到异构环境里。

基础设施层的竞争已经拥挤，但跨厂商、审计就绪的控制层竞争相对更薄。大多数替代方案卖的是主权算力、通用私有 AI 平台，或需要大量咨询实施的 DIY 栈，而不是一个厂商中立的合规证明产品。

为什么现有厂商不会默认胜出

• 云平台. 它们的主权控制能力很强，但大多局限在自家区域、密钥管理和运维边界内，而不是覆盖客户已经存在的混合硬件环境。
• 私有 AI 平台. 它们能简化本地模型部署，但通常还做不到按监管方要求交付证据工作流，也缺少逐个辖区映射控制项的能力。
• 专属区域方案. 它们解决的是主权算力采购，但也会把买方推向单一厂商足迹，且无法自动把既有集群变成审计就绪环境。
• 内部开源栈. DIY 的 Terraform 加策略与运行时工具仍然灵活，但银行仍得自己把控制、证据和漂移监控一条条缝起来。

Sovereign Cluster Autopilot 应该以厂商中立的合规控制平面切入，服务那些已经部署或正在采购专用 AI 基础设施的受监管银行，而不是再做一个私有 AI 平台或托管 GPU 云。首个客户应是一家 EU 二线银行：已经有本地或机房托管 GPU 集群，手上有活跃的审计或监管发现，但还没有持续证明 AI 工作负载在驻留、访问和策略层面合规的办法。产品切口是一套一天内完成加固和证据产出的工作流，把现有集群变成审计就绪环境，并持续输出合规证明、证据链路和可导出报告，供安全与合规团队使用。研究支持这个痛点触发点，因为云外包、运营韧性和 AI 治理审查，已经让证据产出变成银行内部有预算支持的整改项目。公司在启动阶段应明确避开算力、模型托管或泛 MLOps 编排——这些预算已经被现有厂商占住，真正更锋利的预算触发点，是正在推进中的基础设施需要做合规整改。最大的战略下注在于：目标银行里，已经有足够多的私有 AI 容量或近期集群项目，足以支撑一个软件附着式打法。最大的反证风险不是产品做不出来，而是市场是否就绪：如果真正上线集群的银行太少，或者厂商原生的主权方案已经“够用”，这个切口会很快被压扁。这是个可信的 pre-seed 机会，ACV 做到六位数有现实基础，但在 EU 银行业务之外扩张之前，公司必须先证明附着率、试点转正式，以及辖区包复用能力。

问题

• 采用专用基础设施跑 AI 的受监管银行，今天仍要把 Terraform、策略工具、SIEM 日志、顾问工作底稿和电子表格拼在一起，才能证明数据驻留、访问控制和运行时合规。
• 这种碎片化工作流会把每一次审计、监管复核或新工作负载上线，都拖成一个缓慢的整改项目——哪怕底层集群早就已经存在。

解决方案

• 提供一个厂商中立的控制平面：先把集群基线加固，再持续把运行时状态对照辖区和行业策略检查，最后输出审计方能直接阅读的证据包。
• 接入银行现有的身份、SIEM、Kubernetes 和基础设施自动化栈，让银行不用更换硬件供应商、也不用迁移工作负载，就能把现在的私有集群变成审计就绪环境。

为什么我们会赢

• 公司瞄准的是基础设施采购之上的那个有预算的痛点：客户集群已经买了，或者正在买，真正缺的是怎么持续证明它合规。
• 护城河会随着辖区专属控制包、跨审计周期积累的证据链路，以及可信集成能力一起加深；这些都比单纯的 policy-as-code 更难复制。

里程碑

flowchart LR
  Wedge[Bank compliance wedge] --> MVP[Audit-ready cluster MVP]
  MVP --> Proof[Faster evidence and production proof]
  Proof --> Expansion[More clusters, more jurisdictions, more verticals]

创始团队

实验路线图

风险评估

必须成立的条件

• 至少一半的合格目标银行，必须已经上线或将在未来 12 个月内启动有预算的专用 AI 集群项目。
• 一个付费试点，必须把审计证据准备时间相对客户当前手工流程压缩至少 50%。
• 至少 50% 的付费试点，必须能转成每集群 ARR 高于 $80k 的正式订阅。
• 一套 EU 银行业控制库，必须能在至少 3 个银行账户里复用，而不需要定制重建。
• 至少一个附着式伙伴渠道，必须在第 12 个月前比创始人主动外拓更快地产出合格试点。

待尽调问题

• 目标银行里，到底有多少已经在运行或明确采购私有 AI 集群，而不是继续依赖超大规模云厂商的推理服务？
• 最能触发预算的审计证据到底是什么：驻留证明、访问日志、整改工作流，还是外包控制？
• 什么样的证据格式和复核流程，才能让合规团队愿意信自动化，而不是继续依赖顾问和电子表格？
• 为什么银行要买这一层，而不是继续扩展 Azure、Oracle、Nutanix、Red Hat，或自己的内部 DevSecOps 栈？
• OEM、机房托管或咨询伙伴，能否加速分发，同时又不把公司拖进低毛利的定制交付？

模型合理性

• 收入引擎. 基础情景的核心，是把由合规触发的试点转成每年约 $120K 的正式账户，并从 Y2 退出时的 18 个客户继续复利到 Q4Y3 的 35 个。
• 必须做对的事. 产品必须足够产品化，才能守住 70% 毛利率；同时在首批正式案例出来后，至少有一条附着式或咨询渠道，能稳定缩短银行销售周期。
• 模型会失效，如果. 如果真正拥有可接入私有集群的银行太少，而定制集成又把毛利率拖向 65%，下行情景会把现金压到接近过桥融资区间。
• 下一轮验证点. Y2 结束时做到 18 个正式客户、1 个可复用的 APAC 辖区包，以及 1 条有效伙伴渠道，是最清晰的 seed 轮跳升里程碑。

情景

敏感性

flowchart LR
  Audits[Audit and remediation triggers] --> Pilots[Paid pilot and hardening motion]
  Pilots --> Customers[Production bank subscriptions]
  Customers --> Clusters[1.2 managed clusters per bank]
  Clusters --> Revenue[Subscription revenue]
  Revenue --> GrossProfit[70% gross profit]
  GrossProfit --> Cash[Cash and runway]

警示项: 基础情景仍假设客户数会从 Y2 退出时的 18 个快速跳到 Y3 退出时的 35 个，因此伙伴可信度和辖区包复用必须按计划到位。 · 模型有意排除了试点和 onboarding 收入，这让早期结果更保守，但如果试点在转正式前就能顺利变现，也可能低估商业牵引。 · 只有当实施范围足够收窄、可复用时，毛利率才能守住；如果安全或监管映射工作高度定制化，公司就会滑向重服务业务。

• 监管碎片化. EU、APAC 和中东的合规要求差异很大，法规一边演化一边分化，框架维护会变得昂贵又容易出错。 缓解措施: 把框架库做成模块化结构，引入社区和伙伴共建，并在每个目标司法辖区接入本地监管顾问，持续验证和维护映射。
• 硬件厂商打包销售. Dapple 或超大规模云厂商完全可能把原生合规证明工具打进自己的专用云方案里，压缩独立产品的可服务市场。 缓解措施: 把重点放在厂商中立的多供应商支持，以及打得更深的监管框架细节上——这些都不是厂商打包工具的优先级；同时尽早拿下锚点客户。
• 企业销售周期过长. 受监管企业买方的采购周期往往有 9–18 个月，前期营收增长会很难，现金跑道压力也会被明显拉长。 缓解措施: 提供 30 天免费合规缺口审计，作为付费试点入口；优先瞄准已经有审计发现或监管检查的客户，压缩决策时间线。