Datos de clientes latinoamericanos en un VPS en Canadá

Alojar datos de clientes en un VPS en Canadá: la respuesta corta

Sí, una empresa de México, Colombia, Argentina, Chile o Perú puede alojar los datos personales de sus clientes en un VPS en Canadá. Ninguna de las cinco leyes lo prohíbe. Lo que cada una hace es condicionar la salida de los datos del país a un mecanismo concreto: un contrato con quien recibe los datos, el consentimiento del titular, o que el país de destino figure en una lista de países con protección adecuada. Para un servidor alquilado, el mecanismo que casi siempre aplica es el contrato, porque el proveedor no decide nada sobre los datos: solo los guarda por cuenta tuya.

Antes de crear el servidor hay cuatro tareas. Identificar qué mecanismo exige tu ley. Firmar con el proveedor un contrato de encargo de tratamiento. Escribir un mapa de datos que diga dónde vive cada copia, incluidos respaldos y registros. Y configurar el VPS para que ese mapa sea verdad. Todo lo que sigue es una lista de comprobación para esas cuatro tareas, no una opinión legal. Las leyes de la región cambiaron mucho entre 2024 y 2025, así que confirma cada texto en la fuente oficial antes de apoyarte en él.

Encargar no es lo mismo que transferir

La distinción que decide casi todo es esta. Una transferencia es entregar datos a un tercero que va a usarlos con sus propios fines, por ejemplo una aseguradora o un socio comercial. Un encargo es entregar datos a un proveedor que solo los trata siguiendo tus instrucciones, por ejemplo el proveedor del VPS, que pone el disco y la red pero no lee ni decide nada. Las cinco leyes tratan las dos cosas de forma distinta, y el encargo casi siempre es el camino barato: exige un contrato, no exige pedir permiso de nuevo a cada cliente.

El nombre cambia por país. México lo llama remisión, Colombia lo llama transmisión, Argentina habla de prestación de servicios, y Perú y Chile hablan de encargado de tratamiento. El concepto es el mismo: el proveedor no es dueño de los datos y responde ante ti, y tú sigues respondiendo ante el cliente y ante la autoridad. Por eso el contrato con el proveedor importa tanto como el cifrado.

Qué dice la ley de tu país sobre sacar los datos del territorio

México: la LFPDPPP de 2025

La Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) vigente se publicó en el Diario Oficial de la Federación el 20 de marzo de 2025 y sustituyó a la de 2010. En el mismo decreto desapareció el INAI, y la autoridad para el sector privado pasó a ser la Secretaría Anticorrupción y Buen Gobierno. Si tu aviso de privacidad todavía nombra al INAI, ese es el primer arreglo.

El artículo 2, fracción XX, define transferencia como "toda comunicación de datos personales dentro o fuera del territorio mexicano, realizada a persona distinta de la persona titular, del responsable o de la persona encargada del tratamiento". El proveedor del VPS es una persona encargada, así que alojar la base de datos en Canadá no es una transferencia en el sentido de la ley y no entra en los artículos 35 y 36, que son los que piden que el aviso de privacidad incluya la cláusula de aceptación de transferencias. Lo que sí aplica es el artículo 18, que te obliga a mantener medidas de seguridad administrativas, técnicas y físicas, y el artículo 19, que te obliga a informar de inmediato a los titulares de cualquier vulneración que afecte de forma significativa sus derechos. El Reglamento de 2011, que sigue siendo la referencia mientras no se publique uno nuevo, dedica su artículo 52 al cómputo en la nube y lista lo que debes comprobar del proveedor antes de contratarlo: que tenga políticas alineadas con la ley, que sea transparente con sus subcontratistas, que no se apropie de los datos, que guarde confidencialidad y que los borre al terminar el servicio. El texto vigente está publicado por la Cámara de Diputados.

Colombia: la Ley 1581 de 2012

La autoridad es la Superintendencia de Industria y Comercio (SIC). El artículo 26 de la Ley 1581 prohíbe transferir datos personales a países que no ofrezcan un nivel adecuado de protección, salvo excepciones como la autorización expresa del titular o la ejecución de un contrato entre el titular y el responsable. La SIC publicó su lista de países adecuados en la Circular Externa 005 de 2017, y Canadá no aparece en ella por su nombre. La circular también se apoya en las decisiones de adecuación de la Comisión Europea, y Canadá tiene una desde 2001 para sus organizaciones comerciales, pero esa lectura debe confirmarla tu asesor o la propia SIC mediante una declaración de conformidad. Puedes leer la circular en la compilación normativa de la DIAN.

