随着欧盟《人工智能法案》的推进，企业面对的问题已经不只是“模型是否足够安全”，而是能否持续证明：系统经过了风险评估，安全控制确实生效，用户获得了必要说明，内容来源和处理过程可以追溯。
OpenAI 将安全、安保、透明度与来源证明视为支持欧洲负责任 AI 治理的重要实践。这四个方面不是相互独立的合规清单，而应连接成一条可审计的工程链路：识别风险、执行控制、记录决策、保留证据，并根据法规和产品变化持续更新。
四类实践需要落到同一条链路
安全关注系统可能造成的伤害，例如不可靠输出、危险建议、偏见和自动化决策失误。工程团队需要明确使用场景、禁止用途、评测集合、人工复核条件和失败后的降级方式。
安保处理恶意使用和系统入侵风险，包括越权访问、提示注入、数据泄露、模型接口滥用和供应链攻击。常见控制包括最小权限、密钥轮换、速率限制、输入隔离、依赖扫描和安全事件响应。
透明度要求系统参与者知道 AI 在何处介入、输出有什么限制，以及重要决定由谁负责。透明度不等于公开全部模型细节，也不意味着把内部推理过程暴露给用户。更实际的做法是提供清晰的 AI 标识、能力边界、申诉渠道和版本信息。
来源证明回答“这段内容从哪里来、经过了什么处理”。它可以包括输入来源、模型和策略版本、生成时间、人工修改记录以及内容哈希。来源信息需要采用开放、可验证的格式，并避免把个人数据直接写入日志。
这四类实践只有连接起来才有治理价值。例如，风险评测发现某类输出需要人工复核，运行时策略就应执行拦截，审计记录则应保存策略版本和复核结果。否则，组织只能证明自己写过制度，无法证明制度在生产环境中运行。
把治理要求转成可验证证据
治理文档应对应具体的技术或运营证据。可以建立如下映射：
| 治理问题 | 控制措施 | 可保留的证据 |
|---|---|---|
| 哪些请求不得自动处理？ | 风险分类与人工复核规则 | 策略版本、分类结果、复核记录 |
| 谁能调用模型？ | 身份认证与最小权限 | 访问日志、角色配置、权限变更记录 |
| 用户是否知道正在与 AI 交互？ | 界面标识与输出声明 | 产品截图、文案版本、验收测试 |
| 输出如何追溯？ | 生成事件和内容哈希 | 模型版本、时间戳、输入输出摘要 |
| 控制是否持续有效？ | 定期评测与事件监控 | 测试报告、告警、修复工单 |
记录应满足三个条件：可以关联到一次真实请求，可以识别当时生效的策略和模型版本，并且受到访问控制与保留期限约束。日志越多不等于治理越好；未经筛选地保存提示词、模型输出和用户身份，反而可能扩大隐私与安全风险。
一个可运行的最小审计网关
下面是一个仅依赖 Python 标准库的示例。它不是法律合规方案，也没有替代专业的内容安全模型；它展示的是如何在模型调用边界生成结构化证据。示例使用哈希保存输入和输出指纹，避免把原文直接写进审计日志。
将代码保存为 ai_gateway.py，然后运行 python ai_gateway.py：
import hashlib
import json
import time
import uuid
POLICY_VERSION = "eu-policy-2025-01"
MODEL_VERSION = "example-model-1"
BLOCKED_TERMS = {"steal credentials", "disable audit logs"}
def digest(text: str) -> str:
return hashlib.sha256(text.encode("utf-8")).hexdigest()
def classify(prompt: str) -> tuple[str, list[str]]:
normalized = prompt.lower()
matches = sorted(term for term in BLOCKED_TERMS if term in normalized)
return ("blocked" if matches else "allowed", matches)
def call_model(prompt: str) -> str:
# Replace this deterministic stub with your approved model client.
return f"Example response for: {prompt[:60]}"
def handle_request(prompt: str, actor_id: str) -> dict:
request_id = str(uuid.uuid4())
decision, reasons = classify(prompt)
event = {
"request_id": request_id,
"timestamp": int(time.time()),
"actor_id_hash": digest(actor_id),
"prompt_hash": digest(prompt),
"policy_version": POLICY_VERSION,
"model_version": MODEL_VERSION,
"decision": decision,
"reason_codes": reasons,
"human_review": decision == "blocked",
}
if decision == "blocked":
event["output_hash"] = None
print(json.dumps(event, ensure_ascii=False))
return {"request_id": request_id, "status": "review_required"}
output = call_model(prompt)
event["output_hash"] = digest(output)
print(json.dumps(event, ensure_ascii=False))
return {
"request_id": request_id,
"status": "completed",
"ai_generated": True,
"output": output,
}
if __name__ == "__main__":
result = handle_request(
prompt="Summarize the approved product documentation.",
actor_id="employee-42",
)
print(json.dumps(result, ensure_ascii=False, indent=2))
接入真实系统时，需要替换三处内容：使用经过评测的分类器代替关键词集合；通过受控客户端调用获批模型；把审计事件发送到具备加密、访问控制、不可篡改策略和保留期限的日志系统。若业务需要重放请求，应将原始内容放入独立的加密存储，而不是直接扩充普通日志。
对于高影响场景，还应在事件中记录数据来源、人工审批人、申诉状态和下游动作。不要只记录模型生成了什么，还要记录系统是否据此拒绝服务、修改账户状态或向用户提供关键建议。
在法规演进中保持可调整
欧盟 AI 治理仍会随着法规实施、标准形成和监管解释而细化，因此系统设计不宜把规则写死在业务代码里。风险分类、审核阈值、模型清单和日志保留期限应有版本，并能在不重新部署整个产品的情况下更新。
落地时可以按以下顺序推进：
- 建立 AI 系统清单，标明用途、负责人、模型、数据来源和受影响用户。
- 按场景评估风险，不要假设同一个模型在所有产品中具有相同风险。
- 为每项风险指定控制措施、证据、责任人和复查周期。
- 在模型网关集中执行身份认证、策略检查、版本记录和审计事件生成。
- 定期运行安全评测和攻击测试，并验证人工复核与申诉流程是否真的可用。
- 让法务、安全、隐私、产品和工程团队共同复查变更；技术日志不能替代法律判断。
负责任 AI 治理的核心不是一次性提交一套文件，而是建立能持续回答三个问题的系统：当前有什么风险，哪些控制正在生效，组织能拿出什么证据。安全、安保、透明度和来源证明共同构成这套证据链，也为适应欧盟《人工智能法案》的后续推进留下调整空间。