Auditoría de Desensibilización de Información Personal (privacy-audit)

Propósito

Realizar auditorías de cumplimiento de desensibilización de información personal en paquetes de skills locales, repositorios de código y directorios de datos, generando listas clasificadas de problemas e informes de auditoría estandarizados. Se basa en la legislación china: Ley de Protección de la Información Personal (Decreto Presidencial N.º 91), Ley de Seguridad de Datos, Ley de Seguridad Cibernética (revisión 2025), GB/T 35273-2020, GB/T 45574-2025 (en vigor desde el 1 de noviembre de 2025), GB/T 43697-2024, Medidas para la Gestión de Auditorías de Cumplimiento de la Protección de la Información Personal (en vigor desde el 1 de mayo de 2025), etc. La auditoría es estricta: cualquier tratamiento sin una base legal clara se considera "prohibido".

Escenarios de aplicación: control de seguridad antes de la publicación de skills de IA/código/documentos, verificación de desensibilización antes de compartir conjuntos de datos, investigación de fugas en registros y configuraciones, elaboración de informes de auditoría de cumplimiento. Diferenciación del posicionamiento: Este skill es una "revisión/auditoría" (detección + clasificación + recomendaciones de corrección + índice de normas), no un "ejecutor de desensibilización". Para escenarios que requieran enmascaramiento o reemplazo directo de datos, utilice skills de herramientas de desensibilización; este skill se encarga de determinar de antemano "si se debe publicar, dónde hay infracciones y según qué norma". Posicionamiento comercial (v1.2.0): Orientado al escenario de "autocontrol de cumplimiento antes de publicar un skill/aplicación de IA". Compatible con plataformas conversacionales como 扣子 (el usuario puede subir archivos o pegar texto para escanear, sin necesidad de un directorio local). Puede comercializarse como un skill de pago.

Palabras clave de activación

auditoría de desensibilización / auditoría de privacidad / verificación de cumplimiento de privacidad / revisión de cumplimiento / auditoría de protección de privacidad
escaneo de información sensible / escaneo de PII / detección de campos sensibles / escaneo de información personal / investigación de fugas de datos
escanea este directorio en busca de información personal / escanea este skill en busca de información personal
escaneo de DNI / verifica si el código contiene números de teléfono / números de identificación / fugas de números de tarjeta bancaria
¿hay claves hardcodeadas en el repositorio? / ¿hay contraseñas en texto plano en los registros? / ¿hay información sensible en el archivo subido?
¿este skill filtra privacidad? / ¿se puede publicar este skill? / ¿se debe desensibilizar antes de compartir? / verificación de desensibilización de conjuntos de datos
recomendaciones de corrección de desensibilización / elaborar un informe de auditoría de cumplimiento / control de seguridad previo a la publicación / revisión de cumplimiento previa al lanzamiento

Preparación del entorno

# Dependencias: Python 3.8+, solo biblioteca estándar, sin dependencias de terceros
export SKILL_DIR=~/.workbuddy/skills/privacy-audit   # Ruta de instalación del skill
export TARGET_DIR=/path/to/directorio-a-auditar       # Directorio a auditar (código/skill/datos)
export REPORT_DIR=/path/to/directorio-de-informes     # Se recomienda fuera del directorio escaneado para evitar auto-hits

Flujo de ejecución

Primer paso: Escaneo automático L1 (primero máquina, después humano)

# Escaneo de un solo directorio + informe JSON
python3 "$SKILL_DIR/scripts/privacy_audit.py" "$TARGET_DIR" \
  --rules "$SKILL_DIR/scripts/biblioteca-regex-campos.json" \
  --json "$REPORT_DIR/audit_result.json"

# v1.1.0 Escaneo de múltiples directorios (auditoría combinada) + informe HTML visual
python3 "$SKILL_DIR/scripts/privacy_audit.py" "$TARGET_DIR_A" "$TARGET_DIR_B" \
  --rules "$SKILL_DIR/scripts/biblioteca-regex-campos.json" \
  --json "$REPORT_DIR/audit_result.json" \
  --html "$REPORT_DIR/audit_result.html"

