给家政服务平台用的同意控制平面，用来批准、限制并审计 Physical AI 试点中的家庭数据使用。

1. 对家政服务 App 来说，Physical AI 数据请求已经不是纸上谈兵。
2. 真正的运营分界线，在于试点会不会从受控培训场景跨进客户家里。
3. 和 DPDP 相关的不确定性，让同意、标注和商业化决策不再是后台整理，而是眼前急事。
4. 哪怕只是一场不透明的合作讨论，也足以把平台推入必须公开澄清的信任危机。

催化因素。 Snabbit-Human Archive 这次事件说明，具身 AI 的数据请求已经真的到了，和 DPDP 相关的同意问题也足以把一场合作讨论迅速推成平台级风险。

做一套面向家政服务中 Physical AI 数据合作的同意控制平面。产品先从工作流切入：把每一条外部数据请求都收进来，按预设政策模板流转，为服务人员和住户生成角色化的同意材料，并把哪些获批、哪些被拒、哪些受限完整记账。系统维护一份可审计的权利台账，覆盖采集场景、标注权限、允许的模型用途、留存窗口和跨境传输限制。第一版产品不做通用隐私套件，它只解决高风险入户录制提案里的快速决策和留证。

差异化。 现有隐私工具是围着网站、App 和企业内部数据治理设计的，它们不处理“谁可以在家庭空间里录”“按什么脚本录”“对应哪些下游模型权利”这类运营决策。这个产品是围着平台与合作方的审批流程做的，不是通用 Cookie 同意，也不是企业 GRC。真正能守住的资产，是在敏感消费者场景里关于现实世界 AI 数据权利的政策图谱和审计证据。

待完成任务

flowchart LR
  Buyer[家政服务平台运营与法务] --> Pain[入户 AI 数据试点审批既慢又不安全]
  Pain --> Product[面向数据范围、权利和审计证据的同意轨道]
  Product --> Outcome[在可证明的家庭数据边界内更快推进合作]

高管要点

• 这个切口是真实存在的：Physical AI 实验室已经在向印度家政服务平台索要家庭任务数据，平台也被迫公开解释自己的边界。
• 滩头市场不大，但足够紧：一小批集中在大城市、又极其在意品牌的头部平台，只要碰上一次不透明试点，就会放大成信任、法务和公关风险。
• 通用隐私巨头已经证明，买方愿意为同意、评估和审计工作流买单；但它们不是围着“住户与服务人员双重同意、标注权、以及家庭场景里的下游模型用途审批”来设计的。
• 能不能长成风险投资级公司，取决于能否把同一条权利与审批轨道，扩到养老、住宅安防、酒店和现场服务等相邻私密场景，而不是假设家政服务本身就够大。

市场定义

这是面向家庭及其他私密服务环境中 Physical AI 数据采集的审批、约束与留证工作流软件。第一版产品比通用隐私软件更窄：它卡在平台收到厂商关于视频、远程操控、标注或模型训练权请求的那个时点，把请求变成一项受治理、可审计的决策。

用户与买方

核心用户是印度家政服务平台里的运营、法务、信任安全和合作团队，他们正在评估高风险数据试点。经济买方通常是运营负责人、首席法务官或信任负责人，因为他们要对品牌风险、政策执行和试点周转时间负责。

购买触发点

• 合作方要求采集或复用入户视频、服务人员视频或远程操控数据来训练 AI，平台就再也没法回避目的限定和下游使用权的问题。 [1][2][3][5]
• 行业头部平台本来就已经做到数百万订单和数百万用户规模，所以任何围绕家庭录制的信任事故，都会从试点问题升级成品牌事件。 [8][10][11][13][14][17]
• 劳动力短缺、密集竞争和高现金消耗，让买方更愿意为“可控试验”付费，而不是继续靠临时法务回路或不确定的一刀切。 [11][12][13][17]

支付意愿

现有厂商的公开定位已经说明，买方本来就在为隐私运营、同意编排、评估流程和审计轨迹编预算：OneTrust、TrustArc、DataGrail、Transcend 和 BigID 都在卖围绕证据、权限或风险工作流的自动化；TrustArc 与 MineOS 还明确把自己的产品和“表格驱动的评估流程”作对比。这说明，只要这条更窄的轨道能缩短高风险试点审批时间、降低信任或合规暴露，预算就有机会切出来。 [19][22][23][24][26][27][28][38]

品类动态

增长信号 18-22% CAGR through FY30

验证信号

