RGPD y hosting en la UE: en qué deben fijarse los equipos con las herramientas de desarrollo

Cuando una empresa quiere introducir una nueva herramienta de analítica, el procedimiento está ya rodado: el delegado de protección de datos pregunta por el contrato de encargo de tratamiento, alguien comprueba la ubicación de los servidores, se completa la política de privacidad. Con la caja de herramientas del departamento de desarrollo suele ir de otro modo: un miembro del equipo encuentra una herramienta útil, crea una cuenta y tres meses después es parte silenciosa del trabajo diario. Este trato desigual no tiene fundamento objetivo — también las herramientas de desarrollo tratan datos, y algunas más de lo que sus usuarios son conscientes.

Los servicios de testing son un buen objeto de estudio. Un servicio de capturas de pantalla, por ejemplo, fotografía páginas web — y una foto de una página web contiene todo lo que esa página muestra. En una página pública de marketing eso no es crítico. Interesante se vuelve en los bordes: entornos de staging rellenados con copias de datos reales de producción. Páginas que muestran comentarios de usuarios, valoraciones o fotos de perfil. Direcciones en cuyos parámetros de URL se esconden rasgos de sesión o identificadores. Quien entrega páginas así a un servicio externo transmite, según el caso, datos personales — aunque en la cabeza solo esté el «estamos probando el layout».

El RGPD ordena una constelación así con claridad: la empresa que usa el servicio sigue siendo responsable del tratamiento de los datos; el servicio actúa por regla general como encargado del tratamiento. Este reparto de papeles no es un formalismo, sino que tiene una consecuencia práctica: hace falta un contrato de encargo de tratamiento conforme al artículo 28 — habitualmente como documento estándar del proveedor —, y la responsabilidad de que el tratamiento sea en conjunto lícito no emigra con los datos al prestador del servicio. Se queda en la empresa.

La segunda pregunta estándar apunta al lugar del tratamiento. Dentro de la UE, el RGPD rige de forma directa; con proveedores que tratan datos en terceros países comienza, en cambio, un capítulo de examen propio: decisiones de adecuación, cláusulas contractuales tipo, evaluaciones de impacto de las transferencias. Para las transmisiones a Estados Unidos existe, es cierto, una decisión de adecuación, pero sus predecesoras ya fueron tumbadas dos veces por los tribunales, y también el marco actual sigue siendo jurídicamente discutido. Nada de eso hace inutilizables los servicios estadounidenses — pero cada una de esas construcciones es esfuerzo de examen que con una ubicación en la UE sencillamente desaparece. El hosting en la UE es, en ese sentido, menos un sello de calidad que un atajo: hace más corta la evaluación, no superflua.

ScanU, un servicio de pruebas de regresión visual y capturas de navegador, sirve aquí como ejemplo concreto porque el proveedor hace explícita la ubicación de los datos: según indica el propio proveedor, los datos se alojan en Frankfurt, y el servicio se posiciona expresamente con la mirada puesta en el RGPD — puede leerse en la página de inicio en español de ScanU. Para una empresa alemana significa: la cuestión del tercer país no se plantea de entrada para el servicio principal, y el examen puede concentrarse en los puntos habituales — contrato, plazos de conservación, borrado, subencargados del tratamiento.

Y justo aquí corresponde una frase honesta que vale para cualquier proveedor, también para el aquí considerado: las afirmaciones de una web de producto son el punto de partida del examen, no su resultado. «Alojado en Frankfurt» y «orientado al RGPD» son autodeclaraciones del proveedor — quien quiera usar el servicio profesionalmente lee el contrato de encargo de tratamiento, comprueba la lista de subencargados y aclara qué ocurre con los datos al rescindir. Un proveedor que entrega esos documentos de buen grado hace más por la confianza que cualquier fórmula de marketing; uno con el que no se encuentran, ya ha respondido a la pregunta más importante.