Escanea 17 tipos de campos sensibles: N.º de identificación / N.º de teléfono / N.º de tarjeta bancaria / Correo electrónico / IP / Dirección exacta / Coordenadas de ubicación precisa / Nombre del médico / Nombre de la institución hospitalaria / Contraseña en texto plano / Información de salud médica / Información de menores / N.º de matrícula / N.º de pasaporte / ID de WeChat / N.º de QQ / Código de crédito social unificado (nuevo en v1.1.0)
Detecta 5 tipos de credenciales hardcodeadas: clave SkillHub / token GitHub / clave OpenAI / SecretId de Tencent Cloud / credencial temporal COS
Códigos de salida (se pueden integrar en CI): 0=Aprobado; 1=Alto riesgo (prohibido publicar); 2=Riesgo medio (requiere confirmación manual)
--json: Informe estructurado (contiene scanned_roots/summary/verdict/findings, consumible por CI); --html: Informe visual autónomo (tarjeta de resumen + gráfico de distribución por nivel + lista de hits agrupada por archivo, visible sin conexión)
--strict: Los hits de nivel general también se consideran fallo; --quiet: Solo muestra la línea de resultado

Escaneo conversacional (nuevo en v1.2.0, adaptado para escenarios conversacionales como 扣子, sin necesidad de directorio local):

# Escaneo de un solo archivo (archivo subido por el usuario, como .py/.md/.json/.txt, etc.)
python3 "$SKILL_DIR/scripts/privacy_audit.py" --file /ruta/al/archivo_subido.py \
  --rules "$SKILL_DIR/scripts/biblioteca-regex-campos.json" \
  --json "$REPORT_DIR/audit_result.json"

# Escaneo de contenido de texto (código o fragmento de texto pegado por el usuario)
python3 "$SKILL_DIR/scripts/privacy_audit.py" --text "contenido de texto a auditar" \
  --rules "$SKILL_DIR/scripts/biblioteca-regex-campos.json"

# Escaneo de entrada estándar (tubería)
echo "texto a auditar" | python3 "$SKILL_DIR/scripts/privacy_audit.py" --stdin \
  --rules "$SKILL_DIR/scripts/biblioteca-regex-campos.json"

Segundo paso: Revisión completa L2 (comparación manual de seis dimensiones)

Utilice references/norma-desensibilizacion-info-personal.md como base de ejecución y verifique dimensión por dimensión:

Identificación y clasificación: Integridad de la lista de campos, etiquetado de nivel de sensibilidad, riesgo de reidentificación por combinación, etiquetado especial de menores
Método y escenario de desensibilización: Si la elección de desidentificación/anonimización coincide con el nivel de sensibilidad (irreversible prioritario; si es reversible, debe haber control de claves)
Desensibilización a nivel de campo: Verificación campo por campo en los cuatro eslabones de almacenamiento/mostración/transmisión/compartición (énfasis: DNI/tarjeta bancaria deben almacenarse cifrados; máscara por defecto en la interfaz; los registros no deben contener texto plano)
Proceso y lista de verificación: Marcar uno por uno los 33 ítems (A identificación previa 5 / B almacenamiento 6 / C visualización 6 / D registros 4 / E uso compartido 5 / F pruebas 2 / G garantía técnica 6)
Investigación de escenarios de infracción: Investigar uno por uno los 15 escenarios de infracción comunes (almacenamiento en texto plano, interfaz sin máscara, recopilación excesiva, consentimiento marcado automáticamente, reconocimiento facial obligatorio, texto plano en registros, filtración no notificada, venta de datos, evaluación transfronteriza no realizada, etc.)
Verificación de base normativa: Los nombres de las normas/números de decreto/fechas y los números de estándares nacionales deben basarse en la sexta parte de la norma, sin modificaciones

Tercer paso: Corrección y verificación

Los riesgos altos (P0) deben corregirse: Eliminar credenciales hardcodeadas → variables de entorno/gestión de claves; datos sensibles en texto plano → almacenamiento cifrado + visualización con máscara
Después de la corrección, vuelva a ejecutar el escaneo L1 para confirmar que el código de salida se reduce a 0 (o solo quedan riesgos bajos)
Los riesgos medios (P1) se recomienda corregirlos en la próxima iteración; los riesgos bajos (P2) se registran para optimización posterior

