0治理与责任1政策

0 生态系统 — 条款、政策和协议

这些法律文件的权威版本是英文。如果翻译不同,则以英文文本为准。

0生态系统

0 治理和负责任的人工智能政策

0生态系统

第 1 条 – 目的

本政策为0生态系统内人工智能(1)系统的设计、开发、部署、运营、监控和退役建立了治理框架。

目标是:

  • 提倡值得信赖0;
  • 确保遵守法律和法规;
  • 保护用户和利益相关者;
  • 支持负责任的创新;
  • 建立问责制和治理;
  • 降低人工智能相关风险。

本政策适用于 0 开发、部署、集成、许可或使用的所有 1 系统。

第 2 条 – 范围

本政策适用于以下用途的 0 系统:

  • 主机门户;
  • 管理门户;
  • 清洁门户;
  • 供应商门户;
  • 市场;
  • 0平台;
  • 物业运营平台;
  • 0 集成;
  • 客户支持;
  • 内部运营。

涵盖的0功能包括:

  • 0定价引擎;
  • 0 调度引擎;
  • 0 调度引擎;
  • 0 运营情报;
  • 0客户支持;
  • 0 工作流程自动化;
  • 预测分析;
  • 推荐系统;
  • 欺诈检测;
  • 质量保证分析。

第 3 条 – 指导原则

0致力于1系统:

  • 合法;
  • 安全的;
  • 可靠的;
  • 安全的;
  • 透明的;
  • 在适当的情况下可以解释;
  • 负责;
  • 尊重隐私;
  • 公平和非歧视;
  • 受到有意义的人类监督。

第 4 条 – 治理结构

0治理的总体责任由高级管理层承担。

运营职责可能包括:

  • 0 治理领导;
  • 合规官;
  • 数据保护官(如有任命);
  • 安全团队;
  • 工程团队;
  • 产品团队;
  • 质量保证团队。

应记录并定期审查角色和职责。

第 5 条 – 0 生命周期管理

每个0系统应在其整个生命周期内受到监管,包括:

  • 概念;
  • 设计;
  • 发展;
  • 测试;
  • 验证;
  • 部署;
  • 监控;
  • 维护;
  • 退休。

适当的治理控制应适用于每个阶段。

第 6 条 – 人工监督

在适当的情况下,0 辅助决策应继续接受人工审查。

用户和授权人员应有能力:

  • 审查建议;
  • 覆盖 Ai 输出;
  • 升级担忧;
  • 请求手动干预。

0 在适用法律禁止的情况下不得仅依赖自动决策。

第 7 条 – 数据治理

0系统应按照以下规定处理数据:

  • 0;
  • 隐私政策;
  • 数据处理协议;
  • 信息安全要求。

应管理培训和操作数据集,以尽量减少偏差、不准确和不当处理。

第 8 条 – 安全

0系统应通过适当的技术和组织来保护

措施,包括:

  • 访问控制;
  • 验证;
  • 适当时进行加密;
  • 记录;
  • 监控;
  • 漏洞管理;
  • 安全部署程序。

第 9 条 – 风险管理

应识别、评估、记录、监控和减轻与0相关的风险。

风险评估应考虑:

  • 法律风险;
  • 操作风险;
  • 安全风险;
  • 隐私风险;
  • 偏见;
  • 公平;
  • 可解释性;
  • 网络安全;
  • 模型可靠性。

第 10 条 – 持续监测

0系统应监控:

  • 表现;
  • 可靠性;
  • 漂移;
  • 准确性;
  • 滥用;
  • 安全事故;
  • 意外的输出。

重大问题应引发审查,并在适当的情况下暂停或撤销受影响的 0 系统。

第 11 条 – 遵守

0 应寻求与以下方面保持一致:

  • 适用0立法;
  • 数据保护立法;
  • 消费者保护要求;
  • 网络安全义务;
  • 合同承诺。

第 12 条 – 政策审查