Quien lee por primera vez un contrato de encargo de tratamiento puede orientarse por cuatro puntos. Primero, el objeto: ¿describe el contrato en concreto qué datos se tratan con qué fin, o se queda en un genérico intercambiable? Segundo, las medidas técnicas y organizativas, casi siempre como anexo: ¿figuran ahí indicaciones comprensibles sobre cifrado, control de acceso y ubicación — o lugares comunes? Tercero, la regulación de los subencargados: ¿se informa al cliente de los cambios y puede oponerse? Cuarto, la devolución y el borrado de los datos al terminar el contrato. Ninguna de estas preguntas exige estudios de Derecho — son preguntas de comprensión que cualquier persona con conocimientos técnicos puede responder. Y donde el contrato calla, la consulta directa al proveedor es el test más honesto de su disposición a informar.

Un punto de examen a menudo pasado por alto son los plazos de conservación — y eso que en protección de datos son un tema nuclear, palabra clave minimización de datos: los datos no deben retenerse más de lo que el fin exige. En los servicios de capturas, la conservación del historial de pruebas determina cuánto tiempo permanecen en el proveedor imágenes de las propias páginas. ScanU escalona ese historial por nivel de precio — de tres días en la tarifa gratuita, pasando por 15 y 30 días, hasta 90 días en el nivel mayor, como recogen los niveles de precio de ScanU. Lo notable: desde la óptica de la protección de datos, el nivel más pequeño es el más sobrio. Quien necesita historiales largos, por ejemplo para acotar regresiones a lo largo de meses, elige conscientemente el plazo más largo — pero debe ser una elección consciente, no un ajuste por defecto sobre el que nunca nadie reflexionó.

Al menos tan importante como el examen del proveedor es el propio comportamiento de uso — porque la medida de protección de datos más eficaz es no entregar al servicio datos sensibles desde el principio. Para los servicios de testing significa en concreto: rellenar los entornos de prueba con datos de ejemplo sintéticos en lugar de copias de la base de datos de producción. Probar páginas públicas y layouts en lugar de vistas con sesión iniciada y datos reales de clientes. Vigilar que en las URL probadas no se escondan tokens de sesión ni identificadores personales. Estas reglas cuestan poco, valen para cualquier herramienta basada en URL — y desactivan la cuestión de la protección de datos con más eficacia que cualquier cláusula contractual.

Cómo pueden ser esas reglas de uso cabe en tres frases para el wiki del equipo. Primera: al servicio van solo direcciones de páginas públicas o de entornos de staging con datos sintéticos — jamás vistas que muestren datos reales de clientes. Segunda: antes de crear un nuevo proyecto de prueba se revisa una vez, conscientemente, la URL y sus parámetros; los tokens de sesión y los identificadores personales no pintan nada ahí. Tercera: los informes compartidos se tratan como documentos internos — entrega solo a los implicados, enlaces fuera de los canales públicos. Reglas así se formulan en diez minutos y se transmiten rápido en el onboarding de las nuevas compañeras y compañeros. Su valor está menos en la literalidad que en el hecho de que el tema se haya pronunciado una vez: los tropiezos de protección de datos en el uso de herramientas rara vez nacen de la intención — casi siempre de la rutina en la que nadie hizo nunca la pregunta.

También los informes compartidos merecen un pensamiento. Los informes de prueba compartibles son extraordinariamente prácticos para la colaboración — justo por eso debería estar claro quién puede abrir un informe compartido y cuánto tiempo permanece disponible. No es una peculiaridad de los servicios de testing: para los informes vale lo mismo que para los documentos compartidos en cualquier herramienta en la nube. Un informe que contiene capturas de una página de producto no publicada es material confidencial y debe tratarse como tal.

