¿El CRA se aplica a mi producto? Guía de ámbito

Comprobador del ámbito CRA: evaluación inicial de un producto

Responde a cuatro preguntas para obtener un fundamento de revisión y una lista de evidencias. Tus respuestas permanecen en este navegador; descarga el informe sin cuenta.

Es una evaluación inicial del ámbito, no asesoramiento jurídico ni confirmación de cumplimiento. El responsable del producto debe revisar el resultado. No determina las obligaciones específicas de los administradores de comunidad de programas informáticos de código abierto.

¿Evalúas software o hardware, incluido su tratamiento de datos a distancia necesario?Describe el producto, su versión y sus funciones. La etiqueta SaaS, por sí sola, no determina el ámbito.¿El uso previsto o razonablemente previsible incluye conexión con un dispositivo o red?Incluye conexiones directas e indirectas, lógicas y físicas.¿Se comercializa el producto en el mercado de la UE en el curso de una actividad comercial?Registra el modelo de distribución y tu papel. Un producto gratuito no es automáticamente un producto no comercial.¿Has identificado una posible exclusión o régimen específico del artículo 2 CRA?Comprueba normas sectoriales, fines de defensa y seguridad nacional y código abierto no comercial. Elige «No lo sé» si requiere revisión.

Fundamento de las preguntas: artículos 2 y 3 CRA

El ámbito CRA no se determina solo por el sector de la empresa ni por etiquetas como «SaaS», «IoT» o «proveedor de software». Empieza por el producto concreto con elementos digitales, su comercialización en la UE, el papel de la organización y cualquier tratamiento de datos a distancia que forme parte de sus funciones.

El resultado debe ser una evaluación documentada con fundamento visible de la conclusión, no un sí/no sin explicación.

Paso 1. Identifica el producto

Empieza por lo que un usuario compra, descarga, instala, integra o recibe como componente.

Registra:

nombre e identificador;
versión o familia de versiones;
finalidad prevista;
funciones principales;
modelo de entrega;
marca con la que llega al mercado;
mercados donde se comercializa.

Si el equipo no puede delimitar el producto, el resto depende de supuestos difíciles de revisar después.

Paso 2. Comprueba la definición de producto con elementos digitales

El CRA lo define como producto de software o hardware y sus soluciones de tratamiento de datos a distancia. Los componentes comercializados por separado también pueden estar incluidos.

Para servicios remotos importa la relación funcional. El reglamento describe tratamiento a distancia cuyo software diseña y desarrolla el fabricante o se desarrolla bajo su responsabilidad y cuya ausencia impediría desempeñar una función del producto.

Por eso «funciona en la nube» no es una prueba suficiente del ámbito. Mapea primero producto y dependencias.

Paso 3. Determina el papel de la organización

El papel pertinente puede ser:

fabricante;
representante autorizado;
importador;
distribuidor;
otra persona que realiza una modificación sustancial y comercializa el producto.

Un caso importante es un importador o distribuidor que pone el producto en el mercado con su nombre o marca o lo modifica sustancialmente. Pueden aplicársele entonces las obligaciones del fabricante.

Paso 4. No ignores productos ya en el mercado

Los requisitos principales CRA se aplican desde el 11 de diciembre de 2027, pero eso no permite ignorar productos existentes para notificaciones actuales.

El artículo 69(3) establece que las obligaciones de notificación del artículo 14 se aplican a productos incluidos aunque se pusieran en el mercado antes del 11 de diciembre de 2027.

Para un producto existente aún utilizado, notificar vulnerabilidades e incidentes es, por tanto, una cuestión operativa actual.

Paso 5. Comprueba exclusiones y legislación sectorial

No te bases en una breve lista en línea de «sectores excluidos de CRA». El reglamento tiene ámbito, exclusiones e interacciones propios con legislación sectorial de la UE.

Un proceso defendible consiste en:

registrar disposición jurídica y fuente de evaluación;
registrar fecha de revisión;
separar hechos de supuestos;
señalar cuestiones que exigen revisión jurídica cualificada en vez de convertir incertidumbre en una afirmación categórica sobre el producto.

Registro mínimo de evaluación del ámbito

Campo	Qué registrar
Producto	nombre, versión, identificador
Papel de la organización	fabricante / importador / distribuidor / otro
Mercado	dónde se comercializa
Funciones digitales	software, hardware, interfaces, componentes
Tratamiento a distancia	qué se ejecuta remotamente y si es necesario para una función
Fundamento	disposición CRA, orientaciones de la Comisión, supuestos
Resultado	probablemente incluido / probablemente no incluido / exige evaluación más profunda
Responsable de decisión	persona que aprueba la evaluación
Fecha de revisión	cuándo reexaminar la decisión

Cuándo reevaluar

Una evaluación no debe convertirse en un PDF olvidado. Reexamínala cuando, por ejemplo:

cambia la finalidad prevista;
un nuevo servicio remoto es necesario para una función;
el producto se modifica sustancialmente;
cambia distribución o marca;
la organización asume otro papel de operador económico;
nuevas orientaciones de la Comisión o autoridad cambian el fundamento.

Cómo mantiene Pulsar trazable la decisión

Pulsar puede conservar el fundamento con documentos de respaldo y conectar el resultado a riesgos, acciones y evidencias. El valor no es una respuesta automática sin explicación. Es poder mostrar después qué se evaluó, qué fuentes se usaron, quién aprobó y qué acciones siguieron.

Pulsar no sustituye una evaluación jurídica individual.

Consulta cómo ejecutar una evaluación en Pulsar GRC

Orientaciones relacionadas

Método propuesto: construir una decisión de ámbito que pueda revisarse

Imagina un proveedor que distribuye un equipo de otro fabricante, añade software propio y lo comercializa con su marca. Su equipo no puede resolver el ámbito copiando la evaluación del equipo original. Primero debe describir qué suministra al usuario, qué ha cambiado y qué papel asume en la comercialización. Este escenario hipotético muestra cómo preparar los hechos para una revisión; no determina la conclusión jurídica del caso.

Abre una ficha por producto o familia claramente delimitada. La ficha identifica versión, variantes, funciones previstas, componentes y mercado. Adjunta una descripción comprensible de lo que recibe el usuario y de lo que ejecuta remotamente. Si distintas variantes tienen funciones o componentes relevantes diferentes, explica si pueden evaluarse juntas o necesitan registros separados.

No empieces por una casilla «aplica/no aplica». Reúne los hechos que pueden cambiar la respuesta. Un mismo nombre comercial puede cubrir una aplicación, un dispositivo y un servicio web. Una distribución gratuita tampoco elimina automáticamente la necesidad de revisar las condiciones del ámbito. Las definiciones y exclusiones se contrastan con el texto legal y las orientaciones vigentes, no con el precio o la etiqueta del catálogo.

Evidencias que pueden aclarar el papel de la empresa

Revisa contratos, marca, documentación técnica, relaciones de desarrollo y canales de distribución. Registra quién diseña, quién encarga el desarrollo y quién pone el producto en el mercado. Cuando exista una modificación, describe su contenido y la evaluación de su relevancia. Evita que el equipo jurídico reciba únicamente un nombre comercial mientras ingeniería conserva todos los hechos que afectan a la decisión.

Una fuente comercial puede ayudar a identificar una oferta, pero no sustituye una descripción técnica. Un contrato puede indicar responsabilidades, pero también debe contrastarse con lo que realmente se hace. Si ambas fuentes difieren, deja la discrepancia abierta y asigna una revisión. Darla por resuelta por elegir el documento más conveniente debilita el expediente.

El registro del papel debe conservar fecha y aprobador. Si cambia la marca o la organización empieza a modificar el producto, la decisión vuelve a revisión. La misma empresa puede actuar de manera diferente en otra oferta. Una conclusión corporativa única suele esconder estas diferencias y dificulta saber qué obligaciones corresponden a cada equipo.

