AI 助手的隐私困境：你的数据安全吗？
当你让 AI 助手帮你处理邮件、分析文档、管理日程时，你实际上在把大量个人数据交给它。这些数据中可能包含手机号、身份证号、银行卡号、家庭住址、商业机密……如果这些信息原封不动地发送到云端 AI 模型，隐私风险不言而喻。
OpenClaw 深知这个问题的重要性，提供了从输入过滤到输出脱敏的全链路隐私保护方案。本文将详细介绍如何在实际使用中确保敏感信息不被泄露。
隐私保护的三道防线
OpenClaw 的隐私保护架构采用纵深防御策略，包含三道防线：
- 输入过滤：在用户消息发送给模型之前，自动检测并替换敏感信息
- 上下文隔离：不同会话之间严格隔离，防止隐私数据交叉泄露
- 输出脱敏：模型返回的结果经过二次检查，确保不会泄露敏感信息
第一道防线：输入过滤（Pre-filter）
输入过滤是最关键的一道防线。OpenClaw 使用多模式匹配引擎，在消息发送到模型之前自动检测和替换敏感信息。
内置敏感信息识别器
# OpenClaw 隐私过滤配置
privacy:
input_filter:
enabled: true
rules:
- type: phone # 手机号
pattern: "1[3-9]\\d{9}"
replacement: "[PHONE_REDACTED]"
- type: id_card # 身份证号
pattern: "[1-9]\\d{5}(19|20)\\d{2}(0[1-9]|1[0-2])\\d{2}\\d{3}[\\dXx]"
replacement: "[ID_REDACTED]"
- type: bank_card # 银行卡号
pattern: "\\d{16,19}"
replacement: "[BANK_REDACTED]"
- type: email # 邮箱地址
pattern: "[\\w.-]+@[\\w.-]+\\.\\w+"
replacement: "[EMAIL_REDACTED]"
- type: api_key # API 密钥
pattern: "(sk|pk|ghp|gho)_[\\w-]{20,}"
replacement: "[API_KEY_REDACTED]"每个规则包含三个要素：
- type：敏感信息类型标识，用于日志记录和审计
- pattern：正则表达式匹配模式
- replacement：替换文本，使用占位符让模型理解此处有数据但不暴露真实值
智能替换 vs 简单替换
简单的文本替换会破坏上下文语义。比如”我的手机号是 13800138000，请帮我查一下账单”，替换后变成”我的手机号是 [PHONE_REDACTED]，请帮我查一下账单”——模型仍然可以理解意图并正常工作。
但更高级的做法是同态替换：用一个格式相同但值不同的假数据替换，让模型甚至察觉不到过滤的发生：
# 同态替换配置
privacy:
input_filter:
homomorphic_replace: true
mappings:
phone: "13800000000" # 保留格式，替换为统一占位号
id_card: "110101199001011234"
email: "user@example.com"
bank_card: "6222000000000000000"这样模型看到的是完全合法格式的数据，可以正常处理逻辑，但真实信息不会泄露到云端。
第二道防线：上下文隔离
即使输入过滤做得到位，如果不同用户的上下文混在一起，仍然有泄露风险。OpenClaw 的上下文隔离机制确保：
会话级隔离
# 会话隔离配置
session:
isolation: strict # 严格隔离模式
cross_session_access: false # 禁止跨会话访问
memory_scope: session # 记忆系统仅限当前会话strict 模式下，每个会话有独立的上下文空间，AI 无法访问其他会话的数据。这在多用户场景下尤为重要——你不会希望 AI 把 A 用户的信息告诉 B 用户。
多租户隔离
对于团队部署，OpenClaw 支持租户级别的隔离：
# 多租户配置
tenants:
- id: team-alpha
isolation: full
data_directory: /data/alpha
memory_scope: tenant
- id: team-beta
isolation: full
data_directory: /data/beta
memory_scope: tenant每个租户有独立的数据目录和记忆空间，物理隔离确保数据不会交叉。
第三道防线：输出脱敏（Post-filter）
即使输入已过滤，模型有时仍可能基于推理”还原”出敏感信息。比如用户说”帮我记住我的手机号是 [PHONE_REDACTED]”，模型回复时可能说”好的，我记住了你的手机号 138…”——这种情况需要输出脱敏来兜底。
# 输出脱敏配置
privacy:
output_filter:
enabled: true
rules:
- type: phone
action: redact # 脱敏处理
format: "138****8000" # 保留前3后4位
- type: id_card
action: redact
format: "110101********1234" # 保留前6后4位
- type: bank_card
action: redact
format: "6222****0000" # 保留前4后4位输出脱敏的 format 支持灵活的掩码模式：用星号替代中间部分，保留足够信息让用户确认是哪条数据，但不暴露完整值。
实战：构建一个隐私安全的邮件助手
让我们用实际场景走一遍完整流程。假设你要让 AI 帮你处理邮件，邮件中可能包含各种敏感信息。
# 邮件助手隐私配置
privacy:
input_filter:
enabled: true
homomorphic_replace: true
rules:
- type: phone
- type: id_card
- type: email
- type: bank_card
- type: api_key
output_filter:
enabled: true
custom_rules:
# 企业自定义：检测客户姓名
- type: customer_name
pattern: "客户[：:]\\s*[\\u4e00-\\u9fa5]{2,4}"
replacement: "[CUSTOMER_REDACTED]"
# 企业自定义：检测订单号
- type: order_id
pattern: "ORD-\\d{12}"
replacement: "[ORDER_REDACTED]"配置完成后，当 AI 处理邮件时：
- 输入阶段：邮件中的手机号、身份证号等被自动替换为占位符
- 处理阶段：AI 基于替换后的内容正常理解意图、执行操作
- 输出阶段：回复内容经过脱敏检查，确保不泄露敏感信息
审计日志：隐私操作的完整追踪
隐私保护不能只有技术手段，还需要可审计。OpenClaw 记录所有隐私相关的操作：
# 审计日志配置
audit:
enabled: true
log_path: /var/log/openclaw/privacy.log
events:
- input_filtered # 输入过滤事件
- output_redacted # 输出脱敏事件
- filter_bypass # 过滤绕过尝试
retention_days: 90 # 日志保留90天每条审计日志包含：时间戳、会话ID、触发规则类型、原始值哈希（不记录原始值）、替换动作。这既满足了合规审计要求，又不会在日志中引入新的泄露风险。
本地模型的终极隐私方案
如果你对数据上云有严格限制，终极方案是使用本地模型。通过 Ollama 在本地部署大模型，所有数据处理都在本地完成，数据完全不离开你的机器。OpenClaw 对 Ollama 有一等公民支持，配置非常简单：
# 切换到本地模型
models:
default: ollama/llama3:8b
# 敏感场景自动路由到本地模型
router:
- condition: "contains_pii(message)"
model: ollama/llama3:8b甚至可以做到自动检测：如果消息中检测到 PII（个人身份信息），自动路由到本地模型处理；普通消息则使用云端模型获得更好的效果。
总结
数据隐私保护不是可选项，而是 AI 助手的基本要求。OpenClaw 通过输入过滤、上下文隔离、输出脱敏三道防线，加上审计日志和本地模型支持，构建了完整的隐私保护体系。关键原则是：默认安全、最小暴露、可审计追踪。在生产环境中部署 AI 助手时，请务必启用并配置好这些隐私保护功能——这不是额外工作，而是上线前的必要步骤。
