根据 152-FZ 在 LLM 中保护 PII 而不损失 UX

152-FZ合规下LLM中的个人身份信息保护：使用NestJS实现令牌替换

一家建筑公司开发AI助手用于客户线索处理时，发现一个关键风险：所有包含个人数据（PII）的用户消息都会直接发送至Google Gemini API。姓名、电话号码、电子邮件及客户公司信息被传送到境外服务器——这违反了俄罗斯《第152-FZ号联邦法》。跨境数据传输需向联邦通信监督局（Roskomnadzor）报备，并获得数据主体明确同意，违规最高可处300万卢布罚款。

解决方案：在将数据发送给模型前，用占位符替换PII。LLM处理的是匿名化文本，但仍能生成个性化回复。真实数据仅在最终输出阶段恢复。

令牌替换原理

该流程分为四个阶段：

• 在消息到达API前进行拦截。
• 将PII替换为占位符：[USER_NAME]、[USER_EMAIL]、[USER_COMPANY]、[PHONE]。
• 将掩码后的文本发送至LLM，接收包含令牌的响应。
• 在向用户展示结果前恢复真实数据。

LLM看到的是：“太好了，[USER_NAME]！我将为[USER_COMPANY]在[USER_EMAIL]准备报价。” 用户收到的则是自然流畅、包含其真实信息的文本。模型全程未接触原始PII。

生产环境实现：NestJS与WebSocket

基础模式看似简单，但流式LLM响应使执行复杂化。令牌通过WebSocket分块抵达，导致屏幕上出现闪烁的[USER_NAME]等占位符。

核心挑战与应对方案：

• 令牌跨块分割问题：若[USER_出现在一个数据块，而NAME]在另一个，则替换失败。通过缓冲机制解决：StreamingPiiRestorer类（每个流实例独立）会累积尾部片段，检测是否含闭合]，再发出完整令牌。
• 流水线绕过风险：原估算模块直接从PostgreSQL读取PII。现所有LLM调用均通过单一入口点统一管理。
• 正则表达式误判：估算中的金额和SKU被错误识别为INN或OGRN。采用分离规则：法人INN（10位）、自然人INN（12位）、OGRN（以1或5开头），并结合联邦税务署（FNS）校验规则验证。

五层安全架构

系统采用多层互补防护，确保全面安全：

第一层：已知PII的确定性替换。来自对话档案的姓名、邮箱、电话、公司信息。准确率高达99%。

第二层：正则扫描器动态识别PII。自动检测邮箱、电话、INN、OGRN、护照号、IP地址、信用卡号，并进行格式校验。

第三层：PostgreSQL加密存储。PII字段采用AES-256-GCM加密。密钥存于环境变量中，数据库快照无法读取。

第四层：HMAC审计日志。记录清洗后的文本 + 原始数据的HMAC-SHA256摘要（使用密钥）。既证明无泄露，又不暴露敏感信息。

第五层：按保留策略自动清除。定时任务每90天对旧对话中的PII进行匿名化处理（每次批量500条，无锁机制）。

业务与合规优势

数据始终保留在企业内部基础设施中。LLM保留对话上下文，但无法访问PII。面对Roskomnadzor审计时，可提供加密证明。

局限性：无联系方式的第三方名称（如“联系伊万”）不会被屏蔽——俄语命名实体识别准确率约65%-75%，存在少量误报。此类信息在152-FZ框架下不构成可追责的PII。

技术防护措施辅以行政手段：用户授权、向Roskomnadzor报备、与服务提供商签署数据处理协议（DPA）。

关键启示

• 令牌替换可在不损害用户体验的前提下，实现LLM零PII泄露。
• 流式缓冲机制有效解决WebSocket流中的令牌碎片问题。
• 单一入口点防止流水线绕过。
• HMAC日志提供可验证的合规证据。
• 保留策略自动化满足152-FZ的数据删除要求。

— Editorial Team