• Pronto 曾公开承认做过一项有限 opt-in 试点，使用朝外摄像头，并把它与 AI 相关数据计划挂钩。
• Snabbit 确认自己与 Human Archive 做过探索性讨论和受控环境评估，但对客户家中落地画下了硬红线。
• 头部即时家政平台本来就已经在处理数百万订单、服务数百万用户，所以治理软件不是落在想象中的流量上，而是真实运营规模。
• Pronto 和 Snabbit 都已经公开写出正式隐私条款，说明这个赛道已经成熟到需要把专门的同意轨道做成运营系统。

监管与技术约束

• 当同意是合法性基础时，同意必须是自由给出的、具体的、知情的、无条件的、明确无歧义的，而且撤回必须和给予一样容易。
• 重要数据受托人可能被要求任命 DPO、指定审计师，并定期开展 DPIA 与审计。
• 儿童数据处理受到更严格约束，包括对追踪、行为监测和定向广告的限制。
• 即便机器人行业专门规则还不成熟，全球隐私指引也越来越把高风险 AI 处理视作需要 DPIA 级问责的治理事项。

竞争大致分成五类：广义隐私自动化套件、评估与同意平台、数据使用权限轨道、隐私运营自动化，以及数据安全/AI 治理平台。这些现有厂商证明了预算存在，但它们的起点是网站、SaaS 系统和企业数据资产，而不是客户家里的多方授权。

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

• 隐私自动化套件. OneTrust 已经覆盖隐私运营、评估、同意和 AI 治理，但它的重心仍是广义企业合规，不是围绕家庭录制试点里的厂商接入审批。
• 评估与同意平台. TrustArc 是最贴近的相邻巨头，因为它已经卖 PIA、DPIA、AI 风险和同意工作流；但它的产品语言仍然围着数字渠道和隐私项目管理，不是专门给家政服务合作审批做的。
• 数据使用权限轨道. Transcend 在“把权限编码进客户数据系统”这件事上很强，但这个新公司只有在先拿下离线决策层——也就是数据还没被录下来之前——才有胜算。
• 隐私运营自动化. DataGrail 证明了集成式隐私工作流和审计能力有需求，但它的重心仍是 SaaS 系统与 DSR，不是建模“住户-服务人员-厂商”三方权利。
• 数据安全与 AI 治理平台. BigID 证明企业愿意为 AI 治理和跨境控制买单，但它从“数据采集后怎么发现和保护”开始，而不是先判断一个敏感试点到底该不该放行。

Household Data Consent Rail 是一款很窄但很硬的工作流产品，面向那些已经开始收到厂商请求——想拿入户视频、服务人员视频、远程操控数据或下游 AI 训练权——的印度家政服务平台。真正的痛点不是泛化的隐私合规，而是在任何录制发生之前，先决定什么能采、谁必须同意、允许哪些标注与模型使用权，以及平台之后怎么把这些边界证明清楚。研究里的触发信号是真实的：Pronto 和 Snabbit 都说明，哪怕只是探索性的 Physical AI 数据讨论，也足以把有一定订单体量的消费品牌推成公开信任事件。公司应该先拿下一个单点滩头：那些品牌显眼、正和合作方谈真实项目、且运营规模足够大到“一次不透明试点就会惊动法务、公关和董事会”的印度即时家政平台。第一版产品应该是一套从录入到决策的控制平面，带政策模板、住户与服务人员双重同意材料、权利台账和高管签字，而不是大而全的隐私套件，也不是采集后数据目录。GTM 要由创始人亲自带，按事件触发：平台一收到真实请求，就卖一个付费试点；等所有高风险合作请求都开始走系统，再转成年约；然后按城市、试点类型和相邻私密场景行业往外扩。市场证据支持一个可信但偏窄的软件切口：研究给出的 SAM 约 $6.0M，第 3 年 SOM 约 $1.8M，所以要有真正的风险投资上行，就必须证明这套工作流能复用到养老、住宅安防、酒店或现场服务。当前最缺的证据，是头部平台每季度到底会收到多少这类请求，以及买方究竟会为软件买单，还是仍然只愿意付律师费；因此这些点现在仍应被当作明确的运营假设，而不是既成事实。

问题

• 家政服务平台正在收到 Physical AI 与数据采集请求，但它们还没有一套产品化机制，去批准、限制或拒绝入户录制、标注、传输与商业化权利。
• 现在的替代方案——NDA、外部律师、邮件线程、表格，或者一刀切禁录——既慢、难审计，又会在家庭录制变成公众信任议题时暴露出脆弱性。

解决方案