Para el hosting, la vía práctica no es esa. El Decreto 1377 de 2013, hoy compilado en el Decreto 1074 de 2015, distingue la transferencia (a otro responsable) de la transmisión (a un encargado), y dice que la transmisión internacional a un encargado no requiere informar al titular ni obtener su consentimiento cuando existe un contrato de transmisión de datos personales. Ese contrato debe fijar el alcance del tratamiento, las actividades que el encargado hará por tu cuenta y sus obligaciones frente a ti y frente al titular. Si tu empresa está obligada a inscribir sus bases en el Registro Nacional de Bases de Datos (RNBD), el formulario pregunta por las transmisiones internacionales, y el país que declares tiene que coincidir con el del servidor.

Argentina: la Ley 25.326

El artículo 12 de la Ley 25.326 prohíbe transferir datos personales a países que no proporcionen niveles de protección adecuados. La Agencia de Acceso a la Información Pública (AAIP) mantiene la lista, aprobada en la Disposición 60-E/2016, y en ella figura "Canadá (sólo respecto de su sector privado)", según la página de transferencias internacionales de la AAIP. Un proveedor de hosting privado entra en ese sector, así que una empresa argentina puede alojar en Canadá sin cláusulas adicionales y sin consentimiento específico.

Lo que no desaparece es el artículo 25 de la misma ley, sobre prestación de servicios informatizados: el prestador solo puede usar los datos para el servicio contratado y debe destruirlos al terminar, salvo que el contrato prevea conservarlos. Si en algún momento cambias a un proveedor en un país fuera de la lista, la misma Disposición trae un contrato modelo para prestación de servicios, y la Resolución 198/2023 de la AAIP añadió las cláusulas modelo de la Red Iberoamericana de Protección de Datos.

Chile: de la Ley 19.628 a la Ley 21.719

Chile es el caso con dos fechas. La Ley 19.628 de 1999, todavía vigente en septiembre de 2026, apenas regula las transferencias internacionales y no tiene autoridad de control. La Ley 21.719, publicada el 13 de diciembre de 2024, la reescribe casi por completo y está prevista para entrar en vigencia el 1 de diciembre de 2026. Crea la Agencia de Protección de Datos Personales y regula la transferencia internacional al estilo europeo: es lícita si el país de destino tiene un nivel adecuado de protección según la Agencia, si existen garantías como cláusulas contractuales tipo o normas corporativas vinculantes, o si el titular da su consentimiento expreso e informado.

Como la Agencia es nueva, su lista de países adecuados también lo es. Planifica con el contrato: un encargo de tratamiento por escrito con el proveedor, con las cláusulas tipo cuando la autoridad las publique, cumple la ley nueva sin depender de que Canadá aparezca en una lista que todavía se está formando.

Perú: la Ley 29733

La Ley 29733 llama a esto flujo transfronterizo de datos personales. Su artículo 15 dice que el titular del banco de datos solo puede realizarlo si el país de destino mantiene niveles de protección adecuados y, si no los tiene, debe garantizar por contrato que el tratamiento se hará conforme a la ley peruana. El consentimiento previo, informado, expreso e inequívoco del titular de los datos es una de las excepciones.

El reglamento nuevo, el Decreto Supremo 016-2024-JUS, en vigor desde marzo de 2025, añade el trámite que la mayoría olvida: el flujo transfronterizo se comunica a la Autoridad Nacional de Protección de Datos Personales (ANPD) y queda inscrito en el Registro Nacional de Protección de Datos Personales, junto con el banco de datos que lo origina. El formulario pide, entre otras cosas, el país de destino. Si la base está en Toronto y los respaldos en Montreal, ambos son Canadá. Si los respaldos van a un bucket en Estados Unidos, declaraste un país y usas dos.

El lado canadiense: PIPEDA y la Ley 25 de Quebec

Canadá no exige que los datos se queden en Canadá y no prohíbe que un cliente extranjero alquile un servidor allí. La ley federal del sector privado es la Personal Information Protection and Electronic Documents Act (PIPEDA), que según la Oficina del Comisionado de Privacidad de Canadá cubre a las organizaciones privadas que recogen, usan o divulgan información personal en el curso de una actividad comercial. Tu proveedor está sujeto a ella. Tres provincias tienen leyes propias consideradas equivalentes, Quebec, Alberta y Columbia Británica. Ontario no, así que un servidor en Toronto se rige por PIPEDA sin capa provincial.

