Política de protección de datos de Amazon para vendedores: qué ven de tus compradores las aplicaciones de terceros

Dos documentos que obligan a cualquier aplicación

Primero una aclaración: si eres comprador y quieres saber qué hace Amazon con tus propios datos, el documento que buscas es el aviso de privacidad de amazon.es o amazon.com.mx. Este artículo es para vendedores que conectan aplicaciones a su cuenta de vendedor, y es nuestra lectura de las reglas como desarrolladores, no asesoramiento legal.

Todo desarrollador que usa la Selling Partner API de Amazon acepta dos políticas. La Data Protection Policy (DPP) fija las reglas de seguridad y conservación. La Acceptable Use Policy (AUP) fija las de conducta: qué puede pedir un desarrollador y qué puede hacer con lo que recibe. Las dos son públicas y marcan el techo de cualquier aplicación que pida acceso a tu cuenta.

La DPP tiene dos niveles. La sección 1 se aplica a "all systems that store, process, or otherwise handle data vended and retrieved from the Amazon Services API" (todos los sistemas que tratan datos obtenidos de la API), es decir, a cualquier aplicación, incluso a una que solo lea tu contador de pedidos del día. La sección 2 añade requisitos más estrictos que solo entran en juego cuando una aplicación toca datos personales. Ahí está la clave: una aplicación que nunca recibe datos del comprador se queda en el nivel ligero, y los roles que pide te dicen en qué nivel está.

La AUP añade dos frases que te importan. "Do not request access to or retrieve Information that is not necessary for your Application's functionality." (No pidas datos que tu aplicación no necesita.) Y: "Do not request or share Amazon Portal usernames or passwords from Authorized Users." (No pidas las credenciales de los usuarios.) Una aplicación que quiere tu contraseña de Seller Central, o un rol que no sabe explicar, ya está fuera de las reglas antes de guardar un solo byte.

Para los vendedores en España, debajo de todo esto está el RGPD, con la minimización de datos y la limitación de la finalidad en el centro. Que un proveedor actúe o no como encargado del tratamiento forma parte de tu propio cumplimiento y conviene verlo con tu asesor; este artículo se queda en las reglas de Amazon.

Qué cuenta como dato personal, código postal incluido

La DPP define los datos personales como "information that can be used on its own or with other information to identify, contact, identify in context, or locate an Amazon Customer or Authorized User" (información que, sola o combinada, permite identificar, contactar o localizar a un cliente de Amazon). La lista que viene después es más larga de lo que espera la mayoría de los vendedores: "name, address, e-mail address, phone number, gift message content, survey responses, payment details, purchases, cookies, digital fingerprint (e.g., browser, user device), IP Address, geo-location, postal code, or Internet-connected device product identifier".

Dos cosas de esa lista merecen una segunda mirada. La primera es el código postal: por sí solo parece inofensivo, pero Amazon lo considera dato personal porque, combinado con otros datos, permite localizar a una persona. La segunda es lo que no aparece: una línea de pedido sin ningún campo del comprador. Que alguien comprara dos unidades de un SKU en amazon.es a las 14:03 no identifica ni localiza a nadie.

La trampa del código postal en las notificaciones de pedido

Este detalle solo lo descubrimos construyendo una aplicación. La notificación ORDER_CHANGE de Amazon, el mensaje al que se suscriben los desarrolladores para seguir los pedidos, lleva un campo DestinationPostalCode en su resumen. Quien guarda ese mensaje tal cual en una base de datos ya tiene datos personales, y con ellos todo el peso de la sección 2: conservación de 30 días, cifrado en reposo, escaneos de vulnerabilidades, pruebas de intrusión. Quien descarta el campo antes de guardar nada se queda en la sección 1. Pregunta a cualquier app de avisos o de analítica qué hace con el código postal: lo rápido que entienda la pregunta te dice mucho.

Restricted Data Tokens: la puerta delante de los datos del comprador