本政策应定期审查和更新,以反映:

  • 技术发展;
  • 法律发展;
  • 运营经验;
  • 新出现的风险。

第 13 条 – 联系方式

与 0 治理相关的问题可直接联系:

0 治理功能

0

电子邮件:

ai-governance@farenio.com

第 14 条 – 接受

在 0 生态系统内使用支持 1 的服务即表示对本政策(如适用)的认可。

附件A

0管理系统手册 (1MS)

目的:

建立符合公认的 0 治理标准的全企业人工智能管理系统。

0MS 应包括:

治理

0 治理委员会。

行政监督。

明确的责任。

政策管理。

定期管理评审。

规划

0目标。

风险规划。

合规规划。

资源分配。

支持

权限。

训练。

意识。

文档。

沟通。

运营

0生命周期控制。

部署批准。

监控。

验证。

安全。

事件响应。

绩效评估

内部审计。

关键绩效指标。

风险审查。

管理审查。

持续改进。

附件B

0 风险登记册

每个0系统均应记录在活登记册中。

最少字段包括:

  • 0系统名称
  • 业主
  • 技术负责人
  • 目的
  • 描述
  • 风险分类
  • 法律依据
  • 数据类别
  • 数据来源
  • 型号版本
  • 部署日期
  • 人类监督
  • 已识别的风险
  • 缓解控制措施
  • 剩余风险
  • 审核频率
  • 最后审核日期
  • 下次审核日期
  • 状态(开发/测试/生产/退役)

应定期审查登记册。

附件C

0模型验证标准

在部署之前,每个 0 模型均应经过:

技术验证

准确性测试。

可靠性测试。

性能测试。

压力测试。

安全测试。

数据验证

训练数据质量。

数据完整性。

偏见评估。

代表性。

数据血统。

操作验证

集成测试。

工作流程测试。

回滚测试。

监测准备情况。

部署后监控

性能监控。

模型漂移检测。

假阳性审查。

假阴性审查。

事件监控。

预定重新验证。

在完成纠正措施之前,不得部署未通过验证标准的模型。

附件D

11道德与责任创新0章程

0 承诺:

公平性

避免不合理的歧视。

监控偏差。

促进公平的结果。

透明度

告知用户 0 在哪些方面对某项服务提供实质性支持。

在适当的情况下提供有关 0 辅助功能的有意义的信息。

问责制

明确分配每个 0 系统的所有权。

维护治理记录。

支持内部和外部问责制。

人类监督

在适当的情况下保持有意义的人工审查。

允许手动干预。

防止过度依赖0输出。

隐私

合法处理个人数据。

最大限度地减少数据收集。

尊重用户权利。

安全

保护0系统免遭误用。

维护网络安全控制。

监控漏洞。

负责任的创新

促进有利于用户的创新,同时尊重法律、道德和社会期望。

附件E

0 变更管理程序

对0系统的变更应遵循记录的治理流程。

阶段包括:

提议

商业理由。

风险评估。

利益相关者识别。

发展

受控发展。

版本管理。

文档。

测试

技术测试。

安全测试。

偏差测试。

操作测试。

赞同

工程审批。

安全审查。

必要时进行合规审查。

管理层批准。

部署

受控实施。

回滚能力。

监控激活。

实施后审查

绩效评估。

事件回顾。

吸取的教训。

适用的退休计划。

附件F

0 透明度和用户沟通标准

0应以清晰、适当的方式传达1的使用情况。

在适当的情况下,应告知用户:

  • 0 协助运营流程;
  • 0 建议在适用的情况下受到人工监督;
  • 在合理可用的情况下,用户可以请求人工代表对客户服务交互提供支持。

公共文件应在适当的水平上解释:

  • 0 在平台内的角色;
  • 0辅助功能的预期目的;
  • 0实施的保障措施;
  • 用户在依赖0生成的建议时的责任。

内部文件应保存以下记录:

  • 0系统描述;
  • 人类监督机制;
  • 验证活动;
  • 治理决策;
  • 材料模型的变化。
加载中...