Dónde ubicar sus servidores y sus datos: latencia y ley

La ubicación de un servidor solía ser un detalle de compras. Hoy determina tres cosas a la vez: la rapidez con la que los usuarios perciben su aplicación, qué leyes rigen los datos que contiene y lo bien que se recupera cuando falla una instalación o una región.

Esta guía recorre la decisión tal como debería tomarla un equipo de infraestructura: empezar por los datos y los usuarios, poner cifras a la latencia, mapear las restricciones legales en términos generales, tener en cuenta cada copia de los datos (no solo la principal) y plasmar el resultado en sus contratos.

Una nota antes de empezar: esta es una guía de ingeniería, no asesoramiento jurídico. Las normas de privacidad y residencia cambian, dependen de hechos específicos de su negocio y los distintos reguladores las interpretan de manera diferente. Use este material para plantear las preguntas y luego confirme cada conclusión jurídica con asesores legales cualificados en las jurisdicciones que le afectan.

Empiece por los datos, no por el mapa

Antes de elegir una ciudad, clasifique lo que el sistema almacena y procesa. La mayoría de las organizaciones acaba con un número reducido de clases de datos, cada una con sus propias reglas de ubicación.

• Datos personales. Todo lo que identifica a una persona: nombres, correos electrónicos, direcciones IP, identificadores de dispositivos, historial de ubicación. La mayoría de las leyes de privacidad se aplican aquí.
• Categorías sensibles o especiales. Datos de salud, biométricos, financieros, documentos de identidad oficiales, datos de menores. Suelen estar sujetos a normas de tratamiento y transferencia más estrictas.
• Datos de sectores regulados. Datos de pago, registros bancarios, historias clínicas, datos del sector público. Los reguladores sectoriales suelen añadir requisitos a los de la ley general de privacidad.
• Datos confidenciales del negocio. Código fuente, modelos, contratos, precios. No siempre están regulados, pero los clientes pueden exigir igualmente control sobre su ubicación.
• Datos operativos. Logs, métricas, trazas, tickets de soporte. Suelen pasarse por alto, a menudo están llenos de datos personales y es habitual que se envíen por defecto a un tercer país.

Para cada clase, registre dónde están los interesados, dónde se crean los datos, quién necesita acceder a ellos y desde dónde, y qué prometen ya los contratos con clientes.

Latencia: lo que realmente cuesta la distancia

La luz en la fibra óptica viaja a unos 200.000 km por segundo, aproximadamente dos tercios de su velocidad en el vacío. Eso equivale a cerca de 1 ms de tiempo de ida y vuelta por cada 100 km de fibra. Las rutas reales de los cables son más largas que las líneas rectas, y cada router y punto de intercambio suma un poco, por lo que los tiempos de ida y vuelta medidos suelen ser de 1.3 a 2 veces la cifra calculada en línea recta.

Los tiempos de ida y vuelta aproximados en condiciones reales son los siguientes.

• Misma área metropolitana. De 1 a 5 ms.
• Misma región, hasta unos 1.000 km. De 10 a 25 ms.
• A lo ancho de los Estados Unidos continentales, de costa a costa. De 60 a 80 ms.
• De la Costa Este de los Estados Unidos a Europa Occidental. De 75 a 100 ms.
• De la Costa Este de los Estados Unidos a la India. De 180 a 250 ms.
• De Singapur a la India. De 50 a 80 ms.
• De la Costa Oeste de los Estados Unidos a Singapur. De 160 a 200 ms.
• De la Costa Este de los Estados Unidos a São Paulo. De 110 a 140 ms.

Por qué esto importa más de lo que parece: una página o una llamada a una API rara vez necesita una sola ida y vuelta. A 200 ms por ida y vuelta, cinco idas y vueltas secuenciales suponen un segundo completo de espera antes de cualquier procesamiento en el servidor. El mismo flujo a 20 ms cuesta 100 ms.