Amazon no entrega datos personales a una aplicación solo porque tú la hayas autorizado. Los datos del comprador salen de la Orders API únicamente a través de las llamadas restricted operations, y la documentación de la Tokens API lo dice sin rodeos: "Restricted operations return customers' Personally Identifiable Information (PII). You need an RDT to call a restricted operation." (Necesitas un RDT para llamar a una operación restringida.) Un Restricted Data Token hay que pedirlo para cada una de esas llamadas, y Amazon solo lo emite a aplicaciones cuyos roles aprobados cubren esos datos.

En el modelo de datos de la Orders API, tres objetos llevan la marca restricted: ShippingAddress, BuyerInfo (nombre, correo, datos fiscales) y BuyerTaxInformation. Todo lo demás vuelve sin ningún token. Con eso trabajan un aviso de pedidos o un panel de ventas.

Dos matices. El número de pedido no está en la lista de datos personales de Amazon y vuelve sin token, pero se puede rastrear hasta un comprador en Seller Central, así que lo tratamos como dato seudónimo y guardamos solo un hash con clave. Y mientras un pedido está pendiente, Amazon no devuelve ningún precio, por lo que una app de avisos muestra una estimación hasta que se publica el importe.

El modelo de roles: qué apruebas al conectar una aplicación

Los roles son, en palabras de Amazon, "the mechanism by which the Selling Partner API (SP-API) determines whether a developer or application has access to an operation or resource" (el mecanismo que decide el acceso a una operación o recurso). El desarrollador los solicita al registrarse y tú los vuelves a ver en la página de autorización de Seller Central en el momento de conectar la aplicación. Lo que no esté ahí, la aplicación no lo puede llamar. Esa página la recorremos paso a paso en nuestra guía para conectar una aplicación a Amazon Seller Central.

Cuatro roles están marcados como restricted: Direct-to-Consumer Shipping, Tax Invoicing, Tax Remittance y Professional Services. La página de roles explica la etiqueta: "Restricted means that the role requires sensitive information, which might include personally identifiable information (PII). For these roles, you must provide additional information about your data use and security controls." (Estos roles manejan información sensible y obligan a dar detalles adicionales sobre el uso de los datos y la seguridad.) Solo los roles restringidos desbloquean los Restricted Data Tokens. Una herramienta de impresión de etiquetas necesita uno, una de facturación también. Un aviso, un panel o un repricer, no.

El rol que necesita un aviso de pedidos se llama Inventory and Order Tracking, y su descripción termina con una frase que conviene recordar: "Operations that require this role do not use PII required to ship an order." (Sus operaciones no usan los datos personales necesarios para enviar un pedido.) Devuelve pedidos, artículos y métricas de ventas, y permite suscribirse a ORDER_CHANGE tanto para pedidos de Logística de Amazon como para los gestionados por el vendedor. Un detalle más: si el desarrollador añade un rol después, Amazon exige una autorización nueva, así que verás otra página de autorización en lugar de una ampliación silenciosa.

Plazos de borrado y auditorías para una app con datos personales

Si una aplicación sí recibe datos personales, la DPP es concreta. El desarrollador "will retain PII for no longer than 30 days after order delivery and only for the purpose of, and as long as is necessary to (i) fulfill orders, (ii) calculate and remit taxes, (iii) produce tax invoices and other legally required documents, and (iv) meet legal requirements". Es decir, 30 días tras la entrega, con las obligaciones fiscales y legales como única razón para guardar algo más tiempo. La AUP cierra la otra puerta: "Do not use Personally Identifiable Information about Customers for any purposes other than merchant-fulfilled shipping or to meet legal requirements."

Los datos de pedidos sin identidad siguen otro reloj. El desarrollador solo puede conservarlos mientras sean estrictamente necesarios para la finalidad que autorizaste, y debe borrarlos todos de forma permanente, copias activas incluidas, dentro de los 30 días siguientes a que revoques la autorización o a que Amazon pida el borrado. Un contador diario de ventas que sigues usando es una finalidad así; una copia de tus pedidos guardada después de desconectar, no.

