La aplicación de tu teléfono habla con un servidor que has construido. Bajo la Ley de Ciberresiliencia ese servidor no es algo aparte que puedas descartar. Forma parte del producto. El ejemplo de cabecera del propio Reglamento para el tratamiento de datos a distancia es una aplicación móvil que accede a una API o a una base de datos que corre en un servicio que has desarrollado. Así que el backend que hay detrás de tu aplicación no es un vecino del producto. Está dentro de él.
Esta página te da la prueba y luego ordena cada backend con el que habla una aplicación típica en tres categorías: solución de tratamiento de datos a distancia, componente y fuera del ámbito. Resumimos la prueba en el análisis de la guía de la Comisión de marzo de 2026. Esta es la versión resuelta paso a paso para cualquiera que publique una aplicación de teléfono, una API o un backend en la nube.
Resumen
- El tratamiento de datos a distancia forma parte del producto. El CRA trata un producto conectado como el dispositivo o la aplicación más el backend que has construido y que necesita para funcionar. La gente abrevia "solución de tratamiento de datos a distancia" como RDPS, y esta página usa esa sigla.
- Una prueba, tres condiciones que se cumplen a la vez. Un backend es tratamiento de datos a distancia cuando corre a distancia, tu producto lo necesita para realizar una función y lo has construido tú o lo has hecho construir bajo tu responsabilidad. Si falla cualquiera de las tres, no lo es.
- El ejemplo de manual es una aplicación y su API. El caso de cabecera del propio Reglamento es una aplicación móvil que accede a una API o a una base de datos gestionada por un servicio que has construido.
- Tres categorías, nada más. Cada backend que toca tu aplicación es una solución de tratamiento de datos a distancia, un componente o algo fuera del ámbito.
- Un SaaS estándar no es RDPS, pero sigue siendo asunto tuyo. Un servicio que solo licencias es un componente. Aun así evalúas el riesgo de integración y aplicas diligencia debida sobre el proveedor.
- La red 5G queda fuera por completo. Una red móvil es un habilitador de conectividad, como un router o una señal Wi-Fi. No le debes ninguna diligencia debida al operador.
- Tu CI/CD y tu CRM quedan fuera. El CRA no regula tu red corporativa en su conjunto. Las canalizaciones internas, las nóminas y la infraestructura de red team se quedan fuera.
El tratamiento de datos a distancia en cuatro cifras: las condiciones que compruebas, las dos preguntas que lo deciden, las categorías donde puede caer una dependencia y el ejemplo con el que abre el Reglamento.
Qué significa realmente el tratamiento de datos a distancia
El Reglamento lo reduce a una sola idea, y tres condiciones tienen que cumplirse al mismo tiempo. Los datos tienen que tratarse en un lugar distinto del propio dispositivo del usuario. Tu producto tiene que necesitar ese tratamiento para realizar una de sus funciones. Y tienes que haber construido el servicio, o haberlo hecho construir bajo tu responsabilidad. Si se dan las tres, tienes una solución de tratamiento de datos a distancia. Si falla una, no.
Lee las tres por separado, porque cada una hace tropezar a un equipo distinto.
- Tratado a distancia. El tratamiento ocurre fuera del dispositivo o el entorno del usuario. Puede estar en el borde, en un enlace cableado o en uno inalámbrico. Una aplicación móvil que accede a una función en la nube es parte del tratamiento que ocurre en la nube.
- Necesario para una función. Sin el servicio, el producto no puede realizar una de sus tareas. La palabra que usa el Reglamento es funciones, no funcionalidades principales, y eso importa. La siguiente sección desgrana lo amplia que es.
- Construido por ti o para ti. Tú diseñaste y desarrollaste el servicio, o un proveedor lo construyó bajo tu responsabilidad. Alquilar el espacio donde corre no cambia la respuesta.
Dos detalles confunden a la gente antes incluso de empezar a clasificar:
- Es tu software, no el hardware donde corre. La solución de tratamiento de datos a distancia es el código que has construido y ejecutas a distancia. El hipervisor o el entorno de ejecución del proveedor que hay debajo es un componente, y el hardware físico sobre el que se asienta todo es el entorno del producto. Ninguno de los dos es tu solución de tratamiento de datos a distancia, y evalúas el riesgo de ambos.
- No tiene por qué ser nube pública. Una solución de tratamiento de datos a distancia puede correr en tus propios servidores on-premise o en una nube privada en tus instalaciones. La prueba es el diseño, el desarrollo y la necesidad, no dónde está físicamente la máquina.
Las tres preguntas
Pasa cada backend del que depende tu aplicación por tres preguntas en orden. Cada vía termina en una de las tres categorías.
La primera pregunta filtra todo lo que nunca sale del dispositivo. Las dos siguientes son el par decisivo, y ambas tienen que ser un sí. Conviene fijar tres cosas antes de empezar:
- Función es más amplio que funcionalidad principal. Cubre cualquier cosa que sostenga cómo se comporta el producto, no solo la funcionalidad de cabecera. Enviar comandos a un dispositivo, sincronizar archivos, dar de alta a un usuario, configuración y personalización, recibir actualizaciones incluidos los parches de seguridad e iniciar la sesión de los usuarios cuentan todos como funciones. Si un backend es necesario para cualquiera de ellas, la segunda pregunta es un sí.
- Un mecanismo manual de reserva no te exime. Una bombilla que puedes encender por una aplicación o por un interruptor físico sigue siendo una solución de tratamiento de datos a distancia por la vía remota. La opción manual no saca la función del ámbito.
- Construido por ti o para ti no es quién lo opera. Puedes ceder la operación a un tercero y seguir siendo responsable. Bajo tu responsabilidad significa hecho a medida, construido por encargo según tu especificación y en propiedad en lugar de licenciado. Licenciar un producto existente, o una versión ligeramente modificada, no es construido por ti o para ti.
El caso de manual: tu aplicación, tu API, tu base de datos
Empieza por el caso que el propio Reglamento usa como ejemplo. Una aplicación móvil necesita una API o una base de datos, y esa API o base de datos corre en un servicio que has construido. En ese caso el servicio es una solución de tratamiento de datos a distancia, sin más. Esta es la imagen sobre la que se construye el resto de la página.
Pasa una aplicación de notas por las tres preguntas. La aplicación sincroniza archivos a través de tu API REST y tu base de datos. Tratado a distancia, sí. Necesario para una función, sí, porque la sincronización de archivos es una función. Construido por ti o para ti, sí, porque tú diseñaste la API y el esquema de la base de datos. Tres síes. Tu API y tu base de datos son una solución de tratamiento de datos a distancia. Están dentro del ámbito de conformidad del producto.
La plataforma en la nube que hay debajo es otra cuestión. Si alquilas infraestructura y despliegas tu propio código sobre ella, la plataforma que alquilas no es la solución de tratamiento de datos a distancia. Tu código lo es. El IaaS que hay debajo es un componente. Documentas la dependencia, evalúas el riesgo de integración y puedes pedir al proveedor pruebas de seguridad.
Las tres categorías de un vistazo
Cada dependencia cae en exactamente una categoría. Las dos preguntas decisivas en sí es una solución de tratamiento de datos a distancia. Necesario para una función pero no bajo tu responsabilidad es un componente. No necesario para una función queda fuera del ámbito, y compruebas el riesgo que aun así introduce.
| Categoría | Cuándo se aplica | Significado | Qué tienes que hacer |
|---|---|---|---|
| Solución de tratamiento de datos a distancia | a distancia, necesario para una función y construido por ti o para ti | Parte del propio producto | Cumple los requisitos esenciales del anexo I. Intégralo en la evaluación de riesgos del producto. Cúbrelo en la declaración UE de conformidad y en la documentación técnica. Gestiona y notifica las vulnerabilidades a lo largo del período de soporte |
| Componente | a distancia y necesario para una función, pero no construido por ti o para ti | Una pieza de tercero en la que se apoya tu producto | Evalúa el riesgo de integración. Mitiga a nivel de producto, mediante autenticación, comprobaciones de integridad, aislamiento y validación de respuestas. Aplica diligencia debida sobre el proveedor y pon garantías de seguridad en el SLA. Reutiliza las pruebas que el proveedor ya posee, como un marcado CE, un certificado ISO/IEC 27001 o 27017, un certificado europeo de ciberseguridad, pruebas de las obligaciones NIS2 del proveedor o de sus obligaciones DORA cuando se apliquen |
| Fuera del ámbito | no necesario para una función, o pura conectividad | Ni una solución de tratamiento de datos a distancia ni un componente | Sin deber de conformidad ni de componente. Aun así evalúas cualquier riesgo que introduzca la comunicación. La pura conectividad, como la red móvil, el Wi-Fi o un router, es el único caso en el que no le debes nada al proveedor |
Nuestra opinión: En la práctica la prueba rara vez falla en las dos primeras preguntas. Casi todo aquello con lo que habla una aplicación corre a distancia y es necesario para algo. La respuesta gira sobre la tercera pregunta, la propiedad, y ahí es donde vemos resbalar a los equipos. Si un servicio se construyó para ti y es tuyo, trátalo como dentro del ámbito y sigue adelante. El error caro que vemos una y otra vez es archivar un backend hecho a medida como componente porque resulta que lo opera un proveedor.
Ejemplos resueltos
La guía borrador razona sobre un conjunto de productos ficticios y arquetípicos, y la galería de abajo refleja eso. Cuando nombra una categoría tecnológica real, clasifica el patrón típico. La respuesta gira sobre cómo usas la cosa, construido por cuenta propia frente a licenciado de forma estándar, nunca un veredicto legal sobre un proveedor concreto.
A. Tu propio backend de sincronización
Producto: una aplicación de notas o de productividad. La aplicación se conecta a tu API REST y a tu base de datos en infraestructura alquilada. Tratado a distancia, sí. Necesario para una función, sí, la sincronización de archivos. Construido por ti o para ti, sí. Esto es una solución de tratamiento de datos a distancia. La infraestructura alquilada que hay debajo es un componente. Es el caso de manual de la sección anterior.
B. Aplicación complementaria domótica
Producto: un termostato o una bombilla y su aplicación complementaria. La aplicación habla con tu backend en la nube, que has construido y ejecutas sobre infraestructura de tercero. El dispositivo también funciona con un interruptor manual. Tratado a distancia, sí. Necesario para una función, sí, enviar comandos a un dispositivo, y el mecanismo manual de reserva no cambia eso. Construido por ti o para ti, sí. Esto es una solución de tratamiento de datos a distancia. La infraestructura que hay debajo es un componente. El Reglamento confirma que el control en la nube de un fabricante de dispositivos domóticos entra dentro del ámbito.
C. Aplicación bancaria, el caso de las tres categorías
Producto: la aplicación bancaria. Una aplicación, cuatro dependencias, tres categorías.
- Tu capa de API autoalojada es una solución de tratamiento de datos a distancia. La has construido, la aplicación la necesita, corre a distancia.
- El sistema de cuentas y el de libro mayor que la aplicación nunca toca directamente quedan fuera del ámbito, una dependencia externa. Aun así se les evalúa el riesgo. Aplicas autenticación fuerte de las interfaces del backend, protección de la integridad y verificación de las respuestas.
- Un SaaS de chat de soporte de tercero es un componente. Lo aíslas del flujo bancario principal, validas el contenido que devuelve y aplicas diligencia debida.
- Tu código de notificaciones push sobre un PaaS de tercero es una solución de tratamiento de datos a distancia. La propia plataforma PaaS es un componente. Tu código es el software que diseñaste. La plataforma es la capa alquilada que hay debajo.
D. Identidad e inicio de sesión
Producto: cualquier aplicación. Iniciar la sesión de los usuarios es una función, así que la identidad entra en juego.
- Tu propio servicio de autenticación que emite tokens es una solución de tratamiento de datos a distancia. La has construido, la aplicación la necesita para iniciar la sesión de los usuarios.
- Un proveedor de identidad de tercero que solo licencias de forma estándar es un componente, no una solución de tratamiento de datos a distancia. Evalúas el riesgo de integración y aplicas diligencia debida.
- Un proveedor que construye un servicio de identidad hecho a medida solo para ti, en tu propiedad, vuelve a ser una solución de tratamiento de datos a distancia. Mismo proveedor, distinto contrato, distinta respuesta.
E. Almacenamiento SaaS estándar
Producto: una aplicación multimedia o de lectura que guarda el contenido comprado en un SaaS de almacenamiento genérico de tercero. Tratado a distancia, sí. Necesario para una función, sí. Construido por ti o para ti, no, porque licenciaste un producto existente de forma estándar. Esto es un componente, no una solución de tratamiento de datos a distancia. Aseguras la autenticación, el cifrado y la integridad de la comunicación, y aplicas diligencia debida. Contrástalo con el ejemplo A. La misma tarea, el almacenamiento de archivos, cae en una categoría distinta por quién construyó el servicio.
F. Funcionalidad de IA y LLM
Producto: una aplicación con una funcionalidad de IA.
- Tu propio modelo o servicio de inferencia que has construido y ejecutas sobre infraestructura de tercero es una solución de tratamiento de datos a distancia.
- Una API de modelo de tercero que solo licencias de forma estándar es un componente, no una solución de tratamiento de datos a distancia. Evalúas el riesgo de integración y aplicas diligencia debida.
- Los datos enviados solo para el entrenamiento del modelo o para estadísticas, no necesarios para una función del producto, probablemente quedan fuera del ámbito. Aun así evalúas cualquier riesgo que añada esa comunicación.
G. El conjunto fuera del ámbito
Fuera del ámbito no es una sola cosa. Tiene dos subzonas, y conllevan trabajo distinto.
- Nada que deber al proveedor. La red 5G o móvil, el Wi-Fi del usuario y el router son habilitadores de conectividad. No son una solución de tratamiento de datos a distancia ni un componente. No le debes ninguna diligencia debida al operador.
- No es una solución de tratamiento de datos a distancia, pero sigue habiendo una comprobación de riesgo. La telemetría de fallos o de uso recopilada solo para estadísticas o para el desarrollo futuro del producto no es una solución de tratamiento de datos a distancia, pero evalúas cualquier riesgo de comunicación que añada. Un sitio de marketing o un centro de ayuda al que la aplicación solo enlaza tampoco es una solución de tratamiento de datos a distancia.
- Tu propia red. El CRM interno, RRHH, las nóminas, las canalizaciones de CI/CD, la distribución interna de actualizaciones a ubicaciones de borde y la infraestructura de pruebas de penetración o de red team no son una solución de tratamiento de datos a distancia. El CRA no regula tu red corporativa en su conjunto.
A qué te obliga cada categoría
La categoría no es una etiqueta. Fija el trabajo.
La línea se mueve con el modelo de nube. Sobre infraestructura alquilada, el software que despliegas puede ser una solución de tratamiento de datos a distancia, el hipervisor del proveedor que hay debajo es un componente y el hardware físico es el entorno del producto. Sobre una plataforma alquilada, el código de tu aplicación puede ser una solución de tratamiento de datos a distancia y la plataforma de ejecución es un componente. Una aplicación SaaS estándar es un componente, no una solución de tratamiento de datos a distancia.
Solución de tratamiento de datos a distancia. Está dentro del producto. Cumples los requisitos esenciales del anexo I, la integras en la evaluación de riesgos del producto, la cubres en la declaración UE de conformidad y en la documentación técnica, y gestionas y notificas las vulnerabilidades a lo largo del período de soporte.
Componente. Es una pieza de tercero en la que se apoya tu producto. Evalúas el riesgo de integración y mitigas a nivel de producto, mediante autenticación, comprobaciones de integridad, aislamiento y validación de respuestas. Aplicas diligencia debida sobre el proveedor y pones garantías de seguridad en el SLA. Puedes reutilizar las pruebas que el proveedor ya posee, como un marcado CE, un certificado ISO/IEC 27001 o 27017, un certificado europeo de ciberseguridad, pruebas de las obligaciones NIS2 del proveedor o de sus obligaciones DORA cuando se apliquen. Que un proveedor de tercero cambie su propio servicio no es una modificación sustancial de tu producto.
Fuera del ámbito. Sin deber de conformidad ni de componente. Aun así evalúas cualquier riesgo que introduzca la comunicación, salvo en el caso de la conectividad, donde no le debes nada al proveedor.
Escribe las soluciones de tratamiento de datos a distancia y la dependencia de terceros en tu documentación técnica. La evaluación de riesgos cubre las soluciones de tratamiento de datos a distancia, la dependencia de terceros y el entorno del producto.
No tienes que someter todo tu backend a la conformidad. El CRA solo alcanza las partes de tus sistemas que almacenan o tratan los datos que necesita una función del producto. Segregar esas partes del resto, como la aplicación bancaria mantiene su libro mayor separado de su API, reduce lo que cae dentro de la evaluación. Y si un mismo backend sirve a varios productos, decláralo en la documentación técnica de cada producto. Puedes reutilizar esa documentación de la evaluación de un producto a la del siguiente.
Errores frecuentes
- Tratar toda tu nube como dentro del ámbito. El CRA no alcanza tu red corporativa en su conjunto. Tu CI/CD, CRM, RRHH y nóminas quedan fuera.
- Dar por hecho que quien lo opera lo decide. La operación no es la prueba. El diseño, el desarrollo y la propiedad sí.
- Olvidar que los componentes también dan trabajo. Quedar fuera del ámbito de conformidad no es quedar libre de obligaciones. Un componente necesita una evaluación de riesgo de integración, mitigaciones a nivel de producto y diligencia debida sobre el proveedor.
- Creer que la telemetría te mete dentro. La telemetría solo estadística no es una solución de tratamiento de datos a distancia. Aun así recibe una comprobación de riesgo de comunicación, pero no es parte del producto.
- Confundir las actualizaciones de producto con la distribución interna de actualizaciones. Un producto que recibe actualizaciones, incluidos los parches de seguridad, es una función, así que el servicio de entrega de actualizaciones que construyes puede ser una solución de tratamiento de datos a distancia. La distribución interna de esas actualizaciones por tus propias ubicaciones de borde es infraestructura interna y queda fuera del ámbito.
Preguntas frecuentes
¿La propia API REST de mi aplicación está dentro del ámbito del CRA?
Sí, si la has construido y tu aplicación la necesita para realizar una función. El propio ejemplo del Reglamento es una aplicación móvil que accede a una API o base de datos gestionada por un servicio que el fabricante construyó, y eso sitúa tu API dentro del ámbito de conformidad del producto. La plataforma en la nube sobre la que la ejecutas es una cuestión aparte, y se trata como un componente.
Si alojo mi backend en una nube de tercero, ¿esa nube convierte todo mi stack en una solución de tratamiento de datos a distancia?
No. La solución de tratamiento de datos a distancia es el software que diseñaste y desarrollaste, no la plataforma que hay debajo. Esa plataforma es del proveedor, no tuya, así que la infraestructura alquilada es un componente. Evalúas el riesgo de integración y aplicas diligencia debida sobre el proveedor.
¿Un proveedor de inicio de sesión de tercero es una solución de tratamiento de datos a distancia?
Depende de cómo lo uses. Un proveedor de identidad de tercero que licencias de forma estándar es un componente, no una solución de tratamiento de datos a distancia, aunque iniciar la sesión de los usuarios sea una función. Si en cambio un proveedor construye un servicio de identidad hecho a medida solo para ti y en tu propiedad, eso vuelve a ser una solución de tratamiento de datos a distancia. Mismo proveedor, distinto contrato, distinta respuesta.
¿Cubre el CRA mi canalización interna de CI/CD y mi CRM?
No. El CRA no regula tu red corporativa y tus sistemas de información en su conjunto. El CRM interno, las nóminas, las canalizaciones de CI/CD, la distribución interna de actualizaciones a ubicaciones de borde y las pruebas de penetración o de red team quedan todos fuera. Esto es tu propia red, no una solución de tratamiento de datos a distancia de la que dependa tu producto.
¿La red móvil sobre la que corre mi aplicación está dentro del ámbito?
No. Una red 5G o móvil es un habilitador de conectividad, como un router, un cable Ethernet o una señal Wi-Fi. No es una solución de tratamiento de datos a distancia ni un componente, y no le debes ninguna diligencia debida al operador de la red. Este es el único caso fuera del ámbito que no conlleva obligación alguna hacia el proveedor.
¿Cuál es la diferencia entre una solución de tratamiento de datos a distancia y un componente?
Ambos pueden correr a distancia y ambos pueden ser necesarios para una función. La diferencia es quién construyó el servicio. Una solución de tratamiento de datos a distancia la diseñas y desarrollas tú, o se construye bajo tu responsabilidad, así que está dentro del ámbito de conformidad del producto. Un componente es una pieza de tercero que licencias, así que se queda fuera de la conformidad pero aún necesita una evaluación de riesgo de integración, mitigaciones a nivel de producto y diligencia debida. Consulta Qué es un producto con elementos digitales para ver dónde encaja el tratamiento de datos a distancia en la prueba de ámbito más amplia.
Este artículo tiene únicamente fines informativos y no constituye asesoramiento jurídico. Los ejemplos resueltos siguen la guía borrador de la Comisión Europea, Comunicación Ares(2026)2319816 de 3 de marzo de 2026, cuya consulta se cerró el 13 de abril de 2026 y que aún no está adoptada formalmente. Para una orientación de cumplimiento específica, consulta con asesoría jurídica cualificada.