Por qué la Ley CLOUD cambia su elección de BaaS

Las comparaciones de BaaS generalmente se organizan en torno a cuatro ejes: precio por uso, riqueza funcional, facilidad de migración y experiencia del desarrollador. La riqueza funcional cubre funciones de autenticación, base de datos, tiempo real, almacenamiento y borde. Estos son criterios legítimos. Ninguno de los cuatro responde a una pregunta simple: ¿quién puede acceder legalmente a sus datos y bajo qué autoridad?

La Ley CLOUD (Ley de Aclaración del Uso Legal de Datos en el Extranjero) se promulgó en marzo de 2018 en los Estados Unidos. Autoriza a las autoridades federales a obligar a cualquier proveedor con presencia legal en suelo estadounidense a producir los datos que posee, incluso almacenados en el extranjero (18 U.S.C. § 2713). El texto responde directamente a una disputa en la que Microsoft se negó a transmitir al FBI datos almacenados en un servidor en Dublín. El Congreso decidió por ley en lugar de esperar la decisión de la Corte Suprema y luego se hizo cargo del caso.

Esta pregunta no aparece en casi ninguna tabla de comparación pública, incluidos sitios de terceros dedicados a BaaS. La razón es estructural: un sitio de comparación enumera características que se pueden verificar: presencia de un SDK, cuota gratuita, compatibilidad con GraphQL. La jurisdicción de una empresa no es una funcionalidad que se pueda activar en un panel de administración, por lo que no encaja en el formato de tabla habitual. Eso no lo hace menos decisivo.

Los detalles del texto, su articulación con el RGPD y una lista completa de verificación de proveedores se tratan en nuestra guía compatible con el RGPD y backend soberano de la UE. Esta sección se limita a lo que realmente cambia en una comparación de BaaS.

Verificar una región anfitriona europea en un panel de administración no es suficiente para ir más allá del alcance de la Ley CLOUD. La ley se aplica a la empresa que opera el servicio, no a la ubicación física del servidor, dos datos que la página de precios de un proveedor casi nunca distingue.

Supabase, Inc. es la entidad identificada como controlador de datos en su propia política de privacidad, con sitios alojados principalmente en los Estados Unidos. Firebase es un producto de Google LLC, una subsidiaria de Alphabet Inc., una empresa constituida bajo la ley estadounidense. AWS Amplify está vinculado contractualmente de forma predeterminada a Amazon Web Services, Inc., ubicada en el estado de Washington. Los tres ofrecen una región anfitriona de la UE. Las tres siguen siendo, como entidad contratante, empresas de derecho americano.

Esto no es un juicio sobre su calidad técnica, es una observación sobre la estructura legal de la entidad que firma el contrato con usted. Un producto excelente puede quedar legalmente expuesto; las dos evaluaciones son independientes entre sí.

La CLOUD Act no merece el mismo peso en todos los proyectos. Un MVP en solitario, sin un usuario europeo identificado y sin datos de salud o recursos humanos, puede razonablemente tratar este criterio como secundario al precio y la velocidad de desarrollo.

El cambio se produce en cuanto aparece una señal: un DPO o un abogado involucrado en la decisión, datos sensibles en el sentido del artículo 9 del RGPD: salud, biometría, opiniones. Se confirma con un cliente del sector público, o un contrato público de la UE que requiere una garantía explícita de soberanía. En este punto, se debe verificar la prueba legal antes de comparar precios, no después de haber elegido un favorito técnico.

Este es el punto de inflexión típico para un CTO de PYME-ETI que arbitra entre la construcción interna, Supabase Cloud, AWS Amplify y una solución soberana. El detonante no es el tamaño de la empresa, sino la naturaleza de los datos tratados y la existencia de un contacto que tendrá que responder ante un cliente o un regulador.

En concreto, el criterio se verifica en tres momentos distintos de un ciclo de compra de BaaS. Antes de la preselección, sirve como filtro binario para proyectos ya identificados como sensibles. Durante la debida diligencia técnica, se verifica documento por documento, junto con la DPA y la política de seguridad. Antes de firmar, se convierte en una cláusula contractual, no sólo en una respuesta oral de un vendedor de demostración.

Una cláusula útil para negociar en esta etapa: el derecho a rescindir el contrato sin penalización si cambia la estructura accionarial del proveedor. Una adquisición por parte de una empresa estadounidense cambia la respuesta a la cuestión jurídica, incluso si la infraestructura sigue siendo técnicamente idéntica al día siguiente.

Aquí está la cuadrícula para agregar a una comparación de BaaS existente, ordenada por intensidad de exposición en lugar de alfabéticamente por proveedor.

Agregue esta cuadrícula como una columna más en su hoja de cálculo de comparación existente, no como un documento separado. Debe permanecer visible cuando se decide entre dos favoritos técnicamente cercanos.

Una primera verificación no requiere asesoramiento legal. Bastan dos documentos públicos para localizar a cualquier candidato a proveedor: su política de confidencialidad y las condiciones generales adjuntas al contrato.

1. Busque "controlador de datos" o "controlador de datos" en la política de privacidad; esa es la entidad legal real, no la marca que se muestra en el sitio.
2. Localice la cláusula de ley aplicable en las condiciones generales: indica la jurisdicción bajo la cual opera el contrato y, a menudo, la entidad.
3. Verifique si existe una entidad de la UE separada para su región (subsidiaria irlandesa, por ejemplo) y si cambia la respuesta a la pregunta anterior o solo la dirección de facturación.

Este es el método utilizado para verificar los hechos citados en este artículo: Supabase, Inc. Política de privacidad, Términos y condiciones de AWS, Política de privacidad de Google. Tres documentos públicos, ninguno de los cuales requiere una cuenta comercial para verlos.

El criterio de la CLOUD Act no te exime de evaluar el resto de la comparación. El coste de la migración, la madurez del ecosistema, la calidad real del RLS y la experiencia del desarrollador siguen siendo factores determinantes para la velocidad de un equipo. Un proveedor soberano de la UE con un SDK inmaduro sigue siendo una mala elección para muchos proyectos.

También hay un argumento de tiempo específico para la elección de un BaaS: cuanto más profundamente un equipo integra un proveedor (esquema, políticas, funciones perimetrales, webhooks), más costosa será la migración posterior. Un criterio legal descubierto tras seis meses de producción se maneja con urgencia y con una relación de poder desfavorable. El mismo criterio evaluado antes de firmar sólo cuesta el tiempo de lectura de dos documentos públicos.