Cuarto paso: Generar informe estándar

Genere el informe siguiendo la estructura de references/plantilla-informe-auditoria.md: Objeto de auditoría y perfil de datos → Resumen de resultados → Lista clasificada de problemas (P0/P1/P2) → Verificación de ítems de cumplimiento → Prioridad de corrección → Tabla comparativa de lista de verificación → Conclusión y descargo de responsabilidad.

Lista de dependencias

Python 3.8+ (biblioteca estándar: argparse / json / os / re / sys)
Sin dependencias de terceros; opcional --json para informe estructurado consumible por CI

Límites y seguridad (línea roja)

No constituye asesoramiento legal: Las conclusiones del informe deben combinarse con el escenario comercial específico; los escenarios de alta sensibilidad requieren revisión manual + consulta con un abogado especializado en cumplimiento
El informe debe generarse fuera del directorio escaneado: Para evitar que el informe de auditoría sea escaneado y también para evitar que caiga en el producto final a publicar
Íntegramente local: No llama a ninguna API en la nube, no transmite el contenido auditado
Omitir binarios: No escanea .zip/.png/.pdf/.docx/.xlsx/.pyc, etc. (si es necesario escanear, descomprimir/convertir a texto primero)
Prohibido eliminar: Este skill solo informa, no elimina ni modifica ningún archivo auditado

Errores incorporados (lecciones aprendidas, no repetir)

Error	Causa raíz	Solución (ya incorporada en el script)
Constantes de coordenadas/cadenas numéricas largas se detectan erróneamente como DNI/tarjeta bancaria	La regex pura solo coincide con la "forma" sin verificar la "validez"	Verificación del dígito de control MOD 11-2 para DNI, verificación Luhn para tarjeta bancaria; si falla, se omite como falso positivo
Los números internos del DNI son detectados nuevamente por regex de teléfono/tarjeta bancaria	Conflicto de prioridad de regex	Deduplicación de intervalos: si el intervalo de un hit cae completamente dentro de otro hit de mayor prioridad → se omite (por ejemplo, los 6 dígitos que comienzan con 110101 no se detectarán erróneamente como número de teléfono)
Cadenas numéricas largas (por ejemplo, constantes de coordenadas como 0.00669342162296594323) detectadas como número de teléfono	La regex de teléfono no tiene límite	Agregar límite de dígitos anterior y posterior a la regex de teléfono `(?<![0-9])…(?![0-9])`
El informe de auditoría escrito en el directorio escaneado es escaneado nuevamente	El informe en sí contiene "ejemplos de hit"	Generar el informe fuera del directorio escaneado (--json apunta a un directorio externo)
Codificación incorrecta de archivos chinos en Windows	El archivo puede ser GBK en lugar de UTF-8	read_text primero intenta UTF-8, si falla, decodifica según la proporción de caracteres imprimibles
Directorios grandes como node_modules/.git ralentizan el escaneo	Sin filtro, se escanea todo	SKIP_DIRS incorporado (.git/pycache/node_modules/.venv/dist/build, etc.)
El script se comporta de manera inconsistente después de agregar nuevos campos en el JSON de la biblioteca de regex	La biblioteca de regex está separada del script, lo que causa desincronización	El JSON de la biblioteca de regex es la única fuente de verdad, el script lo carga dinámicamente; para agregar un nuevo tipo de campo, primero modifique el JSON y luego ejecute el script
El texto de definición de patrón en el JSON de la biblioteca de regex se detecta a sí mismo (por ejemplo, las palabras "Hospital del Pueblo" aparecen en la regex de nombres de hospital)	La definición de la regla es en sí misma una muestra de palabra sensible	Es un fenómeno normal; cuando ocurre un hit durante la autoinspección, confirme manualmente que es una definición de patrón e ignórelo (dirección conservadora, mejor REVISAR que no detectar)
"Beijing A12345" (nombre de lugar + números) se detecta erróneamente como número de matrícula	La regex de matrícula no tiene límite, la subcadena "Beijing A12345" coincide	Agregar límite de caracteres chinos/letras/dígitos anterior y posterior a la regex de matrícula `(?<!…)(?<!["\u4e00-\u9fa5"])…(?![…])`, doble seguro con validador de estructura (provincia + letra + longitud 7/8)
Una cadena numérica aleatoria de 18 dígitos tiene aproximadamente 1/31 de probabilidad de pasar la verificación GB 32100 del código de crédito social unificado	La verificación módulo 31 permite naturalmente cadenas aleatorias	USCC se posiciona como "sensibilidad media" (REVIEW requiere confirmación manual) en lugar de alta sensibilidad, precisamente como red de seguridad; las pruebas de control negativo utilizan el último dígito real ilegal
Las etiquetas de muestra de prueba se detectan a sí mismas (por ejemplo, "falso WeChat ID: xxx" es detectado por la regex de WeChat ID)	La etiqueta en sí contiene el prefijo de activación + formato legal	Es un comportamiento correcto (en un escenario real, "WeChat ID: xxx" debería ser detectado); al diseñar muestras de prueba, evite repetir el prefijo de activación en la etiqueta
Los casos de `evals/` contienen muestras sensibles ficticias que hacen que `preflight --strict` informe alertas de teléfono/correo electrónico	Los casos de prueba deben tener muestras con forma real para probar la capacidad de detección, y la puerta de seguridad de publicación no distingue entre real y ficticio	Al realizar la autocontrol de publicación, use `--waive phone --waive email --reason "los casos evals contienen muestras de prueba ficticias, no son datos personales reales"` para eximir y dejar rastro; elimine `.preflight-waiver.json` antes de publicar; la primera línea de los archivos de muestra debe etiquetarse uniformemente con "Datos de prueba ficticios"
Una cadena numérica aleatoria de 18 dígitos (como marca de tiempo + número secuencial) tiene aproximadamente 1/11 de probabilidad de pasar la verificación del dígito de control MOD 11-2 del DNI y ser detectada erróneamente	El dígito de control solo garantiza la legalidad, no la autenticidad; las cadenas aleatorias tienen naturalmente una probabilidad de pasar	Es una limitación conocida: después de la confirmación manual de que es un número secuencial/marca de tiempo/número de serie, ignórelo; no relaje la regex por esto (mejor REVISAR que no detectar)