Un servidor en Montreal está en Quebec, donde la ley provincial fue reformada por la Ley 25 y la supervisa la Commission d'accès à l'information (CAI). La Ley 25 obliga a quien opera una empresa en Quebec y, según la CAI, exige una evaluación de factores relativos a la vida privada antes de comunicar información personal fuera de Quebec. Esa obligación recae en el proveedor, y en ti solo si operas en Quebec. Aun así, léela si tus respaldos salen de Montreal hacia otra provincia, porque el proveedor te preguntará por ellos.

Sobre el acceso de autoridades: en Canadá, como regla general, una autoridad necesita una orden judicial para obtener datos de un proveedor. La pregunta que importa es la nacionalidad del proveedor, más que el país del centro de datos. Si es una filial de una empresa estadounidense, la ley de Estados Unidos alcanza a la matriz y, a través de ella, a tus datos, y elegir entre un VPS en Canadá y uno en Estados Unidos explica esa diferencia con detalle. Lo que la residencia de datos en Canadá garantiza y lo que no está en residencia de datos en un VPS canadiense.

Un dato más que conviene tener a mano: la Comisión Europea reconoce a Canadá como país con protección adecuada para sus organizaciones comerciales desde 2001, y su revisión de enero de 2024 mantuvo esa decisión, según la página de decisiones de adecuación. La lista argentina y la circular colombiana miran a esa decisión, así que es el argumento que tu asesor usará primero.

En qué se diferencia de alojar datos europeos

Con datos de clientes europeos hay una sola ley, el Reglamento General de Protección de Datos (RGPD), y una sola decisión de adecuación que cubre a Canadá, así que no hacen falta cláusulas contractuales tipo. Con datos latinoamericanos hay cinco leyes y cinco autoridades, ninguna ha delegado en la Comisión Europea, y el mecanismo cambia de país en país: lista en Argentina, contrato de transmisión en Colombia, encargo en México, registro ante la autoridad en Perú y, desde diciembre de 2026, cláusulas tipo en Chile. Lo que sí es igual es el contrato con el proveedor: el artículo 28 del RGPD exige uno, y las cinco leyes de la región también. Si además tienes clientes en Europa, alojar datos europeos en un VPS con residencia en la UE cubre la otra mitad de esa decisión.

Los controles que un VPS permite y un plan compartido no

En un hosting compartido o en un plan de marketplace no eliges la clave con la que se cifra el disco, no eliges el formato de los registros y no eliges a qué país van las copias. En un VPS sí. Cuatro controles cubren lo que las cinco leyes piden, y los cuatro se pueden demostrar con un comando.

Un mapa de datos antes que un servidor

El mapa de datos es una lista, no un documento largo. Para cada conjunto de datos personales dice qué contiene, en qué sistema vive, en qué ciudad está ese sistema, a dónde van sus respaldos, qué registros lo mencionan y qué terceros lo reciben. Un ejemplo mínimo:

clientes:
  contiene: nombre, correo, teléfono, dirección de facturación
  sistema: MariaDB en vps-app (Toronto, Canadá)
  respaldos: restic hacia vps-copias (Montreal, Canadá), 30 días
  registros: nginx access.log (IP truncada), 14 días, mismo servidor
  terceros: pasarela de pagos (México), proveedor de correo (Estados Unidos)

Ese archivo alimenta todo lo demás: el aviso de privacidad mexicano, el formulario del RNBD colombiano, la comunicación de flujo transfronterizo peruana y el anexo del contrato con el proveedor. Si el mapa dice Toronto y un respaldo está en Oregón, el mapa miente, y una autoridad lo va a leer antes que tu configuración.

Cifrado en reposo con LUKS en un volumen aparte

LUKS (Linux Unified Key Setup) cifra un dispositivo de bloque completo con una clave que solo tú conoces. Protege contra el escenario que las leyes describen como pérdida o acceso no autorizado: un disco retirado, una imagen copiada, un snapshot que acaba en el sitio equivocado. No protege contra un anfitrión comprometido mientras el volumen está abierto, porque la clave vive en la memoria del servidor, y conviene decirlo así en el mapa de datos.

Empieza con un volumen de almacenamiento en bloque añadido al VPS y confirma su nombre con lsblk. En KVM el segundo disco suele ser /dev/vdb.

sudo apt update && sudo apt install -y cryptsetup
lsblk
sudo cryptsetup luksFormat --type luks2 /dev/vdb
sudo cryptsetup open /dev/vdb datos
sudo mkfs.ext4 /dev/mapper/datos
sudo mkdir -p /srv/datos
sudo mount /dev/mapper/datos /srv/datos

