Derecho UE: RGPD, DORA, CRA y Ley de IA

El Reglamento General de Protección de Datos (RGPD), Reglamento (UE) 2016/679, es la ley de la UE sobre el tratamiento de información sobre personas. Se aplica directamente en todos los Estados miembros y abarca cualquier tratamiento de datos personales, es decir, información que identifica a una persona directa o indirectamente, por organizaciones de la UE y por organizaciones de fuera que ofrecen bienes o servicios a personas en la UE o controlan su comportamiento. Sus ideas centrales son sencillas: tener una base jurídica para cada uso, usar solo lo necesario, mantener los datos exactos y no más tiempo del necesario, protegerlos, informar a las personas afectadas y poder demostrarlo todo. Las personas tienen derechos como el acceso, la rectificación y la supresión. Para un equipo de seguridad el RGPD importa por partida doble: los registros de seguridad son datos personales, y un incidente puede ser una violación de datos personales con su propia obligación de notificación. La ley nacional añade normas, por ejemplo sobre datos de empleados, así que revise la suya.

A menudo sí, y en un contexto de seguridad conviene suponerlo. Un dato personal es cualquier información sobre una persona identificable directa o indirectamente, y el RGPD menciona los identificadores en línea entre los ejemplos. Una dirección IP no lleva un nombre, pero normalmente puede vincularse a uno: en una empresa, la dirección de un portátil señala a la persona que lo usa, y un proveedor de internet puede asociar una dirección pública a un abonado. El Tribunal de Justicia de la UE ha declarado que una dirección IP dinámica puede ser un dato personal para el operador de una web que dispone de medios legales para identificar a la persona que hay detrás. En la práctica, trate los registros de red, los nombres de dispositivos y los registros de conexión como datos personales: con base jurídica, acceso limitado, conservación solo el tiempo necesario y reflejo en su registro de actividades. NetSenX los trata como datos personales según su contrato de encargo y los guarda en la UE.

Una violación de la seguridad que provoca la destrucción, pérdida o alteración de datos personales, o su comunicación o acceso no autorizados, de forma accidental o ilícita. Es más amplio que una fuga: un ransomware que cifra una base de clientes es una violación aunque no se copiara nada, porque los datos dejaron de estar disponibles, y también lo es un correo enviado a destinatarios equivocados o un portátil sin cifrar extraviado. No todo incidente de seguridad es una violación de datos personales, porque algunos no afectan a datos personales, y no toda violación hay que notificarla. Según el artículo 33 del RGPD, el responsable la notifica a la autoridad de control sin dilación indebida y, si es posible, en las 72 horas siguientes a tener constancia, salvo que sea improbable que suponga un riesgo para las personas; toda violación debe documentarse en cualquier caso. Decídalo con su delegado de protección de datos. Desde el plan Starter, NetSenX prepara para él un borrador de notificación del artículo 33 con los datos del incidente; valorar el riesgo y presentarla le corresponde a usted.

El responsable decide para qué y cómo se tratan los datos personales; el encargado los trata por cuenta del responsable y siguiendo sus instrucciones. Cuando su empresa usa un servicio de seguridad para vigilar su red, normalmente su empresa es la responsable de los datos de red y el proveedor es el encargado. El responsable asume las obligaciones principales: base jurídica, transparencia con los interesados, atención de sus solicitudes y decisión sobre la notificación de brechas. El encargado debe seguir sus instrucciones documentadas, mantener la confidencialidad y la seguridad, recurrir a subencargados solo con su autorización, ayudarle con brechas y solicitudes, y devolver o suprimir los datos al final. Lo recoge un contrato, normalmente llamado contrato de encargo del tratamiento. Los papeles dependen de los hechos, no de las etiquetas: un proveedor que usa sus datos para fines propios pasa a ser responsable de ese uso. En NetSenX, TriStiX S.L. actúa como encargado y su organización como responsable, como recoge el contrato de encargo publicado.