Ejemplo de uso (simulación conversacional)

Usuario: Revisa el directorio ~/projects/skill-demo, ¿se puede publicar?
Agente:
  1. Ejecutar escaneo L1:
     python3 ~/.workbuddy/skills/privacy-audit/scripts/privacy_audit.py ~/projects/skill-demo \
       --rules ~/.workbuddy/skills/privacy-audit/scripts/biblioteca-regex-campos.json --json ~/reports/demo_audit.json
  2. Código de salida 1 → 2 hits de alto riesgo (token GitHub hardcodeado + DNI en texto plano) → Se determina que está prohibido publicar
  3. Realizar verificación L2 de seis dimensiones según la "Norma de revisión": almacenamiento no cifrado, visualización sin máscara, registros con texto plano…
  4. Generar lista clasificada de problemas (H-1 token hardcodeado / H-2 almacenamiento de DNI en texto plano / M-1 registros en texto plano…)
  5. Recomendaciones de corrección + informe estándar → El usuario corrige y vuelve a ejecutar L1 → Código de salida 0 → Se permite publicar

Documentos de referencia

references/norma-desensibilizacion-info-personal.md: Norma completa de seis dimensiones (capas L1/L2, lista de 33 ítems, 15 escenarios de infracción, índice de 18 leyes + 6 estándares nacionales, instrucciones de herramientas del apéndice) — la única base fáctica para la ejecución de la auditoría
references/puntos-clave-desensibilizacion-info-personal.md: Puntos clave de seis dimensiones (antecedentes normativos y explicación detallada de las dimensiones de juicio; la fuente oficial = leyes, regulaciones y estándares nacionales, consenso de la comunidad = casos típicos públicos de aplicación de la ley/judiciales y prácticas de la industria)
references/plantilla-informe-auditoria.md: Plantilla de estructura de informe estándar L2
references/Changelog.md: Única fuente fáctica del historial de versiones (registro completo de cambios desde 1.0.0 hasta la versión actual y descripción del alcance de las versiones)
evals/: Conjunto de evaluación de regresión (10 casos de prueba ejecutables + conjunto de intenciones de palabras clave trigger_eval.json), después de modificar este skill, ejecute una vez para verificar que no se hayan dañado las capacidades existentes; consulte evals/README.md para la ejecución

