企业 AI 安全、合规与审计控制面系统设计面试题
LLM 数据分级、外发治理与审计证据面试题 解决“单份数据如何被正确使用”；本页解决“企业如何对模型、Prompt、RAG、Agent、MCP、数据和供应商建立统一的治理控制面”。
本页讨论的是工程治理框架，不替代组织的法务、隐私或监管评估。实际落地应以适用地域、行业和公司制度为准。
一、30 秒总答法
面试官：设计一个企业 AI 安全、合规与审计平台，你从哪里开始？
我不会把治理理解成在 Prompt 前后加几条敏感词规则。首先建立 AI 资产台账，登记每个应用、模型、Prompt、知识库、数据集、Agent、MCP Server、工具和供应商的 owner、风险等级、依赖、区域和生命周期。其次做场景影响评估，确定数据、模型通道、工具权限、人审和审计要求。运行时由统一 Policy Engine 根据身份、租户、用途、数据标签、区域、工具风险和发布版本输出 allow、mask、approval 或 deny；所有决策、脱敏、外发、审批和执行写入可验证的 evidence bundle。控制项以策略即代码和自动测试持续验证，例外有审批、范围和到期日；供应链组件有签名、版本、兼容性和紧急冻结能力。这样安全、合规和业务不是三个孤岛，而是可追责、可发布、可回滚的控制面。
关键词：资产台账、风险分级、Policy as Code、ABAC、证据账本、例外到期、供应链、持续控制验证。
二、为什么不能只靠 Prompt 护栏
Prompt 可以帮助模型理解边界，但它不是权限系统、数据出境网关、审批系统或审计账本。只靠 Prompt 的问题包括：
- 模型可能忽略、误解或被注入绕过约束。
- Prompt 无法证明某次访问的身份、授权、用途和审批。
- 工具、MCP Server、缓存、外部插件可以在 Prompt 之外接触数据。
- 换模型、改工具 Schema、换索引或供应商后，旧规则容易失效。
- 没有统一资产台账时，事件发生后无法快速回答哪些应用受影响。
高分回答要落到一句话：模型可以提出意图，系统边界才拥有权限和执行权。
三、AI 资产台账与依赖图
传统 CMDB 记录主机和服务，AI 资产台账还要记录会改变行为与风险的“软资产”。
| 资产 | 核心字段 | 治理价值 |
|---|---|---|
| 应用 / Agent | owner、场景、风险、用户群、SLA | 确定责任人和业务边界 |
| 模型 / 路由 | provider、版本、区域、能力、合同限制 | 控制外发、fallback 和成本 |
| Prompt / Workflow | 版本、变量、审批、评测集 | 追溯行为变更 |
| RAG 知识库 | 数据 owner、分类、ACL、保留期、索引版本 | 控制数据使用与删除 |
| 工具 / MCP Server | 风险级别、scope、Schema、运行位置、owner | 控制副作用与供应链 |
| 数据集 / Judge | 用途、授权、脱敏、保留、标注 owner | 防止评测/训练旁路泄露 |
| Guardrail / Policy | 规则版本、适用范围、例外、测试结果 | 支持审计与回滚 |
依赖关系要可查询，例如“这个供应商模型出现区域故障，哪些 RAG 应用、Prompt、租户和工具通道受影响”“这条删除请求会落到哪些索引、缓存、评测集和备份”。资产下线时应先分析依赖、迁移或冻结，再撤销凭据和策略。
四、风险分级与 AI 影响评估
发布前不要只问“模型准确率是多少”，还应根据场景完成一份轻量但可审计的影响评估。
| 维度 | 示例问题 |
|---|---|
| 业务影响 | 是辅助建议，还是自动做决定/写操作？ |
| 数据影响 | 是否含 PII、商业机密、受限数据、跨租户数据？ |
| 模型通道 | 能否使用公有 SaaS，是否有区域和合同限制？ |
| 工具影响 | 是否调用支付、权限、邮件、代码执行、生产发布？ |
| 用户影响 | 对外用户、未成年人、员工、客户还是高风险人群？ |
| 可解释与审计 | 是否需要引用、人工复核、不可抵赖证据？ |
| 供应链 | 是否引入新模型、新插件、MCP、解析器或数据源？ |
风险评估输出的不是一份静态 PDF，而是一组可执行控制：可用模型白名单、最大数据等级、工具权限、是否 HITL、审计保留、发布门禁和复审周期。低风险内部摘要可自动化；高风险决策、资金、权限和对外承诺则要求人工确认和更强的证据。
五、Policy as Code：把规则变成运行时决策
治理规则分散在 Wiki、表格和人工记忆里时，必然出现不同系统执行不一致。策略即代码的目标是让同一规则在 RAG、模型网关、Tool Gateway、MCP、Dify 和发布流水线都能被调用和测试。
Request Context
+ subject: user / service / tenant / role
+ resource: data / model / tool / knowledge base
+ action: read / retrieve / egress / execute / export
+ purpose: support / analytics / evaluation / training
+ environment: region / release / risk
-> Policy Engine
-> allow / mask / tokenize / require_approval / sandbox / deny策略示例：
deny egress if data.classification == restricted and model.channel == public_saas
require_approval if tool.risk_level >= L3
mask pii if subject.role lacks field.read_sensitive
deny cross_region_fallback if data.residency == local_only策略要版本化、评审、单元测试、灰度和回滚。每次策略变化都应说明影响资产、预期 allow/deny 差异和回归集结果，不能直接修改生产规则。
六、身份传播、ABAC、委托与职责分离
企业 AI 服务常跨越 Web 应用、Agent、Gateway、MCP Server 和内部业务系统。只把 user_id 作为普通参数传递是不安全的；身份上下文需要可信签名、短期令牌、audience、scope、tenant、用途与过期时间。
| 机制 | 解决什么问题 |
|---|---|
| ABAC | 用 subject、resource、action、context 和数据标签做细粒度判断 |
| 短期 scoped token | 避免 Host 或插件永久持有高权限凭据 |
| 受限委托 | Agent 只能代表用户完成被允许的动作，不能自我提权 |
| 目的绑定 | 客服问答授权不等于可用于训练、导出或外发 |
| 职责分离 | 发起人、审批人、执行人不能在高风险操作中全部由同一主体承担 |
| break-glass | 紧急权限必须时间有限、强审计、事后复核 |
面试要强调：Host 可以传递身份，但 MCP Server 和业务服务仍需二次校验 token、scope 和资源 ACL。模型输出永远不是可信授权证据。
七、区域、供应商、密钥与供应链治理
治理控制面需要同时管理“模型能力”与“模型风险”。模型、Embedding、Reranker、护栏、解析器、MCP Server、Dify 插件都应有版本、来源、owner、签名/校验值、依赖清单和兼容性状态。
| 场景 | 控制要点 |
|---|---|
| 区域驻留 | 模型与数据区域匹配，禁止不合规的跨区 fallback |
| 供应商模型 | 明确处理边界、训练使用限制、可用区域、故障策略 |
| MCP/插件 | 来源审计、最小权限、网络出口、依赖漏洞、紧急禁用 |
| 模型/工具升级 | 兼容矩阵、Schema 回放、评测和灰度 |
| 密钥 | KMS/Secret Manager 引用、短期令牌、轮换、按环境隔离 |
| 组件漂移 | 定时探针、版本差异告警、自动冻结高风险通道 |
可复述：
我把模型和工具都当供应链组件管理。能调用不代表能上线，必须知道它来自哪里、依赖什么、能访问什么数据、发生漂移时如何发现和一键冻结。
八、不可抵赖审计与证据账本
普通应用日志是调试信息；合规证据需要证明事件未被悄悄修改，并且可按最小权限查询。每个关键事件可写入 append-only ledger：
| 事件 | 最小证据 |
|---|---|
| 资产变更 | 资产版本、提交者、评审、差分、发布时间 |
| 策略决策 | policy version、输入摘要、allow/deny、理由、审批 |
| 数据访问/外发 | 数据分类、用途、通道、区域、DLP/脱敏结果 |
| 工具执行 | identity、scope、参数摘要、幂等键、结果、trace |
| 删除与留置 | 请求、传播状态、例外、完成证据 |
| 安全事件 | 告警、证据冻结、响应动作、复盘和门禁回灌 |
实现可采用 WORM 存储、哈希链、受控时间源和分离的审计访问权限。重点不是堆砌术语，而是保证：业务管理员不能既执行高危操作又无痕修改审计；审计查询本身也不会成为数据泄露入口。
九、持续合规：控制验证、例外与复审
治理不是上线前盖一次章。成熟系统把控制项做成持续任务：
- 每次发布自动检查资产台账、风险等级、策略版本、评测证据、owner 与例外状态。
- 定期运行 ACL、外发、注入、删除、审计覆盖和供应链回归。
- 例外必须包含范围、业务理由、补偿控制、负责人、流量上限和过期日期。
- 到期未续的例外自动失效或冻结对应能力，不把风险遗忘在表格里。
- 高风险资产按周期复审：数据用途、供应商、工具权限、模型行为和审计规则是否变化。
控制项的测试示例
| 控制 | 自动验证 |
|---|---|
| 外发策略 | 受限数据无法路由到公有通道 |
| ABAC | 跨租户、跨角色、字段权限测试全通过 |
| 审计 | 关键请求 evidence 字段覆盖率 100% |
| 供应链 | 未登记或签名不匹配组件无法进入生产 |
| 删除 | 删除后向量、缓存、引用、Memory 不可再访问 |
| 例外 | 到期或范围外调用自动 deny |
十、SOC 联动与事件响应
当检测到异常外发、越权、注入诱导写操作、密钥泄露或供应链风险，控制面应能把安全事件和 AI 资产关联起来：
Alert
-> 根据 asset / release / policy / trace 定位影响面
-> 冻结模型通道、撤销凭据、关写工具、失效缓存
-> 保护 evidence bundle，按角色进行取证
-> 分级、通知、修复与恢复验证
-> 事故转成 red-team / regression / policy test恢复不是“服务又能响应”就结束。要确认权限、外发、缓存、异步任务和策略版本均已恢复到可信状态，并完成新的门禁和监控规则。
十一、系统设计题：Enterprise AI Governance Control Plane
核心模块
| 模块 | 职责 |
|---|---|
| Asset Registry | 应用、模型、Prompt、RAG、Agent、工具、数据资产与依赖图 |
| Risk & Approval | 场景评估、RACI、例外、复审周期 |
| Policy Control Plane | 策略编写、测试、版本、发布、决策 API |
| Identity Broker | 身份传播、短期 scope、委托、审批与 break-glass |
| Egress & Tool Gateway | 模型通道、DLP、区域、工具权限、网络出口 |
| Evidence Ledger | 防篡改审计、证据包、受控查询、保留/留置 |
| Supply Chain Registry | 组件签名、SBOM、Schema、兼容性、紧急冻结 |
| Continuous Assurance | 控制测试、漂移探针、例外到期、发布门禁 |
| Incident Console | 告警、定界、止血、取证、复盘和回灌 |
面试追问：控制面挂了怎么办
应答按“fail closed 与可用性平衡”展开：对受限数据外发和高危写工具默认 fail closed；低风险只读能力可使用短期缓存策略并强审计；策略缓存必须有版本、TTL、撤销通知和紧急全局 kill switch。不能为了可用性让高危控制失效后默认放行。
十二、项目讲法与反面回答
项目表达模板：
我们将模型、Prompt、知识库、Agent、MCP 工具和数据集登记到统一资产台账，发布时生成可查询的依赖图。每个场景先做风险评估，产出的数据等级、模型通道、工具权限和审计要求由 Policy Engine 在 RAG、模型网关和工具网关统一执行。身份通过短期 scoped token 传播，Agent 只能受限委托，写操作仍需审批和后端 ABAC。关键访问和策略决策落到 evidence ledger，供应链组件有版本、签名和兼容性检查。我们还把 ACL、外发、删除、审计覆盖和例外到期接入持续测试，安全事件会冻结受影响资产并自动回灌到门禁集。
反面回答：“我们做了脱敏、审批和日志。”
为什么不够：没有说明治理对象是否完整、规则是否可执行、身份是否可信、日志能否作为证据、供应链如何管理、例外何时失效、事故如何止血并防止复发。
速记
- 治理控制面的核心价值？把安全和合规规则转化为运行时决策、发布证据和持续验证。
- 为什么需要资产台账？没有依赖图，无法评估变更、定界事故或安全下线。
- Policy as Code 是什么？规则可版本化、评审、测试、灰度、回滚，并在多个网关一致执行。
- Agent 能代表用户做任何事吗？不能，必须用受限委托、ABAC、短期 scope 和职责分离。
- 审计日志为什么要防篡改？高危操作的执行者不应能无痕修改自己留下的证据。
- 供应链治理管什么？模型、插件、MCP、解析器、护栏、Schema、依赖、签名和漂移。
- 例外怎么管理？有范围、补偿控制、负责人、过期日，到期自动失效或冻结。
- 控制面失效后默认放行吗？受限数据外发和高危写操作应 fail closed。
继续阅读
- LLM 数据分级、外发治理与审计证据面试题：数据全生命周期与外发控制。
- AI 安全合规与治理：安全、合规、治理的基础框架。
- Agent 工具安全与权限边界：ABAC、审批、幂等和工具执行安全。
- MaaS 平台生产化高频问答：模型目录、租户、路由和平台治理。
- LLM 评测与发布门禁实战：将控制验证接入发布决策。