Exige medidas apropiadas al riesgo, no una lista cerrada. El responsable y el encargado deben aplicar medidas técnicas y organizativas acordes con el estado de la técnica, los costes de aplicación, la naturaleza y los fines del tratamiento y la probabilidad y gravedad del daño para las personas. El RGPD pone ejemplos: la seudonimización y el cifrado, la capacidad de garantizar la confidencialidad, integridad, disponibilidad y resiliencia de los sistemas, la capacidad de restaurar los datos tras un incidente y un proceso para verificar y evaluar con regularidad las medidas. Así que cada empresa debe decidir, documentar y revisar qué es apropiado para sus datos, y poder justificarlo. Darse cuenta de una brecha forma parte de ello, porque no se puede notificar ni contener lo que no se ve, y muchas brechas salen a la luz por una actividad de red inusual. NetSenX puede ser una de esas medidas: en todos los planes detecta beaconing, escaneos, movimiento lateral y volúmenes de salida inusuales. Si el conjunto de sus medidas es apropiado sigue siendo su valoración.

Según el RGPD, solo en ciertos casos: autoridades públicas y organizaciones cuyas actividades principales consisten en una observación habitual y sistemática de personas a gran escala o en el tratamiento a gran escala de categorías especiales de datos, como los de salud. Muchas empresas medianas quedan fuera de esos casos, pero la ley nacional puede añadir otros. En Alemania, el artículo 38 de la BDSG exige un delegado cuando, por regla general, al menos 20 personas se ocupan de forma permanente del tratamiento automatizado de datos personales, además de otros supuestos. Revise la ley de su país. Aunque no sea obligatorio, alguien debe encargarse de la protección de datos, y un contacto designado ayuda cuando corre el plazo de notificación de una brecha. Si lo nombra, debe participar a tiempo en las cuestiones de protección de datos, actuar con independencia y rendir cuentas al más alto nivel de la dirección. Una herramienta de seguridad no cambia si lo necesita, aunque la vigilancia de red es un tema que debería revisar. Desde el plan Starter, NetSenX prepara un borrador de notificación de brecha según el RGPD para quien ocupe ese papel.

Normalmente sí, siempre que la vigilancia sea necesaria para la seguridad y proporcionada, y que documente la ponderación. El RGPD permite el tratamiento necesario para los intereses legítimos del responsable, salvo que prevalezcan los derechos de los interesados, y sus considerandos citan la seguridad de las redes y de la información como uno de esos intereses, en la medida estrictamente necesaria y proporcionada. Eso significa redactar una breve prueba de ponderación: qué vigila y para qué, por qué no bastarían medios menos intrusivos, qué garantías aplica y cuánto tiempo conserva los datos. Vigilar metadatos en busca de señales de ataque no pesa lo mismo que leer el contenido de mensajes u observar la conducta de personas concretas. Informe a la plantilla en su aviso de privacidad y revise la legislación laboral nacional, que puede exigir consultar o pactar con la representación de los trabajadores. NetSenX está pensado para mantener esa balanza del lado prudente: registra metadatos, nunca descifra el tráfico e informa del uso de IA por dispositivo y programa, no por persona. La valoración jurídica sigue siendo suya.

Por las infracciones más graves, hasta 20 millones de euros o el 4 % del volumen de negocio total anual global del ejercicio anterior, la cuantía que sea mayor, según el artículo 83, apartado 5, del RGPD. Ese tramo superior cubre las infracciones de los principios básicos, la base jurídica, los derechos de los interesados y las transferencias internacionales. Un tramo inferior se aplica a otras obligaciones, como la seguridad del tratamiento y la notificación de brechas, con máximos más bajos fijados en el mismo artículo. Son topes, no tarifas: la autoridad decide caso por caso, teniendo en cuenta la naturaleza, gravedad y duración de la infracción, la intencionalidad o negligencia, lo hecho para limitar el daño, las infracciones anteriores y la cooperación. La multa es solo una consecuencia; la autoridad también puede ordenar que cese el tratamiento, y los afectados pueden reclamar una indemnización. Lo que reduce la exposición es una diligencia ordinaria y demostrable: conocer sus tratamientos, medidas de seguridad documentadas, un procedimiento de brechas que funcione y notificaciones a tiempo. NetSenX ayuda en una parte, detectar pronto una brecha y, desde el plan Starter, preparar el borrador de notificación; no elimina el riesgo de multa.

