安全是我们构建产品的核心。本页描述的是我们当前架构与实践中真实存在的情况——而不是一份营销清单。凡是我们尚未完成的事项（正式审计、某项认证），我们都会直说，而不会暗示相反的情况。
医疗健康与 HIPAA
目前，Divinci 的产品未获批准处理受保护健康信息（PHI）。 没有任何商业伙伴协议（Business Associate Agreement）涵盖 Divinci 平台，请勿向其中输入 PHI。
我们正在为医疗健康场景准备一项独立的产品：一个专用的聊天运行时，托管在其自己的 Google Cloud 项目中，并与 Divinci 平台的其余部分隔离。其设计目标是不存储对话记录。我们目前尚未签署 Business Associate Agreement。
这不是什么： 这不是 HIPAA 合规认证。不存在政府颁发的 HIPAA 证书，我们也不声称符合 HIPAA。合规是技术保障措施、书面政策，以及与数据路径上每一家供应商签署的 Business Associate Agreement 的综合结果，并针对每一段客户关系分别评估。我们已采纳书面政策，目前仍在法律审查中；情况变化时我们会在此说明。
数据保护
加密
- 传输中：客户端、我们的边缘节点与源站基础设施之间全程使用 TLS。
- 静态存储：主数据存储与对象存储启用了服务商级别的加密，并针对指定的敏感字段设有专门的字段级加密层。
- 密钥与凭据管理：凭据和 API 密钥通过集中式的密钥管理服务管理，不会硬编码，也不会以明文形式存放在配置中。生产环境被配置为在密钥服务不可达时采取「失败即停止」（fail closed）策略，而不是悄悄退回到过期的凭据。
数据最小化
- 在聊天内容被存储或发送给 AI 提供商之前，可选择对其应用 PII 遮蔽（Microsoft Presidio）。这属于实体检测，并不是 HIPAA 去标识化认定，也不意味着产品可安全处理 PHI。
- 日志按策略只记录元数据：我们不会把消息内容、电子邮件地址或其他个人数据写入应用日志或错误信息中。
访问控制
- 通过 Auth0 进行身份认证。
- 基于角色的访问控制（平台级）加上逐资源权限（文档/工作区级）——默认遵循最小权限原则。
- 防篡改审计日志：对敏感记录的访问会记录在哈希链式日志中，其设计使条目事后无法被悄悄修改。
- 对生产服务进行季度性的访问与配置审查。
应用安全
- 在渲染边界防御 XSS：用户生成和 AI 生成的内容在以 HTML 形式渲染时都会经过净化处理（DOMPurify）；不允许来自不受信任来源的原始 HTML 注入。
- 授权测试：我们针对预发布环境和生产环境开展自有的 AI 辅助测试与人工安全测试，包括已认证状态下的授权/IDOR 探测——但这（目前）还不是一个周期性的第三方渗透测试计划，在它真正存在之前，我们不会声称拥有这样的计划。
- 依赖与代码审查：所有变更都执行标准的代码审查；依赖更新通过我们常规的构建工具链进行跟踪。
可用性与监控
- 对面向客户的端点进行合成监控，在真实故障发生后数分钟内通过 PagerDuty 呼叫值班人员，而不仅仅在服务器报错时才告警——检查会校验返回内容，而不只是看「是否返回了 200」。
- 多区域基础设施（Cloudflare 边缘 + Google Cloud 源站），并对主数据存储进行自动备份。
- 我们目前不提供具有合同效力的正常运行时间服务等级协议（SLA）。如果您的使用场景需要，请告诉我们——我们可以就您的部署讨论怎样的承诺是切合实际的。
事件响应
我们维护着一套成文的安全事件响应流程：检测与分级、遏制、对该事件是否构成需上报的数据泄露作出诚实评估、修复，以及一次不追责的事后复盘，并将结论反馈到我们后续的监控中。如果您是与我们签有业务伙伴协议（BAA）的客户，该协议规定了我们对您的通知义务——以该协议条款为准，而非本页面。
如需报告安全问题或疑似漏洞，请发送邮件至 security@divinci.ai。我们目前没有运行正式的漏洞赏金计划；但我们会认真对待每一份报告，并本着诚信与您协作。
我们在正式认证方面的进展
在这一点上我们选择直说，因为很多安全页面并不这么做：
- HIPAA：我们没有获得任何 HIPAA 认证，也不声称合规。请参阅上文“医疗健康与 HIPAA”。
- SOC 2：尚未启动。它在我们的路线图上；等到有真正可汇报的进展时，我们会更新本页面——在那之前不会。
- ISO 27001、FedRAMP、PCI DSS：我们并不持有这些认证。银行卡支付通过 Stripe 处理；Divinci 不会直接存储持卡人数据。
我们宁愿在此少说一点而赢得信任，也不愿夸大其词、日后不得不收回。
联系方式
安全相关问题、漏洞报告，或针对具体合作的合规问题：security@divinci.ai