Versión y fuentes fácticas

El número de versión actual se basa en el version del frontmatter de SKILL.md; la etiqueta de publicación, el resumen de versión en README y la entrada de versión actual en references/Changelog.md deben estar alineados con él.
Los cambios históricos se basan en references/Changelog.md como la única fuente fáctica. Los Changelogs en SKILL.md y README son solo resúmenes de las dos últimas versiones + un enlace a ese archivo, no registre un historial de versiones completo en varios lugares; si se mantienen tres versiones completas en paralelo, inevitablemente divergirán.
Las anotaciones "nuevo en v1.1.0" / "nuevo en v1.2.0" en el texto son etiquetas de pertenencia de funcionalidad: indican en qué versión apareció por primera vez esa funcionalidad, son registros históricos y no cambian con el número de versión actual (la versión actual ya es 1.3.0, la anotación se mantiene igual).
"version": "1.1.0" en scripts/biblioteca-regex-campos.json es la versión de la biblioteca de reglas: independiente de la versión del skill, solo se incrementa cuando los tipos de campo, las regex o los validadores cambian realmente. 1.2.0 solo modificó los puntos de entrada de escaneo (--file/--text/--stdin) sin cambiar las reglas, por lo que la biblioteca de reglas sigue siendo 1.1.0 — este es el estado correcto, no es un error tipográfico, no lo "alinee sin pensar".

Changelog

El historial de versiones completo se encuentra en references/Changelog.md (única fuente fáctica), la siguiente tabla es un resumen de las dos últimas versiones.

| Fecha | Versión | Tipo de cambio | Contenido del cambio | Fuente | |---|---|---|---| | 2026-09-06 | 1.3.1 | Optimización | Se agregaron etiquetas internas de la plataforma (protección de privacidad/desensibilización/PII/protección de información personal, etc., 6 en total), sin cambios funcionales | Optimización de SkillHub | | 2026-08-29 | 1.3.0 | Optimización | Cobertura de palabras clave del 58% al 100% (se agregaron 16 intenciones en el conjunto evals/trigger_eval.json + se ampliaron los clústeres de palabras clave a 30); la descripción se redujo de 444 caracteres a 238, los detalles se trasladaron al texto; se agregó el conjunto de evaluación de regresión ejecutable evals/ con 10 casos (puntuación media de --run --aggregate 1.00); se agregó references/Changelog.md; se estableció la versión y el historial de versiones como dos fuentes fácticas | Corrección del informe de salud | | 2026-08-19 | 1.2.0 | Nuevo | El script agregó puntos de entrada de escaneo de archivo único/texto/entrada estándar (--text/--stdin/--file, adaptado para entrada conversacional de 扣子, sin necesidad de directorio local); el posicionamiento se centró en "puerta de seguridad de cumplimiento previo a la publicación"; se agregó la descripción del posicionamiento comercial | Adaptación para 扣子 |

(Las entradas de la versión 1.1.0 y anteriores se encuentran en references/Changelog.md)

Descargo de responsabilidad

Este skill ha sido generado con asistencia de IA y es solo para fines de referencia. No constituye asesoramiento legal formal y no puede reemplazar a un abogado colegiado. Las decisiones de cumplimiento específicas deben consultarse con profesionales legales en el contexto comercial correspondiente, y deben basarse en las leyes y regulaciones vigentes más recientes.

privacy-audit (审查/审计 de datos personales)

¿Qué es 审计 de datos personales)?

Preguntar en tu IA favorita

Documentación