El Reglamento de Resiliencia Operativa Digital (DORA), Reglamento (UE) 2022/2554, es la ley de la UE que busca que bancos, aseguradoras, empresas de inversión, entidades de pago y otras entidades financieras puedan resistir fallos tecnológicos y ciberataques y recuperarse de ellos. Se aplica directamente en todos los Estados miembros y se apoya en varios pilares: un marco de gestión del riesgo de TIC del que responde el órgano de dirección; la clasificación y notificación de incidentes graves relacionados con las TIC a la autoridad competente; pruebas periódicas de resiliencia operativa digital, con pruebas de penetración basadas en amenazas para algunas entidades; la gestión del riesgo de los proveedores terceros de servicios TIC, con requisitos contractuales y una estrategia de salida; y el intercambio voluntario de información sobre amenazas. Para los proveedores que las autoridades europeas de supervisión designan como críticos, DORA añade supervisión directa. Para una entidad financiera, DORA es la norma especial y prevalece sobre las normas generales de NIS2 donde coinciden. Si presta servicios TIC a entidades financieras, espere que DORA le llegue a través de contratos y cuestionarios. NetSenX no es una herramienta de DORA como tal; su detección puede apoyar la parte de vigilancia de un marco de riesgo de TIC.

Atribuye la responsabilidad última de la gestión del riesgo de TIC al órgano de dirección, que no puede trasladarla al departamento de TI ni a un proveedor. Según DORA, el órgano de dirección define, aprueba y supervisa el marco de gestión del riesgo de TIC y responde de su aplicación. En la práctica, eso supone aprobar la estrategia de resiliencia operativa digital y las políticas que la sustentan, fijar y revisar el presupuesto, aprobar los acuerdos con proveedores terceros de servicios TIC y la política para recurrir a ellos, estar informado de los incidentes graves y sus consecuencias, y mantener al día sus propios conocimientos mediante formación. Para los consejeros es un deber de gobierno corporativo que un supervisor puede examinar: actas, documentos aprobados y pruebas de que los informes se leyeron y se actuó en consecuencia. Pregunte a su función de cumplimiento cómo documenta su organización estas decisiones y consulte las orientaciones del supervisor nacional para los detalles. NetSenX no interviene en ese gobierno, pero sus alertas y sus informes de cumplimiento en PDF, desde el plan Starter, pueden ser una de las fuentes de información del órgano de dirección.

El Reglamento de Ciberresiliencia (CRA), Reglamento (UE) 2024/2847, es la ley de la UE sobre la seguridad de los productos con elementos digitales: hardware y software que se conectan a un dispositivo o a una red, desde routers y cámaras hasta aplicaciones y sistemas operativos vendidos en la UE. Impone obligaciones a los fabricantes, y otras más ligeras a importadores y distribuidores. Los productos deben diseñarse pensando en la seguridad, comercializarse sin vulnerabilidades explotables conocidas y con una configuración segura por defecto, y recibir actualizaciones de seguridad durante un periodo de soporte que fija el fabricante. Los fabricantes deben gestionar las vulnerabilidades de forma ordenada, documentar los componentes que usan y notificar las vulnerabilidades explotadas activamente y los incidentes graves, como establece el artículo 14. Algunas categorías, como los productos de seguridad y los equipos de red, se someten a una evaluación de la conformidad más estricta, y los productos que cumplen los requisitos llevan el marcado CE. Las fechas en que se aplica cada parte figuran en sus disposiciones finales. Si solo compra y usa productos, el CRA sobre todo le ayuda: espere de los proveedores periodos de soporte y compromisos de actualización más claros.

Sí, si introducen software en el mercado de la UE como producto: las aplicaciones instalables, el firmware, los sistemas operativos, las bibliotecas que se venden comercialmente y las aplicaciones móviles son productos con elementos digitales, y la empresa que los comercializa con su nombre es el fabricante. Las obligaciones incluyen una evaluación de riesgos, la seguridad desde el diseño y por defecto, la gestión y corrección de vulnerabilidades durante el periodo de soporte, la documentación de componentes, la información e instrucciones de seguridad para los usuarios y la notificación de vulnerabilidades explotadas activamente e incidentes graves según el artículo 14. El software libre y de código abierto desarrollado o suministrado fuera de una actividad comercial queda en gran parte fuera del Reglamento, y las organizaciones que apoyan proyectos de código abierto destinados a uso comercial, llamadas administradores de software de código abierto, tienen obligaciones más ligeras. El software que desarrolla solo para uso interno no se introduce en el mercado. Si vende software, empiece por enumerar sus productos, sus periodos de soporte y su proceso de gestión de vulnerabilidades, y consulte el propio Reglamento para los detalles. NetSenX no evalúa si su software cumple los requisitos.