Una orientación práctica: las aplicaciones interactivas se perciben ágiles cuando la ida y vuelta hasta el origen se mantiene por debajo de unos 50 ms, y la mayoría de los usuarios nota los retrasos cuando el tiempo de respuesta total supera unos cientos de milisegundos. La latencia entre sus propios niveles también importa: un servidor de aplicación y su base de datos normalmente deben estar en la misma instalación o zona de disponibilidad, porque el tráfico intensivo hacia la base de datos multiplica cada milisegundo.

Normas de residencia, soberanía y transferencia en términos generales

Hay tres términos que se usan con poca precisión. La residencia de datos es el lugar donde los datos se almacenan físicamente. La localización de datos es un requisito legal de que ciertos datos permanezcan dentro de un país. La soberanía de datos es la idea más amplia de que los datos están sujetos a las leyes del lugar donde se conservan y, a veces, a las leyes del país donde tiene su sede el proveedor. La mayoría de las leyes generales de privacidad no exigen la localización. En cambio, regulan las transferencias internacionales y las garantías que las rodean.

• GDPR (Unión Europea y EEE). Los datos personales pueden salir del EEE, pero solo al amparo de un mecanismo reconocido: una decisión de adecuación para el país de destino, cláusulas contractuales tipo con una evaluación del riesgo de la transferencia, normas corporativas vinculantes o excepciones limitadas. Las transferencias a organizaciones estadounidenses certificadas en el Marco de Privacidad de Datos UE-EE. UU. (EU-US Data Privacy Framework) están cubiertas por una decisión de adecuación. El acceso remoto desde otro país cuenta como transferencia.
• CCPA, modificada por la CPRA (California). No exige localización. Se centra en los derechos del consumidor (acceso, eliminación, oposición a la venta o al intercambio de datos) y en contratos con proveedores de servicios que limiten cómo usan los datos. Varios otros estados de los Estados Unidos han aprobado leyes en general similares.
• LGPD (Brasil). Su estructura es muy similar a la del GDPR. Las transferencias internacionales requieren una base legal, como la adecuación, cláusulas contractuales tipo aprobadas por la autoridad nacional (ANPD) o un consentimiento específico, y la autoridad ha emitido reglamentos que detallan estos mecanismos.
• DPDP Act (India). La Ley de Protección de Datos Personales Digitales de 2023 (Digital Personal Data Protection Act) permite en general las transferencias fuera de la India, salvo a los países que el gobierno restrinja mediante notificación, y sus normas de aplicación se están implementando de forma gradual. Las normas sectoriales en la India pueden ser más estrictas que la ley general y prevalecen donde se aplican.
• Otros países. Algunas jurisdicciones exigen que ciertas categorías de datos, o al menos una copia de ellos, se almacenen localmente, o requieren aprobación para las transferencias. Si atiende a usuarios en un país, revise sus normas desde el principio y no en el momento de firmar el contrato.

Un proveedor con sede en un país y alojamiento en otro puede estar sujeto a requerimientos legales de ambos. Pregunte a su asesor legal cómo se aplica a su situación y registre la respuesta en sus documentos de diseño.

Normas sectoriales que prevalecen sobre el panorama general

Las normas sectoriales imponen con frecuencia requisitos más estrictos o más específicos que la ley general de privacidad. Algunos ejemplos habituales:

• Pagos. PCI DSS no impone un país, pero define cómo se segmentan, se accede y se auditan los entornos de datos de titulares de tarjetas, y eso influye en qué instalaciones y proveedores califican. Algunos reguladores nacionales van más allá: el Banco de Reserva de la India (RBI), por ejemplo, exige que los datos de los sistemas de pago se almacenen únicamente en la India.
• Salud. En los Estados Unidos, HIPAA no exige alojamiento nacional, pero sí un acuerdo de socio comercial (business associate agreement) con cualquier proveedor que maneje información de salud protegida. Aun así, muchos clientes del sector salud añaden por contrato requisitos de alojamiento exclusivo en los Estados Unidos.
• Servicios financieros. Los reguladores bancarios y de seguros suelen exigir notificación o aprobación para las externalizaciones materiales, derechos de auditoría para el regulador y planes de salida documentados.
• Sector público. Los programas gubernamentales suelen exigir alojamiento en el país, personal habilitado o marcos de autorización específicos, y estos requisitos normalmente se trasladan a los subcontratistas.