Luego vienen las obligaciones técnicas. Todo desarrollador debe cifrar la información en tránsito con "secure protocols such as TLS 1.2 or higher", mantener las credenciales como las claves de API "encrypted at rest, accessible only to authorized personnel, and rotated at least once every twelve (12) months" y dar acceso solo a quien lo necesita. Quien guarda datos personales debe además cifrarlos en reposo, hacer "vulnerability scanning conducted at least every 30 days" y "perform penetration testing at least every 365 days". Encima, Amazon se reserva el derecho a auditar los sistemas de un desarrollador y a pedir una certificación escrita de cumplimiento. Nada de esto lo ves tú como vendedor, y justo por eso importan los roles de la página de autorización: te dicen qué obligaciones ha asumido el desarrollador y si su aplicación las necesitaba.

Por qué un aviso de pedidos no necesita nada de esto

Piensa en lo que de verdad necesita un cha-ching en tu teléfono. Que exista un pedido, para contarlo una vez. Cuándo se hizo, para que el aviso pueda decir lo rápido que llegó. En qué marketplace y por cuánto aproximadamente, para que la cifra en pantalla signifique algo. Quizá el SKU o el título, para saber qué producto se acaba de vender. Todos esos campos salen del rol Inventory and Order Tracking sin Restricted Data Token, y ninguno dice quién compró.

El nombre de tu comprador no hace el sonido más dulce ni su dirección hace que el aviso llegue antes; para la velocidad lo que cuenta es cómo busca la aplicación los pedidos nuevos, algo que medimos en cómo de rápido puede llegar una alerta de pedidos de Amazon. Una aplicación de esta categoría que pide datos del comprador o ha entendido mal la política o quiere los datos para otra cosa. Ninguna de las dos es buena señal. La misma lógica vale para casi todos los paneles e incluso para la app Seller oficial, cuyas notificaciones repasamos en qué avisa y qué no avisa la aplicación Amazon Seller.

Cómo comprobar qué pide una aplicación

No hace falta leer el código de un desarrollador para juzgar una aplicación. Con cuatro comprobaciones cubres casi todo.

1. Lee la página de autorización antes de confirmar. Enumera cada rol que pide la aplicación, y los nombres de los roles restringidos son muy elocuentes: Direct-to-Consumer Shipping, Tax Invoicing, Tax Remittance, Professional Services.
2. Empareja cada rol con una función que vayas a usar. Imprimir etiquetas justifica Direct-to-Consumer Shipping; facturar justifica Tax Invoicing. Los avisos, la analítica, el repricing y la planificación de stock no justifican ningún rol restringido.
3. Abre la política de privacidad del desarrollador y busca tres respuestas: qué campos guarda, dónde están los servidores y cuánto tiempo conserva los datos tras desconectar. Según la DPP, la última respuesta no puede pasar de 30 días.
4. Haz una pregunta por correo: "¿Guardan datos de compradores y qué hacen con el código postal que viene en la notificación de pedido?" Quien ha leído la política responde en dos líneas.

Si una aplicación pide más de lo que sus funciones necesitan, no confirmes. La AUP prohíbe pedir información que la aplicación no necesita, así que no estás siendo quisquilloso. Si ya la conectaste, revócala: en Seller Central abre Aplicaciones y servicios, elige Gestionar tus aplicaciones, busca la aplicación, desactiva la autorización y confirma con OK. La documentación de Amazon avisa de que la aplicación queda desactivada pero sigue visible en esa página, así que verla ahí después es normal. Desde ese momento el desarrollador tiene 30 días para borrar tus datos. Y si conectaste la app sobre todo para oír tus ventas, nuestro repaso de todas las formas de recibir un aviso de venta en Amazon muestra cuáles funcionan sin ningún dato de comprador.