Registros de roles de proveedores, subencargados y avisos de privacidad de SDK en apps de comercio

Un subencargado del tratamiento es un encargado contratado por otro encargado, así que la mayoría de los proveedores que contratas directamente, como el alojamiento en la nube, la analítica o el constructor de apps, son tus encargados, no subencargados. Por eso una app de comercio necesita un registro de roles de proveedores que cubra todo el conjunto, más las listas de subencargados de las cadenas de encargados que contiene. La distinción determina contratos, autorizaciones y comunicaciones.

Esta guía separa los cuatro documentos, explica cómo valorar el rol real de un proveedor y cubre las declaraciones de SDK, las transferencias y las etiquetas de las tiendas. Complementa privacidad y consentimiento en apps móviles de comercio electrónico.

Respuesta corta. Construye un registro de roles de proveedores para todo el conjunto de proveedores. Anota de cada proveedor su flujo de datos, su finalidad, su rol legal, su ubicación, su contrato y su vía de supresión. Mantén u obtén las listas de subencargados de las cadenas de encargados que haya dentro. Usa el registro para crear tu aviso de privacidad, tus etiquetas de la App Store y de Play, y tu pantalla de consentimiento. No copies el registro dentro de cada uno de ellos.

Alcance y lo que esto no es. Esta es una guía práctica, no asesoramiento legal. El rol legal de un proveedor y el mecanismo de transferencia correcto dependen de tus flujos de datos y de tus contratos concretos, y cambian con el tiempo. Trabaja el análisis con asesoría legal y verifica en la fuente los requisitos vigentes de las plataformas y de los reguladores antes de apoyarte en él.

Cuatro documentos, cuatro públicos

Manténlos como documentos separados, porque sirven a lectores y a finalidades distintas:

El registro es la fuente de verdad interna. Los otros tres salen de él, pero cada uno tiene su público y sus reglas. Entre los errores habituales están publicar el registro interno como aviso de privacidad, o llamarlo lista de subencargados.

La pregunta del rol va primero, y la decide la realidad

Antes de incluir a un proveedor en una lista, determina su rol legal. La etiqueta cambia tus obligaciones. Trata estos ejemplos de comercio como puntos de partida para una valoración, no como clasificaciones cerradas:

Dos puntos importan más que la tabla. Primero, el rol lo determina la realidad, no la etiqueta del contrato. Un contrato de encargo no convierte a una empresa en tu encargado si esa empresa decide de forma independiente por qué y cómo usar los datos, o si los reutiliza para sus propias finalidades. Pregunta quién decide por qué y cómo se tratan los datos. Los SDK de publicidad y de medición merecen especial atención, porque el constructor de apps, la marca, el proveedor de analítica y la plataforma publicitaria pueden tener roles distintos en flujos distintos.

Segundo, una relación de corresponsabilidad trae su propia obligación. Según el artículo 26 del RGPD, los corresponsables tienen que repartir sus responsabilidades de forma transparente mediante un acuerdo, y lo esencial de ese acuerdo tiene que estar a disposición de los interesados. Así que "la plataforma y nosotros somos corresponsables" es el comienzo de una obligación, no una casilla marcada. Acertar con estos roles es también lo que hace que la supresión sea encaminable, como explica nuestra guía sobre el mapa de datos.

Campos recomendados del registro de roles de proveedores

Mantén el registro interno y con el detalle suficiente para dar soporte a la asesoría legal, a las solicitudes de supresión y a un regulador. Son campos operativos, no un formato público obligatorio:

• Nombre de la entidad legal (la entidad que firma de verdad).
• Servicio y finalidad del tratamiento.
• Categorías de datos implicadas.
• Rol: responsable, encargado, subencargado, corresponsable o responsable independiente.
• Entidad contratante, lugares de alojamiento y lugares de acceso remoto (el lugar de tratamiento por sí solo rara vez basta).
• Destinatarios posteriores con los que el proveedor comparte datos, y el análisis de transferencia correspondiente.
• Referencia del contrato (el contrato de encargo u otro acuerdo), guardada internamente, porque un contrato de encargo suele ser un contrato comercial confidencial y no algo que enlazar en público.
• Fecha de alta, estado y responsable.