luksFormat pide confirmar con YES en mayúsculas y luego una frase de paso. sudo cryptsetup luksDump /dev/vdb debe mostrar Version: 2 y una ranura de clave en uso, y lsblk debe listar datos como hijo de vdb con tipo crypt. Si no tienes un volumen aparte, un archivo sirve igual: sudo fallocate -l 20G /srv/datos.img y luego los mismos comandos con /srv/datos.img en lugar de /dev/vdb, porque cryptsetup asocia el archivo a un dispositivo loop por su cuenta.

No pongas la frase de paso en un archivo del mismo servidor ni en /etc/crypttab, porque entonces el disco se abre solo al arrancar y el cifrado deja de proteger una copia del disco. Tras cada reinicio, abre y monta el volumen a mano, y haz que el servicio que usa los datos no arranque sin él:

sudo mkdir -p /etc/systemd/system/mariadb.service.d
printf '[Unit]\nConditionPathIsMountPoint=/srv/datos\n' \
  | sudo tee /etc/systemd/system/mariadb.service.d/override.conf
sudo systemctl daemon-reload

Con el volumen sin montar, systemctl status mariadb muestra el servicio inactivo y una línea was skipped because of an unmet condition check (ConditionPathIsMountPoint=/srv/datos). Eso es lo que quieres: un servidor que reinicia solo, sin la clave, no expone nada.

Dónde van las copias de seguridad

Un respaldo es una copia de los datos personales y hereda todas las obligaciones del original. Elige el destino con el mapa en la mano: un segundo VPS en Canadá, o un almacenamiento compatible con S3 cuya región sea canadiense. restic cifra en el cliente antes de enviar, así que el servidor de destino nunca ve datos en claro.

sudo apt install -y restic
echo 'una-frase-larga-y-distinta' | sudo tee /root/.restic-pass >/dev/null
sudo chmod 600 /root/.restic-pass
sudo restic -r sftp:respaldo@copias.example.com:/srv/restic \
  --password-file /root/.restic-pass init
sudo restic -r sftp:respaldo@copias.example.com:/srv/restic \
  --password-file /root/.restic-pass backup /srv/datos
sudo restic -r sftp:respaldo@copias.example.com:/srv/restic \
  --password-file /root/.restic-pass snapshots

snapshots debe listar una fila con la fecha, el host y la ruta /srv/datos. El usuario root del VPS necesita una clave SSH aceptada por el servidor de copias, porque restic usa ssh por debajo, y un Permission denied (publickey) viene de ahí, no de restic. Pregunta también por los snapshots que el propio proveedor toma del disco: en algunos paneles se guardan en otra región, y ese es un respaldo que no aparece en tu mapa hasta que lo preguntas.

Los registros también son datos personales

Una dirección IP identifica a una persona a efectos de las cinco leyes, así que el access.log de nginx es una base de datos personales que llevas guardando sin decidirlo. Dos medidas bastan: truncar la IP antes de escribirla y limitar la retención. Crea /etc/nginx/conf.d/anon-log.conf:

map $remote_addr $remote_addr_anon {
    ~(?P<ip>\d+\.\d+\.\d+)\.    $ip.0;
    ~(?P<ip>[^:]+:[^:]+):       $ip::;
    default                     0.0.0.0;
}

log_format anon '$remote_addr_anon - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" "$http_user_agent"';

Y en cada bloque server, incluido el de /etc/nginx/sites-enabled/default, añade access_log /var/log/nginx/access.log anon;. La directiva del bloque server reemplaza a la heredada de nginx.conf, que sigue escribiendo la IP completa para cualquier servidor que no la sobrescriba.

sudo nginx -t && sudo systemctl reload nginx
curl -s -o /dev/null http://localhost/
tail -n 1 /var/log/nginx/access.log

La última línea debe empezar por 127.0.0.0, no por 127.0.0.1. Si nginx -t responde unknown log format "anon", el archivo de conf.d no se cargó antes del bloque server; comprueba que el nombre termina en .conf. La retención la fija /etc/logrotate.d/nginx, que en Ubuntu rota a diario y conserva 14 archivos con rotate 14; baja ese número si tu política dice menos. Y si envías registros a un servicio de monitoreo en la nube, esa empresa es un tercero más en el mapa, con su país.

El contrato de encargo con el proveedor

En inglés se llama DPA (data processing agreement, acuerdo de tratamiento de datos) y la mayoría de los proveedores serios tienen uno para firmar en línea. Antes de firmarlo comprueba que responde a estas preguntas, porque son las que hacen el artículo 52 del Reglamento mexicano, el contrato de transmisión colombiano, el artículo 25 argentino y el reglamento peruano:

