如何对 Prompt、附件、日志、评估集、向量库和记忆统一进行数据分类与最小收集？
建立统一的数据分类体系：按敏感度（公开/内部/机密/PII）与用途（Prompt、附件、日志、评估集、向量库、记忆）对各类数据资产打标签；对每类资产执行最小收集原则——只收集完成任务所需的数据，丢弃不必要字段；定义每类数据的保留期、访问权限与处理方式。通过数据目录（data catalog）统一登记各类数据资产，实施分类分级的访问控制与脱敏。
统一分类是"数据治理"的基础。最小收集降低泄露面与合规负担，分类分级决定访问控制与处理策略。
Provider 密钥为何只能由服务端 Vault/KMS 等托管？轮换、短期凭证与泄漏处置如何实现？
Provider 密钥（API Key、Bearer Token）是访问外部模型的高价值凭证，若放前端或代码库会被窃取，只能由服务端 Vault/KMS 托管，加密存储并控制访问。轮换：定期或按策略自动轮换，更新存储并通知相关服务；短期凭证：用短期 scope 受限的 token 降低泄露影响；泄漏处置：检测到泄露立即吊销、轮换、中断相关请求，审计影响范围并更新威胁模型。
密钥托管把凭证集中到受控环境，轮换与短期凭证降低凭证生命周期风险，泄漏处置止损。
Provider 密钥（API Key、Bearer Token）应如何安全管理？
Provider 密钥应只存于服务端私密存储（Vault/KMS/环境变量），禁止进前端、代码库或日志；通过服务端代理调用模型，前端不直接接触密钥；使用最小权限的密钥与 scope，按需申请；建立密钥生命周期管理：创建、轮换、吊销、审计，检测到异常立即轮换。对密钥做脱敏与最小化，避免在日志中记录。
安全要点是"密钥不落前端、不落日志、集中托管、生命周期受控"。前端只经代理，不持有密钥。
模型输入中的 PII 应在发送模型前还是日志落盘前脱敏？二者脱敏策略有何不同？
发送前脱敏：在把输入送给外部模型前移除/替换 PII，减少数据出境风险，但可能影响模型对上下文的理解（需保留占位符语义）。日志落盘前脱敏：在日志写入前对 PII 做掩码/哈希，保证日志可用但保护隐私。两者策略不同：发送前脱敏侧重"数据不出域"，可能做语义化替换；落盘前脱敏侧重"日志不泄露"，通常做掩码与最小化。实践中两者都要做，且按合规要求选择力度。
两个阶段的脱敏目标不同：发送前管"数据流动"，落盘前管"数据留存"。需双管齐下并兼顾功能与合规。
向量反演攻击（vector inversion）为何使 Embedding 也成为敏感数据，存储与查询应如何防护？
向量反演攻击可从嵌入向量近似重建原始文本，因此 Embedding 能反向泄露原始内容，使其成为敏感数据。防护：存储上对向量加密、限制访问权限、按租户隔离；查询上对相似度结果做访问控制过滤，防止跨租户检索；对可重建高敏感内容的向量加强保护，必要时对嵌入做扰动或访问审计。Embedding 不应被视为"不可读"而忽略保护。
向量可反演意味着"向量=数据"的弱化版本。防护需把向量当作敏感数据：加密、隔离、访问控制、审计。
成员推断（membership inference）攻击如何让 Embedding 泄露"是否包含特定记录"的信息？
成员推断攻击通过构造查询，观察模型/向量检索的行为差异，判断某条特定记录是否存在于训练数据或知识库中。在 Embedding 场景，攻击者可通过查询相似度、输出置信度等推断某文档是否被索引。缓解：结果扰动（对相似度/输出加噪声）、访问审计（记录并分析可疑查询）、检索限制（限制返回条数与敏感度）、对可区分性高的查询告警。
成员推断是"存在性泄露"。缓解思路是降低查询结果的可区分性并加强审计，使攻击者难以确认成员关系。
删除请求如何传播到对象存储、日志、评估数据、向量索引、缓存与备份中？
删除请求需覆盖所有数据资产：主数据（对象存储）、日志、评估数据、向量索引、缓存与备份。实现：建立删除编排（删除管线），收到删除请求后按数据目录逐项处理；对象存储删除或标记删除，向量索引删除对应向量，缓存按 key 失效，备份按保留策略删除或标记；日志与评估数据按 TTL 与删改补偿。通过删除日志与审计验证传播完成，对无法立即删除的做失效处理。
删除的关键是"全链路覆盖 + 可验证"。数据目录与删除管线保证删除不遗漏，审计验证删除完成。
KMS 密钥轮换应如何在不停服的情况下更新 Provider 凭证？影响在途请求怎么处理？
采用多版本密钥轮换：新凭证写入配置中心并保留旧凭证一段时间，服务按版本优先使用新凭证，失败时回退旧凭证（可配置双 key 支持），实现在不停服下平滑切换。在途请求处理：轮换期间保留旧凭证的有效期，使已发出的请求能完成；对使用旧凭证的请求做标记与重试，避免失败。轮换完成后可销毁旧凭证并更新审计记录。
平滑轮换的关键是"新旧并存 + 优雅切换 + 容错回退"。在途请求靠保留旧凭证有效期兜底。
短期凭证（short-lived token）的过期、撤销与刷新应如何在微服务间无感流转？
短期凭证通过在微服务间传递 token 并携带过期时间，服务校验合法性；过期后通过刷新机制（refresh token 或 identity-injected context）无感获取新凭证，避免打断调用。撤销通过吊销列表或服务端校验实时生效。无感流转需要统一的身份上下文（如 OAuth token exchange、服务间信任链），让服务间自动续期并传播身份，同时对刷新做限流与审计。
短期凭证降低泄露风险，但需无感刷新保证可用性。token exchange 与统一身份上下文是关键技术。
前端使用短期受限凭证时，应限制哪些来源、模型、配额和有效期？
前端短期凭证应限制：来源（允许的域名/来源，防跨站盗用）、可访问的模型列表（只允许指定模型）、配额（调用次数与 Token 上限）、有效期（短期、到期自动失效）。这些限制在服务端签发凭证时编码进 scope/claims，前端调用时服务端校验来源、配额与有效期，检测到超限或来源不符即拒绝。
前端凭证可控性弱，必须用受限 scope 与配额限制影响面。服务端校验是安全底线。
跨区域部署如何验证数据未因遥测、故障转移或第三方工具越过地域边界？
验证数据不越界：启用数据驻留配置（region pinning），限制存储与处理在指定区域；对遥测、第三方工具（监控、日志、BI）做数据流审计，确认其存储与传输区域；故障转移时配置为区域内/受控区域，避免把数据带到未授权区域；通过数据流图、日志分析、出口流量监控与合规检查验证数据停留区域。必要时做数据驻留测试。
数据越界常发生在"遥测、第三方、故障转移"这些隐性路径。需数据驻留配置 + 数据流审计 + 出口监控多管齐下。
为什么不能把"哈希"作为 PII 的脱敏手段？哈希可被反向重建吗？
哈希是可逆的（在特定场景）：对低熵的 PII（手机号、身份证、姓名）可用彩虹表、字典或预计算攻击在有限空间内反向匹配，且相同输入哈希相同（可被关联），因此哈希不能作为 PII 脱敏。正确做法用带盐的强哈希（仅用于匹配）、加密保存、掩码（保留部分）或假名化，并配合访问控制。脱敏需满足"不可逆、不可关联、可审计"。
哈希的"不可逆"对低熵数据不成立。脱敏要看攻击者能否反向或关联，需用盐、加密与掩码组合。
日志中保留完整对话文本会带来哪些隐私与合规风险？应保留哪些聚合字段即可？
完整对话文本含 PII、敏感信息与业务内容，保留会造成隐私泄露、合规违规（GDPR/PIPL）与数据出境风险。应改为最小化日志：只保留必要的聚合字段，如请求 ID、时间戳、用户标识（脱敏）、模型、Token 用量、状态码、错误码、耗时、风险标签等，不保留完整 Prompt 与输出。对确需排障的上下文做脱敏与受限访问。
日志最小化是隐私工程的核心。保留"可审计、可排障"的元数据，而非内容本身，兼顾安全与合规。
数据保留与删除策略：对话、日志、向量索引、缓存与备份的 TTL、归档与自动删除如何满足合规？删除请求如何全链路传播？
对各类数据设置 TTL 与保留策略：对话、日志、向量索引、缓存按业务合规定义保留期，到期自动删除或归档；归档数据按更严格访问控制保留并在法定期限后删除；备份纳入保留策略，防止删除后恢复。删除请求需全链路传播：通过删除编排覆盖主数据、日志、向量、缓存、备份与评估数据，审计验证删除完成，满足"被遗忘权"合规。
保留与删除是合规两面：该留的留（审计、法定），该删的删（隐私）。TTL 自动化 + 删除编排全链路覆盖。
浏览器端使用受限凭证（如 Browser AI 短期 Token）应如何设计？
浏览器端凭证应设计为受限、短期：通过服务端签发短期 token，编码受限 scope（仅允许指定模型、来源、配额），并绑定来源（Origin）防止跨站盗用；前端调用时服务端校验来源、配额、有效期与 scope；凭证过期自动刷新，配额耗尽即拒绝。避免把高权限 Provider 密钥暴露给前端。
前端凭证不可控，必须"受限 + 短期 + 服务端校验"。设计核心是让泄露风险最小化、影响面可控。
为什么不能假设 Provider 已遵守所有隐私法规？应用层应做哪些独立审计与验证？
Provider 的合规承诺不能替代应用自身的责任：法规适用因地域、场景而异，Provider 的合规状态可能变化、不完整或未覆盖应用的具体数据流。应用层应独立审计与验证：核验 Provider 的数据处理条款、数据驻留与传输方、隐私政策与认证（如 SOC2、ISO）、数据传输与存储路径；对数据出境、PII 处理做独立 DPIA 与合规审查，不盲信 Provider 声明。
合规责任最终在应用层。独立审计是"不盲信、可验证"，覆盖数据处理条款、驻留、传输与认证。
PII 检测与脱敏工具（如 Microsoft Presidio）在发送前/落库前的部署位置与误脱敏控制是什么？
Presidio 等 NER 工具可在两处部署：发送前（模型输入链路）对 PII 做识别与替换，降低数据出境风险；落库前（持久化链路）对日志/存储做脱敏。部署位置要结合性能与合规：发送前需低延迟、语义化替换；落库前可较重、做掩码。误脱敏控制：配置白名单/黑名单与实体类型、阈值调节、对高风险替换做人工复核或提示，避免破坏功能或引入新错误。
部署位置决定"数据流动"与"数据留存"的防护。误脱敏控制平衡"隐私保护"与"功能可用"。