Coloca el proceso de aviso de cambios en el documento que corresponda a su público. Los avisos del artículo 28 van a los responsables de un encargado. Los avisos de privacidad van a los consumidores. No metas ese proceso en cada fila de proveedor.

El conjunto típico de proveedores de una app de comercio

Los stacks de las apps de comercio suelen ser más largos de lo que se espera, y los roles varían. Los datos personales pueden llegar a:

• Alojamiento en la nube e infraestructura de base de datos
• Red de distribución de contenidos (CDN)
• Proveedor de autenticación
• Monitorización de errores e informes de fallos
• Analítica de producto
• Infraestructura de envío de notificaciones push
• Plataforma de atención al cliente
• Proveedor de email y SMS
• Almacén de datos
• SDK de atribución y publicidad
• Integraciones de Shopify y del pago
• Servicios de Apple y Google

Algunos son claramente tus encargados. Otros, sobre todo los de publicidad, pagos y tiendas de apps, pueden actuar en otro rol para una parte o para todo lo que hacen. Recorre la lista proveedor a proveedor y asigna el rol de forma deliberada.

Qué es una lista de subencargados

Una lista de subencargados indica a los responsables de un encargado qué proveedores usa ese encargado. Si tú eres la marca, las listas que te interesan son las que publican o te entregan tus encargados, y cubren a sus propios proveedores. Mantén tu propia lista solo cuando actúas como encargado para otra empresa.

El mecanismo que hay detrás es contractual, no una función para el consumidor. Según el artículo 28 del RGPD, cuando un responsable ha dado a un encargado una autorización general para contratar subencargados, el encargado tiene que informar al responsable de las incorporaciones o sustituciones previstas y darle la oportunidad de oponerse. Es un deber que un encargado tiene con su responsable. No es un derecho de los consumidores, y una página pública del tipo "hemos actualizado nuestros proveedores" no lo cumple. Mantén las dos cosas separadas: el aviso y la oposición del artículo 28 suben por la cadena de encargados; la transparencia hacia el consumidor va por tu aviso de privacidad.

Qué revela el aviso de privacidad (y qué no)

El aviso de privacidad es un documento para el consumidor, así que informa de lo que el cliente necesita, no de todo el registro interno. Un aviso de privacidad expone por lo general las finalidades, las categorías de datos, los destinatarios o categorías de destinatarios, los derechos del cliente y las transferencias cuando corresponde. Fíjate en "destinatarios o categorías de destinatarios": a menudo no estás obligado a nombrar en el aviso público a cada entidad legal de tu registro, y por lo general no se publican contratos de encargo confidenciales. Decide de forma deliberada qué nombra el aviso y qué agrupa por categorías, y mantenlo coherente con el registro que hay detrás. Los controles de cara al cliente a los que apunta ese aviso se explican en la sección sobre el centro de privacidad de nuestra guía de privacidad y consentimiento.

Transferencias internacionales

Trata las transferencias como una prueba legal, no como un mapa. "Los datos están alojados en el extranjero" no es un análisis. Para los datos personales del EEE o del Reino Unido, pregunta si el acuerdo es una transferencia internacional restringida y, si lo es, qué mecanismo vigente aplica. Puede ser una decisión de adecuación, las Cláusulas Contractuales Tipo, el acuerdo o la adenda de transferencia internacional del Reino Unido, o un marco certificado como el Marco de Privacidad de Datos entre la UE y Estados Unidos. Desde Schrems II, el mecanismo por sí solo puede no bastar. Puede que necesites además una evaluación del riesgo de la transferencia.

Lo que decide es el flujo real, no solo dónde está el servidor: las entidades contratantes, el acceso de soporte remoto desde otros países, las transferencias posteriores y quién es exportador e importador. Anota el análisis proveedor a proveedor, y no des por fijo el mecanismo de un proveedor concreto, porque los proveedores cambian de entidades, de regiones y de marcos. Confirma la situación vigente con asesoría legal.

Contratos de encargo y otros contratos