• Qué empresa firma, en qué país está constituida y quién es su matriz.
• En qué ciudad está el centro de datos del plan que contratas.
• Dónde se guardan los snapshots y las copias que hace el proveedor, y por cuánto tiempo.
• Qué subcontratistas tocan la infraestructura y cómo te avisan si cambian.
• En cuántas horas te notifican una vulneración de seguridad.
• Qué pasa con el disco cuando cancelas: cuándo se borra y cómo lo demuestran.
• Que el proveedor solo trata los datos según tus instrucciones y no los usa para nada propio.

Guarda el contrato firmado junto al mapa de datos. Es el documento que la autoridad pedirá primero si un cliente presenta una queja.

Toronto o Montreal, y cómo pagar desde tu país

Para una empresa latinoamericana la diferencia legal entre las dos ciudades es la capa provincial: Toronto solo tiene PIPEDA; Montreal añade la Ley 25 y una autoridad que trabaja en francés. Si no operas en Quebec, esa diferencia recae en el proveedor, no en ti. La comparación de Toronto, Montreal y Vancouver como ubicación de un VPS cubre lo demás, y VPS en Toronto explica qué mirar en esa ciudad en concreto. Desde Ciudad de México, Bogotá, Lima o Buenos Aires, qué latencia esperar hacia un VPS en Canadá desde América Latina te dice si tus usuarios notarán la distancia.

El pago es el otro trámite. La factura llega en dólares estadounidenses o canadienses, y un plan de entrada cuesta del orden de USD 5 a 10 al mes: en cifras redondas, al tipo de cambio de septiembre de 2026, entre 100 y 200 pesos mexicanos o entre 20.000 y 40.000 pesos colombianos, más la comisión de conversión de tu banco. Cómo resolver ese pago desde tu país está en pagar un VPS canadiense desde el extranjero, y VPS en Canadá para usuarios hispanohablantes cubre lo que cambia cuando el equipo que administra el servidor trabaja en español.

FAQ

¿Necesito el consentimiento de cada cliente para alojar sus datos en Canadá?

En general no, si el proveedor del VPS actúa como encargado y firmas un contrato con él. México excluye a la persona encargada de la definición de transferencia, Colombia exime de consentimiento la transmisión internacional a un encargado con contrato, y Argentina reconoce a Canadá como país adecuado para su sector privado. Perú exige registrar el flujo transfronterizo ante la ANPD, y Chile, desde diciembre de 2026, acepta cláusulas contractuales tipo. El consentimiento es la vía cara y frágil: hay que pedirlo a cada cliente y se puede revocar.

¿Canadá está en la lista de países con protección adecuada de mi país?

En Argentina sí, "sólo respecto de su sector privado", según la lista que publica la AAIP. En Colombia no aparece por su nombre en la Circular Externa 005 de 2017, aunque la circular se apoya en las decisiones de adecuación de la Comisión Europea, que sí reconoce a Canadá para sus organizaciones comerciales. México y Perú no funcionan con una lista pública comparable, y la lista chilena la elaborará la Agencia de Protección de Datos Personales cuando entre en funciones. Comprueba la lista en la página de la autoridad, no en un resumen de terceros, porque cambian.

¿El cifrado con LUKS me exime de cumplir la ley de mi país?

No. El cifrado es una medida de seguridad que las cinco leyes exigen o recomiendan, y reduce el daño de una vulneración, pero los datos cifrados siguen siendo datos personales y el servidor sigue estando en otro país. El contrato con el proveedor, el mapa de datos y, donde aplique, el registro ante la autoridad siguen siendo obligatorios.

¿Qué cambia si el proveedor canadiense es filial de una empresa de Estados Unidos?

El centro de datos sigue en Canadá y PIPEDA sigue aplicando, pero la matriz está sujeta a la ley estadounidense, que puede obligarla a entregar datos que controle aunque estén fuera de Estados Unidos. Pregunta en el contrato de encargo qué empresa firma y quién es su matriz, y anota la respuesta en el mapa de datos. Si la respuesta te incomoda, elige un proveedor constituido en Canadá.

¿Toronto o Montreal: cambia algo desde el punto de vista legal?

Para ti, casi nada, si tu empresa no opera en Quebec. Un servidor en Toronto está bajo PIPEDA; uno en Montreal está además bajo la ley de Quebec reformada por la Ley 25, y esa capa obliga sobre todo al proveedor. La diferencia práctica aparece si tus respaldos cruzan de una provincia a otra: el proveedor de Quebec te preguntará por ellos, porque su ley le exige una evaluación antes de comunicar datos fuera de la provincia.