实时 AI 数字人的安全审查不应从“供应商是否加密”开始，而应从完整数据流开始。先明确用户输入、身份、检索内容、工具结果、数字人要说的音频、动作数据、日志与客户端资源分别经过哪里，再判断每一层需要什么控制。
核心结论
- 先画数据流与责任边界，再审查供应商问卷。
- 区分用户音频与已经批准、准备给数字人呈现的语音音频。
- 短期会话凭证、最小权限和安全日志比把长期密钥放进客户端更可靠。
- 将子处理商、保留、区域、删除和事件响应纳入同一份评估。
1. 先画数据流
列出数据类别、来源、目的地、处理目的、保留时间与责任人。NIST 的 Privacy Framework提供了识别和管理隐私风险的通用方法；安全团队还可以用威胁建模检查信任边界与攻击路径。
2. 区分用户音频与数字人语音音频
用户对麦克风说的内容与数字人最终要说的内容不是同一数据。应用可能在前者上执行 ASR、身份校验、检索和策略判断，之后才产生可以发送到呈现层的 TTS 音频。这个区分有助于减少不必要的数据暴露，也能解释供应商实际收到什么。
3. 保护凭证和会话
长期 API Key 不应进入浏览器或移动应用。由后端认证用户并签发范围有限、有效期短的会话凭证，同时限制角色、资源与并发。参考 OWASP API Security Top 10检查对象级授权、认证、资源消耗和资产清单。
4. 避免敏感内容进入日志
运营日志通常只需要时间、关联 ID、集成路径、事件类型、结果和安全错误类别。不要默认记录完整转写、Prompt、Token、工具参数或客户数据。OWASP Logging Cheat Sheet说明了应排除的敏感信息和日志完整性要求。
5. 审查完整供应商链
检查子处理商、数据区域、传输和静态加密、保留与删除、人员访问、漏洞管理和事件通知。SOC 2 或 ISO 认证可以作为证据之一，但不能替代对实际数据流与合同范围的检查。
6. 规划滥用与恢复控制
限制会话时长、并发和资源消耗；为异常请求、重复失败、Token 滥用和被篡改客户端设置监控。用户还应有关闭、切换文本和离开数字人路径的清晰控制。
在 Spatius 中应用清单
Spatius 接收数字人要说的语音音频并返回动作数据，AvatarKit 在客户端本地渲染。应用继续拥有用户输入、ASR、LLM、TTS、检索、权限、工具与工作流。开发者文档总览是当前边界的权威来源。
在实际部署前，还应结合数字人供应商应接收哪些数据建立字段级清单，并由安全、隐私和法律团队按场景审查。
常见问题
是否应该保存所有对话用于质量评估？
不应该默认这样做。先定义目的、最小字段、访问范围、保留周期与删除机制，并确认客户合同和适用要求。
加密是否已经足够？
不够。加密不能替代授权、最小化、保留控制、日志治理、供应商管理和事件响应。