外观
数据授权
总则一句话：数据的默认状态是不可用。任何一次数据使用都必须能指向一条明确的授权依据，找不到依据就拒绝，手续不能事后补。约束落在能力上：系统里存在一条未经授权就能读到他人数据的路径，本身就是不合规，与是否实际使用无关。
角色
| 角色 | 承担者 | 职责 |
|---|---|---|
| 数据控制者 | 租户企业 | 决定数据的处理目的与方式，是数据的权利主体 |
| 受托处理者 | 沅虹 | 按委托目的处理，不得超出委托范围自行使用 |
| 子处理者 | 云服务商、模型服务商、短信服务商 | 沅虹委托的下游，须向租户披露 |
| 数据管家 | 底座团队 | 执行规范，维护授权登记与审计 |
| 授权批准人 | 沅虹指定负责人与商务 | 批准数据流向上线，对授权依据的完备性负责 |
推论：沅虹作为受托处理者，对客户数据没有独立的使用权。批准人与管家不应为同一人。
四个层次
| 层 | 内容 | 载体 | 缺失后果 |
|---|---|---|---|
| 合同层 | 数据共享协议：范围、目的、期限、责任、解约后处理 | 合同或补充协议 | 无法律依据 |
| 系统层 | 租户侧的授权开关，控制者自己开关 | 租户管理后台 | 变成沅虹自授权 |
| 查询层 | 每次查询携带目的标识，与授权范围比对后放行或拒绝 | 统一查询层 | 授权范围形同虚设 |
| 审计层 | 授权变更与数据访问全量留痕，可导出 | 审计库 | 无举证能力 |
合同层由商务负责，其余三层由底座负责。合同未签署前，系统层开关不提供给该租户。
集团与子公司
集团公司与子公司是独立法人，集团看子公司数据要走与外部共享同等的手续，授权方向是子公司向集团授权。可接受的形式按强度排序：子公司自己开授权开关并留痕；子公司签授权书，沅虹代配置并留痕通知；集团签的框架协议里明确列出各子公司。集团口头要求、沅虹自行开通、默认开通都不可接受。集团视图不提供个人维度指标。
授权粒度
按"数据集、接收方、目的"三元组授权。一条授权项六要素：数据集、接收方、目的、粒度（如组织级聚合，不含个人维度）、期限、状态。
授权针对目的，换一个用途就要重新授权。同一份数据用于"集团安全绩效监督"被允许，用于"模型训练"要另行授权。用客户数据做模型训练或调优不属于运维必需，必须单独授权。
开关在租户自己的管理后台，沅虹的运维后台只能看，不得代为开启；代操作需客户书面委托并全程留痕。新租户所有对外授权项默认关闭，私有化部署客户默认不具备上送能力。撤回后接收方立即不可见，撤回必须填理由。
四道校验
每次查询经统一查询层，任一不过即拒绝并记入审计：
- 消费方契约里是否声明了该数据集。
- 请求的目的是否与契约声明一致。
- 数据所属租户是否已对该接收方、该目的开启授权。授权状态由租户侧开关实时决定，上线后随时可变。
- 请求范围是否在授权范围内：集团边界、时间范围、粒度、禁用维度。
身份也要匹配：运营专用的数据只能由运营身份查，集团范围的要集团用户，自有范围的要租户用户。跨多个租户查询时逐租户校验，无授权的租户被剔除，一个都没授权才整体拒绝。审计放行与拒绝都落，只记放行不记拒绝，透明性就是空话。
统一查询接口
POST /api/uancore/v1/query消费方取数的唯一入口，凭查询身份令牌调用。请求里只有指标名、维度名、过滤条件与目的，不接受 SQL，也不暴露表名：
| 字段 | 说明 |
|---|---|
consumer / purpose | 消费方与目的，走上面的四道校验 |
metrics | 指标目录里已登记的指标 |
dimensions | 分组维度，如组织、日期、隐患类型、风险等级 |
filters | 过滤条件 |
as_of / metric_versions | 按某天生效的口径出数，或给个别指标钉死口径版本，用于按旧口径复算 |
按日期分组时，日期一列回 YYYY-MM-DD 文本。分组结果按维度的先后升序排，文本按字节序、空值排最后。PostgreSQL 与 openGauss 出来的行序一致；一租户一库跨租户查询时，各库结果合并后按同一套规则排，再截取条数。
透明性
租户随时能看到：
- 哪些数据集被上送、什么粒度、依据什么
- 接收方与目的
- 最近一次上送时间与历史记录
- 授权变更历史：谁在什么时候开启或撤回
- 谁查过我的数据、为什么查、放行还是拒绝
对应接口 GET /api/uancore/v1/transparency，授权变更流水 GET /api/uancore/v1/grants/{id}/events，租户随时可查，沅虹不可删。审计流水按身份限定范围：租户身份只看得到与自己相交的记录，运营身份看全部。集团查看行为对子公司事后可查。
沅虹自身能用什么
| 可用 | 不可用 |
|---|---|
| 调用量、活跃用户数、存储用量、错误率、响应时延 | 隐患条数、类型分布、进度数值等业务指标 |
| AI 准确率的分子分母，用于服务质量保障 | 具体隐患内容、照片、位置 |
| 订阅与计费状态 | 任何可识别到具体业务事项的信息 |
判定标准：这项数据是否为履行服务合同所必需。
禁止入库的字段
隐患描述文本、照片与视频路径、上报人与责任人姓名、精确经纬度与位置文本、个人证件号、联系方式、健康与薪酬信息。字段白名单在数据产生侧生效，已经流出的数据无法收回。
生命周期与删除
| 阶段 | 要求 |
|---|---|
| 保留期 | 每个数据集声明保留期，到期自动清理。感知事件、证据、问答留痕按租户配天数，后台每小时清 |
| 授权撤回 | 立即停止新增上送，接收方立即不可见 |
| 租户解约 | 合同终止后清理该租户全部数据，出具清理证明；授权与访问记录本身保留 |
| 备份 | 备份中的数据同样在清理范围内 |
清理要做成可执行的技术能力，光在合同里承诺一句不够。控制台"数据删除"页先出清单（试跑），再登记删除范围，执行前拿库里实际的表与登记比对，发现未登记的表直接拒绝整次操作。执行需二次确认，批次历史可查。
每张表登记了放在哪个库。一租户一库时，定向删除先删租户库里的数据，再删主库里带这个租户的行。制度库的原件随定向删除一起删，删了几个记在删除明细里；对象存储连不上，试跑就报错，整次不删。
问答留痕可能含提问人的个人信息，保留期没有默认天数，由租户自己配，不配不删，定向删除时一起删。
对外集成凭据
第三方平台经 /api/open/v1 读事件，凭据与内部管理密钥完全隔离，两套不共享、不互相兜底。签发时必须指定租户，并按事件类型、场站、严重度收窄，可单独吊销、单独留痕。对外的事件编号用"租户加幂等键"，自增编号不对外，集中式切到分级汇聚时不会让对方重复入库。
规划中
- 聚合结果的最小组阈值（任一分组计数低于阈值时合并入"其他"）
- 连续查询模式的差分攻击告警
- 门户统一签发查询身份令牌