4、请求分类与优先级：自动化分类算法、紧急请求标记、SLA时间线管理

好，咱们进入第四讲。说实话，这一章是实战中特别容易「翻车」的地方。你想想看，每天几十上百个数据主体请求涌进来，要是全靠人工一个个看，那效率得多低？我见过不少公司，一开始都是靠Excel表格手动打标签，结果呢？要么漏掉了紧急请求，要么把简单问题拖成了投诉。

所以这一讲，咱们重点聊三件事：怎么让机器帮你自动分类、怎么一眼认出紧急请求、以及怎么管好SLA这条生命线。

4.1 自动化分类算法：别让规则写死，让模型学起来

先说说分类。很多人一上来就写if-else规则：包含「删除」就归为删除请求，包含「访问」就归为访问请求。嗯，这种做法在初期还行，但一旦请求文本变得复杂，比如用户写「请把我所有数据都清掉，但我要先看看你们存了什么」，这种混合意图，规则就傻眼了。

我个人习惯用轻量级文本分类模型。比如基于BERT的微调模型，或者更轻量的FastText。你不需要自己从零训练，用现成的预训练模型，拿你们公司过去一年标注好的请求数据做微调就行。

这里给一个简单的分类流程示例：

# 伪代码：请求分类流水线
def classify_request(text):
    # 1. 预处理：去除特殊字符，统一小写
    cleaned = preprocess(text)
    
    # 2. 意图识别：用微调后的BERT模型
    intent = intent_model.predict(cleaned)
    # 返回类型：'access', 'deletion', 'rectification', 'portability', 'objection'
    
    # 3. 实体抽取：提取用户ID、数据范围、时间范围
    entities = ner_model.extract(cleaned)
    
    # 4. 规则兜底：如果模型置信度低于0.6，走规则引擎
    if intent.confidence < 0.6:
        intent = rule_based_classifier(cleaned)
    
    return intent, entities

我在项目中遇到过一个问题：模型对「删除」和「匿名化」经常分不清。后来发现是因为训练数据里，很多用户把「匿名化」也写成了「删掉我的数据」。解决办法是——在训练数据里专门加了一批「删除 vs 匿名化」的对比样本，准确率直接从82%提到了94%。

4.2 紧急请求标记：哪些请求必须「插队」？

分类搞定了，接下来是优先级。不是所有请求都值得你立刻响应。我见过最夸张的情况——有人把「我想看看你们存了我什么照片」这种普通访问请求，标记成了「紧急」，结果真正需要紧急处理的「撤回同意」请求反而被压在了下面。

那么，哪些请求应该被标记为紧急？我个人总结了三类：

• 涉及敏感数据的删除/撤回同意：比如用户明确要求删除生物识别信息、健康数据、金融数据。这类请求一旦延迟，合规风险极高。
• 来自监管机构或律师的请求：这类请求通常有法律时效，拖一天都可能被罚款。
• 用户明确标注「紧急」或「投诉」的请求：虽然不能全信，但至少要提高警惕。

怎么自动标记？我建议用关键词+情感分析的组合：

# 紧急请求标记逻辑
def flag_urgent(text, user_info):
    urgent_keywords = ['立即', '紧急', '投诉', '律师', '监管', 'GDPR罚款']
    sensitive_data_keywords = ['指纹', '人脸', '基因', '病历', '银行账户']
    
    # 检查关键词
    has_urgent_word = any(kw in text for kw in urgent_keywords)
    has_sensitive = any(kw in text for kw in sensitive_data_keywords)
    
    # 情感分析：检测愤怒或焦虑情绪
    sentiment = sentiment_analyzer(text)
    is_emotional = sentiment.label in ['anger', 'fear'] and sentiment.score > 0.8
    
    # 综合判断
    if has_urgent_word or (has_sensitive and is_emotional):
        return True, 'high_priority'
    elif has_sensitive:
        return True, 'medium_priority'
    else:
        return False, 'normal'

我曾经踩过一个坑：有个用户写「我真的很生气，你们再不处理我就找律师了」，情感分析直接给了高分，标记为紧急。结果一看，他其实只是想修改一下邮箱地址。嗯，从那以后我加了一条规则——如果请求类型是「修改」或「查询」，即使情感分高，也只标记为中等优先级。因为真正紧急的删除或撤回同意，用户通常不会用「修改」这个意图。

4.3 SLA时间线管理：别让承诺变成空话

分类和优先级都搞定了，最后一步是管好时间线。GDPR要求一个月内响应，CCPA要求45天内。但说实话，不同请求类型的处理时间差别很大。你想想看，一个「访问请求」可能只需要查数据库，而一个「删除请求」可能要跨系统清理备份，时间完全不一样。

我建议按请求类型设定不同的SLA：

怎么管理这些时间线？我推荐用状态机+定时任务。每个请求从创建开始，就进入一个状态机：

# SLA时间线管理状态机
class RequestStateMachine:
    def __init__(self, request_type, priority):
        self.state = 'created'
        self.sla_deadline = calculate_sla(request_type, priority)
        self.escalation_threshold = self.sla_deadline - timedelta(days=3)
    
    def transition(self, event):
        if event == 'assign':
            self.state = 'in_progress'
        elif event == 'need_info':
            self.state = 'waiting_for_user'
            # 暂停SLA计时
            self.sla_paused = True
        elif event == 'complete':
            self.state = 'resolved'
        # 每天检查一次
        if datetime.now() > self.escalation_threshold and self.state != 'resolved':
            send_alert('SLA即将超期，请尽快处理')

这里有个细节：等待用户补充信息的时间，要不要算在SLA里？ 我个人建议不算。因为很多时候是用户自己没写清楚，你不能为这个背锅。但要注意——你得有记录证明你在等用户回复。我习惯在系统里自动发一封邮件：「我们已收到您的请求，但需要您补充以下信息...」，然后把计时器暂停。等用户回复了，再重新开始计时。

4.4 实战中的避坑指南

最后，分享几个我踩过的坑，希望能帮你少走弯路：

• 别把所有请求都往一个队列里塞：我曾经犯过这个错，结果紧急请求和普通请求混在一起，处理人员只能按时间顺序一个个看。后来我分了三个队列：紧急队列（红色）、普通队列（黄色）、低优先级队列（绿色），每个队列有独立的处理人员。
• 自动化分类的准确率要定期复盘：我建议每个月抽100条请求，人工复核一下分类结果。如果发现某个类别的准确率下降了，赶紧检查是不是有新的请求模式出现了。
• SLA超期了怎么办？ 别慌。先发一封道歉邮件，说明原因和预计完成时间。然后内部启动升级流程——我习惯在超期当天自动通知部门主管，超期3天通知法务，超期7天通知CEO。压力层层传递，问题才能被重视。

嗯，这一讲的内容差不多就这些。说白了，请求分类和优先级管理，就是让你在有限的人力下，把资源用在最该用的地方。下一讲咱们聊聊「数据主体请求的验证与身份确认」——这个环节要是做不好，前面所有工作都可能白费。