Cuando un contrato con un cliente o un regulador impone un requisito de ubicación, este se convierte en una restricción obligatoria.

Respaldos, réplicas y las copias que se olvidan

La mayoría de los fallos de residencia no tienen que ver con la base de datos principal. Un sistema que almacena los datos de producción en un país pero envía respaldos nocturnos, flujos de logs o exportaciones de soporte a otro tiene, en la práctica, una presencia en varios países.

Enumere cada lugar donde puede terminar una copia de los datos:

• Respaldos y snapshots. ¿Dónde se almacenan, cuánto tiempo se conservan y están cifrados con claves que usted controla?
• Réplicas. Réplicas de lectura, bases de datos en standby y replicación entre regiones para la recuperación ante desastres.
• Logs y observabilidad. Los logs de aplicación, los logs de acceso, las trazas y los informes de errores suelen contener direcciones IP, IDs de usuario y cuerpos de solicitudes.
• CDN y cachés. Las cachés de edge pueden almacenar contenido personal en muchos países. Configure qué se puede almacenar en caché y dónde.
• Soporte y administración. El acceso remoto de ingenieros o personal de soporte desde otro país puede contar como transferencia según varias leyes.
• Pipelines de analítica y de IA. Los datos exportados para análisis, entrenamiento de modelos o inferencia pueden trasladarse a otra región o a otro proveedor.

Un patrón habitual y defendible es mantener la base principal y su standby inmediato en una sola jurisdicción, ubicar las copias de recuperación ante desastres en una segunda instalación dentro de la misma jurisdicción cuando sea posible y, cuando el respaldo transfronterizo sea necesario, cifrar antes de la transferencia con claves custodiadas en la jurisdicción principal. Que el cifrado cambie o no el análisis jurídico depende de la ley y de los hechos, así que confirme también ese punto con su asesor legal.

Un enlace dedicado de 1 Gbps mueve unos 10 TB al día a plena utilización, y menos en la práctica. Si una restauración completa de su mayor conjunto de datos por ese enlace tarda más que su objetivo de tiempo de recuperación, necesita un enlace más grande, una copia más cercana o un plan de recuperación diferente.

Diseños multirregión y lo que cuestan

Operar en más de una región resuelve dos problemas distintos: la proximidad a usuarios de diferentes zonas geográficas y la supervivencia ante una caída regional.

• Una sola región, varias instalaciones. Principal y standby en centros de datos separados dentro de la misma área metropolitana o el mismo país. Baja latencia de replicación y una situación de residencia sencilla; protege frente al fallo de una instalación, pero no frente a un evento regional.
• Activo-pasivo entre regiones. Una región atiende el tráfico y una segunda mantiene réplicas que pueden promoverse. La replicación asíncrona implica que el punto de recuperación queda entre segundos y minutos por detrás. Es un buen equilibrio para la mayoría de los sistemas de negocio.
• Activo-activo entre regiones. Ambas regiones atienden tráfico. Exige un manejo cuidadoso de las escrituras, resolución de conflictos o propiedad particionada de los datos, y muchas más pruebas. Se justifica para bases de usuarios globales con requisitos estrictos de disponibilidad.
• Celdas regionales. Cada región guarda los datos de sus propios usuarios y solo los atiende a ellos, con un estado compartido mínimo. Esto encaja bien con los requisitos de residencia: usuarios europeos en una celda europea, usuarios indios en una celda india, y así sucesivamente.

