Tu registro de seguridad también puede ser un cajón de secretos.
Guardar todos los prompts de todos los clientes puede resolver una pregunta y crear otras diez.
En el nombre de la trazabilidad, alguien activa «guardar todo». Documentos, conversaciones, identificadores. Y los errores. Luego ese registro acaba al alcance de personas que no podrían abrir el expediente original.
La intención era poder reconstruir el trabajo. El resultado puede ser un repositorio adicional de información sensible, con permisos y plazos de conservación distintos. Registrar también es una decisión de arquitectura.
La pregunta no es solo si cabe en el disco
La AEPD explica principios como minimización, limitación del plazo de conservación e integridad y confidencialidad. Aplicarlos obliga a justificar qué datos se guardan y para qué, también cuando el soporte sea un log. No basta con llamarlo «seguridad» para que todo tratamiento resulte proporcionado. Fuente primaria ↗
El registro que yo pediría diseñar
Definiría primero el hecho que necesito reconstruir: quién autorizó una entrega, qué versión salió o por qué se devolvió una conclusión. Después elegiría los campos mínimos para ese propósito. Un evento podría contener referencia al expediente y a la versión, sin copiar íntegramente el contenido.
Separaría el acceso al registro operativo del acceso al documento, y ambos del de administración. Establecería cómo se consultan los eventos, qué cambios se permiten y qué ocurre al terminar la relación con un proveedor. Son propuestas de control que deben adaptarse al sistema real.
Las excepciones son precisamente lo importante
Es fácil acordar un plazo sobre el papel. Es más difícil localizar las copias de depuración, los adjuntos de soporte y las exportaciones que alguien hizo para investigar una incidencia. Incluiría esas rutas en el mapa antes de prometer borrado o retención.
Tampoco describiría un hash de información sensible como anonimización automática. Preguntaría qué información auxiliar existe, si el contenido es predecible y qué reidentificación resulta plausible en ese contexto.
Una pregunta de compra bastante incómoda
«Cuando abro un ticket de soporte, ¿qué datos del expediente puede ver tu equipo?» Después pediría una demostración con material sintético. La documentación contractual importa, pero también interesa observar qué información aparece de verdad en la pantalla de soporte.
El contenido de esta web es divulgativo y no sustituye un análisis de protección de datos. Su laboratorio utiliza ejemplos locales; no necesita expedientes reales para enseñar los conceptos.
Una buena traza ayuda a explicar una decisión. Una mala traza obliga a explicar una filtración adicional.
El expediente detrás del artículo.
Principios de protección de datos ↗Agencia Española de Protección de Datos · GuíaOrientación institucional
Fuentes consultadas el 9 de septiembre de 2026. Las recomendaciones y ejemplos son elaboración editorial: no se atribuyen íntegramente a estas fuentes. Comprueba versión y ámbito antes de aplicar una norma.
Divulgación general. Ninguna herramienta de esta web certifica la revisión, seguridad o conformidad de un proceso.