InfoQ 开放了一个为期五周的 AI Security & Privacy Engineering cohort，目标人群是受监管行业里的资深工程师和架构师。这个方向值得关注，不是因为“AI 安全”又多了一个课程名，而是因为生产级 AI 系统已经把安全、隐私、威胁建模、可观测性和治理揉成了同一个工程问题：模型调用、提示词、检索数据、用户输入、日志和审批流程，任何一环都可能变成风险入口。
生产 AI 系统的风险不只在模型
传统后端安全常盯认证、授权、网络边界和数据存储。AI 系统多了几层新的攻击面：提示词注入、越权检索、敏感信息泄漏、模型输出不可预测、第三方模型供应链，以及无法解释的自动化决策。
在银行、保险、医疗、政务、能源这类受监管行业里，问题更尖锐。系统不是“能回答”就够了，还要能证明：
- 哪些数据进入了模型上下文；
- 哪些输出被拦截、降级或人工复核；
- 哪些用户、服务或代理触发了高风险操作；
- 哪些策略阻止了敏感数据外发；
- 事故发生后能不能从日志重建链路。
这也是该 cohort 把安全、隐私、威胁建模、可观测性和治理放在一起的原因。它们不是五个孤立主题，而是同一条生产链路上的控制点。
威胁建模要落到 AI 数据流上
做 AI 威胁建模时，不要只画“用户 -> 应用 -> 模型”的三段图。更有用的是把上下文来源拆开：用户输入、系统提示词、RAG 检索结果、工具调用结果、会话历史、审计日志、模型响应。
可以这样实践：为每个 AI 功能建立一份轻量威胁登记表，先不追求复杂工具，重点是让工程团队能在评审时逐项讨论。
# ai-threat-model.yaml
system: claims-assistant
domain: regulated-insurance
owner: platform-ai-team
assets:
- name: customer_pii
examples: ["name", "policy_number", "medical_notes"]
classification: restricted
- name: system_prompt
classification: confidential
- name: retrieved_documents
classification: internal_or_restricted
entry_points:
- user_chat_message
- document_upload
- retrieval_query
- model_tool_call
threats:
- id: T001
name: prompt_injection_overrides_policy
entry_point: user_chat_message
impact: model may reveal restricted claim data or ignore workflow rules
controls:
- separate system instructions from user content
- run input/output policy checks
- require authorization before retrieval
telemetry:
- prompt_injection_score
- blocked_response_count
- id: T002
name: unauthorized_retrieval
entry_point: retrieval_query
impact: user may receive documents outside permitted policy scope
controls:
- enforce document-level ACL before context assembly
- log document IDs added to model context
telemetry:
- retrieved_doc_ids
- acl_denied_count
- id: T003
name: pii_leak_to_external_model
entry_point: model_tool_call
impact: restricted data may leave approved processing boundary
controls:
- redact PII before model call where possible
- route restricted workloads only to approved model endpoints
telemetry:
- pii_detected_before_call
- model_endpoint_used
这份 YAML 不是某个官方格式，只是一个可以改造的工程模板。关键是把“风险、控制、观测指标”绑定在一起，避免威胁建模停留在文档里。
隐私控制要放在模型调用之前和之后
AI 应用里常见的失误是只在数据库层做权限控制，却把检索结果、用户输入和工具返回值原样塞进 prompt。对受监管行业来说，隐私工程要进入请求路径。
下面是一个最小 Python 示例，演示如何在调用模型前做敏感信息检测和脱敏，并记录可审计事件。这里不绑定具体模型供应商，你可以把 call_model() 替换成内部网关、云模型 API 或自托管推理服务。
运行前需要 Python 3.10+，无需额外依赖。
# ai_privacy_guard.py
import json
import re
import time
from hashlib import sha256
PII_PATTERNS = {
"email": re.compile(r"[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}"),
"phone": re.compile(r"\b(?:\+?\d{1,3}[-. ]?)?(?:\d{3}[-. ]?\d{3}[-. ]?\d{4})\b"),
"policy_number": re.compile(r"\bPOL-[A-Z0-9]{6,12}\b"),
}
def detect_and_redact(text: str) -> tuple[str, list[str]]:
findings = []
redacted = text
for label, pattern in PII_PATTERNS.items():
if pattern.search(redacted):
findings.append(label)
redacted = pattern.sub(f"[{label.upper()}_REDACTED]", redacted)
return redacted, findings
def audit(event: dict) -> None:
print(json.dumps(event, ensure_ascii=False, sort_keys=True))
def call_model(prompt: str) -> str:
# Replace this with your approved model gateway or vendor SDK call.
return f"Model received sanitized prompt: {prompt}"
def handle_ai_request(user_id: str, user_text: str) -> str:
redacted_text, findings = detect_and_redact(user_text)
request_hash = sha256(user_text.encode("utf-8")).hexdigest()
audit({
"ts": int(time.time()),
"event": "ai_request_privacy_check",
"user_id": user_id,
"request_hash": request_hash,
"pii_types": findings,
"action": "redacted" if findings else "allowed",
})
response = call_model(redacted_text)
safe_response, response_findings = detect_and_redact(response)
audit({
"ts": int(time.time()),
"event": "ai_response_privacy_check",
"user_id": user_id,
"response_pii_types": response_findings,
"action": "redacted" if response_findings else "allowed",
})
return safe_response
if __name__ == "__main__":
result = handle_ai_request(
user_id="u-123",
user_text="Please review claim POL-ABC123456 for jane.doe@example.com",
)
print(result)
运行：
python ai_privacy_guard.py
这个例子很小，但工程方向是对的：不要把隐私检查当成离线合规报表，而要放进模型请求路径，并且生成可追踪的审计事件。
可观测性不是只看 token 和延迟
生产 AI 系统当然要监控延迟、错误率、token 消耗和模型供应商状态，但在受监管场景中，这些还不够。你还需要能回答更具体的问题：
- 哪些请求触发了敏感信息脱敏；
- 哪些响应被策略拦截；
- 哪些检索文档进入了模型上下文；
- 哪些用户操作导致模型调用了工具；
- 哪个版本的提示词、策略和模型参与了响应生成。
可以这样给 AI 网关或应用层加结构化日志字段：
{
"event": "ai_completion",
"request_id": "req-20250115-001",
"user_id": "u-123",
"model": "approved-model-gateway/prod",
"prompt_template_version": "claims-assistant-v7",
"policy_version": "ai-privacy-policy-2025-01",
"retrieved_doc_ids": ["doc-88", "doc-91"],
"pii_detected": true,
"pii_redacted": true,
"response_blocked": false,
"latency_ms": 842,
"input_tokens": 734,
"output_tokens": 188
}
日志本身也可能包含敏感信息，所以不要把完整 prompt 和完整响应无脑打进日志。更稳妥的做法是记录哈希、版本号、文档 ID、策略决策和风险分类；只有在合规允许、访问受控、保留期明确的环境里，才保存原文样本。
采用建议：把课程内容转成工程检查表
如果团队准备系统学习 AI 安全与隐私工程，可以把这类 cohort 当成一次架构校准，而不是单纯培训。尤其是资深工程师和架构师，学习产出最好能落成可复用的内部资产。
一个实用检查表：
- 每个 AI 功能都有数据流图和威胁登记表；
- RAG 检索在组装上下文前执行文档级授权；
- 模型调用前后都有隐私检测、脱敏或阻断策略；
- 高风险输出进入人工复核或降级流程；
- 日志记录策略版本、提示词版本、模型端点和检索文档 ID；
- 供应商、模型、提示词和策略变更进入发布审批；
- 事故响应手册包含 AI 特有场景，例如提示词注入、敏感数据泄漏、错误自动化建议。
边界也要讲清楚：五周课程不能替代组织内的合规责任，也不能自动修复遗留系统的数据治理问题。它更适合成为一个起点：让安全、平台、数据、合规和业务架构团队使用同一套语言，把生产 AI 的风险控制写进日常工程流程。