La Ley de IA de la UE para energía y utilities: dónde la línea de alto riesgo es real (2026)
La IA de balance de red y SCADA puede ser de alto riesgo bajo el anexo III, punto 2; la de back-office no. Artículos 9-15, solape con NIS2 y un ejemplo.
La IA de un operador de red cierra un bucle de control y deslastra carga de forma automática cuando un fallo amenaza la estabilidad de frecuencia. Ese sistema es de alto riesgo bajo la Ley de IA de la UE. El modelo de analítica de facturación no lo es. En la mayoría de los sectores regulados la discusión es si su IA es de alto riesgo siquiera; en energía y utilities la regulación nombra el sector de plano, así que la pregunta es operativa, no teórica. Esta guía traza la línea sistema por sistema, recorre el conjunto de obligaciones para los sistemas que la cruzan y mapea el solape con NIS2.
El anexo III, punto 2 del Reglamento (UE) 2024/1689 cubre los sistemas de IA destinados a usarse como componentes de seguridad en la gestión y operación de infraestructura digital crítica, tráfico rodado y el suministro de agua, gas, calefacción y electricidad. El sector está en la lista por su nombre. Así que la pregunta divisoria no es «¿somos una empresa energética?» —lo eres—, sino «¿es este sistema de IA concreto un componente de seguridad en la gestión u operación del suministro?». La mayor parte de la IA de una utility no lo es. Una minoría crítica sí. La disciplina es clasificar cada sistema contra el artículo 6 y el anexo III en lugar de tratar todo el parque como un único cubo de riesgo. El calendario autónomo del anexo III ya está fijado —2 de diciembre de 2027—, cubierto en detalle al final.
Las dos preguntas que deciden la clasificación
La clasificación por esta vía gira sobre dos extremos, y un sistema tiene que satisfacer ambos. Falla cualquiera y el anexo III, punto 2, no aplica.
Qué significa «componente de seguridad» según el artículo 3(14)
El artículo 3(14) define un componente de seguridad como un componente de un producto o sistema que cumple una función de seguridad y cuyo fallo o defecto pone en peligro la salud y la seguridad de las personas o los bienes. Ese es el concepto que abre la puerta, explicado en detalle en componente de seguridad. Es una prueba funcional, no una etiqueta: un sistema se gana la descripción por lo que hace su fallo, no por dónde se sitúa en el organigrama.
El anexo III, punto 2, exige entonces el segundo extremo encima: la IA debe ser un componente de seguridad y usarse en la gestión u operación del suministro de electricidad, gas, calefacción o agua (o de infraestructura digital crítica, o de tráfico rodado). Ambos, o ninguno.
Por qué la mayor parte de la IA de una utility no supera la prueba del componente de seguridad
Esta es la respuesta honesta, dicha sin rodeos: un sistema que meramente apoya a una utility no es un componente de seguridad y en general no es de alto riesgo por esta vía. La analítica de facturación, los modelos de fuga de clientes, la optimización de marketing, la búsqueda documental, la previsión de demanda para aprovisionamiento: ninguno cumple una función de seguridad en la operación del suministro. Su fallo cuesta dinero o molesta a los clientes; no pone en peligro a las personas ni la continuidad del suministro en el sentido del artículo 3(14). Trátalos como de riesgo mínimo. El trabajo es encontrar los pocos sistemas que gobiernan de verdad la operación física de la red.
El filtro de no-alto-riesgo del artículo 6(3), y por qué es difícil apoyarse en él aquí
El artículo 6(3) ofrece una excepción: un sistema del anexo III no es de alto riesgo cuando realiza solo una tarea procedimental estrecha, mejora el resultado de una actividad humana previa, detecta patrones de decisión sin sustituir la valoración humana, o es puramente preparatorio. Un modelo de previsión que solo alimenta una decisión humana de sala de control puede encajar; un sistema que de verdad gobierna la estabilidad de la red en bucle cerrado rara vez lo hace. Y la excepción nunca elimina el deber del artículo 49: un proveedor que reclama estatus de no-alto-riesgo según el artículo 6(3) debe aun así documentar esa evaluación y registrar el sistema antes de introducirlo en el mercado.
Una frontera que conviene tener clara: un modelo de uso general afinado para convertirse en una herramienta de red se evalúa como el sistema de alto riesgo en el que se integra, no como un modelo GPAI flotante. No confundas ambos.
IA de red y SCADA frente a IA de back-office: un mapa de clasificación
El mismo modelo neuronal de previsión puede ser de riesgo mínimo en una mesa de trading y de alto riesgo dentro de una acción de control SCADA en bucle cerrado. Lo deciden la finalidad prevista y la prueba de la función de seguridad, no el algoritmo. La tabla proyecta casos de uso habituales de IA de utility sobre dónde se sitúan, su clasificación probable, la vía que rige y el detonante que decide cada uno.
| Caso de uso de IA | Dónde se sitúa | Clasificación probable | Vía | Detonante que decide |
|---|---|---|---|---|
| Control automático de generación / regulación de frecuencia | SCADA / sala de control | Alto riesgo | Anexo III punto 2 | Función de seguridad en bucle cerrado sobre el suministro |
| Lógica automatizada de deslastre de carga | Capa de protección SCADA | Alto riesgo | Anexo III punto 2 | Actúa sobre el suministro sin revisión humana |
| Lógica de decisión de relés de protección | OT de subestación | Alto riesgo | Anexo III punto 2 | El fallo pone en peligro a personas / la continuidad |
| Previsión de carga DMS / EMS | Asesoría de sala de control | Zona gris | Anexo III punto 2 o art. 6(3) | Alto riesgo solo si impulsa una acción automatizada |
| Mantenimiento predictivo (transformadores) | Gestión de activos | Zona gris → normalmente fuera | Art. 6(3) | Asesora a un humano; sin bucle de seguridad |
| Predicción de interrupciones | Planificación de operaciones | Normalmente fuera | Art. 6(3) | Informa, no controla |
| Modelo de trading de energía al por mayor | Mesa de trading | No alto riesgo | — | Sin función de seguridad en el suministro |
| Previsión de demanda para aprovisionamiento | Comercial | No alto riesgo | — | Comercial, no operativo |
| Analítica de facturación / medición | Back-office | No alto riesgo | — | Sin función de seguridad |
| Chatbot de atención al cliente | Operaciones de cliente | No alto riesgo | Solo transparencia art. 50 | Interactúa con personas |
| Analítica de imágenes de vegetación / activos | Operaciones de campo | No alto riesgo | — | Analítica, no control |
| Cribado de selección (técnicos de campo) | RR. HH. | Alto riesgo | Anexo III punto 4, letra a) | Vía de empleo, no del punto 2 |
Los candidatos a alto riesgo son los sistemas integrados en la capa de control: IA en el control automático de generación o la regulación de frecuencia, IA de lógica de protección, y deslastre automatizado de carga dentro de SCADA, cada uno cumpliendo una función de seguridad cuyo fallo pone en peligro a las personas o la continuidad del suministro.
La zona gris es donde el artículo 6(3) muerde con más fuerza: la previsión de carga del sistema de gestión de la distribución (DMS) y del sistema de gestión de la energía (EMS), más el mantenimiento predictivo. Son de alto riesgo solo si la salida impulsa directamente una acción de seguridad automatizada; si informa a un humano que decide, se abre la excepción.
Las filas claramente fuera importan para la delimitación. El trading, la previsión de aprovisionamiento, la analítica de facturación y medición, el trabajo de imágenes de activos y las herramientas de RR. HH. no son componentes de seguridad en la operación del suministro. Dos salvedades: el chatbot aún debe la transparencia del artículo 50, y la herramienta de selección es de alto riesgo, pero bajo el anexo III, punto 4, letra a) sobre empleo, un epígrafe distinto con su propio conjunto de obligaciones, no el punto 2.
El conjunto de obligaciones de los artículos 9-15 para la IA de energía de alto riesgo
Para los sistemas que aterrizan en alto riesgo, la clasificación es el inicio de la carga de trabajo, no el final. El capítulo III, sección 2, del Reglamento (UE) 2024/1689 expone el conjunto completo de obligaciones; recorrerla muestra el coste real de un sistema de control que cruza la línea.
Gestión de riesgos del artículo 9 y gobernanza de datos del artículo 10
El artículo 9 exige un sistema de gestión de riesgos continuo e iterativo mantenido a lo largo del ciclo de vida, detallado en artículo 9: gestión de riesgos. Es especialmente exigente cuando un fallo puede desestabilizar el suministro, porque el análisis de riesgos tiene que dar cuenta de los efectos de red en cascada, no del sistema aislado. El artículo 10 añade requisitos de datos y de gobernanza de datos sobre los datos de entrenamiento, validación y prueba, relevante cuando los modelos de control aprenden de años de telemetría.
Artículos 11-12: documentación técnica y registro automático
El artículo 11 exige documentación técnica con el contenido especificado en el anexo IV: diseño, proceso de desarrollo, lógica de control, resultados de validación. El artículo 12 exige el registro automático de eventos durante la vida del sistema. Para una utility esto encaja con la telemetría que las plataformas SCADA y EMS ya registran; la obligación va menos de construir nueva infraestructura que de retener y estructurar lo que la capa de tecnología operativa ya capta.
Artículos 13-15: transparencia, supervisión humana y precisión/solidez/ciberseguridad
El artículo 13 exige que el sistema sea lo bastante transparente para que un responsable del despliegue pueda interpretar su salida y usarla adecuadamente. La supervisión humana del artículo 14 es la clave para los operadores de red: el diseño debe permitir que un operador de sala de control entienda, intervenga y anule la IA. Esa supervisión retroalimenta la clasificación: un sistema construido para que un operador decida de verdad pudo calificar para el artículo 6(3); un bucle cerrado no. El artículo 15 exige precisión, solidez y ciberseguridad apropiadas, donde la Ley de IA de la UE y los regímenes existentes de seguridad de tecnología operativa del sector se encuentran de forma más evidente: el puente hacia la sección de NIS2 de más abajo.
Asigna las obligaciones al actor correcto. Los proveedores de IA de red suelen ser proveedores según el artículo 16, cargando con la evaluación de la conformidad y los deberes más pesados. El operador de red que despliega la herramienta suele ser un responsable del despliegue según el artículo 26: usar según las instrucciones, asegurar la supervisión, monitorizar la operación. Pero según el artículo 25, un operador que modifica sustancialmente el sistema o lo introduce en el mercado bajo su propio nombre gira a estatus de proveedor. El tratamiento en profundidad de esta vía está en seguridad de infraestructuras críticas.
NIS2 y resiliencia de entidades críticas: coordinar, no duplicar
Los operadores de energía son entidades esenciales según la Directiva NIS2 y a menudo entidades críticas según la Directiva sobre la resiliencia de las entidades críticas. Son instrumentos separados del Reglamento (UE) 2024/1689: el cumplimiento de la Ley de IA no los satisface, y ellos no satisfacen la Ley de IA. Ejecutarlos como dos programas desconectados es un desperdicio; la respuesta es una única base de evidencia proyectada sobre varios regímenes.
Los solapes genuinos merecen aprovecharse. Las expectativas de ciberseguridad del artículo 15 se alinean estrechamente con las medidas de gestión de riesgos de NIS2, y el registro del artículo 12 apoya tanto la trazabilidad de la Ley de IA como la evidencia de gestión de incidentes de NIS2. Construye el almacén de registros una vez, proyéctalo dos veces.
Las brechas son donde NIS2 no da cobijo. La gobernanza de datos (artículo 10), la supervisión humana (artículo 14), la documentación técnica del anexo IV, y el marcado CE y la evaluación de la conformidad son específicos de la Ley de IA. Una utility con un programa NIS2 maduro ha cubierto quizá un tercio del conjunto de obligaciones de IA de alto riesgo, no toda.
La notificación de incidentes corre por vías paralelas. La notificación de incidentes graves del artículo 73 va a la autoridad de vigilancia del mercado; la notificación de incidentes de NIS2 va al CSIRT nacional. Un único fallo de red causado por una IA de control defectuosa puede disparar ambas, en calendarios separados, a organismos separados. Mapea los detonantes por adelantado para que un incidente no se convierta en un fallo de notificación encima de uno operativo.
Ejemplo práctico: un DSO regional clasifica su parque de IA
Considera Verdalux Netze GmbH, un operador regional de red de distribución de electricidad (DSO) en Baja Sajonia: unos 1.400 empleados y alrededor de 900.000 puntos de conexión, entidad esencial según NIS2. Su responsable de cumplimiento inventaría cinco sistemas:
- Un módulo de IA dentro de SCADA que realiza deslastre automatizado de carga en condiciones de fallo.
- Un modelo de previsión de carga DMS que recomienda acciones de conmutación a los operadores de sala de control.
- Un modelo de mantenimiento predictivo para transformadores de distribución.
- Un chatbot de atención al cliente.
- Una herramienta de cribado de selección para técnicos de campo.
La clasificación sale limpia una vez aplicada la prueba del componente de seguridad por sistema. El módulo de deslastre automatizado de carga es de alto riesgo según el anexo III, punto 2: un componente de seguridad que actúa en bucle cerrado sobre el suministro, cuyo fallo pone en peligro la continuidad. El modelo de previsión de carga y el modelo de mantenimiento predictivo probablemente quedan fuera vía artículo 6(3): cada uno asesora a un humano que decide, ninguno cierra un bucle, siempre que Verdalux documente ese razonamiento y la decisión humana sea real, no nominal. El chatbot solo debe la transparencia del artículo 50. La herramienta de selección es de alto riesgo, pero bajo el anexo III, punto 4, letra a): una vía distinta con su propio conjunto de obligaciones.
El reparto de obligaciones se sigue de ahí. Para el módulo de deslastre de carga, Verdalux es responsable del despliegue según el artículo 26, salvo que modifique sustancialmente la herramienta del proveedor y vuelque a estatus de proveedor según el artículo 25, lo que su equipo de ingeniería debería comprobar antes de cualquier cambio interno. Debe ejecutar el diseño de supervisión del artículo 14 en la interfaz de la sala de control y alimentar los registros del módulo tanto en su registro del artículo 12 como en su base de evidencia de NIS2.
La lección de secuenciación es la duradera. Una determinación de una línea por sistema, fechada y documentada —«módulo de deslastre de carga: alto riesgo, anexo III, punto 2, responsable del despliegue»; «modelo de previsión: no alto riesgo, asesoría del art. 6(3), registrado según el art. 49»— permite a Verdalux defender su delimitación ante la autoridad de vigilancia del mercado más adelante. Esa determinación fechada y basada en reglas es exactamente la salida que Confir está construida para producir.
Cómo ayuda Confir
La energía y las utilities afrontan una versión más afilada del problema de clasificación que la mayoría de los sectores: la ley te nombra, así que la respuesta nunca es «estamos fuera» en bloque, sino sistema por sistema, y la línea entre un modelo asesor y una acción de control en bucle cerrado es donde ocurren los errores.
El motor de clasificación de Confir trabaja cada sistema por el artículo 6 y el anexo III, punto 2, en secuencia, aplicando la prueba del componente de seguridad del artículo 3(14) y las condiciones de la excepción del artículo 6(3) como reglas explícitas. La entrada saca a la luz los hechos que lo deciden —¿cierra esta IA un bucle de control sobre el suministro, o decide un operador humano?— y produce una justificación de clasificación fechada que un ingeniero de sala de control o una autoridad de vigilancia del mercado pueden seguir y cuestionar. El motor es determinista y basado en reglas: sin inferencia de modelo, sin alucinación. Mismas entradas, misma salida.
Para los sistemas que aterrizan en alto riesgo, Confir estructura la documentación técnica del artículo 11 y el anexo IV, rastrea el registro de gestión de riesgos del artículo 9 y mantiene un Registro de Riesgos que sostiene un parque mixto —IA de back-office de riesgo mínimo junto a IA de control de alto riesgo— en una única vista, con rol, vía y plazo visibles por sistema.
Preguntas frecuentes
¿Es automáticamente de alto riesgo la IA de balance de red o SCADA según la Ley de IA de la UE? No. Es de alto riesgo solo si cumple ambos extremos del anexo III, punto 2: la IA debe ser un componente de seguridad (artículo 3(14)) y usarse en la gestión u operación del suministro de electricidad, gas, calefacción o agua. La IA que cierra un bucle de control sobre el suministro, como el deslastre automatizado de carga o la regulación de frecuencia, suele calificar. Un modelo de previsión que solo asesora a un operador humano de sala de control puede quedar fuera, a menudo vía la excepción del artículo 6(3). El factor que decide es la función de seguridad y la finalidad prevista, no el algoritmo.
¿Es de alto riesgo la IA de back-office o de trading de una utility? En general, no. Los modelos de trading de energía al por mayor, la previsión de demanda para aprovisionamiento, la analítica de facturación y medición, el análisis de imágenes de activos y los chatbots de atención al cliente no son componentes de seguridad en la operación del suministro, así que el anexo III, punto 2, no aplica. Suelen ser de riesgo mínimo. Dos salvedades: un chatbot de cliente aún debe la transparencia del artículo 50, y una herramienta de cribado de selección es de alto riesgo, pero bajo el anexo III, punto 4, letra a) sobre empleo, una vía distinta con su propio conjunto de obligaciones, no el epígrafe de infraestructura crítica.
¿Qué obligaciones se aplican una vez que un sistema de IA de energía es de alto riesgo? El conjunto completo de obligaciones del capítulo III, sección 2: gestión de riesgos del artículo 9, gobernanza de datos del artículo 10, documentación técnica del artículo 11 según el anexo IV, registro automático del artículo 12, transparencia hacia los operadores del artículo 13, supervisión humana del artículo 14, y precisión, solidez y ciberseguridad del artículo 15. Para los operadores de red, la supervisión del artículo 14 es central: un operador de sala de control debe poder entender y anular el sistema. La ciberseguridad del artículo 15 es donde la Ley de IA se encuentra de forma más clara con las obligaciones existentes de seguridad de tecnología operativa de una utility.
¿Cómo interactúa la Ley de IA de la UE con NIS2 para los operadores de energía? Son regímenes separados. Los operadores de energía son entidades esenciales según NIS2 y a menudo entidades críticas según la Directiva sobre la resiliencia de las entidades críticas; el cumplimiento de uno no satisface al otro. Hay solape genuino: la ciberseguridad del artículo 15 se alinea con las medidas de gestión de riesgos de NIS2, y el registro del artículo 12 apoya a ambos. Pero la gobernanza de datos, la supervisión humana, la documentación del anexo IV y la evaluación de la conformidad son específicas de la Ley de IA. La notificación de incidentes corre en paralelo: el artículo 73 a la autoridad de vigilancia del mercado, NIS2 al CSIRT nacional, en relojes distintos.
¿Es el operador de red o el proveedor de IA el responsable del cumplimiento? Normalmente ambos, en roles distintos. El proveedor que desarrolla y suministra la IA de red suele ser el proveedor según el artículo 16, cargando con la evaluación de la conformidad y el marcado CE. El operador que la despliega suele ser un responsable del despliegue según el artículo 26, responsable de usarla según las instrucciones, asegurar la supervisión humana y monitorizar. Según el artículo 25, un operador que modifica sustancialmente el sistema o lo introduce en el mercado bajo su propio nombre se convierte en proveedor y hereda las obligaciones más pesadas. Proyectar cada sistema sobre el rol correcto pronto evita brechas.
¿Cuándo se aplican de verdad estas obligaciones? La mayoría de los sistemas de alto riesgo de red y SCADA se sitúan en la vía autónoma del anexo III (artículo 6(2)), que se aplica desde el 2 de diciembre de 2027. Esa fecha la fija el Ómnibus Digital, adoptado en junio de 2026: el Parlamento Europeo lo votó en el pleno el 16 de junio de 2026 y el Consejo lo adoptó formalmente el 29 de junio de 2026. Planifica frente al 2 de diciembre de 2027. La IA integrada en productos del anexo I sigue el calendario separado del 2 de agosto de 2027 (aplazamiento adoptado al 2 de agosto de 2028).
¿Cuáles son las sanciones por equivocarse en la clasificación? Las infracciones de obligaciones de alto riesgo acarrean multas de hasta 15 millones de euros o el 3 % del volumen de negocios anual total mundial, lo que sea mayor (artículo 99(4)). Suministrar información incorrecta o engañosa a las autoridades —por ejemplo, una evaluación de no-alto-riesgo del artículo 6(3) indefendible— acarrea hasta 7,5 millones de euros o el 1 % (artículo 99(5)). Las infracciones de prácticas prohibidas alcanzan 35 millones de euros o el 7 % (artículo 99(3)). Según el artículo 99(6), las pymes y empresas emergentes se limitan al menor de los importes aplicables. Documentar cada decisión de clasificación es la defensa práctica.
Plazos, sanciones y qué hacer antes de que la ley se asiente
El calendario autónomo del anexo III
La mayoría de los sistemas de alto riesgo de red y SCADA se sitúan en la vía autónoma del anexo III según el artículo 6(2), que se aplica desde el 2 de diciembre de 2027. Esa fecha la fija el Ómnibus Digital, adoptado en junio de 2026 (Parlamento Europeo: 16 de junio de 2026; Consejo: 29 de junio de 2026); es el Reglamento (UE) 2026/1744, publicado en el DOUE el 24 de julio de 2026 y en vigor desde el 27 de julio de 2026. Planifica frente al 2 de diciembre de 2027. Son fechas de calendario fijas: la propuesta de la Comisión de noviembre de 2025 vinculaba el inicio del alto riesgo a la disponibilidad de normas, con fechas límite de reserva, pero los colegisladores adoptaron fechas fijas. No todo está aplazado.
La vía de productos es separada. La IA integrada en productos regulados del anexo I vía artículo 6(1) sigue el 2 de agosto de 2027 (aplazamiento adoptado al 2 de agosto de 2028), relevante cuando la IA de energía vive dentro de un producto de homologación de tipo u otro producto del anexo I en lugar de como control autónomo.
Exposición a sanciones según el artículo 99
El artículo 99 fija los techos. El incumplimiento de las obligaciones de alto riesgo y de la mayoría de las demás acarrea hasta 15 millones de euros o el 3 % del volumen de negocios anual total mundial, lo que sea mayor (artículo 99(4)). Suministrar información incorrecta o engañosa a las autoridades —incluida una autoevaluación del artículo 6(3) indefendible— acarrea hasta 7,5 millones de euros o el 1 % (artículo 99(5)). Las infracciones de prácticas prohibidas alcanzan 35 millones de euros o el 7 % (artículo 99(3)). Según el artículo 99(6), las pymes y empresas emergentes se limitan al menor de los importes aplicables.
Un plan de acción sin arrepentimiento para 2026
El trabajo es idéntico tanto si el plazo cae en 2026 como en 2027, así que empieza ya. Inventaría cada sistema de IA. Aplica la prueba del componente de seguridad por sistema, separando el control en bucle cerrado de las herramientas de asesoría humana. Documenta el razonamiento del artículo 6(3) allí donde reclames estatus de no-alto-riesgo, y registra según el artículo 49. Empieza la base de evidencia de los artículos 9-15 para los sistemas que cruzan la línea: registro de riesgos, documentación del anexo IV, diseño de supervisión, registro proyectado sobre NIS2. Nada de ello se desperdicia en ningún escenario.
Guías relacionadas
- El anexo III, punto 2, y la doctrina del componente de seguridad
- cómo el artículo 6 clasifica la IA de alto riesgo
- qué cuenta como componente de seguridad
- el sistema de gestión de riesgos del artículo 9
- las dos vías al alto riesgo en la fabricación
Gestiona el cumplimiento de la Ley de IA en un solo lugar
Confir automatiza la clasificación de riesgos, la documentación técnica y los registros de auditoría para tu empresa. Sin consultores. Sin proyectos de seis meses. Prueba gratuita de 14 días.
Prueba gratis 14 días →