¿Hasta dónde debe llegar el examen? El propio RGPD da la respuesta: basado en el riesgo. Un servicio de capturas que fotografía páginas públicas de marketing es de otro calibre que un software de nóminas con datos salariales. Sería desproporcionado someter a ambos al mismo catálogo de preguntas — pero igual de erróneo no mirar en absoluto el caso menor. Un término medio pragmático para las herramientas de desarrollo: aclarar el papel (¿encargado del tratamiento?), recabar el contrato, anotar ubicación de los datos y subencargados, registrar plazos de conservación y borrado, formular reglas de uso para el equipo. Eso se despacha en un tiempo abarcable y cubre las obligaciones esenciales.

Jugado sobre el ejemplo de un servicio de capturas, ese catálogo queda así. Papel: el servicio trata los contenidos de página transmitidos por encargo de la empresa — encargado del tratamiento, por tanto; en consecuencia, recabar y archivar el contrato conforme al artículo 28. Ubicación de los datos: leerla en el proveedor y anotarla; en ScanU figura Frankfurt, con lo que el examen de tercer país decae para el servicio principal. Subencargados: extraer la lista de la documentación contractual o solicitarla — también un proveedor de la UE puede emplear subprestadores, y solo esa lista completa la cadena. Plazos de conservación: el nivel de precio elegido determina cuánto tiempo se retienen el historial de pruebas y, con él, las capturas; contrastar el plazo con la necesidad real y justificar la decisión en una frase. Borrado: aclarar qué ocurre con informes e historiales al rescindir. Quien documenta estos cinco puntos en una página ha hecho lo esencial para una herramienta de esta clase de riesgo — y tiene a la vez una plantilla reutilizable con la siguiente herramienta. Las respuestas a las preguntas típicas sobre el propio servicio las agrupa el proveedor en las preguntas frecuentes sobre ScanU.

A ello pertenece también una entrada en el registro de actividades de tratamiento — esa documentación obligatoria en la que una empresa deja constancia de qué servicios tratan qué datos con qué fin. Suena más burocrático de lo que es: para una herramienta de desarrollo son unas pocas líneas. El verdadero valor está en otra parte: quien escribe la entrada tiene que haber respondido las preguntas. La documentación fuerza el examen que, si no, se diluye en el día a día.

Una objeción de la práctica merece aquí una respuesta honesta: si el examen se vuelve farragoso, no se hace con más fondo, sino que no se hace. Si entre «herramienta encontrada» y «herramienta aprobada» median seis semanas y tres instancias, las desarrolladoras y los desarrolladores acaban creando la cuenta en privado — y de un servicio examinable sale shadow IT de la que ya nadie sabe. La consecuencia no es renunciar al examen, sino ajustarlo al riesgo: una comprobación corta y documentada para las herramientas con escaso contacto con datos, el examen completo para todo lo que roce datos de producción o sistemas de clientes. Un equipo que sabe que la comprobación corta dura pocos días y casi siempre acaba en un sí no tiene motivo para esquivarla. La organización de protección de datos más sólida es, al final, aquella cuyo camino oficial es más rápido que el rodeo.

Queda la clasificación de conjunto. La elección de herramientas sobrias con los datos y alojadas con transparencia no es una sutileza jurídica, sino parte del esmero artesanal que los equipos hace tiempo dan por sentado en otros ámbitos — nadie operaría una base de datos sin concepto de copia de seguridad. El hosting en la UE, los plazos de conservación claros y un contrato de encargo de tratamiento limpio son tres buenos criterios entre varios, no un sustituto del examen propio: también un servicio alojado en Frankfurt puede estar mal configurado, mal usado o alimentado con los datos equivocados. La responsabilidad de eso no la lleva el proveedor, sino la empresa que lo emplea.

La buena noticia para terminar: el esfuerzo es único y abarcable. Una hora de examen estructurado por herramienta, una entrada breve en la documentación, dos reglas de uso para el equipo — más no hace falta para la mayoría de las herramientas de desarrollo. Comparado con el esfuerzo de tener que explicar a posteriori una transmisión de datos irreflexiva, es un cambio muy ventajoso.