En general no a un servicio en línea puro, pero puede alcanzar la parte en la nube de un producto. El CRA abarca los productos con elementos digitales que se introducen en el mercado. El software prestado solo como servicio por internet, sin un producto que instale el cliente, queda en principio fuera; la seguridad de esos servicios es sobre todo cosa de NIS2 cuando el proveedor está incluido. Sin embargo, el CRA cubre también el tratamiento remoto de datos que un fabricante diseña como parte de un producto, cuando sin él el producto no podría cumplir alguna de sus funciones: el servidor en la nube de una cámara inteligente o de un sensor de red que se entrega con un agente son ejemplos típicos. Así que una empresa que vende un componente instalable y un servicio en la nube puede tener obligaciones del CRA para el conjunto. Identifique qué partes de su oferta instalan los clientes y cuáles funcionan solo de su lado, y lea con cuidado las definiciones del Reglamento. NetSenX, que entrega agentes junto con un servicio en la nube, se hace la misma pregunta.

Una lista de materiales de software (SBOM) es una relación legible por máquina de los componentes de un programa, como bibliotecas y sus versiones, parecida a una lista de ingredientes. Permite a un fabricante, y a quien se la facilite, saber rápidamente si una vulnerabilidad recién publicada afecta a un producto. El CRA exige a los fabricantes identificar y documentar los componentes de sus productos, entre otras cosas elaborando una SBOM en un formato de uso común y legible por máquina que cubra al menos las dependencias de primer nivel. Forma parte de la documentación técnica; el Reglamento no obliga al fabricante a publicarla, aunque las autoridades pueden pedirla. Si compra software, pregunte a los proveedores si mantienen una SBOM y cómo la usan para seguir las vulnerabilidades, en lugar de exigir el archivo en sí. Los formatos habituales son CycloneDX y SPDX. NetSenX no genera SBOM de sus productos, y un sensor de red no ve qué bibliotecas hay dentro de una aplicación.

El Reglamento de Inteligencia Artificial, Reglamento (UE) 2024/1689, es la ley de la UE que regula los sistemas de IA según el riesgo que plantean. Algunas prácticas están prohibidas, como la puntuación social y ciertos usos del reconocimiento de emociones en el trabajo. Los sistemas de alto riesgo, enumerados por ámbitos, como la IA usada en selección de personal, gestión de trabajadores, decisiones de crédito o como componente de seguridad de infraestructuras críticas, deben cumplir requisitos de gestión de riesgos, calidad de datos, documentación, supervisión humana, precisión y seguridad antes y después de comercializarse. Algunos sistemas tienen obligaciones de transparencia, por ejemplo avisar de que se está hablando con un chatbot. La mayoría de las demás IA, como los filtros de spam, no tienen obligaciones específicas. Hay normas propias para los modelos de IA de uso general. Las obligaciones recaen en los proveedores, que desarrollan los sistemas y los comercializan, y en los responsables del despliegue, que los usan profesionalmente. Desde el 2 de febrero de 2025, el artículo 4 exige a ambos adoptar medidas sobre la alfabetización en IA de su personal, lo que desde su modificación en julio de 2026 significa fomentarla, no garantizar un nivel concreto en cada persona; el resto se aplica por etapas. Pregunte a su proveedor en qué categoría entra su sistema.

Normalmente no, pero depende de qué decide la herramienta y sobre quién. Las categorías de alto riesgo se definen por el uso, no por la tecnología: IA usada, entre otros fines, para contratar, promocionar, supervisar o evaluar a trabajadores, valorar la solvencia o como componente de seguridad en la gestión de infraestructuras críticas. Una herramienta que detecta tráfico de malware entre dispositivos no es por sí misma uno de esos usos. Se acerca cuando sus resultados se usan para evaluar la conducta o el rendimiento de empleados concretos, o cuando actúa como componente de seguridad de, por ejemplo, una red eléctrica. Haga dos preguntas a cada herramienta de seguridad: ¿evalúa personas o máquinas, y qué ocurre automáticamente a partir de sus resultados? Pida al proveedor su propia clasificación y el razonamiento. NetSenX está diseñado para observar dispositivos y conexiones, no para evaluar personas, e informa del uso de IA por dispositivo y programa, no por persona. Su página de transparencia sobre IA describe dónde usa IA y qué queda bajo su control; usar las alertas para juzgar al personal sería decisión suya y requeriría su propia evaluación.