La replicación síncrona entre regiones añade el tiempo de ida y vuelta completo a cada escritura, así que un enlace de 70 ms añade al menos 70 ms a cada transacción confirmada. La mayoría de los equipos usa la replicación síncrona solo dentro de un área metropolitana y la asíncrona en distancias mayores. Presupueste también la infraestructura duplicada, los cargos de transferencia entre regiones cuando correspondan y el tiempo de ingeniería para realizar pruebas de conmutación por error periódicas.

Cláusulas contractuales que conviene solicitar

El diseño técnico solo se sostiene si el contrato lo respalda. Al evaluar cualquier proveedor de hosting o de nube, solicite cláusulas o compromisos por escrito que cubran lo siguiente, y pida a sus asesores legales que revisen la redacción final.

• Ubicaciones nombradas. El país y, idealmente, la instalación o la región de los datos principales, los respaldos y las réplicas, indicados en el formulario de pedido o en la declaración de trabajo.
• Ningún traslado sin aprobación. El proveedor no trasladará los datos a otra ubicación sin su consentimiento previo por escrito.
• Acuerdo de tratamiento de datos. Roles (responsable y encargado del tratamiento), finalidades del tratamiento, medidas de seguridad y mecanismos de transferencia cuando existan flujos transfronterizos.
• Lista de subencargados y aviso. Una lista actualizada de subencargados con sus ubicaciones, y aviso previo con derecho a oponerse antes de cualquier cambio.
• Divulgación del acceso remoto. Desde qué países puede el personal del proveedor acceder a los sistemas o a los datos, y bajo qué controles.
• Notificación de brechas. Un plazo de notificación definido que se ajuste a sus propios plazos regulatorios, además de la información que entregará el proveedor.
• Solicitudes de acceso gubernamental. El compromiso de notificarle cuando la ley lo permita y de impugnar las solicitudes excesivamente amplias.
• Auditoría y evidencias. Acceso a informes de auditoría de terceros o a certificaciones de las instalaciones relevantes para su sector, y un proceso para auditorías de reguladores si lo necesita.
• Salida y eliminación. Exportación de los datos en formatos utilizables, un período de transición y eliminación certificada de todas las copias, incluidos los respaldos, al finalizar el contrato.

Una lista de verificación para su próxima revisión de diseño

• Cada clase de datos inventariada con las jurisdicciones de los interesados.
• Restricciones de ubicación legales, regulatorias y contractuales enumeradas y confirmadas con asesoría jurídica.
• RTT desde las principales bases de usuarios hasta cada ubicación candidata: medido, no estimado.
• Servidores de aplicación y bases de datos en la misma instalación o zona.
• Copias mapeadas: principal, réplicas, respaldos, logs, cachés, analítica, exportaciones de soporte.
• Flujos transfronterizos: mecanismo documentado, responsable designado.
• Claves de los respaldos custodiadas en la jurisdicción prevista.
• RPO y RTO definidos, y el enlace de respaldo puede cumplirlos.
• Conmutación probada en los últimos seis meses, resultados registrados.
• Los contratos fijan las ubicaciones, vetan traslados no aprobados y cubren subencargados, notificación de brechas y salida.
• Decisión y justificación documentadas. Próxima auditoría o cuestionario de cliente: horas, no semanas.

Cómo puede ayudar Vonahost

Vonahost permite a sus clientes elegir el país de cada servidor, y los datos no se trasladan sin su aprobación. Los servidores dedicados, los VPS NVMe y los VPS SSD se despliegan en la región que usted elija, y la nube gestionada puede funcionar en la plataforma propia de Vonahost o en regiones de AWS y Google Cloud, lo que resulta útil cuando un diseño requiere celdas regionales o un sitio de recuperación ante desastres en una jurisdicción concreta.

Cada propuesta de Vonahost indica la configuración, la ubicación, las responsabilidades y el precio mensual en dólares estadounidenses, de modo que las decisiones de ubicación de su revisión de diseño quedan escritas en el propio pedido. Las conclusiones jurídicas siguen siendo competencia de su asesor legal.