企业
面向 AI 辅助开发的只增不减审计日志
每一条提示词、每一次合并、每一次部署与每一项管理员操作,都被只增不减地记录——因此“谁做了什么、谁批准了它”这个问题,有一个你的审计员能读懂的答案。
Ciao 在提示词、合并、部署与管理员操作之间维护着一份只增不减的审计日志。与那些只记录提交历史的开发工具不同,这份日志捕获了 AI 时代新出现的问题——向 AI 提出了什么请求、由此产生了什么变更、哪位人类审核了它——Guardrails 会在每一次合并背后记录人工审核。这份日志可以被导出以供审计审阅,也可以在评估过程中被现场演示。
发布日期 2026-07-03 · 最近更新 2026-07-03
“谁做了什么”现在也包括了 AI
传统的变更管理审计三样东西:工单、提交与批准。AI 辅助开发增加了第四样,而大多数工具都忽视了它——提示词。当一句简单语言的请求就能产生一次生产环境的变更时,这个请求本身就是变更记录的一部分,而一份从提交开始记录的审计轨迹,已经错过了这个故事的开头。
Ciao 记录了整个序列。提示词是一等的事件;合并携带着 Guardrails 的审核记录——适用了哪项政策、哪位人类审核了它、批准了什么;部署与管理员操作补全了这幅图景。这份日志是只增不减的:条目不断累积,你的审计员读到的历史,就是真实发生过的历史。这个序列的任何部分,都不需要在事后从聊天记录导出或截图中重建。
对一位 CISO 而言,这把一个令人不安的问题——“你们如何控制 AI 改动了什么?”——变成了一个可评审的问题:调出这份日志,精确阅读当时请求了什么、改动了什么、谁批准了它,以及它是何时发布的。这一项单一能力,往往能把一个 AI 开发平台从风险评审中“需要解释的例外情况”那一栏,移到“可以引用的控制措施”那一栏,因为在资产版图的其他部分,很少有变更管理故事能像这样从请求本身就开始记录。
记录了什么
四类事件,一份轨迹——按顺序记录,而不是事后拼凑:
- 提示词 — 向平台提出的简单语言请求——每一次变更真正的起点,被捕获下来,而不是遗失在一个聊天窗口中。
- 带有审核上下文的合并 — Guardrails 把代码映射进业务领域、探测高风险变更、应用简明英文政策并记录人工审核——在每次合并背后留下审计轨迹。
- 部署 — 发布了什么、何时发布的,把已批准的变更和用户面前真正运行的东西连接起来。
- 管理员操作 — 身份、访问与配置的变更——包括来自 SSO 和 SCIM 的供给事件——因此访问评审和变更评审依据的是同一份记录。
- 在设计上只增不减 — 这份轨迹会不断累积;条目不会被就地编辑。审核人员读到的,是事件真实发生时的那个序列。
导出与审阅
无法提取的证据,就等于没有证据。这份轨迹可以被导出以供审计审阅,因此你的团队可以把记录带入自己的工作底稿和留存流程,而不必对着供应商的界面截图。在评估过程中,请要求两样东西:一次现场演示——你挑选一次真实的变更,端到端地追踪它——以及那同一序列的一次导出,让你的审计员看到他们真正会用来工作的格式。也要问清楚谁能执行导出操作,以及导出事件本身是如何被记录的——一个好的日志故事,也包括日志本身的访问故事。
对事故响应而言,同一份轨迹服务于一个不同的目的。当出现故障或看起来不对劲时,响应人员可以从提示词到部署重建整个序列,而不必等待任何人回忆起当时请求和批准了什么。在季度评审中让审计员满意的证据,也是在糟糕的一周里缩短事故处理时间线的证据。
一次审计请求是如何进行的
一次具体的演练,展示你的审计员会如何使用这份轨迹:
1. 界定问题范围
一位审计员就一次变更提出问题:谁发起了它、它触及了什么、谁批准了它、它是何时到达生产环境的。
2. 调出轨迹
定位这个序列——提示词、产生的变更、Guardrails 的政策与审核记录、部署事件。
3. 展示审核记录
合并记录展示了当时适用的简明英文政策,以及 Guardrails 记录的人工审核,直接回答了批准的问题。
4. 导出证据
把相关记录导出到审计的工作底稿中,让审计结论建立在记录之上,而不是回忆之上。
5. 闭合这个循环
因为管理员操作也在同一份轨迹中,关于“当时谁有访问权限”这类后续问题,也能从同一个来源得到答案。
事件类型及审核人员关心的原因
| 事件类型 | 记录了什么 | 审核人员为什么关心 |
|---|---|---|
| 提示词 | 向平台提出的简单语言请求 | 一次 AI 辅助变更的真实起点 |
| 合并 | 高风险变更检测、适用的政策、记录的人工审核 | 每次合并背后的批准证据 |
| 部署 | 发布了什么、何时发布的 | 把批准和生产环境的现实连接起来 |
| 管理员操作 | 身份、访问与配置的变更 | 访问评审与特权变更证据 |
验证说明
这份轨迹是一项你可以亲眼看到运行的控制措施:在评估过程中,通过平台做一次变更,然后在日志中找到自己。对于书面证据,SOC 2 Type II 报告可在 NDA 下获取,安全资料包——可通过联系页面按需索取——涵盖了日志架构和留存的具体细节。如果你的审计框架有特定的留存或格式要求,请在采购过程中以书面形式提交给企业团队。
有一个来自审计做得好的团队的习惯值得借鉴:每个月挑选一次真实的变更,把它端到端地追踪一遍,当作一次演练。这能让审计这块肌肉保持热身状态,在问题还容易修复时就把缺口暴露出来,并把年度审计变成一件例行公事的重复,而不是一场手忙脚乱。
常见问题
管理员能编辑或删除审计日志条目吗?
这份轨迹在设计上是只增不减的——条目不断累积,而不是被就地编辑。若要了解这项特性背后的架构细节,请索取安全资料包,以及在 NDA 下涵盖相关控制措施的 SOC 2 Type II 报告。
AI 提示词真的是审计记录的一部分吗?
是的。这份轨迹涵盖提示词、合并、部署与管理员操作,因此一次变更的记录始于请求本身,而不是提交本身。在评估过程中,你可以追踪一条提示词直到它的部署。
审计记录会被保留多久?
留存的具体细节应该以书面形式记录,而不是写在一个营销页面上——它们涵盖在安全资料包中,也可以写入你的协议。请在采购过程中说明你的框架的留存要求,并把答案文档化。
我们能把这份轨迹接入我们的 SIEM 或 GRC 工具吗?
这份轨迹可以被导出以供审计审阅。接入你具体的 SIEM 或 GRC 技术栈是一个集成问题——向企业团队描述你的流水线,并在评估过程中确认这个工作流程,而不是想当然地假设。
谁能阅读这份审计轨迹?
对这份轨迹的访问权限受基于角色的访问控制治理,因此审计可见性是你的工作区有意分配的一个角色。访问权限的变更本身也是管理员操作——被记录在它所授予访问权限的那同一份轨迹中。