> For the complete documentation index, see [llms.txt](https://doras-dreamland-adventure.gitbook.io/enterprise-ai-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doras-dreamland-adventure.gitbook.io/enterprise-ai-transformation/di-wu-bu-fen-luo-di-pian/32-an-quan-yu-hu-lan.md).

# 第 32 章 · 安全与护栏

落地篇的最后一件事，是护栏。AI 上线之前，有几道防线必须先搭好，否则前面所有的努力，可能被一次事故一笔勾销。

先看要防的几类风险。第一类是幻觉和错误：AI 会自信地给出错的答案。对策是设人工核对的关口、用确定的系统去校验它的产出（第 3 章的两台机器），在高责任环节让它只做准备、不下定论。第二类是数据泄露和隐私：别把敏感数据随意喂给外部模型，要有权限、脱敏和清楚的边界（合规篇会展开）。第三类是被滥用和诱导：对外的场景，要防止 AI 被人诱导着说错话、做错事（第 18 章）。第四类是成本失控：要给用量设护栏，别让账单悄悄失控（运营篇会展开）。

但比起逐条列风险，更重要的是背后那个心法上的转变。传统的安全，追求的是"消灭漏洞、把错误归零"——找到 bug、修掉、不再犯。可 AI 的错误是概率性的，归不了零，只能压低。这意味着护栏的思路必须换一种：不是幻想造出一个永不出错的系统，而是像管理风险那样，去"经营"这些错误。多个模型交叉验证、对产出做抽样审计、保留可回滚的机制、限定权限、监控异常——这一整套，本质上是在管理一个"错误的投资组合"，承认错误一定会有，重点是让它可控、可发现、可挽回，而不是假装它不存在。从"消灭错误"到"经营错误"，是把 AI 用在关键场景时，风险思路上最要紧的一次转身。

护栏还要分层。不是所有场景都需要一样厚的防线——第 5 章说过，容错高的场景可以薄一点，容错低、后果重的场景必须厚。给一个内部的文案助手配上跟核电站一样严的审查，没有必要；而给一个能对外做承诺、或能动账的 Agent，护栏怎么厚都不为过。按后果的严重程度来配护栏的厚度，是把安全成本花在刀刃上的办法。

最后要说清护栏的目的。护栏不是越厚越好——过度的限制会让 AI 变得没法用，该发挥的价值也一并锁死了。护栏的意义，是让企业敢用，而不是不用：正因为有了可靠的兜底和监控，才敢把 AI 放进更有价值、也更需要谨慎的地方。把护栏当成"不出事的免责工具"，还是当成"敢往前走的安全带"，决定了它是拖累还是助力。

## 要点速查

* 四类风险与护栏：幻觉/错误（人核+确定系统校验+高责任只做准备）、数据泄露/隐私（权限/脱敏/边界）、被诱导滥用（对外防注入）、成本失控（用量护栏）。
* 核心心法（N6/R5）：传统安全"消灭错误、归零"；AI 错误归不了零，只能压低——从"消灭错误"转向"经营错误"（多模型交叉、抽样审计、可回滚、限权、监控）。
* 分层配比：按后果严重程度配护栏厚度（容错高薄、容错低厚），别一刀切。
* 护栏是为了敢用，不是为了不用；过厚会锁死价值。

## 给管理者的三步

* 现在：给每个要上线的 AI 场景，按后果严重程度定护栏厚度，别一刀切也别裸奔。
* 三个月：把"经营错误"的机制搭起来——抽样审计、可回滚、异常监控，至少覆盖高后果场景。
* 一年：形成一套分层的安全标准，让团队敢在有兜底的前提下，把 AI 用到更有价值的地方。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://doras-dreamland-adventure.gitbook.io/enterprise-ai-transformation/di-wu-bu-fen-luo-di-pian/32-an-quan-yu-hu-lan.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.