Nvidia adquiere Hugging Face por más de 11.000 millones de euros
Eva Mickler
4 Min. de lectura Nvidia adquiere Hugging Face por unos 11.100 millones de euros, contrato del 2 de septiembre ...
Leer artículo
9 min de lectura
El 11 de septiembre de 2026 entra en vigor el artículo 14 del Reglamento de Resiliencia Cibernética. A partir de esa fecha, los fabricantes deberán notificar las vulnerabilidades explotadas activamente y los incidentes graves de seguridad en plazos fijos. Para los CIO y CDO, el mensaje clave está en la adquisición: la obligación de notificación recae sobre el fabricante. Quienes adquieran productos de fabricantes cuyos procesos aún no están establecidos recibirán tarde -o no recibirán- información sobre una vulnerabilidad explotada activamente en su propio entorno.
Lo más importante en resumen
- Obligación de notificación a partir del 11 de septiembre de 2026: El artículo 14 del RRC se aplicará a partir de esa fecha a los fabricantes; la organización operadora queda fuera de esta obligación de notificación.
- Solo 24 y 72 horas para los fabricantes: La alerta temprana y la notificación posterior corresponden al fabricante, que debe informar tanto a la CSIRT coordinadora como a la ENISA.
- Los contratos necesitan solidez: Las pruebas, los canales de notificación, las actualizaciones y una fecha de finalización definida del soporte sustituyen a una garantía genérica de cumplimiento legal.
RelacionadoPor qué la factura de la nube nunca disminuye / Regulación de IA: hasta un 3 por ciento del volumen de negocios del grupo
Cuatro semanas hasta el artículo 14: la situación para las compras
El Reglamento de Resiliencia Cibernética entró en vigor el 10 de diciembre de 2024. Las obligaciones principales entrarán en vigor el 11 de diciembre de 2027. Entre ambas fechas se encuentra el hito que ahora preocupa a las operaciones: el artículo 14 entrará en vigor el 11 de septiembre de 2026. En organizaciones más grandes, los CIO, CDO y estrategas de TI gestionan presupuestos, relaciones con proveedores y decisiones arquitectónicas. Precisamente ahí recae el impacto de la obligación de notificación, aunque la organización en sí no esté sujeta a esta obligación.
¿Qué es el Reglamento de Resiliencia Cibernética? El Reglamento de Resiliencia Cibernética es un marco jurídico de la UE para la ciberseguridad de productos con elementos digitales. Obliga a los fabricantes a cumplir requisitos de seguridad durante todo el ciclo de vida y a notificar vulnerabilidades explotadas activamente, así como incidentes graves de seguridad. El RRC entró en vigor el 10 de diciembre de 2024. El artículo 14 se aplicará a partir del 11 de septiembre de 2026, y las obligaciones principales entrarán en vigor el 11 de diciembre de 2027.
Para el CIO, la asignación de las obligaciones es el mensaje central. La obligación de notificación recae sobre el fabricante. El operador adquiere productos que funcionan en redes, sistemas de control y aplicaciones especializadas. Si el fabricante no domina sus vías de notificación e información, la organización operadora carecerá de información oportuna sobre vulnerabilidades explotadas activamente en su propio entorno. Por ello, la perspectiva de acción se centra en los contratos, las conversaciones con proveedores y el control de la cadena de suministro.
Quién debe informar, a quién y por qué responde el fabricante
Los fabricantes deben informar simultáneamente al CSIRT de coordinación y a la ENISA. Para ello existe una plataforma conjunta de notificación. Los detalles técnicos de esta plataforma aún no se han hecho públicos. En cuanto a su funcionamiento, el proceso se basa en la relación de suministro: el fabricante sigue siendo el destinatario de la obligación de notificación y el interlocutor para el comprador.
La responsabilidad no finaliza con la lista de componentes del fabricante. Este sigue siendo responsable de la componente completa, incluso si adquiere piezas a terceros. Los plazos de 24 y 72 horas aplican al fabricante. No se aplican de forma general a cada proveedor de la cadena. Por ello, si un CIO gestiona una cadena de suministro multinivel, debe aclarar cómo fluyen las informaciones desde el subproveedor hasta el fabricante y desde este hasta su propia empresa.
El fin del soporte tampoco altera significativamente la asignación de responsabilidades. Ante el fin del soporte de un componente, el fabricante sigue siendo responsable de subsanar las vulnerabilidades durante al menos cinco años. Para arquitecturas con largos períodos de operación, esto implica que un producto que quede fuera del soporte activo no dejará de estar bajo la responsabilidad en materia de seguridad del fabricante. En las decisiones de adquisición, este plazo debe incluirse en la evaluación del ciclo de vida del producto y de la estrategia de sustitución.
Plazos, contenidos de notificación y sanciones
El artículo 14 distingue dos casos: vulnerabilidades explotadas activamente y graves incidentes de seguridad. Ambos procesos comienzan con una alerta temprana en un plazo de 24 horas. Los plazos se dirigen al fabricante. Para el operador, estos plazos no constituyen una obligación legal de notificación propia según el artículo 14, pero sí marcan la velocidad a la que deben circular las informaciones en el entorno del fabricante cuando el propio parque esté afectado.
En el caso de vulnerabilidades explotadas activamente, se deben facilitar más informaciones en un plazo de 72 horas y un informe final en un plazo de 14 días tras la disponibilidad de una medida correctiva. En el caso de graves incidentes de seguridad, la notificación del incidente debe realizarse en un plazo de 72 horas y el informe final en un plazo de un mes tras la notificación del incidente. Si un CIO habla con fabricantes sobre procesos de incidentes y vulnerabilidades, necesita conocer estas etapas como base de la conversación: ¿cuándo se entera el cliente de la alerta temprana, cuándo de la notificación posterior y cuándo de la medida correctiva?
| Fecha límite | Qué aplica | Para quién |
|---|---|---|
| 10 de diciembre de 2024 | Entrada en vigor del Reglamento de Resiliencia Cibernética | Fabricantes y demás destinatarios del CRA |
| 11 de septiembre de 2026 | Artículo 14: obligaciones de notificación por vulnerabilidades explotadas activamente y graves incidentes de seguridad | Fabricantes como obligados a notificar |
| En un plazo de 24 horas | Alerta temprana en caso de vulnerabilidad explotada activamente o grave incidente de seguridad | Fabricantes, notificación al CSIRT de coordinación y a la ENISA |
| En un plazo de 72 horas | Más informaciones en caso de vulnerabilidades o notificación del incidente en graves incidentes de seguridad | Fabricante |
| En un plazo de 14 días tras la disponibilidad de una medida correctiva | Informe final en caso de vulnerabilidad explotada activamente | Fabricante |
| En un plazo de un mes tras la notificación del incidente | Informe final en caso de grave incidente de seguridad | Fabricante |
| 11 de diciembre de 2027 | Entran en vigor las obligaciones principales del CRA | Fabricantes y demás destinatarios del CRA |
El CRA prevé multas de hasta 15 millones de euros o el 2,5 % del volumen de negocios anual mundial. La sanción afecta al destinatario de las obligaciones, es decir, al fabricante en la lógica de notificación del artículo 14. Para el CIO que realiza las compras, la cuantía de la multa altera el poder de negociación: un fabricante con procesos poco claros conlleva un riesgo regulatorio que, en la relación de suministro, se traduce en riesgos de fallos, retrasos e información. Las previsiones sobre la práctica de aplicación de las autoridades no deben incluirse en la planificación, ya que no están respaldadas. Lo que sí está respaldado son los plazos, los destinatarios y el marco sancionador.
Qué debe incluirse ahora en los contratos y en las conversaciones con proveedores
Una declaración genérica de cumplimiento legal no es suficiente. Los contratos con proveedores deben incluir pruebas, vías de notificación, actualizaciones y una fecha de finalización del soporte definida. Estos puntos están respaldados como requisitos. No existen textos modelo oficiales de cláusulas contractuales concretas. Compras, Legal y Seguridad deben traducir estos requisitos al lenguaje propio de la empresa y aplicarlos a las relaciones existentes con proveedores.
Las pruebas deben aclarar si el fabricante gestiona realmente sus procesos relevantes para el CRA. Las vías de notificación deben definir cómo la empresa se entera de una vulnerabilidad explotada activamente y quién recibe internamente la información. Las actualizaciones deben especificar cómo se proporcionan y documentan las medidas correctivas. Una fecha de finalización del soporte definida aclara cuándo termina el soporte activo y cómo se refleja en la relación la responsabilidad de al menos cinco años para la corrección de vulnerabilidades tras la finalización del soporte.
En las conversaciones con proveedores, un marco de verificación sencillo es útil. ¿Quién es responsable en la empresa fabricante de notificar al CSIRT coordinador y a la ENISA? ¿Cómo llega la información en paralelo al canal del cliente? ¿Qué subproveedores forman parte del componente global por el que el fabricante sigue siendo responsable? ¿Cuánto tiempo dura el soporte y cómo se organiza la obligación de corrección después? Estas preguntas se enmarcan en lo respaldado y evitan especulaciones sobre prácticas administrativas o costes de implementación.
Las decisiones arquitectónicas dependen de estos mismos puntos. Los productos con una fecha de finalización de soporte poco clara, rutas de actualización ambiguas o vías de notificación inexistentes aumentan el riesgo operativo. El artículo 14 obliga al fabricante a notificar las vulnerabilidades explotadas activamente y los incidentes graves al CSIRT coordinador y a la ENISA. Los usuarios afectados deben ser informados en paralelo. La finalización del soporte y las rutas de actualización regulan otras partes del CRA. El CIO gestiona el riesgo a través de la selección, la redacción contractual y las vías de escalación, aunque la obligación legal de notificación recaiga en el fabricante.
La postura contraria: carga para los fabricantes pequeños y medianos
La DIHK advierte sobre las cargas significativas que la implementación del CRA supondrá para las pymes. Muchos fabricantes pequeños no saben si el CRA les afecta. Algunos están considerando retirar productos del mercado. Para el CIO, esto no es un informe abstracto sobre la mediana empresa. Se trata de un problema de aprovisionamiento cuando un proveedor de nicho desaparece o ajusta su cartera.
En organizaciones más grandes, a menudo hay componentes especializados: módulos de control, sensórica, software sectorial, sistemas integrados. Si un fabricante pequeño considera que las obligaciones del CRA son demasiado gravosas y retira un producto, faltarán alternativas, conocimiento especializado y vías de migración. La perspectiva de actuación consiste en identificar con antelación a los proveedores críticos de nicho, verificar su capacidad para cumplir con el CRA y preparar alternativas o estrategias de transición.
Por ello, esta postura contraria debe incluirse en cada conversación con proveedores más pequeños. La pregunta es si el fabricante podrá asumir los procesos de notificación y seguridad hasta el 11 de septiembre de 2026 y las obligaciones principales a partir del 11 de diciembre de 2027. Si la respuesta no está clara, aumenta el riesgo de que el producto sea retirado. La empresa operativa asumirá entonces las consecuencias en la arquitectura y la continuidad operativa, aunque ella misma no esté sujeta a la obligación de notificación.
Alineación con la BSI TR-03183 y próximos pasos
La directriz técnica BSI TR-03183 agrupa los requisitos en tres partes: requisitos generales, lista de componentes de software y notificaciones de vulnerabilidades. Las partes 1 y 3 están disponibles en la versión 1.0.0. La parte 2 se encuentra en la versión 2.1.0. La primera fase de comentarios finalizó el 30 de noviembre de 2024. Desde entonces, el BSI gestiona la parte 1 como un documento vivo, mientras que la parte 3 se publicó en septiembre de 2025. Las versiones 0.9.0 y 2.0.0 solo están disponibles en el archivo.
Para los CIO y los estrategas de TI, esta directriz sirve como marco de orientación en las conversaciones con los fabricantes que suministran productos con elementos digitales. Los requisitos generales, la lista de componentes de software y las notificaciones de vulnerabilidades son los temas en los que se basan las pruebas y los procesos. Conocer los estados de las versiones ayuda a evitar expectativas erróneas: las tres partes están aprobadas, y la parte 1 se actualiza continuamente como documento vivo.
Las próximas semanas, hasta el 11 de septiembre de 2026, son ideales para organizar una ronda específica con proveedores. Priorice productos con alta relevancia operativa y larga vida útil. Solicite pruebas, vías de notificación, compromisos de actualización y una fecha definida de fin de soporte. Aclare los roles en la cadena, ya que los plazos de 24 y 72 horas afectan directamente al fabricante, quien sigue siendo responsable de los componentes en su totalidad. Vigile a los proveedores más pequeños para detectar señales de retirada de productos del mercado. Así podrá gestionar el riesgo antes de que entre en vigor el artículo 14 y antes de que, a partir del 11 de diciembre de 2027, se apliquen las obligaciones principales en la siguiente fase.
Preguntas frecuentes
¿A quién afecta la obligación de notificación según el artículo 14 a partir del 11 de septiembre de 2026?
La obligación de notificación recae sobre el fabricante. El operador queda al margen de esta obligación según el artículo 14. No obstante, para los CIO la repercusión sigue siendo alta, ya que adquieren productos de fabricantes sujetos a notificación y dependen de sus vías de información.
¿Las plazos de 24 y 72 horas también se aplican a cada proveedor de la cadena?
No. Los plazos de 24 y 72 horas son aplicables al fabricante. No se aplican de manera general a cada proveedor de la cadena. El fabricante sigue siendo responsable de la componente completa, incluso si compra piezas.
¿Dónde deben notificar los fabricantes y qué plazos se aplican en detalle?
Los fabricantes notifican simultáneamente al CSIRT coordinador y a la ENISA a través de una plataforma común de notificación. En caso de vulnerabilidades explotadas activamente, se aplica una alerta temprana en un plazo de 24 horas, información adicional en un plazo de 72 horas y un informe final en un plazo de 14 días tras la disponibilidad de una medida correctiva. En caso de incidentes graves de seguridad, se aplica una alerta temprana en un plazo de 24 horas, notificación del incidente en un plazo de 72 horas y un informe final en un plazo de un mes tras la notificación del incidente.
¿Qué debe incluirse en los contratos con proveedores para garantizar la operatividad?
En los contratos deben incluirse pruebas, vías de notificación, actualizaciones y una fecha de finalización del soporte definida. Una garantía genérica de cumplimiento legal no es suficiente. No existen cláusulas modelo oficiales. En caso de finalización del soporte, el fabricante sigue siendo responsable de subsanar vulnerabilidades durante al menos cinco años.
¿Por qué los fabricantes más pequeños ponen en riesgo la adquisición a pesar del enfoque del CRA en las obligaciones del fabricante?
La DIHK advierte de cargas considerables para las pymes debido a la implementación del CRA. Muchos fabricantes pequeños desconocen si el CRA les afecta. Algunos están considerando retirar sus productos del mercado. Un CIO que se quede sin su proveedor de nicho se enfrenta entonces a un problema de adquisición y migración en su propio inventario.
Más del grupo de medios MBF
Más para leer en Digital Chiefs
Digital ChiefsLos planes de capital de NVIDIA y lo que deben revisar los operadoresDigital ChiefsEl auge de las GPU frente a la IT verde: dónde cruje el gasto en IADigital ChiefsCuando la red es el límite y no la GPUFuente de la imagen: Generada por IA (agosto 2026)