• 提供一套合作方接入与同意治理工作流，让每一条高风险数据请求都必须经过结构化界定：采集场景、必须同意的角色、地点限制、标注权、留存窗口、下游模型用途和传输限制。
• 为住户、服务人员、厂商与高管生成可审计的批准或拒绝材料，并维护一份权利台账，清楚记录哪些被批准、哪些受限、哪些被撤回、哪些被拒绝。

为什么我们会赢

• 现有隐私套件已经证明，买方愿意为同意、评估和审计轨迹买单；但它们是为网站、SaaS 系统和企业数据资产优化的，不是为家庭录制试点的采集前审批优化的。
• 如果公司能成为“哪些试点被批、哪些被拒”的记录系统，就能逐步长出一张围绕双重同意、标注和下游用途边界的专有政策图谱，而律师、表格和通用工具都很难把这些数据沉下来。

里程碑

flowchart LR
  Wedge[家政服务同意切口] --> MVP[录入与权利台账 MVP]
  MVP --> Proof[更快、更受治理的试点决策]
  Proof --> Expansion[多城市与相邻行业扩张]

创始团队

实验路线图

风险评估

必须成立的条件

• 前 10 个目标平台里，至少有 5 家每季度会收到 2 条以上相关厂商请求。
• 买方愿意在一次真实请求周期里为付费试点拨款，而不只是去找外部律师。
• 产品能把“请求到决策”的时间至少砍掉 50%，同时保住可审计的同意与权利记录。
• 至少有 1 个试点能转成位于研究 $100k-150k 区间内的年度合同。
• 至少有 1 个相邻行业无需大改产品，就能复用大部分核心工作流。

待尽调问题

• 今天每家头部平台每季度到底会审多少第三方 AI 数据或录制请求？
• 触发出现时，预算究竟归运营、法务、信任，还是合作团队？
• 在不把试点参与率打掉的前提下，住户与服务人员同意能复杂到什么程度？
• 首个部署必须打通哪些现有系统，才能避免掉进重定制服务陷阱？
• TrustArc、OneTrust 或“外部律师工作流”要多快就能把早期切口中和掉？

模型合理性

• 收入引擎. 基准情景收入来自付费部署从 Y1 末的 3 个增至 Q4Y3 的 12 个，同时随着试点转成年化、按城市计费的订阅，ARPU 也持续上升。
• 必须跑对的事. 公司必须把 真实请求 的紧迫性转成约 6 个月的“试点到正式生产”周期，否则第一位销售只会被定制化实施拖住，带不来新增部署。
• 模型会失效的情况. 如果部署停在约 9 个，且毛利率始终上不去 70%，在证明下一轮融资所需指标前，悲观情景下现金可能掉到约 $520K。
• 下一轮证明点. 一个可信的种子轮故事，是在 Y2 末做到 7 个付费部署、覆盖约 4-6 个客户品牌、再加一个相邻行业试点，并看清毛利率冲到 70%+ 的路径。

情景

敏感性

flowchart LR
  LiveRequests[Live Requests] --> PaidDeployments[付费部署]
  PaidDeployments --> AnnualSubscriptions[年度订阅]
  AnnualSubscriptions --> GrossProfit[毛利润]
  GrossProfit --> OperatingCash[经营现金]

警示项: 按退出时点 FTE 算的人均收入仍略低于顶级 SaaS 基准，因此模型必须依赖在现有客户内部按城市扩张，才能把招聘效率守住。 · 业务仍暴露在少数事件触发型买方之下；如果请求量长期零散，模型就高估了持续性软件需求。 · 只有当交付从分析师重投入转向可复用模板和集成后，毛利率才真正越过 70% 目标。 · 这次融资假设公司能在相邻行业证据尚未完全跑出来前，就拿到 pre-seed 区间下限。

• 初始市场过窄. 短期内，真正会评估 Physical AI 数据试点的家政服务平台可能仍是个很小的人群。 缓解措施: 先盯住最活跃的印度即时服务玩家，再把同一套工作流扩到养老、安防和现场服务等相邻行业。
• 合规买方对新软件持怀疑态度. 法务团队可能更愿意找外部律师、继续手工审，而不是为一个新类别采购软件。 缓解措施: 把产品定位成给律师做证据自动化的补位工具，靠更快的试点评审流程和清晰的审计输出打动买方。
• 平台可能直接全面禁录. 部分市场平台可能会因为风险而一刀切禁止所有入户录制，从而压缩产品需求。 缓解措施: 同时支持强硬拒绝政策和受控审批，让软件依然成为合作决策的记录系统。