Algunas, y se aplican sea cual sea la categoría de riesgo. Hay que informar a las personas de que interactúan con un sistema de IA, como un chatbot de atención al cliente, salvo que resulte evidente. Los proveedores de sistemas que generan audio, imágenes, vídeo o texto sintéticos deben marcar los resultados en un formato legible por máquina, de modo que se pueda detectar que son artificiales. Los responsables del despliegue que publican ultrasuplantaciones deben indicar que el contenido es artificial, y quienes publican textos generados por IA sobre asuntos de interés público también deben indicarlo, salvo que una persona los haya revisado y asuma la responsabilidad editorial. Los responsables del despliegue de sistemas de reconocimiento de emociones o de categorización biométrica deben informar a las personas expuestas. Para una empresa, los pasos prácticos son un inventario de dónde la IA habla con clientes o produce contenido publicado, un aviso claro en esos lugares y comprobar que sus proveedores marcan sus resultados. Estas obligaciones se aplican en la fecha que fijan las disposiciones finales de la Ley. NetSenX publica su propia página de transparencia sobre IA para las funciones de IA de su servicio.

Que la privacidad debe integrarse en cómo se configura un sistema y en sus ajustes por defecto, no añadirse después de una queja. Desde el diseño significa que, al elegir y configurar una herramienta, aplica medidas adecuadas al riesgo, como la seudonimización, la minimización de datos y el control de acceso. Por defecto significa que, de entrada, solo se tratan los datos personales necesarios para cada fin, no se guardan más tiempo del necesario y no quedan accesibles a un número indeterminado de personas. En una herramienta de seguridad, las preguntas prácticas son: ¿recoge contenido o solo metadatos?, ¿puede limitar quién ve qué?, ¿cuánto tiempo se guardan los registros?, ¿ven personas ajenas al equipo de seguridad los nombres de los dispositivos de los empleados? La obligación es del responsable, así que documente sus decisiones al implantarla. Los ajustes por defecto de NetSenX van en esa línea: registra metadatos y no contenido, nunca descifra el tráfico, conserva las alertas durante el historial del plan e informa del uso de IA por dispositivo y programa, no por persona; los roles de equipo están disponibles desde el plan Starter.

Responsables y encargados deben llevar un registro por escrito, que puede ser electrónico, de sus actividades de tratamiento y ponerlo a disposición de la autoridad de control cuando lo pida. En el caso del responsable, cada entrada describe los fines, las categorías de interesados y de datos personales, los destinatarios, las transferencias fuera de la UE con sus garantías, cuando sea posible los plazos previstos de supresión y una descripción general de las medidas de seguridad. Los encargados llevan un registro más breve de los tratamientos que realizan para cada responsable. Las organizaciones más pequeñas, por debajo de un umbral de plantilla fijado en el RGPD, quedan exentas en algunos casos, pero no cuando el tratamiento no es ocasional, lo que ocurre en casi cualquier vigilancia de red continua, ni cuando puede entrañar un riesgo o incluye categorías especiales de datos. Así que registre la vigilancia de seguridad como una actividad de tratamiento propia: finalidad, datos recogidos, quién los ve, el proveedor como encargado, dónde se guardan los datos y durante cuánto tiempo. El contrato de encargo de NetSenX y su lista de subencargados le dan los datos del proveedor para esa entrada; el registro en sí lo lleva usted.

Cada uno se ocupa de un objeto distinto, así que una misma empresa puede estar sujeta a varios a la vez. NIS2 trata de la ciberseguridad de las organizaciones de sectores enumerados: medidas de gestión de riesgos, responsabilidad de la dirección y notificación de incidentes significativos según el artículo 23. El RGPD trata de los datos personales, se traten donde se traten, incluida la obligación de notificar violaciones según el artículo 33. DORA es la norma especial de las entidades financieras y prevalece sobre NIS2 donde coinciden. El CRA trata de los productos con elementos digitales y obliga a las empresas que los fabrican y venden. La Ley de IA trata de los sistemas de IA y obliga a proveedores y responsables del despliegue según el riesgo. Un ataque de ransomware contra un proveedor de un hospital puede, por tanto, activar el mismo día una notificación NIS2 y otra del RGPD, y el fallo de producto que lo hizo posible puede dar lugar a la notificación CRA del fabricante. Determine qué leyes le afectan, quién se encarga de cada una y cómo un solo registro del incidente puede alimentar varias notificaciones. NetSenX sigue los plazos de NIS2 por incidente y, desde el plan Starter, prepara un borrador del RGPD; no presenta nada.