El rol que has asignado determina el contrato que necesitas. Cuando un proveedor es tu encargado, el RGPD exige un contrato de encargo del tratamiento con las cláusulas del artículo 28 (tratar los datos solo siguiendo tus instrucciones, confidencialidad, seguridad, reglas sobre subencargados, supresión o devolución al terminar, y apoyo en auditorías). Cuando un proveedor es corresponsable, necesitas un acuerdo del artículo 26 que reparta las responsabilidades y cuyo contenido esencial esté disponible para los interesados. Cuando un proveedor es responsable independiente, tú no le das instrucciones, así que un contrato de encargo es el instrumento equivocado y lo que debes hacer es entender sus propias condiciones. Que el contrato encaje con el rol es parte de acertar con el rol.

Audita las declaraciones de SDK, no te fíes de una lista de funciones

Los SDK de terceros pueden recoger datos de los que tú respondes. "Solo hemos activado estas funciones" no te dice qué tienes que declarar. Un SDK integrado puede arrancar solo, recoger diagnósticos, pedir permisos o cambiar de comportamiento en una actualización, incluso con su función de cara al cliente desactivada. Audita lo que hace la app construida: la versión y la configuración del SDK, los permisos y las API, las llamadas de red y los destinos, y la documentación del proveedor.

Recoge el detalle específico de cada SDK en el registro, porque es de ahí de donde beben los formularios de las tiendas y la pantalla de consentimiento:

• Nombre del SDK, proveedor y versión
• Responsable por tu parte
• Arranque automático y comportamiento por defecto (¿se inicia antes del consentimiento?)
• Permisos y acceso a API que solicita
• Datos que salen del dispositivo, y a qué destinos
• Dependencia del consentimiento (¿espera a una señal de consentimiento?)
• Interruptor o configuración que lo gobierna
• Correspondencia con las declaraciones de Apple y de Play para los datos que maneja

Sobre los manifiestos de privacidad de Apple en concreto: no son una regla simple del tipo "cada SDK necesita un manifiesto". Apple exige manifiestos de privacidad que cubran el uso que hace la app de ciertas API que exigen justificar su uso, y su recogida de datos, con requisitos específicos para un conjunto de SDK de terceros de uso común. Los manifiestos no sustituyen a responder con exactitud a las preguntas de privacidad de la App Store. Como añadir un SDK puede cambiar tus declaraciones y, cuando hace seguimiento entre empresas, activar un aviso de ATT, el inventario de SDK y el diseño del consentimiento son la misma conversación, que se trata en App Tracking Transparency: cuándo necesita ATT una app de comercio electrónico y cómo pedirlo.

Apple y Google necesitan mapas de declaración separados

No des por hecho que un registro rellena las dos tiendas de forma automática, porque Apple y Google usan definiciones y taxonomías muy distintas. El registro alimenta las etiquetas de las tiendas, pero entre ellos hay un paso de correspondencia, con un responsable y una aprobación:

• La información de privacidad de la App Store de Apple pide los tipos de datos, la finalidad de uso, si los datos están vinculados a la identidad del usuario y si se usan para el seguimiento tal y como lo define Apple.
• La sección Seguridad de los datos de Google Play pregunta por la recogida y la cesión según sus propias definiciones, por las finalidades, por si la recogida es obligatoria u opcional, y por declaraciones de seguridad y supresión para toda la app. Google señala que su taxonomía puede diferir bastante de la de otra tienda, y que la declaración es global para el paquete de la app: si alguna versión o región distribuida recoge o cede datos, por lo general eso entra en la declaración.

Dale al mapa de declaraciones un responsable con nombre. Pruébalo contra la app construida y mantenlo alineado con la ficha, usando cómo rellenar la ficha de tu app sin que te la rechacen.

Manténlo al día, en el documento correcto

Cada documento necesita mantenimiento. Actualiza el registro de roles de proveedores cuando añadas, quites o cambies un proveedor, y actualiza después las salidas afectadas. Cuando actúas como encargado, cumple el deber de aviso y oposición del artículo 28 hacia tus responsables. Cuando cambian las prácticas de cara al consumidor, actualiza el aviso de privacidad y da la información que exija la ley aplicable. No existe un derecho universal del consumidor a recibir alertas de cambio de subencargados.