Cómo tratar exclusiones sin convertirlas en atajos

Cuando se plantea una exclusión, registra la disposición exacta utilizada y los hechos que permiten aplicarla. Comprueba si existe legislación sectorial pertinente y qué relación establece el CRA con ella. No es suficiente que el producto se venda a un hospital o a una fábrica; el lugar de uso y la naturaleza jurídica del producto no son lo mismo.

La conclusión puede necesitar documentación adicional: finalidad prevista, clasificación bajo otra norma legal o características técnicas. Define qué falta y quién puede aportarlo. Si la cuestión requiere conocimiento jurídico especializado, prepara una pregunta concreta con los hechos relevantes. Eso reduce revisiones repetidas y evita pagar por una respuesta basada en supuestos que el equipo nunca confirmó.

Guarda la fuente y su fecha. Un resumen de terceros puede ser útil para orientar la búsqueda, pero el fundamento final debe poder contrastarse con fuentes oficiales. Cuando aparezca una guía nueva, revisa las decisiones a las que afecta. No necesitas rehacer todo el inventario si la guía cambia un supuesto específico; sí necesitas saber dónde se utilizó.

Una revisión técnica y otra de fundamento

Ingeniería comprueba que la ficha describe correctamente funciones, componentes y servicios remotos. La función competente para interpretar el ámbito revisa el fundamento legal y las cuestiones abiertas. Producto verifica que el expediente corresponde a lo que se comercializa. Si una sola persona realiza varias revisiones, identifica explícitamente esos papeles y las limitaciones de su experiencia.

La IA puede ayudar a proponer preguntas o comparar documentos aportados. Sus respuestas no deben convertirse en decisiones finales sin comprobación. Comprueba especialmente referencias, citas y relaciones entre componentes. Un borrador que confunde un servicio independiente con un backend desarrollado bajo responsabilidad del fabricante puede llevar a evaluar otro producto distinto.

El criterio de aceptación es sencillo: otra persona puede explicar qué se evaluó, qué hechos se verificaron, qué fuente se utilizó y quién aprobó. Si solo encuentra una frase «CRA no aplica», no hay trazabilidad suficiente. Si encuentra diez documentos contradictorios sin una decisión, tampoco.

Vincula la conclusión con acciones actuales

Una conclusión de ámbito tiene consecuencias operativas. Cuando se determina que el producto está incluido, identifica procesos de notificación vigentes y trabajo pendiente para los requisitos principales. Cuando una evaluación está abierta, define qué decisiones comerciales o técnicas dependen de cerrarla. No supongas que la incertidumbre permite ignorar riesgos actuales.

Cuando la conclusión sea que una oferta queda fuera del ámbito evaluado, conserva igualmente las razones y el desencadenante de revisión. Eso no implica que desaparezcan otras obligaciones de seguridad, contratos o legislación aplicable. El expediente debe expresar su límite: qué norma y qué producto fueron revisados. Una respuesta sobre CRA no es una evaluación completa de toda la actividad.

Prueba el proceso con un cambio real

Selecciona una modificación prevista y pregunta si activa revisión del ámbito. Puede ser una nueva aplicación descargable, otra marca, una función remota necesaria o una distribución distinta. Comprueba que el responsable recibe información antes de publicar y sabe qué documentos actualizar. Si el cambio solo se descubre al preparar una auditoría, el proceso no está integrado en el trabajo del producto.

Pulsar puede mantener la ficha, las fuentes, las aprobaciones y las acciones relacionadas. El fabricante conserva la responsabilidad de su interpretación y decisiones. El resultado práctico es poder modificar una conclusión sin perder el fundamento anterior y explicar qué hecho motivó la nueva revisión. Esa capacidad vale más que una clasificación automática imposible de reconstruir.

Fuentes

Fuentes comprobadas: 12 de septiembre de 2026.

Pulsar GRC — acceso, aislamiento de datos y exportación (polaco)