Robots industriales y cobots: ¿productos importantes del CRA?
Resumen
Esta guía sigue una versión ficticia de un cobot desde la clasificación hasta el límite del producto, la evaluación de riesgos, el SBOM, la firma de la versión, la notificación de vulnerabilidades y el traspaso entre operadores económicos. La misma estructura sirve para un brazo de 6 ejes, una célula colaborativa o un controlador de robot vendido con visión opcional y servicios de nube de flota.
- La ruta estándar es el punto de partida. Los robots industriales y cobots no figuran hoy en las listas de productos importantes o críticos del CRA. Trata como una clasificación aparte cualquier oferta en la que dominen funciones de cortafuegos, gestión de red o controlador resistente a manipulaciones.
- Empieza por el memorando de límites. Nombra la variante exacta: brazo, armario de control, consola de programación, opciones de bus de campo, entorno de ejecución, conector de flota o nube, uso previsto, elementos digitales suministrados, periodo de soporte y motivo de la ruta elegida.
- Ciberseguridad y seguridad de máquinas se cruzan desde 2027. ISO 10218-1:2025 añade requisitos de ciberseguridad cuando afectan a la seguridad del robot, y el Reglamento de Máquinas se aplica desde el 20 de enero de 2027. El expediente CRA y el caso de seguridad comparten evidencia en esos puntos.
- El soporte necesita una fecha creíble. El periodo de soporte es de al menos cinco años, salvo que el tiempo de uso previsto sea menor. Muchos robots funcionan bastante más tiempo en fábrica, así que el expediente debe nombrar una ventana que el fabricante pueda cumplir y comunicar la fecha de fin de soporte antes de la compra.
- La gestión de vulnerabilidades es un modelo operativo. El expediente debe nombrar quién recibe las alertas, quién aprueba las ventanas de mantenimiento, quién puede revertir una actualización y cómo quedan visibles las advertencias residuales.
- El traspaso también es evidencia. El fabricante conserva el expediente del producto; el integrador conserva el expediente de la célula terminada cuando sale bajo su nombre; el operador explota la célula. Cada transferencia se documenta, no se empuja informalmente al cliente.
¿Cómo se clasifica una versión de robot industrial o cobot?
Empieza por la oferta, no por el brazo. Un brazo de 6 ejes vendido a un integrador y el mismo brazo vendido como célula cobot completa a un taller pequeño son productos CRA distintos. La ruta depende de lo que compra el cliente, del controlador y la consola de programación que se entregan, y de si el fabricante también suministra la nube de flota, la configuración de seguridad y la ruta de actualización OTA.
La figura fija la ruta. La matriz fija el memorando de límites: una vez elegida la variante, estas son las filas de evidencia que el fabricante debería poder completar para esa variante concreta.
Venta como componente; el integrador construye la célula.
Brazo, controlador, consola de programación, entorno de ejecución, opciones de bus de campo, actualizaciones firmadas, proceso de gestión de vulnerabilidades y manual para integrador.
Autoridad de escritura de la estación de ingeniería, ranura de recuperación, exposición del bus de campo, seguimiento de avisos de proveedores y rotación de credenciales al retirar la célula.
Brazo colaborativo de fuerza limitada, configuración lista para uso, visión opcional y nube de flota.
Brazo, controlador, consola de programación, configuración de seguridad, sensor de visión, entorno de ejecución, conector de nube de flota y servicio OTA.
Modo colaborativo, rol del operador en espacio compartido, autoridad de la nube de flota, cuentas de la consola y ruta de firmware de seguridad firmado.
Reventa dentro de una línea de envasado o máquina de proceso bajo el marcado CE del integrador.
El fabricante del robot conserva en su expediente el brazo, controlador, consola de programación y software suministrado. La máquina terminada tiene su propio expediente bajo el marcado CE del integrador.
Avisos de proveedor sobre RT OS, bus de campo y visión; coherencia de declaraciones de conformidad del proveedor; exposición durante integración; encaje del soporte con el fabricante de la máquina.
¿Qué entra en el límite del producto robot?
Para un robot o cobot, el límite no coincide siempre con la valla de la célula. Coincide con lo que el fabricante suministra y mantiene: brazo, armario de control, firmware, entorno de ejecución, consola de programación, actualizaciones firmadas, conector de nube y documentación de usuario. Lo que aporta el cliente o el integrador queda fuera por defecto, salvo que el fabricante lo entregue como parte de la oferta.
¿Qué ruta de evaluación de la conformidad se aplica?
Los robots industriales y cobots no figuran hoy en las listas CRA de productos importantes o críticos, así que la ruta estándar es la hipótesis de planificación. El fabricante puede elegir control interno, examen UE de tipo más conformidad con el tipo, aseguramiento pleno de la calidad o un esquema europeo de certificación de ciberseguridad aplicable. La elección no depende de aplicar normas armonizadas.
La condición de «normas plenamente aplicadas» pertenece a la ruta de reserva para productos importantes, no a la ruta por defecto. Si una actualización futura añadiera un subproducto de robot o cobot a esa lista y las normas o esquemas disponibles no cubrieran los requisitos esenciales relevantes, el fabricante necesitaría una ruta de evaluación por tercero para la parte no cubierta. La lista no incluye robots hoy.
El Reglamento de Máquinas 2023/1230 se aplica desde el 20 de enero de 2027 e incluye requisitos de seguridad que se solapan con evidencia ciber, especialmente protección frente a la corrupción y fiabilidad de los sistemas de mando. Trata el expediente CRA y el expediente de seguridad de la máquina como dos hilos de una misma carpeta de producto.
¿Qué controles de arquitectura pertenecen al expediente del robot?
El expediente debe explicar cómo el fabricante controla los puntos en los que una orden digital puede cambiar el movimiento, la configuración de seguridad o el estado de actualización.
| Punto de arquitectura | Qué se comprueba | Evidencia mínima |
|---|---|---|
| Controlador y CPU de movimiento | Quién puede escribir lógica, parámetros y firmware | Modelo de autoridad, firma de firmware, registro de cambios |
| Consola de programación | Qué roles pueden mover el robot, cargar programa o cambiar modo | Matriz de roles, prueba de credenciales, auditoría de sesión |
| Bus de campo | Qué tráfico puede afectar al ciclo de movimiento | Lista de protocolos, reglas de segmentación, prueba de tramas anómalas |
| Nube de flota | Qué autoridad remota existe sobre actualizaciones y telemetría | Mapa de puntos de conexión, certificados, ventana de mantenimiento, reversión |
| Servicio local | Cómo se controlan USB, recuperación y túneles temporales | Modo de servicio, registro de intervención, prueba de cierre automático |
¿Cómo se construye la evaluación de riesgos del robot?
¿Qué producto estamos evaluando?
El ejemplo usa una célula cobot completa vendida a una pyme: brazo de fuerza limitada, controlador, consola de programación, configuración de seguridad preparada, visión opcional, conector de nube de flota, actualizaciones firmadas y documentación de usuario. No evalúa una línea completa de planta ni una célula diseñada por un integrador salvo en los puntos de traspaso.
| Decisión de alcance | Elección del ejemplo | Por qué importa |
|---|---|---|
| Variante | Célula cobot completa | El fabricante conserva el expediente completo de producto |
| Límite digital | Controlador, consola, firmware, visión, nube, OTA | Es lo que puede cambiar movimiento, configuración o disponibilidad |
| Cliente | Pyme operadora | Menos equipo interno de seguridad, más dependencia del fabricante |
| Integrador | Puede instalar, pero no reetiqueta el producto | El traspaso existe, pero no desplaza automáticamente el expediente |
Antes de escribir la tabla de amenazas, prueba las tres rutas que suelen decidir el riesgo del robot: carga de programa y autoridad de la consola, frontera entre seguridad funcional y ciberseguridad, y traspaso al integrador. La figura convierte el ejemplo en preguntas de ingeniería, no en una lista genérica de amenazas.
¿Cómo cambia la superficie de ataque entre un robot vallado y un cobot?
| Superficie | Robot industrial vallado | Cobot de fuerza limitada |
|---|---|---|
| Proximidad humana | Excluida por valla, cortina o enclavamiento | Continua; la monitorización de fuerza, velocidad o separación forma parte del caso de seguridad |
| Acceso a la consola | Normalmente dentro de la célula bloqueada | Espacio compartido, a menudo con rol activo del operador |
| Entrada de visión | Opcional y localizada | Frecuente, a veces central para seguridad y operación |
| Teleoperación | Menos habitual | Cada vez más habitual en algunas gamas |
| Actor más probable | Servicio, ingeniería o integrador | Operador, estación remota o mal uso de rol compartido |
¿Qué activos se protegen?
| Activo | Por qué importa | Ejemplo de evidencia |
|---|---|---|
| Autoridad de movimiento | Cambia trayectoria, velocidad o modo | Matriz de roles, prueba de sesión, bloqueo de modo |
| Firmware de seguridad | Afecta parada, velocidad, separación y enclavamientos | Firma, revisión conjunta seguridad funcional/ciber |
| Programas de robot | Pueden introducir movimientos inseguros o interrupciones | Validación del analizador, control de origen, registro de carga |
| Credenciales de la consola | Permiten cambios locales en producción | Rotación inicial, caducidad, auditoría de operador |
| Conector de nube | Puede distribuir avisos, actualizaciones o túneles | Certificados, lista de puntos de conexión, prueba de reversión |
| Componentes de software | RT OS, visión, bus de campo y librerías tienen vulnerabilidades | SBOM, seguimiento de avisos, decisión de parche |
¿Dónde están los límites de confianza principales?
| Límite | Cruce | Pregunta de riesgo |
|---|---|---|
| Fabricante a integrador | Manual, paquete de importador, configuración de seguridad y avisos | ¿Qué se entrega y qué queda fuera? |
| Integrador a operador | Célula instalada, roles, ventanas de mantenimiento | ¿Quién puede cambiar el movimiento después de la entrega? |
| Estación de ingeniería a controlador | Proyecto, programa, firmware, parámetros | ¿Qué prueba impide una escritura fuera de sesión? |
| Nube a flota | Avisos, actualizaciones, certificados, túneles | ¿Qué autoridad remota existe y cómo se revoca? |
| Proveedor a fabricante | Componentes, librerías, firmware de tercero | ¿Cómo se detecta un aviso que afecta al robot? |
¿Qué amenazas se evalúan primero?
| ID | Amenaza | Activo afectado | Límite |
|---|---|---|---|
| R1 | Una cuenta de fábrica o del integrador queda activa tras la entrega | Autoridad de movimiento | Integrador a operador |
| R2 | Un paquete de firmware antiguo se acepta durante recuperación | Integridad de firmware | Servicio local |
| R3 | La nube de flota inicia un túnel fuera de la ventana de mantenimiento | Autoridad remota | Nube a flota |
| R4 | Un proyecto manipulado cambia la lógica de velocidad o separación | Seguridad colaborativa | Estación de ingeniería |
| R5 | Un certificado caducado bloquea avisos o actualizaciones | Disponibilidad | Nube |
| R6 | El operador no recibe una alerta de vulnerabilidad a tiempo | Gestión de vulnerabilidades | Fabricante a operador |
| R7 | Un proveedor publica un aviso que afecta al RT OS o a la visión y no se detecta | Componentes | Proveedor a fabricante |
| R8 | Una trama de bus de campo provoca fallo de CPU de movimiento o sobrecarga de ciclo | Disponibilidad de movimiento | Bus de campo |
| R9 | Una imagen USB de recuperación se aplica sin auditoría | Integridad de firmware | Medio de servicio |
| R10 | Un paquete de diagnóstico expone nombres de programa, certificados o red | Datos de servicio | Portal de soporte |
| R11 | Una vulnerabilidad en RT OS, bus de campo o visión no se detecta durante el soporte | Componentes de firmware | Avisos de proveedor |
| R12 | Una transferencia de cliente deja activa la estación de ingeniería anterior | Credenciales | Retirada de servicio |
| R13 | El analizador del entorno de ejecución falla o ejecuta contenido no seguro desde un proyecto malformado | Integridad de herramientas | Importación de proyecto |
| R14 | El integrador combina el brazo con un PLC de seguridad de tercero sin evidencia vigente | Conformidad de proveedor | Traspaso de célula |
¿Cómo se priorizan los riesgos iniciales?
Usa una escalera de decisión. No todos los riesgos necesitan la misma respuesta.
| Resultado residual | Por qué queda | Evidencia operativa |
|---|---|---|
| Parche de larga duración | Un componente de proveedor no tiene corrección todavía | Aviso de componente, mitigación temporal, fecha de revisión |
| Cambio del cliente | El operador quiere integrar una estación propia | Memorando de límites, nota de alcance, instrucción de soporte |
| Momento del parche | La planta necesita ventana y validación | Aviso con impacto de máquina, mitigación, reversión |
| Acceso físico de servicio | Armarios, consolas y estaciones son accesibles en mantenimiento | Restricciones de modo servicio, muestra de auditoría, bloqueo de depuración |
¿Qué controles de diseño cambian el riesgo?
| Control | Qué reduce | Evidencia |
|---|---|---|
| Firmware firmado con rechazo de versión anterior | Paquetes antiguos o manipulados | Registro de prueba de actualización, hash, resultado de rechazo |
| Credenciales por dispositivo y rotación inicial | Cuentas compartidas de fábrica | Registro de aprovisionamiento, prueba de primer arranque |
| Roles separados para operador, mantenimiento e ingeniería | Cambios de movimiento fuera de rol | Matriz de autorización y auditoría |
| Ventanas de mantenimiento para nube y túneles | Autoridad remota abierta | Registro de ventana, cierre automático, reversión |
| SBOM y seguimiento de proveedor | Avisos que no llegan al equipo | SBOM, fuentes de avisos, decisión de clasificación |
¿Qué riesgo residual queda tras los controles?
Tras aplicar controles, el fabricante debe nombrar qué queda vivo y por qué. En este ejemplo, el riesgo de vulnerabilidad de proveedor permanece porque el robot depende de RT OS, visión y bus de campo de terceros. El riesgo no se acepta en abstracto: se vincula a seguimiento de avisos, firmado de paquetes, ventanas de mantenimiento, comunicación con integradores y pruebas correctivas. La mitigación documentada debe demostrar que el proceso existe antes de que empiece la producción.
¿Cómo deben circular los avisos de la nube de flota?
La evaluación anterior vive en un armario de robot. El enrutamiento de avisos vive en cientos de robots. Cuando la nube de flota del fabricante da servicio a varios integradores y plantas, la pregunta no es solo si la nube es segura. La pregunta es quién recibe una alerta de vulnerabilidad en 24 h y quién aprueba la ventana de actualización de cada sitio.
| Topología de flota | Quién queda entre fabricante y usuario final | Qué cambia en el expediente |
|---|---|---|
| Operador de un solo sitio, directo del fabricante | Fabricante → operador | El aviso llega al equipo de mantenimiento del operador; un canal puede bastar |
| Operador multisede con ingeniería central | Fabricante → ingeniería central → plantas | El expediente debe registrar el contacto central para que el aviso no se pierda en un buzón local |
| Flota gestionada por OEM | Fabricante → operaciones OEM → operadores finales | El OEM reenvía avisos con impacto de máquina, pero el fabricante necesita ruta hacia usuarios afectados |
| Flota gestionada por integrador | Fabricante → integrador → pymes usuarias | El aviso del fabricante alimenta el proceso propio del integrador cuando este vende bajo su marca |
| Flota de flotas | Nube del fabricante ↔ nube OEM ↔ nube de integrador ↔ operador | Documenta qué cadena es contractual y cuál cubre notificación regulatoria y usuarios |
Registro de versión. Un mapa de enrutamiento de nube de flota debe nombrar, para cada integrador y operador de la lista, el contacto de alertas de 24 h, el dueño de la ventana de mantenimiento, la autoridad de reversión y los avisos residuales abiertos.
¿Qué puertas de validación se cierran antes de liberar?
Evita una puerta genérica de «seguridad revisada». Usa un inventario de puertas con modo de fallo, control y evidencia para cada decisión que puede bloquear el envío.
| Puerta | Fallo que bloquea | Evidencia |
|---|---|---|
| Cierre de variante | No está claro qué se vende | Memorando de límites y ruta |
| Autoridad de movimiento | Un rol incorrecto puede cambiar trayectoria o modo | Prueba negativa y auditoría |
| Firmware de seguridad | La actualización altera la lógica de seguridad sin revisión | Revisión conjunta y prueba firmada |
| Bus de campo | Tramas anómalas afectan ciclo o disponibilidad | Prueba de bus y segmentación |
| Nube y OTA | La nube conserva autoridad indefinida | Ventana, certificados, reversión |
| Documentación | Falta contacto, soporte o instrucciones | Índice de expediente y paquete de importador |
¿Quién asume el desarrollo del robot de concepto a soporte?
Usa un carril de responsabilidad. Cada fase tiene un responsable principal, un registro mantenido y una puerta de revisión. La versión no se cierra hasta que cada fase deja rastro.
¿Qué registros de evidencia van en el expediente?
La lista siguiente es una vista revisable. Congela la identidad del producto, los controles de seguridad y las obligaciones postventa. Cada fila debe apuntar a un registro mantenido, no a una carpeta de capturas sueltas.
| Registro de evidencia | Qué captura para un robot industrial o cobot |
|---|---|
| Identidad del producto | Modelo de brazo, carga útil, alcance, armario de control, consola de programación, rama de firmware, entorno de ejecución, sensor de visión, opciones de bus, servicio de hardware |
| Uso previsto | Operación colaborativa o vallada, carga útil, aplicación, modo operador, patrón de uso y variante |
| Expediente de ciberresiliencia | Ruta de clasificación, límites, lista de amenazas, controles de confianza y decisiones residuales |
| Inventario de componentes | CPU de movimiento, SO en tiempo real, pila de bus de campo, pila esclava EtherCAT, firmware de seguridad, entorno de ejecución, librerías, módulo de visión |
| Configuración segura por defecto | Sin secreto compartido, cuentas únicas, bloqueo de versión anterior, OPC UA seguro por defecto, servicio tras la puesta en marcha |
| Mecanismo de actualización | Firmware firmado, reversión, mapa de impacto de máquina, contacto de cliente y evidencia de nube |
| Gestión de vulnerabilidades | Política de divulgación, contacto único, flujo de clasificación, seguimiento de avisos de componentes e integradores |
| Instrucciones de usuario | Puesta en marcha segura, gestión de roles, retirada, ventanas de actualización, límites de servicio |
| Trazabilidad y contacto | Tipo, lote o serie, datos del fabricante, fecha de fin de soporte y contacto de vulnerabilidades |
¿Qué entra en un SBOM de robot?
El CRA exige un SBOM legible por máquina que identifique componentes y cubra al menos dependencias de primer nivel, pero aún no fija un formato único. Hasta que la Comisión concrete más detalle, los fabricantes suelen elegir CycloneDX o SPDX. La guía transversal está en la guía de SBOM; esta sección cubre el árbol propio del robot.
Una versión de robot suele entregar varios elementos digitales con ciclos de actualización separados, no un único binario. Dos patrones cumplen el mínimo: un SBOM de producto con secciones por elemento, o un SBOM por elemento digital suministrado que se actualiza en cada versión. Cualquiera de los dos sirve si el SBOM es legible por máquina y cubre dependencias de primer nivel.
Registro SBOM: un SBOM legible por máquina en CycloneDX o SPDX que cubra al menos dependencias de primer nivel. Para robots, suele ser un SBOM de producto con secciones por elemento, o un SBOM por elemento digital suministrado. Las dependencias transitivas más profundas son recomendables cuando el sistema de compilación puede producirlas.
¿Qué comprueba la firma de la versión?
Antes de que el robot salga al mercado de la UE, la firma debe cerrar los mismos cuatro registros de las preguntas Q1 a Q4. El inventario no vive en la evidencia abstracta de arriba. Esta tabla es solo para las cuatro decisiones que bloquean la versión.
Firma de versión: cuatro registros que bloquean la salida
- Q1 Memorando de clasificación. Por qué el producto se clasifica así: uso previsto, contexto de venta, elementos digitales entregados y ruta estándar elegida.
- Q2 Inventario de elementos entregados. Qué se envía exactamente: brazo, controlador, consola de programación, visión, firmware, nube, librerías, manuales y variantes.
- Q3 Paquete de prueba segura por defecto. Credenciales por dispositivo, perfil OPC UA, rechazo de versión anterior, bloqueo de depuración y modo de servicio.
- Q4 Proceso de gestión de vulnerabilidades. Contacto público, política de divulgación, clasificación, seguimiento de componentes, integradores y preparación para notificaciones.
Comprobaciones previas: los cuatro registros deben encontrarse en menos de un minuto; las carpetas deben estar fijadas a la rama de firmware y a la línea base de proveedores; debe existir un responsable nombrado para avisos de 24 h y 72 h.
Puerta de firma: si falta un registro, la versión no se firma.
Registro de declaración: usa la guía principal de declaración UE de conformidad para la plantilla y los campos requeridos. En una versión de robot, la identidad del producto debe fijar brazo, armario de control, consola de programación, rama de firmware, opciones suministradas y referencia al periodo de soporte. Si la misma declaración cubre también legislación de máquinas, nombra esa ruta y mantén alineados el expediente técnico del robot y el expediente de seguridad de la máquina.
¿Cómo se traspasa el robot a importador, distribuidor, integrador y operador?
El expediente debe hacer verificable el traspaso desde fabricante a importador, distribuidor, integrador como fabricante de máquina y usuario final. En robots y cobots, el punto débil no suele ser solo el marcado CE. Suele ser si el envío, manual, nube de flota, servicio OTA y traspaso al integrador siguen coincidiendo con la versión evaluada.
Traspaso de operadores económicos: roles, comprobaciones y regímenes cercanos
- 01 Fabricante. Mantiene el paquete de versión: declaración, CE, índice de expediente, ventana de soporte y contacto de vulnerabilidades.
- 02 Importador. Verifica paquete, CE, índice, fecha de soporte y contacto. Pausa el envío si hay dudas sobre trazabilidad, credenciales, cuenta de nube o canal de actualización.
- 03 Distribuidor. Revisa CE visible, documentos suministrados, trazabilidad del operador, soporte y afirmaciones de actualización. Pausa la venta si el anuncio oculta operadores, exagera soporte o contradice la declaración.
- 04 Integrador. Combina brazo con seguridad, visión y lógica de célula. Si la célula sale bajo su nombre, el integrador pasa a ser fabricante de la célula.
- 05 Operador. Recibe avisos, aplica actualizaciones en ventanas de mantenimiento e informa de problemas. No es fabricante.
Comprobación A: representante y notificación no UE. El mandato de representante autorizado es opcional. Fabricantes sin establecimiento principal en la Unión usan la cascada de punto de notificación para elegir el CSIRT coordinador.
Comprobación B: nuevos fabricantes. Un importador o distribuidor que vende bajo su propio nombre, o modifica sustancialmente el robot, pasa a ser fabricante de esa oferta. Otros terceros solo cruzan esa línea cuando su cambio es sustancial.
Regímenes cercanos: Reglamento de Máquinas desde el 20 de enero de 2027, ISO 10218-1:2025, NIS2 para operadores de infraestructuras críticas y Reglamento de IA para aplicaciones con IA.
Las filas siguientes son la versión corta: qué verificar, cuándo pausar y cuándo el robot necesita un nuevo análisis de rol. El detalle transversal de roles está en quién debe cumplir el CRA.
Aceptación del importador
Verifica declaración, control del CE, índice de expediente, periodo de soporte, contacto de vulnerabilidades, identidad del importador y manual en el idioma de destino. Pausa si el paquete, trazabilidad, modelo de credenciales de la consola, cuenta de nube o canal de actualización generan dudas.
Diligencia del distribuidor
Comprueba CE visible, documentos suministrados, trazabilidad del operador, soporte y afirmaciones de actualización. Pausa si la oferta oculta operadores, exagera el soporte, contradice la declaración o sigue vendiendo tras una vulnerabilidad conocida.
Integrador como fabricante de máquina
Un integrador que combina el brazo con seguridad, visión y lógica de célula pasa a ser fabricante de la máquina cuando la célula sale bajo su nombre. El fabricante del robot sigue siendo fabricante del componente para brazo, controlador y software suministrado.
Importador o distribuidor bajo marca propia
Un importador o distribuidor que pone el robot en el mercado de la Unión bajo su propio nombre o marca pasa a ser fabricante de esa oferta. Lo mismo ocurre si modifica sustancialmente un robot ya comercializado: firmware con marca propia, nueva identidad de consola, nueva nube de flota, nuevo canal de actualización, nueva configuración de seguridad o nueva finalidad prevista.
Otro revendedor tras modificación sustancial
Un tercero que no es fabricante, importador ni distribuidor pasa a ser fabricante solo si modifica sustancialmente el robot antes de ponerlo a disposición. El rol se aplica a la parte afectada, o al producto completo si el cambio afecta a la ciberseguridad global.
Representante autorizado y notificación no UE
El fabricante puede nombrar un representante autorizado mediante mandato escrito; es una opción, no una obligación por estar fuera de la UE. La selección del punto de notificación se activa por otro hecho: no tener establecimiento principal en la Unión. La cascada del CRA empieza por representante, sigue por importador, después distribuidor y finalmente mayor base de usuarios.
Regímenes cercanos
Mantén evaluaciones separadas para Reglamento de Máquinas, ISO 10218-1:2025, NIS2 y Reglamento de IA. Pueden compartir evidencia, pero no sustituyen el expediente CRA.
Preguntas frecuentes
¿Los robots industriales y cobots son importantes o críticos bajo el CRA?
No por categoría de robot. Los robots industriales y cobots no figuran hoy en las listas CRA de productos importantes o críticos. La hipótesis de trabajo es la ruta por defecto. La ruta solo cambia si domina una función listada, por ejemplo un robot vendido principalmente como cortafuegos, sistema de gestión de red o controlador resistente a manipulaciones. No existe una categoría de «robot» que fuerce automáticamente la ruta crítica.
¿Un brazo robótico de 6 ejes necesita organismo notificado?
No por ser brazo robótico. En la ruta por defecto, el fabricante puede usar control interno, examen UE de tipo más conformidad con el tipo, aseguramiento pleno de la calidad o un esquema europeo de certificación aplicable. El organismo notificado interviene solo en las rutas que lo requieren. La condición de normas plenamente aplicadas pertenece a la ruta de reserva para productos importantes de clase I, no a la ruta por defecto.
¿El Reglamento de Máquinas ya cubre la parte ciber?
Cubre una parte, no todo. El Reglamento de Máquinas incluye requisitos de seguridad relacionados con corrupción de sistemas de mando y fiabilidad del control. El CRA añade la capa de ciberresiliencia: postura de seguridad, proceso de vulnerabilidades, soporte, SBOM y documentación técnica. Trátalos como dos expedientes conectados.
¿Quién es fabricante cuando un integrador construye la célula?
Si el integrador vende la célula terminada bajo su nombre, el integrador es fabricante de esa célula. El fabricante del robot mantiene su expediente para brazo, controlador y software que suministra. Si el integrador solo instala una célula bajo la marca del fabricante, documenta el traspaso y los límites, pero no inventes un cambio de rol que no existe.
¿Un cobot para talleres pyme cae en la misma categoría que un robot vallado?
Sí, si ninguna función listada domina la oferta. La diferencia está en la evaluación de riesgos, no en la categoría CRA inicial. El cobot suele tener más exposición humana, más roles compartidos y más dependencia del fabricante para avisos, soporte y actualizaciones.
¿Qué pasa si el robot incluye visión, IA o teleoperación remota?
No cambia automáticamente la categoría CRA. Sí cambia el límite y la lista de amenazas. La visión añade cámaras, SDK y modelos; la teleoperación añade autoridad remota; la IA puede activar análisis bajo el Reglamento de IA si cumple sus umbrales. Cada elemento debe aparecer en el memorando de límites y en el SBOM.
¿La nube de flota cambia el límite del producto?
Sí, cuando la nube es suministrada por el fabricante y es necesaria para avisos, actualizaciones, certificados, telemetría o túneles. En ese caso, el conector de nube y su autoridad forman parte del expediente del fabricante. Si la nube pertenece al cliente o al integrador, documenta el traspaso y los límites.
¿Qué debe incluir una evaluación de riesgos CRA de un robot?
Debe cubrir movimiento, firmware de seguridad, consola de programación, estación de ingeniería, bus de campo, nube, servicio local, componentes de proveedor, retirada de servicio y comunicación de vulnerabilidades. La pregunta no es solo si hay cifrado. La pregunta es quién puede cambiar el movimiento, la configuración de seguridad o la disponibilidad.
¿Cuánto detalle necesita el modelo de amenazas?
El suficiente para probar decisiones de versión. Una frase genérica sobre «acceso no autorizado» no sirve. Una entrada útil nombra activo, límite, modo de fallo, control, prueba y decisión residual: por ejemplo, «un paquete de firmware antiguo se acepta durante recuperación; se mitiga con firma y rechazo de versión anterior; se prueba en el modo de recuperación».
¿Qué riesgos se evalúan primero?
Empieza por los que cambian movimiento o seguridad: credenciales de fábrica, actualizaciones de firmware, autoridad de nube, carga de programas, roles de la consola y bus de campo. Después cubre disponibilidad, datos de servicio, avisos de proveedor y retirada de servicio.
¿Cuál es un buen ejemplo de entrada de riesgo?
«Un proyecto de robot malformado provoca un fallo del analizador o carga una trayectoria no validada desde la estación de ingeniería. Activo: autoridad de movimiento. Límite: estación de ingeniería a controlador. Control: validación de formato, firma del proyecto, rol de ingeniería y prueba negativa. Evidencia: informe del analizador, registro de rechazo y auditoría de sesión.»
¿Cuándo debe actualizarse la evaluación de riesgos?
Actualízala cuando cambie el estado liberado: nuevo modelo de cuentas de la consola, nuevo bus de campo, cambio de nube, firmware de seguridad, entorno de ejecución, módulo de visión, depuración o retirada de servicio. La fecha temprana importa: las obligaciones de notificación empiezan el 11 de septiembre de 2026, antes de la aplicación completa del CRA el 11 de diciembre de 2027. La evaluación, la política de divulgación y el contacto único deben funcionar antes de esa fecha.
¿Cuál es la primera evidencia que debe crear un fabricante de robots?
El memorando de límites. Nombra el producto exacto, qué se entrega, qué queda fuera, qué integra el cliente, qué mantiene el fabricante y qué ruta de conformidad se usa. Sin ese registro, el SBOM, la evaluación de riesgos y el traspaso al integrador quedan flotando.
¿Qué pasa si se descubre una vulnerabilidad después de la liberación?
El fabricante debe actuar de inmediato cuando el producto o los procesos no cumplen: corrección, retirada o recuperación del producto cuando proceda. En la práctica, el expediente necesita preparación para la secuencia de notificación: alerta de 24 h para vulnerabilidad explotada activamente, notificación de 72 h, informe final cuando esté disponible la medida correctiva o mitigadora, y aviso a usuarios. En robots, la corrección suele ser una actualización firmada con nota de impacto de máquina y propuesta de ventana de mantenimiento; la recuperación queda para casos que no pueden actualizarse con seguridad en campo.