Lista de comprobación de proveedores

Antes de publicar, confirma:

1. Un registro de roles de proveedores que cubra todo el conjunto de proveedores, incluidos los proveedores que hay dentro de los SDK.
2. Un rol valorado para cada uno, frente al flujo y al contrato reales, y con la realidad decidiendo, no la etiqueta.
3. Listas de subencargados obtenidas de tus encargados, y mantenidas por ti solo cuando actúas como encargado.
4. El contrato correcto para cada rol: contrato de encargo del artículo 28 para los encargados, acuerdo del artículo 26 para los corresponsables, y comprensión de las condiciones de los responsables independientes.
5. Un análisis de transferencia por proveedor para los datos del EEE y del Reino Unido, con un mecanismo y una evaluación cuando el acuerdo sea una transferencia restringida.
6. Una auditoría de SDK sobre la app construida, con los campos específicos de SDK del registro rellenados.
7. Un mapa de declaraciones para Apple y Google, con un responsable y una aprobación.
8. Un aviso de privacidad que informe de los destinatarios o sus categorías, de los derechos y de las transferencias, coherente con el registro.
9. Un proceso de cambios que actualice el documento correcto para el público correcto.

Cómo ayuda NAPPS

NAPPS es un proveedor más dentro de este cuadro. Puede documentar su propio rol y sus servicios, pero no puede tomar tus decisiones legales.

Empieza por su rol, en términos orientativos: si tú eres el responsable del tratamiento y contratas directamente a NAPPS para tratar los datos de los clientes de tu app, NAPPS sería normalmente tu encargado del tratamiento. Es subencargado solo dentro de una cadena de encargados, cuando otro encargado lo contrata. Cuál de los dos casos es el tuyo pertenece a tu valoración y al contrato, no a una etiqueta general. Dos cosas que pedir a NAPPS y verificar contra sus materiales públicos vigentes en lugar de darlas por buenas: un contrato de encargo del tratamiento, y su propia lista de subencargados para la infraestructura que hay detrás de la app, que cubre la infraestructura de NAPPS y no tus proveedores de analítica, publicidad, soporte y demás. Y la disciplina sobre SDK de más arriba también aplica aquí: lo que declaras lo determina lo que hace de verdad la app construida, incluido lo que arranca solo, y no solo las funciones que tú activaste. Lo que NAPPS no hace es decidir el rol de ningún proveedor, elegir mecanismos de transferencia o escribir tu aviso de privacidad. Para ver cómo se conecta el registro con la supresión, consulta nuestra guía sobre conservación y supresión; para la visión más amplia del lanzamiento, cómo convertir una tienda Shopify en una app móvil (2026).

Directamente de la fuente

Estos documentos cambian, así que consulta las versiones vigentes:

• Europa: el texto del RGPD (encargados y contratos de encargo en el artículo 28, corresponsables en el artículo 26, transferencias en el capítulo V) y la orientación del CEPD sobre las Cláusulas Contractuales Tipo y las evaluaciones de transferencia.
• Apple: los requisitos de la información de privacidad de la app y las reglas de manifiestos de privacidad y API que exigen justificar su uso para las apps y los SDK de terceros de la lista.
• Google: los requisitos de la sección Seguridad de los datos de Play.

En resumen

Construye un registro de roles de proveedores para todo el conjunto de proveedores. Valora a cada proveedor por lo que hace de verdad, no por cómo lo llama su contrato. Mantén separadas las listas de subencargados, el aviso de privacidad y el mapa de declaraciones para las tiendas. Después analiza las transferencias, haz que cada contrato encaje con su rol, audita los SDK de la app construida y actualiza el documento correcto cuando algo cambie. Así te queda un mapa de proveedores utilizable, no un muro de logotipos.

Si estás planeando una app de Shopify y quieres las declaraciones de SDK, las etiquetas de privacidad de las tiendas y la documentación de proveedores resueltas con limpieza desde el principio, reserva una llamada de 20 minutos con el equipo de NAPPS y te enseñaremos cómo encaja todo en una app nativa antes de que construyas nada.