公司给员工开一个 AI 助手，常见担心很具体。客户身份证号会不会出现在回答里，用户能不能诱导它讲违规内容，内部客服会不会回答本来就不该接的话题。AI 护栏处理的正是这一段，它在输入和输出旁边加一组可配置的检查，命中规则时拦截、遮盖或返回预先写好的提示。
我查了 Amazon Bedrock Guardrails 当前列出的能力。这个产品可以检查用户输入和模型回答，内容过滤覆盖文字与图片，类别包括仇恨、侮辱、色情、暴力、不当行为和提示攻击。每类可以调过滤强度，企业不用拿一把同样的尺子处理招聘助手和儿童问答。
过滤器要跟业务问题对应
拒绝主题可以限制某些业务范围。银行客服若只负责账户服务，可以把非法投资建议列入拒绝范围。词语过滤适合拦固定词句，敏感信息过滤则能识别身份证号、生日、地址等个人信息，并选择直接阻止或遮盖。公司自己的订单号、会员号有固定格式时，还可以用正则表达式补一条识别规则。
这几类检查解决的问题并不相同。内容分类器判断一段话属于哪类风险，敏感信息规则寻找文本里的具体字段，拒绝主题处理产品允许谈什么。把它们全开到最高，会拦掉大量正常请求。只开最宽松，又可能让风险内容穿过去。配置时需要拿真实问法测试，并记录误拦和漏拦。
Bedrock 还提供自动推理检查，把回答与一组逻辑规则核对，用来发现不一致、未声明假设或可能的幻觉。它适合规则能写清的场景，比如退款条件和服务资格。规则本身若写错，检查也会跟着错，所以版本、负责人和修改记录都要保留。
护栏管不到全部业务责任
护栏能发现一部分内容风险，无法替公司决定谁有权退款、多少金额要主管批准、哪个客户记录可以被这名员工读取。它也不能保证模型给出的每个事实都正确。AWS 文档还明确写了，该页所述检查不覆盖推理内容块。接入方仍要限制工具权限，保存调用记录，并在高风险动作前加人工确认。
比较稳的做法是先做一份测试集。里面放正常请求、故意越界的请求、带个人信息的样本，以及容易被误拦的行业词。Guardrails 创建后会先得到一个工作草稿，可以在测试窗口里反复调整，满意后再创建固定版本。它也能通过 ApplyGuardrail 单独检查内容，不必每次都调用基础模型，适合在上线前批量跑样本。
护栏上线以后仍要定期回看拦截记录。业务新增产品，拒绝主题可能要改。客服开始处理新的证件，敏感信息规则也要补。真正可用的护栏会留下版本和测试结果，让人知道它今天拦什么，哪里仍要靠业务流程负责。