Capturas de pantalla y datos personales en bases de conocimiento
Las bases de conocimiento internas — Confluence, Notion, SharePoint, GitBook — acumulan un tipo específico de problema de datos personales que las herramientas estándar de cumplimiento no detectan: datos personales de clientes incrustados en capturas de pantalla usadas para documentar procesos.
El patrón se repite en miles de equipos de soporte y operaciones.
Un agente de soporte descubre una configuración de cuenta inusual. Toma una captura de pantalla de la página de la cuenta del cliente para documentar el problema. La captura muestra el nombre del cliente en el encabezado de la interfaz, su correo en la configuración de cuenta y los detalles de su plan.
El artículo se publica en la base de conocimiento interna. Ciento cincuenta agentes de soporte pueden verlo ahora. Doce contratistas del helpdesk externo también. El artículo es útil. Explica cómo gestionar ese caso especial. Todo agente que encuentre esa configuración en el futuro lo leerá.
Tres años después, la base de conocimiento contiene 847 artículos de este tipo. Cada uno incluye capturas de cuentas de clientes. Los clientes que aparecen en ellas no consintieron este uso secundario de sus datos. La mayoría no sabe que su información está almacenada allí.
No es un problema menor. Crece con cada nuevo artículo.
Riesgos del RGPD: por qué importa
El análisis del RGPD para capturas de pantalla en bases de conocimiento es directo.
Minimización de datos (Artículo 5(1)(c)): Los datos personales deben ser «adecuados, pertinentes y limitados a lo necesario». Un artículo sobre configuración de cuenta no necesita el nombre real ni el correo del cliente. Una captura con datos difuminados cumple el propósito igual de bien. Incluir datos reales del cliente no es necesario.
Limitación de la finalidad (Artículo 5(1)(b)): Los datos recopilados para un propósito — atención al cliente — no pueden reutilizarse para otro — documentación interna de procesos — sin base jurídica. Los datos de cuenta se recopilaron para prestar el servicio, no para artículos internos. Son dos finalidades distintas. Usar los mismos datos para ambas requiere una base legal que la mayoría de los equipos no ha establecido.
Control de acceso (Artículo 5(1)(f) y Artículo 32): Las medidas técnicas apropiadas deben proteger los datos personales. Las capturas de cuentas de clientes en una herramienta accesible para los 150 agentes y contratistas — incluidos los que no tienen acceso al sistema de cuentas — generan un acceso excesivamente amplio.
Derecho de supresión (Artículo 17): Una persona que solicita la supresión tiene derecho a que se eliminen sus datos «sin dilación indebida». Si sus datos aparecen en 23 artículos como capturas incrustadas, la solicitud exige encontrar y actualizar los 23 artículos. Eso es difícil sin un sistema. Nuestra guía sobre el derecho de supresión del RGPD detalla los pasos.
No son interpretaciones marginales. Son aplicaciones directas del texto normativo a una práctica habitual.
La elusión de los controles de acceso
El problema de cumplimiento más grave con las capturas de Confluence es la elusión del control de acceso que crean.
Los equipos de soporte usan el control de acceso basado en roles (RBAC) para limitar quién puede ver los sistemas de cuentas de clientes. Los agentes de nivel 1 ven datos básicos. Los de nivel 2 ven datos de facturación y técnicos. Los gestores ven el perfil completo.
Cuando un agente de nivel 2 crea un artículo con una captura de la cuenta completa del cliente, esa captura se vuelve visible para todos los usuarios de la herramienta. Los agentes de nivel 1 que no deberían ver datos de facturación ahora pueden verlos. Los contratistas sin acceso al sistema también. El personal nuevo en incorporación también.
La captura elude los controles RBAC del sistema de cuentas. Los datos personales que el RBAC debía proteger ahora están al alcance de todos.
No es un riesgo teórico. Es el resultado normal del flujo de trabajo de documentación. La captura permanece allí sin fecha de expiración, sin registro de acceso y sin pista de auditoría.
Pasos prácticos de corrección
Para equipos que descubren este problema durante una auditoría del RGPD:
Corrección retroactiva:
- Identificar todas las páginas de la base de conocimiento con archivos de imagen adjuntos
- Ejecutar la detección de datos personales en cada archivo adjunto
- Revisar las imágenes marcadas: las detecciones de alta confianza pasan a la cola de revisión
- Para cada imagen marcada: reemplazar por una versión saneada o restringir el acceso a la página
- Registrar las acciones para los registros del RGPD
La escala del trabajo retroactivo depende del tamaño de la base. Para una base de tres años en un equipo de soporte de 50 personas, el número de imágenes puede alcanzar miles. El procesamiento por lotes lo hace viable. La revisión humana de las imágenes marcadas es el cuello de botella clave.
Controles prospectivos:
- Formar a todo el personal de soporte para sanear las capturas antes de publicar
- Proporcionar herramientas: herramientas de anotación de capturas que difuminen nombres de clientes antes de pegar
- Añadir un paso de revisión: un revisor designado comprueba los artículos antes de publicar, buscando específicamente datos personales de clientes en las imágenes
- Ejecutar un escaneo trimestral de todos los archivos adjuntos de Confluence
Control mínimo viable: Una lista de verificación de publicación: «Eliminar o difuminar todos los nombres, correos e identificadores de cuenta en las capturas antes de publicar». Sin automatización, pero crea un control documentado. Para equipos pequeños, este es el punto de partida.
Consulte nuestra visión general de cumplimiento del RGPD para el marco jurídico más amplio, y por qué la política sin controles técnicos fracasa para entender por qué los enfoques solo con listas de verificación fallan a escala.
Por qué el problema crece con el tiempo
Sin controles sistemáticos, la exposición de datos personales en la base de conocimiento se acumula.
Volumen: Cada nuevo artículo con una captura de cliente aumenta la exposición total. A medida que el equipo de soporte crece y la base de conocimiento se amplía, los datos personales acumulados también crecen. Las propiedades que hacen útiles estas herramientas — facilidad de publicación, permanencia, acceso amplio — son lo que empeora el problema.
Artículos olvidados: Los artículos sobre casos antiguos que ya no ocurren siguen siendo accesibles. Contienen datos de clientes que han presentado solicitudes de supresión desde entonces. Nadie revisa un artículo actualizado por última vez en 2022.
Difusión entre equipos: Las bases de conocimiento a menudo se vuelven transversales. Un artículo de soporte con capturas de clientes puede compartirse con el equipo de producto, el de ingeniería o contratistas externos como contexto de una solicitud de funcionalidad o informe de error. Cada uso amplía la audiencia de los datos personales.
Acumulación de solicitudes de supresión: Cuantos más datos de clientes se acumulan en la base, más compleja se vuelve la gestión de las solicitudes de supresión. Sin un sistema, no hay forma fiable de confirmar que todas las instancias de los datos de una persona han sido encontradas y eliminadas.
Los datos personales en bases de conocimiento son más fáciles de prevenir que de corregir. Los controles implementados ahora evitan el problema de corrección que se agrava. Cada artículo publicado sin una captura saneada es una tarea de corrección aplazada al futuro.