Tu registro de seguridad también puede ser un cajón de secretos.

Dentro del expediente

Pongamos que alguien marcó la casilla del registro completo para poder demostrar después qué había hecho el sistema, y que nueve meses más tarde ese registro contiene el borrador de un acuerdo que no llegó a firmarse y la pregunta que un cliente escribió a las once de la noche. Nadie lo llamó archivo confidencial, pero lo es.

No hubo mala fe en la decisión. Hubo una casilla que decía guardar todo y ninguna reunión en la que se preguntara qué significaba exactamente «todo».

El registro es una copia del expediente que nadie llamó copia

Lo que se le entrega a un sistema de IA en un despacho es el material del asunto. El texto del contrato. La cifra que se discute y el nombre de quien está al otro lado. Si ese sistema registra entradas y salidas para poder auditarse, está escribiendo el mismo material una segunda vez, en un soporte con otras reglas de acceso.

Yo lo llamaría duplicación antes que trazabilidad. Y una duplicación que hereda la sensibilidad del original sin heredar sus controles es una superficie nueva que alguien tendrá que defender, más que una medida de seguridad.

Quién puede abrir el registro y quién puede abrir el asunto

Aquí está el desajuste. El acceso al expediente está pensado con cuidado, con un responsable asignado y un motivo para entrar. El acceso al registro está pensado para otra cosa distinta, que es permitir a alguien de soporte diagnosticar por qué falló una ejecución a las tres de la madrugada. Son dos poblaciones de personas con dos justificaciones que no se parecen.

Cuando el contenido del asunto acaba dentro del registro, la segunda población empieza a ver lo que la primera protegía. Nadie tomó esa decisión de forma consciente. La tomó el diseño, y el diseño no responde ante nadie.

La Agencia Española de Protección de Datos recuerda que la minimización obliga a que solo sean objeto de tratamiento los datos que resulten precisos para cada una de las finalidades específicas, y a limitar la extensión del tratamiento, el plazo de conservación y la accesibilidad Fuente primaria ↗. Ese deber no desaparece porque el soporte se llame registro y porque la intención sea buena. Llamar «seguridad» a un tratamiento no lo vuelve proporcionado por sí solo.

Lo que exige el reglamento inteligencia artificial no autoriza a guardarlo todo

El reglamento europeo impone obligaciones de registro y documentación a determinados sistemas en función de su clasificación, con un calendario de aplicación que conviene comprobar antes de afirmar nada sobre el propio caso Fuente primaria ↗. Esa obligación es real y da una razón legítima para conservar evidencia de cómo funcionó el sistema.

Lo que no da es permiso para almacenar cualquier cosa que el sistema sea capaz de escribir. Un deber de registro se cumple guardando lo que acredita el funcionamiento del sistema, no vaciando el expediente dentro del archivo técnico. Yo separaría esas dos preguntas antes de configurar nada, porque se contestan por separado y luego resulta muy caro deshacerlas.

Las copias que ninguna política de conservación persigue

Fijar un plazo sobre el papel es fácil. Lo difícil es que ese plazo alcance a todo lo que existe de verdad. Están los volcados de depuración que alguien activó una semana para cazar un error y olvidó desactivar. Están los adjuntos que un compañero envió a soporte para explicar la incidencia, y las exportaciones que se hicieron para investigar y quedaron en una carpeta con un nombre cualquiera.

Ninguna de esas rutas suele aparecer en el inventario. Se borra lo que se sabe que existe. Yo mapearía esas derivadas antes de prometerle a un cliente cualquier cosa sobre retención o supresión, porque la promesa se hace sobre el sistema documentado y el riesgo vive en el que no lo está.

Un secreto empresarial se defiende o deja de serlo

Esta parte se pasa por alto y es la que más duele. La Ley 1/2019 define el secreto empresarial exigiendo, entre otros requisitos, que su titular haya adoptado medidas razonables para mantenerlo secreto Fuente primaria ↗, sujeto a cómo se interprete ese requisito en cada caso concreto. La protección depende de lo que uno haya hecho para guardarla, y no cae del cielo por el valor de la información.

Si el material de un cliente termina en un registro que puede leer un equipo de soporte externo sin motivo asociado al asunto, la pregunta incómoda ya no se limita a la protección de datos y alcanza a si esas medidas razonables existían. No me gustaría tener que sostener que sí con un log delante que dice lo contrario.

El registro sobrevive a la relación con el proveedor

Los contratos terminan. Los registros no siempre. Cuando se cambia de herramienta, el expediente se migra porque se ve y porque alguien lo echa de menos. El registro técnico no se echa de menos y se queda donde estaba, en la infraestructura de un proveedor con el que ya no se habla, sujeto a una política de borrado que nadie ha vuelto a leer.

Yo pactaría por escrito qué ocurre con ese registro al terminar la relación, y pediría la evidencia del borrado en lugar de la declaración del borrado. Son dos documentos distintos y solo uno sirve de algo.

La prueba que haría antes de firmar nada

Un ensayo con material sintético, inventado para la ocasión y sin relación con ningún cliente. Se procesa un asunto ficticio con nombres falsos y se abre a continuación un ticket de soporte. Después se pregunta al proveedor qué pantalla ve su equipo y se pide verla. Se pide la pantalla misma, no la descripción contractual de lo que vería.

Casi siempre aparece algo que la documentación no anticipaba. Un fragmento del texto original en un mensaje de error, un identificador que no debería estar ahí. Ese ensayo cuesta una tarde y contesta una pregunta que el pliego comercial nunca contesta.

Por qué esto no se ve hasta que ya da igual

Un registro bien poblado no molesta a nadie mientras nada ocurre. No genera avisos y no ralentiza el trabajo. Da una sensación agradable de control. El día que hay una filtración, una reclamación o un cambio de proveedor con mal ambiente, ese mismo registro se convierte en la lista exacta de todo lo que hay que explicar.

Diseñar el registro es decidir qué se podrá demostrar mañana. También es decidir qué habrá que defender.

Lo que me preguntan cuando cierro el portátil.

¿Por qué un log de un sistema de IA puede contener datos confidenciales?

Porque lo que se le entrega al sistema es el material del asunto. Si el registro guarda entradas y salidas para poder auditar la ejecución, guarda ese material otra vez. La confidencialidad no viaja con el texto y se queda en el sistema donde se pensó el acceso.

¿Qué obliga a registrar el reglamento inteligencia artificial?

Impone deberes de registro y documentación a determinados sistemas según su clasificación de riesgo, con un calendario propio que conviene comprobar antes de afirmar nada. Ese deber justifica conservar evidencia del funcionamiento. No justifica almacenar cualquier contenido que el sistema sea capaz de escribir.

¿Basta con fijar un plazo de conservación para el registro?

No, si el plazo solo alcanza al registro principal. Las volcadas de depuración, los adjuntos que alguien envió a soporte y las exportaciones hechas para investigar una incidencia suelen quedar fuera del inventario. Se borra lo que se sabe que existe, y ahí está el hueco.

El expediente detrás del artículo.

Principios de protección de datos ↗Agencia Española de Protección de Datos · Guía
Orientación institucionalReglamento europeo de inteligencia artificial ↗EUR-Lex · Reglamento (UE) 2024/1689 · 2024
Normativa UE; comprobar versión y calendarioLey 1/2019 de Secretos Empresariales ↗BOE · artículos 1 y 2; creación independiente e ingeniería inversa en el artículo 2.1 · 2019
Normativa española

Fuentes consultadas el 10 de septiembre de 2026. Las recomendaciones y ejemplos son elaboración editorial y 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.