Privacidad, OPSEC y soberanía personal | CypherpunkGuide on CypherpunkGuide

Tras comprar Bitcoin: verificación de autocustodia en 10 pasos (2026)

Mon, 27 Jul 2026 00:00:00 +0000

Una nota sobre la financiación: CypherpunkGuide no lleva publicidad de vigilancia. Nada de redes publicitarias, píxeles de seguimiento ni contenido patrocinado. Nos sostienen vías transparentes: hoy, las donaciones; más adelante, una suscripción y programas de afiliación compatibles con nuestra línea editorial. Respondemos ante nuestras lectoras y lectores, no ante los anunciantes.

El saldo de una plataforma de compraventa (exchange) no demuestra que el traspaso de custodia haya terminado. Lo que aparece en la pantalla del servicio es un registro interno del custodio; debes comprobar por separado que existe una salida en la cadena hacia una dirección que tu billetera reconoce. Una billetera no guarda monedas dentro del dispositivo: guarda las claves que autorizan transacciones. En la custodia de terceros, el proveedor controla el acceso a esas claves; en la autocustodia, lo controlas tú. Esta diferencia técnica no decide por sí sola quién es el propietario legal, algo que depende de las condiciones del proveedor y de la ley aplicable (boletín de la SEC para inversores, 2025).

El atajo peligroso consiste en ver una cifra y dar por hecho que todo salió bien. En nuestra prueba aislada con Bitcoin Core v31.1.0, tanto la billetera financiada como una billetera de solo lectura mostraron 0.01000000 BTC. La segunda tenía desactivadas las claves privadas, devolvió complete=false al intentar firmar una transacción de Bitcoin parcialmente firmada y rechazó un gasto directo con el error -4 de la interfaz RPC de Bitcoin Core. El saldo correcto probaba que podía observar los fondos, no que pudiera controlarlos.

La pregunta útil es otra: ¿qué pruebas demuestran que puedes recibir, firmar y recuperar sin fiarte de una pantalla tranquilizadora? Esta verificación de autocustodia en 10 pasos reúne esas evidencias. La autocustodia no elimina el riesgo; lo traslada a tus claves, dispositivos, copias de seguridad, decisiones y plan de emergencia.

Primer principio: la autocustodia traslada el riesgo
#

La autocustodia sustituye parte del riesgo del proveedor por responsabilidad directa. Reduce la dependencia de un exchange, pero puede convertir un secreto perdido, una copia dañada o una transacción precipitada en una pérdida permanente.

La SEC expone ambos lados: un custodio controla el acceso a las claves y puede fallar; quien se autocustodia asume la seguridad de esas claves. «Retíralo todo ahora» no es un consejo universal. Mueve únicamente lo que ya puedas proteger y recuperar.

Dónde aparece el saldo	Quién tiene el material de firma	Principal riesgo que conservas	Qué completa el traspaso
Cuenta de un exchange	El proveedor o su custodio	Fallo del proveedor, bloqueo de la cuenta, condiciones, seguridad y acceso a retiros	Recibir un retiro confirmado; el traspaso solo se completa al demostrar también Firma y Recuperación
Billetera en autocustodia	Tú o los firmantes definidos en tu política	Pérdida de secretos, dispositivo comprometido, copia defectuosa, coacción y error humano	Pruebas de Recepción, Firma y Recuperación
Billetera de solo lectura	Esa billetera no contiene material de firma	Falsa confianza porque el saldo está a la vista	Un firmante aparte debe completar un gasto autorizado

Un traspaso de custodia basado en pruebas termina cuando hay evidencia de Recepción, Firma y Recuperación. Eso no convierte la autocustodia en la mejor opción para todo el mundo. Si todavía no puedes proteger el material de recuperación, practica con una cantidad pequeña.

Recepción, Firma y Recuperación son pruebas distintas
#

La Recepción confirma que el bitcoin llegó a la billetera prevista. La Firma demuestra que la clave necesaria autoriza una transacción. La Recuperación prueba que una restauración independiente puede reconstruir ese control después de una pérdida.

Cada comprobación puede fallar aunque las otras funcionen. Una transacción confirmada puede convivir con una copia de seguridad incorrecta. Una billetera de solo lectura muestra transacciones sin tener una clave privada. Y una semilla puede restaurar una billetera vacía distinta si no coinciden la contraseña adicional (passphrase), el formato de la billetera, la cuenta, el tipo de dirección o la ruta de derivación.

Prueba	Pregunta que responde	Evidencia sólida	Lo que no la demuestra
Recepción	¿Llegó el retiro a la billetera prevista?	Coincidencia de la dirección completa, identificador de transacción, importe esperado y estado de confirmación adecuado	Solo el estado del exchange; revisar únicamente el principio y el final de una dirección copiada
Firma	¿Puede el firmante requerido autorizar exactamente ese gasto?	Una transacción pequeña firmada tras revisar destino, importe y comisión en una pantalla de confianza	Un saldo visible; un descriptor de solo lectura; `listunspent.spendable=true`
Recuperación	¿Puede reconstruirse la billetera después de una pérdida?	Una restauración aislada que encuentra los fondos previstos y firma un gasto pequeño	Un retiro de prueba; una copia de seguridad nunca comprobada; palabras semilla sin la receta completa de recuperación

Una billetera de solo lectura sigue transacciones, pero no contiene claves de firma. Una PSBT —transacción de Bitcoin parcialmente firmada— permite que una billetera prepare la transacción y que otro dispositivo la firme. Ni ver el saldo ni preparar la PSBT demuestra que exista autoridad de firma.

La verificación de autocustodia en 10 pasos
#

Sigue los pasos en orden y detente si algún resultado es ambiguo. No muevas el resto del saldo hasta poder explicar, con evidencias y sin recurrir a la cifra principal de la billetera, cómo superaste Recepción, Firma y Recuperación.

Paso 1: conserva la compra y protege la cuenta del exchange
#

Guarda el registro original de la compra: fecha, cantidad, valor en moneda fiat, comisiones e identificador de la orden. Añade después el registro del retiro y el identificador de la transacción, pero nunca archives con ellos una semilla, clave privada, PIN o passphrase. Mientras haya fondos en el exchange, usa una contraseña única o una clave de acceso (passkey), además de una autenticación multifactor sólida.

Las obligaciones fiscales cambian según el lugar. Conserva los registros y consulta a tu autoridad tributaria local o a un asesor de tu jurisdicción para saber qué datos y operaciones debes conservar o declarar; no copies la lista de otro país. Si hiciste una compra privada, consulta también nuestra guía para comprar bitcoin sin verificación de identidad KYC.

Paso 2: decide cuánta responsabilidad puedes asumir hoy
#

Empieza con una cantidad cuyo posible error de configuración no sea catastrófico. Una billetera de software favorece la comodidad; un firmante de hardware puede aislar las claves y ofrecer una pantalla independiente; una configuración multifirma puede añadir resiliencia, pero también nuevos modos de fallo. Ninguna opción es segura por defecto.

Enumera las amenazas que sí te afectan: malware, pérdida del dispositivo, incendio, acceso físico, coacción, incapacidad y muerte. Si alguien puede obligarte a desbloquear o firmar, revisa antes el modelo de amenazas para la custodia bajo coacción.

Paso 3: obtén la billetera de una fuente verificable
#

Usa el sitio o repositorio oficial del proyecto. Verifica la versión del software que descargues como indiquen sus instrucciones. Revisa el embalaje del hardware, inicializa tú el dispositivo y nunca aceptes palabras de recuperación ya escritas. Actualiza solo mediante el flujo autenticado del fabricante.

Comprueba el mantenimiento del proyecto, el formato de copia de seguridad, la verificación de direcciones y la documentación de recuperación. No buscas una marca concreta, sino un procedimiento que puedas verificar y repetir.

Paso 4: crea la billetera y anota la receta completa de recuperación
#

Genera el material de recuperación en la billetera o el dispositivo firmante previsto, sin conexión cuando así lo exija su procedimiento oficial. Nunca lo fotografíes, lo pegues en notas en la nube, lo envíes por chat ni lo introduzcas en un sitio web. Considera hostil cualquier petición de esas palabras, salvo que tú hayas iniciado de forma deliberada una recuperación oficial en un dispositivo de confianza.

No te limites a escribir «frase semilla». BIP39 transforma la combinación de la lista mnemónica —las palabras de recuperación— y la passphrase exacta en una semilla; cualquier passphrase produce una semilla válida, por lo que una errata puede abrir otra billetera. BIP380 advierte que una copia que solo guarda claves puede omitir el tipo de script y los datos de derivación. Anota la billetera y su versión, el estándar de copia, la cuenta, el tipo de script o dirección, la ruta de derivación de claves —cómo localiza la billetera sus claves— y si necesita una passphrase. Una semilla por sí sola no garantiza que puedas recuperar los fondos en otra billetera. Una clave pública extendida (xpub) o un descriptor público permite vigilar el historial, pero no firmar; compartirlo, además, expone tu privacidad financiera. Un descriptor privado es secreto.

Paso 5: comprueba la copia antes de confiarle el saldo completo
#

Utiliza la comprobación oficial del fabricante cuando exista. La verificación para Trezor Safe 3, por ejemplo, compara la copia introducida con el dispositivo. Demuestra que esas palabras coinciden con ese dispositivo; no demuestra la passphrase, la derivación ni que podrás gastar tras una restauración.

Nunca pruebes una copia real en un sitio web, un chat, un formulario de notas o un ordenador que no sea de confianza. Si no existe una comprobación segura, prepara una restauración aislada en hardware cuya compatibilidad conozcas. Una prueba preliminar detecta errores de transcripción; el paso 10 comprueba el recorrido completo.

Paso 6: genera una dirección nueva y verifica todos sus caracteres
#

Genera una dirección nueva de recepción de Bitcoin. Si el dispositivo tiene una pantalla independiente, compara todos sus caracteres con los que muestran la aplicación y el formulario del exchange; no revises solo los extremos. La explicación de Trezor sobre las direcciones documenta esta comprobación completa. La pantalla demuestra qué dirección generó el dispositivo, no que hayas elegido la red o el destinatario correctos.

Para esta prueba en la cadena, selecciona Bitcoin nativo únicamente cuando el emisor y la billetera receptora admitan la misma red de Bitcoin. Una red incompatible puede dejar los fondos inaccesibles; un sistema distinto elegido a propósito, como Lightning, requiere su propio flujo de recepción documentado. Reutilizar direcciones y consolidar después UTXO —salidas de transacción no gastadas, es decir, las fracciones que Bitcoin registra como disponibles para gastar— puede revelar vínculos. Consulta la privacidad de Bitcoin en la cadena y Silent Payments.

Paso 7: haz un retiro de prueba que limite el riesgo
#

Retira una cantidad superior al mínimo del exchange y lo bastante grande para seguir siendo útil después de las comisiones actuales y futuras. Antes de confirmar, vuelve a revisar la dirección completa. Guarda en privado el identificador del retiro, la comisión, la cantidad y el identificador de la transacción.

Este paso limita la pérdida provocada por un error de dirección, red o procedimiento, pero solo en ese recorrido de recepción. Las comisiones pueden volver poco práctico repetirlo. Que funcione no demuestra ni Firma ni Recuperación.

Paso 8: demuestra la Recepción
#

Espera un nivel de confirmación acorde con la cantidad y el riesgo. Compara el identificador de la transacción, el destino y la cantidad después de la comisión de retiro. La confirmación demuestra que la transacción entró en la cadena de bloques; no demuestra que la copia de seguridad pueda reconstruir el firmante.

Consultar tu propio nodo revela menos metadatos que usar un explorador público. Un explorador puede conocer la dirección y metadatos de tu conexión. No compartas capturas con saldos, etiquetas, direcciones ni identificadores de transacción.

Paso 9: demuestra la Firma con un gasto pequeño
#

Prepara otra transacción pequeña hacia una dirección nueva que controles. Si el firmante tiene una pantalla independiente, revisa allí el destino completo, la cantidad y la comisión. Si no la tiene, la verificación depende del ordenador o móvil que prepara la transacción; si ese equipo está comprometido, tampoco puedes confiar en la comprobación. Firma, difunde y confirma la transacción. Ten en cuenta la salida de cambio —el remanente que vuelve a tu billetera— y el efecto sobre la privacidad de combinar UTXO.

En nuestra prueba, la billetera de solo lectura preparó una PSBT, pero devolvió complete=false; el gasto directo falló con el error -4. Observar permite preparar una solicitud, mientras que la clave privada es lo que la autoriza. Esta comprobación demuestra la Firma actual, no la Recuperación después de una pérdida.

Paso 10: demuestra la Recuperación y completa el plan operativo
#

Restaura la billetera de forma independiente en un entorno aislado y de compatibilidad conocida. Comprueba la dirección o el descriptor esperado, localiza el UTXO financiado y firma una transacción pequeña después de revisar todas sus salidas. Hazlo antes de que falle el dispositivo. Usa un equipo de reserva fiable o un entorno sin conexión. Después de anotar un resultado que no contenga secretos, restablece el dispositivo temporal de restauración según su procedimiento documentado; nunca destruyas tu única copia válida.

Hicimos la copia de la billetera receptora antes de financiarla. La restauración encontró 0.01000000 BTC, firmó 0.00200000 BTC y alcanzó 1 confirmación. Por tanto, la copia regeneró las claves y la autoridad de firma que sometimos a prueba.

Define cada cuánto revisarás el plan, guarda las copias en dos lugares que no puedan fallar por la misma causa y deja instrucciones de emergencia. Mantén las indicaciones para localizar las copias separadas de los secretos de firma. Repite el ensayo después de cualquier cambio importante en la billetera o la passphrase. Para el saldo restante, genera otra dirección y repite la verificación completa; no reutilices una dirección solo porque superó la prueba.

Qué reveló nuestra prueba aislada con Bitcoin Core 31.1
#

Durante 202.22 segundos, nuestra prueba en regtest —la red local de pruebas de regresión de Bitcoin Core— separó la visibilidad del saldo de la capacidad de firmar y recuperar. No usamos bitcoin real, desactivamos las conexiones entre pares (P2P) y terminamos con networkactive=false y 0 conexiones.

Verificamos Bitcoin Core v31.1.0 con el SHA256 b80d9c3e04da78fb6f0569685673418cf686fadba9042d926d13fb87ff503f9e y la firma de Michael Ford (E777299FC265DD04793070EB944D35F9AC3DB76A). Los resultados y el script omiten claves, direcciones, transacciones, copias de seguridad, credenciales e identificadores del equipo. El script reúne la lógica de custodia en una ejecución nueva; el JSON conserva la versión verificada por separado y las dos etapas observadas de las que proceden estas mediciones. El script exige binarios ya verificados y no vuelve a comprobar el hash del archivo ni la firma.

Observación del laboratorio	Resultado medido	Conclusión segura
Saldo de la billetera receptora	0.01000000 BTC	La billetera financiada observó la salida confirmada
Saldo de solo lectura	0.01000000 BTC	El mismo saldo puede verse sin claves privadas
Pruebas de firma	`private_keys_enabled=false`; PSBT `complete=false`; gasto directo -4	Ver el saldo no equivale a tener autoridad para firmar
`listunspent.spendable`	`true`	No es una prueba: Core 31.1 documenta este campo obsoleto como siempre verdadero
Restauración de la copia anterior a la recepción	0.01000000 BTC recuperados; gasto de 0.00200000 BTC; 1 confirmación	La copia probada recuperó las claves necesarias para firmar

Esta prueba lógica en regtest no mide el rendimiento de la red principal (mainnet); 1 confirmación fue únicamente nuestra condición de finalización. La ayuda local de Bitcoin Core 31.1 describe listunspent.spendable como «(DEPRECATED) Always true», de modo que no sirve como criterio de firma. Nuestros archivos reproducibles documentan el comportamiento de v31.1; las referencias archivadas de Core 30 definen private_keys_enabled y los saldos de solo lectura, mientras que la incidencia #21104 recoge el contraejemplo de visibilidad. Por eso la prueba de Firma de este artículo exige un gasto realmente firmado, no el nombre de un campo.

En conclusión: termina el traspaso antes de mover el saldo
#

Protege el registro del exchange, elige un alcance de custodia que puedas manejar y envía una cantidad de prueba a una dirección revisada por completo. Después demuestra por separado Recepción, Firma y Recuperación.

Si una prueba falla, detente. Un retiro confirmado demuestra recepción, no recuperación. La semilla no basta si faltan el formato, la configuración o la passphrase correctos. Mueve el saldo solo cuando hayas probado las nuevas responsabilidades.

Preguntas frecuentes
#

Las respuestas breves mantienen el mismo límite: la autocustodia cambia quién asume el riesgo, un retiro de prueba solo demuestra Recepción y la Recuperación exige la receta completa de esa billetera.

¿Debo retirar el bitcoin de un exchange de inmediato?
#

No necesariamente. La custodia del exchange implica riesgo del proveedor y de la cuenta; una autocustodia precipitada implica riesgo para las claves y las copias. Protege la cuenta y empieza con una cantidad de prueba. Auméntala solo después de superar Recepción, Firma y Recuperación.

¿Necesito una billetera de hardware?
#

No en todos los casos. Una billetera de software con mantenimiento activo puede servir para un saldo pequeño de uso cotidiano. Un firmante de hardware reduce algunos ataques en línea y añade una pantalla independiente, pero no corrige una copia defectuosa, ni evita la coacción ni revisa la transacción por ti.

¿Un retiro de prueba correcto demuestra la autocustodia?
#

Demuestra la Recepción si coinciden la dirección completa, la transacción, la cantidad y la confirmación. Una billetera de solo lectura puede mostrar ese saldo sin Firma, y una copia incompleta o incompatible puede fallar en la Recuperación. Supera las tres pruebas.

¿Puede cualquier billetera recuperar mi bitcoin con la frase semilla?
#

No. La recuperación depende del estándar, la passphrase exacta, la derivación, la cuenta, el tipo de script y la implementación. Sigue la compatibilidad documentada o el procedimiento oficial de la billetera original. Nunca introduzcas palabras semilla reales en un sitio web.

¿Qué registros fiscales debo guardar después de comprar bitcoin?
#

Conserva los registros de compra y retiro, y sigue los requisitos vigentes de tu autoridad tributaria local o de un asesor de tu jurisdicción. No trates una lista de Estados Unidos o de internet como una norma universal. Este artículo no clasifica hechos imponibles ni ofrece asesoramiento fiscal personal.

Cora Aegis

Cora Aegis es el seudónimo detrás de CypherpunkGuide. Escribe guías con la privacidad como eje, basadas en fuentes primarias y pruebas reproducibles.

Más sobre Cora →

Fuentes primarias y archivos
#

Estas fuentes primarias u oficiales respaldan las afirmaciones críticas para la seguridad. Cada par de URL original y archivada tiene una marca temporal exacta; además, comprobamos que cada captura archivada corresponde a la fuente original.

#	Fuente	URL original	Archivado
1	SEC, «Conceptos básicos de la custodia de criptoactivos para inversores minoristas» (2025)	https://www.investor.gov/introduction-investing/general-resources/news-alerts/alerts-bulletins/investor-bulletins/crypto-asset-custody-basics-retail-investors-investor-bulletin-0	https://web.archive.org/web/20260718185151/https://www.investor.gov/introduction-investing/general-resources/news-alerts/alerts-bulletins/investor-bulletins/crypto-asset-custody-basics-retail-investors-investor-bulletin-0
2	Bitcoin Core 30, `getwalletinfo`	https://bitcoincore.org/en/doc/30.0.0/rpc/wallet/getwalletinfo/	https://web.archive.org/web/20260217150325/https://bitcoincore.org/en/doc/30.0.0/rpc/wallet/getwalletinfo/
3	Bitcoin Core 30, `getbalances`	https://bitcoincore.org/en/doc/30.0.0/rpc/wallet/getbalances/	https://web.archive.org/web/20260509142424/https://bitcoincore.org/en/doc/30.0.0/rpc/wallet/getbalances/
4	Incidencia #21104 de Bitcoin Core, clasificación del saldo de solo lectura	https://github.com/bitcoin/bitcoin/issues/21104	https://web.archive.org/web/20221205111908/https://github.com/bitcoin/bitcoin/issues/21104
5	BIP32, billeteras deterministas jerárquicas	https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki	https://web.archive.org/web/20260711030310/https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
6	BIP39, código mnemónico para claves deterministas	https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki	https://web.archive.org/web/20260711080112/https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
7	BIP380, descriptores de scripts de salida	https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki	https://web.archive.org/web/20260705135907/https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki
8	Trezor, direcciones de billetera y verificación de todos los caracteres	https://trezor.io/learn/basics/where-are-my-coins-stored-how-bitcoin-wallets-actually-work	https://web.archive.org/web/20260519102414/https://trezor.io/learn/basics/where-are-my-coins-stored-how-bitcoin-wallets-actually-work
9	Trezor, elegir una red para retirar	https://trezor.io/guides/sending-receiving-staking-funds/moving-funds-from-exchanges/how-to-choose-the-right-network-when-withdrawing-from-or-sending-to-trezor	https://web.archive.org/web/20260215225443/https://trezor.io/guides/sending-receiving-staking-funds/moving-funds-from-exchanges/how-to-choose-the-right-network-when-withdrawing-from-or-sending-to-trezor
10	Trezor Safe 3, comprobar la copia de seguridad de la billetera	https://trezor.io/guides/backups-recovery/general-standards/check-backup-on-trezor-safe-3	https://web.archive.org/web/20260207110415/https://trezor.io/guides/backups-recovery/general-standards/check-backup-on-trezor-safe-3
11	Trezor, comportamiento de la passphrase	https://trezor.io/guides/backups-recovery/advanced-wallets/what-is-a-passphrase	https://web.archive.org/web/20260312222704/https://trezor.io/guides/backups-recovery/advanced-wallets/what-is-a-passphrase

Recuperar una contraseña de Bitcoin: qué puede y qué no puede hacer la IA (2026)

Sun, 23 Aug 2026 00:00:00 +0000

«Perdí mi contraseña de Bitcoin» puede describir problemas muy distintos: el acceso a una cuenta con custodio, la contraseña de un archivo de billetera cifrado, una passphrase BIP39, palabras de recuperación incompletas o una copia de seguridad que ya no aparece. Bitcoin Core no puede restablecer ni revelar la passphrase olvidada de una billetera. Eso no impide que una herramienta sin conexión compruebe un conjunto pequeño de posibilidades delimitado por lo que recuerdas (Bitcoin Core, gestión de la billetera).

La promesa peligrosa es que la «recuperación con IA» cambia la criptografía. No la cambia. Ejecutamos 11 pruebas sintéticas de generación de candidatos con BTCRecover, sin billetera, semilla, clave, dirección, hash, fondos ni contraseña real. Al añadir estructura recordada, una búsqueda ficticia pasó de 2.080 candidatos a 16 sin perder el objetivo. En otra prueba, ampliar cinco clases de erratas de un cambio posible a dos hizo crecer el conjunto de 60 a 1.681 candidatos.

Por tanto, la pregunta útil no es «¿qué IA puede descifrar mi billetera?», sino esta: ¿qué tipo de fallo tienes, qué evidencia no secreta puede acotarlo y dónde existirá el conjunto completo de desbloqueo? Ese conjunto combina la billetera cifrada o la semilla con suficiente material real de candidatos para abrirla. Mantén ambas partes separadas hasta la comprobación sin conexión.

¿Se puede recuperar una contraseña perdida de Bitcoin?
#

Recuperar una contraseña de Bitcoin significa probar candidatos contra la billetera cifrada correcta, no restablecerla. Puede funcionar cuando tus recuerdos acotan las posibilidades; no puede reconstruir desde la nada una clave ausente ni un secreto aleatorio.

Empieza por identificar qué capa de acceso falló. Si nombras mal el problema, elegirás la herramienta equivocada y quizá acabes ante una estafa.

Un mnemónico es la copia ordenada de palabras de recuperación. La semilla es el secreto raíz derivado de esa copia, a veces junto con una passphrase; después, el software de la billetera deriva de ella las claves privadas que autorizan los gastos.

Qué perdiste	Qué controla	Primer camino correcto	Qué no debes hacer
Acceso a un exchange o aplicación con custodio	La entrada a una cuenta de un proveedor	Usa el proceso oficial de recuperación de la cuenta	No descargues un programa que prometa «forzar» billeteras ni entregues el acceso de la cuenta a un desconocido
Contraseña de un archivo de billetera cifrado	El descifrado de claves privadas guardadas en local	Conserva el archivo, identifica su formato exacto y prueba candidatos recordados sobre una copia	No sobrescribas el original ni lo subas junto con posibles contraseñas
Passphrase BIP39	La derivación de otra semilla a partir del mismo mnemónico	Trabaja sin conexión con el mnemónico exacto y una dirección conocida o una clave pública extendida: un identificador público que no puede gastar, aunque puede exponer el historial de direcciones	No esperes un aviso de «passphrase incorrecta»: todas derivan una semilla
Palabras mnemónicas ausentes o mal escritas	La reconstrucción de la copia de la semilla	Sigue el procedimiento específico de esa billetera con un objetivo conocido	No pegues las palabras en un sitio web ni en una IA alojada en la nube
Archivo de billetera ausente	La ubicación del material de claves cifrado	Busca en dispositivos y copias antiguas sin modificar los originales	No supongas que adivinar una contraseña sustituye un archivo que ya no existe
Bitcoin robado o enviado a una estafa	El control ya pasó a otra clave	Informa cuanto antes al exchange pertinente, a las autoridades y a un asesor local	No confundas el rastreo o la vía legal con recuperar una contraseña olvidada

Una passphrase BIP39 es el texto opcional que se combina con un mnemónico para derivar la semilla de una billetera. Según BIP39, cualquier passphrase genera una semilla válida. Por eso una errata puede abrir otra billetera vacía en vez de mostrar un error. Validarla no es lo mismo que desbloquear un archivo wallet.dat cifrado.

Si todavía no tienes una copia independiente cuya recuperación hayas demostrado, nuestra verificación de autocustodia en 10 pasos explica cómo evitar que este fallo vuelva a ocurrir.

Qué hizo la IA en una recuperación publicada en 2026
#

Un caso de 2026 presentado como «la IA descifró una billetera Bitcoin» fue, en realidad, una búsqueda de archivos, no una ruptura del cifrado. CoinDesk informó de que Claude ayudó a localizar una copia antigua; después, su dueño la descifró con una contraseña que ya tenía apuntada.

Las acciones decisivas fueron encontrar la copia anterior y usar aquella contraseña existente. En otros casos, una IA puede comparar metadatos no secretos de archivos o convertir recuerdos abstractos en una plantilla. El software de la billetera sigue siendo quien decide si un candidato abre las claves correctas.

Una passwordlist (lista de contraseñas) contiene un intento completo por línea. Una tokenlist (lista de fragmentos) contiene partes recordadas que BTCRecover combina para formar candidatos completos.

La IA puede ayudar a	La IA no puede demostrar	Evidencia más segura
Clasificar un formato de billetera a partir de metadatos no secretos	Que la billetera te pertenece	Registros de procedencia e inspección sin conexión del soporte original
Convertir patrones recordados en la plantilla de una passwordlist o tokenlist	Que la contraseña verdadera esté en la lista	Una vista previa `--listpass`, que no usa billetera, y el recuento obtenido en la máquina sin conexión
Localizar copias probables por nombre, fecha y tamaño	Que un archivo contenga las claves buscadas	Análisis específico del formato y una dirección u objetivo público conocido
Explicar opciones de las herramientas oficiales	Que una orden generada sea segura para tu billetera concreta	Documentación oficial de la misma versión y una copia de prueba desechable
Diagnosticar una ejecución fallida a partir de errores censurados	El secreto ausente	Una comprobación satisfactoria con software fijo y después un gasto controlado

El caso sirve para entender el papel más útil de la IA: recuperar contexto. No ofrece una tasa de éxito, un benchmark reproducible ni permiso para subir un ordenador antiguo a un modelo en la nube. Un disco viejo puede contener documentos fiscales y de identidad, perfiles del navegador, otras billeteras y restos de contraseñas. No subas el disco ni el material real de recuperación. Limítate a patrones abstractos y marcadores ficticios, siguiendo la separación de datos de nuestra auditoría de privacidad para asistentes de IA.

La IA diseña los candidatos; el software los comprueba
#

En una recuperación asistida por IA, el modelo planifica alrededor de un comprobador de contraseñas fijo. Puede ordenar los intentos, pero BTCRecover o Hashcat sigue siendo quien determina si alguno descifra la billetera.

Un comprobador determinista es un programa que devuelve siempre el mismo resultado de validación para la misma billetera y el mismo candidato. Llamar «IA» a la capa que planifica no reduce por arte de magia un espacio ilimitado de contraseñas aleatorias.

En un benchmark publicado el 4 de julio de 2026, con 30 segundos por prueba, BTCRecover 1.13.0 sobre Windows 11, con un Ryzen 9 9950X y una RTX 5090, alcanzó 3.209,22 contraseñas por segundo en su muestra Bitcoin Core SQLite y 11.948,17 en la muestra Berkeley DB (BDB) (JSON de resultados). Bitcoin Core ajusta el trabajo de derivación de claves al cifrar una billetera; por eso, las iteraciones y velocidades de esas muestras no son constantes del motor de almacenamiento ni tasas universales de Core (código fuente de Core).

La escala, con todo, ayuda a poner límites. A las 3.209,22 pruebas por segundo de esa muestra, recorrer todas las cadenas de diez letras minúsculas —26^10, es decir, 141.167.095.653.376 candidatos— llevaría unos 1.393,9 años. Si el objetivo estuviera distribuido de manera uniforme, el promedio sería de aproximadamente 697,0 años. Es una ilustración basada en una muestra, no un modelo de los hábitos humanos al crear contraseñas.

BTCRecover también publica una evaluación de habilidades de IA. Sus porcentajes son puntuaciones máximas según una rúbrica de comportamiento durante el proceso, no el porcentaje de billeteras recuperadas. Calculamos las diferencias por pares a partir de las tablas oficiales de chat y Docker: cinco de los seis modelos obtuvieron en Docker/herramientas una puntuación inferior a la de chat, y la variación mediana fue de -3,7 puntos porcentuales.

Modelo en la tabla de BTCRecover	Puntuación en chat	Puntuación con Docker/herramientas	Cambio
qwen3.6-27b	70,9%	58,4%	-12,5 puntos
gemma-4-31b	67,5%	65,0%	-2,5 puntos
gemma-4-26b-a4b	57,6%	39,9%	-17,7 puntos
gemma-4-12b	54,2%	51,7%	-2,5 puntos
qwen3.5-9b	52,4%	47,5%	-4,9 puntos
gemma-4-e4b	30,8%	33,4%	+2,6 puntos

La evaluación no demuestra que las herramientas empeoren los modelos en general ni explica por qué bajaron cinco resultados. El modo chat da consejos sin herramientas; el modo Docker permite al modelo evaluado ejecutar órdenes en un entorno aislado y aplica instrucciones de puntuación propias del evaluador. Las tablas comparan conductas observables diferentes, no un efecto causal controlado del acceso a herramientas. El proceso de IA de BTCRecover intenta acotar ese trabajo.

Qué encontramos en nuestro laboratorio sintético de 11 ejecuciones
#

El laboratorio de espacio de candidatos de Cora mide cómo cambia el número de intentos al añadir estructura recordada. Solo utiliza datos ficticios: no abre ninguna billetera ni predice probabilidades de recuperación.

Clonamos BTCRecover desde su origen oficial en el commit 1457088acf17630eb12a5b53989982ac34e55f2a, registramos el árbol del repositorio, comprobamos que no hubiera cambios en los archivos bajo control de versiones y calculamos el hash tanto del punto de entrada como del script del laboratorio. Después usamos la versión 1.13.0-Cryptoguide con Python 3.12.10 para ejecutar 11 situaciones con --listpass. Todas conservaron su objetivo ficticio y ninguna produjo candidatos duplicados dentro de su propia ejecución.

Mantuvimos cuatro familias de fragmentos: dos variantes en cada una de dos familias de palabras, dos años y dos símbolos. A continuación añadimos una restricción cada vez:

Diseño del conjunto de candidatos	Candidatos únicos	¿Conservó el objetivo ficticio?	Cambio frente al conjunto sin estructura
Ocho fragmentos relacionados, cada uno en su propia línea	2.080	Sí	Punto de partida
Variantes de una misma familia marcadas como incompatibles entre sí	632	Sí	69,62% menos
Las cuatro familias de fragmentos pasan a ser obligatorias	384	Sí	81,54% menos
Fragmentos obligatorios y fijados en las posiciones recordadas	16	Sí	99,2308% menos

El conjunto final, ya estructurado, tenía 1/130 del tamaño del inicial. Eso no significa que todos los recuerdos sean correctos. Significa que el trabajo más valioso suele consistir en separar lo que realmente sabes de lo que solo esperas que sea cierto.

También partimos de una contraseña ficticia completa y fija de 16 caracteres. Cuatro búsquedas centradas en un solo error generaron apenas entre 12 y 17 candidatos. Activar a la vez cinco clases de erratas produjo 60 candidatos con un cambio posible y 1.681 con dos: un conjunto 28,02 veces mayor.

El resultado respalda un proceso por etapas: primero las contraseñas completas exactas; después, una clase de error verosímil; por último, combinaciones más amplias. Un modelo puede ayudar a expresar ese plan, pero no debe inventar palabras biográficas, fechas o patrones y presentarlos como si fueran recuerdos.

Puedes revisar el JSON de resultados sin datos sensibles y volver a ejecutar el laboratorio de candidatos sobre el checkout fijado de BTCRecover. Ambos archivos contienen únicamente cadenas sintéticas y fijas. La opción del script que suprime advertencias se limita a enumeraciones sin billetera; no la copies en un proceso de recuperación real.

BTCRecover, Hashcat, IA local o servicio de recuperación
#

El método adecuado debe corresponder al formato de la billetera y exponer la menor cantidad posible de material secreto. BTCRecover y Hashcat comprueban candidatos; la IA ayuda a ordenar el plan; un servicio externo te obliga además a decidir cuánto confías en él.

En Hashcat, un modo elige el validador para un formato concreto de billetera o hash almacenado. No elige la contraseña verdadera.

Método	Cuándo encaja mejor	Ventaja principal	Límite principal	Datos secretos expuestos
Passwordlist de BTCRecover	Tienes varias contraseñas completas posibles	Prueba cada línea sin modificarla y permite añadir después clases de erratas prudentes	Las líneas se prueban como contraseñas completas; no se combinan entre sí como fragmentos	Mantén la billetera o el extracto reducido documentado separado hasta la ejecución sin conexión; un extracto aún puede exponer datos identificativos o correlacionables
Tokenlist de BTCRecover	Recuerdas fragmentos, variantes y posiciones	La exclusión mutua, los fragmentos obligatorios, las anclas y los comodines codifican tus recuerdos	Una estructura equivocada puede excluir el candidato verdadero o disparar el número de combinaciones	Diseña en línea una plantilla con marcadores ficticios; si la billetera correspondiente está presente, sustituye los fragmentos reales solo cuando te desconectes
Hashcat	Tienes un modo compatible verificado y máscaras —patrones de caracteres— o reglas —cambios en candidatos—	Motor maduro orientado a GPU y matriz explícita de modos	La existencia de un modo no garantiza la recuperación; extraer datos y diseñar reglas depende del formato	Sigue la documentación oficial del modo exacto y no subas nunca el conjunto completo de desbloqueo
Agente de IA local	Clasificar el fallo, buscar archivos, construir plantillas y revisar órdenes	Puede trabajar con archivos locales y adaptar el procedimiento	«Local» no significa automáticamente sin conexión, sin registros ni seguro	Comprueba la red, dónde se ejecuta el modelo, los registros, las extensiones y el directorio de trabajo
IA alojada en la nube	Explicaciones no secretas y planificación con marcadores ficticios	Accesible y útil para preguntas concretas sobre documentación	El proveedor recibe prompts, adjuntos, metadatos de cuenta y red, y quizá conserve datos	Dale solo patrones abstractos y marcadores ficticios: nunca una billetera real, semilla, clave, contraseña ni ninguna cadena real de candidato
Servicio humano de recuperación	Casos valiosos y técnicamente difíciles, después de investigar al proveedor	Conocimiento especializado de formatos y equipo adecuado	Fraude, métodos opacos, conflictos por honorarios, exposición de identidad y robo de claves	Prefiere un extracto reducido y documentado, o conserva bajo tu control una de las dos partes indispensables; incluso un extracto que no permita gastar puede afectar a tu privacidad

La página oficial de hashes de ejemplo de Hashcat enumera modos para wallet.dat de Bitcoin Core/Litecoin, Electrum, Blockchain.com/My Wallet, Bisq y otros formatos. Esa lista demuestra que existen validadores. No demuestra que tu copia esté intacta, que la contraseña sea adivinable ni que el modo elegido corresponda al archivo.

Protocolo de recuperación sin conexión en siete pasos
#

Un protocolo que prioriza el trabajo sin conexión mantiene separados la billetera y los candidatos reales hasta que una máquina desconectada los comprueba. Desconectarte al final no borra lo que antes entregaste a la nube.

Deja de modificar el original. Conserva el dispositivo antiguo y, cuando sea posible, crea una copia bit a bit o mediante una herramienta que documente el proceso. Anota el hash criptográfico —la huella digital— de cada archivo para detectar cambios. No repares, migres ni importes en el mismo sitio tu único archivo de billetera.
Clasifica el fallo antes de escoger el programa. Registra solo datos no secretos: producto y versión aproximada de la billetera, sistema operativo, nombre y tamaño del archivo, periodo de creación, si tienes mnemónico y el error exacto. No anotes la semilla, la passphrase, la clave privada ni los candidatos en la misma nota conectada.
Demuestra que tienes autorización y fija un objetivo. Trabaja únicamente con una billetera propia o que estés legalmente autorizado a recuperar. Conserva sin conexión un registro mínimo de propiedad, autorización y procedencia del archivo, sin incluir secretos. Para buscar una semilla o passphrase BIP39, identifica las reglas documentadas de cuenta y ruta que derivan las direcciones, además de un objetivo público conocido, sin publicar todo tu historial.
Obtén y verifica la herramienta mientras estés conectado. Empieza en el repositorio oficial del proyecto mantenido. Fija el commit, comprueba que los archivos bajo control de versiones y el árbol del repositorio coincidan con él, y usa la verificación de la versión firmada cuando el proyecto la documente. Prueba la instalación con ejemplos sintéticos incluidos, no con tu billetera.
Diseña las etapas de candidatos más pequeñas que reflejen tus recuerdos. Pon las contraseñas completas en una passwordlist y los fragmentos combinables en una tokenlist. Empieza por intentos exactos; continúa con una sola incertidumbre recordada y deja las erratas o comodines más amplios para el final. Si la billetera o la semilla correspondiente está en esa máquina, usa marcadores ficticios en cualquier tarea en línea.
Reúne el conjunto de desbloqueo solo sin conexión. Desconecta la máquina de recuperación antes de que contenga a la vez la billetera cifrada y los candidatos reales. Comprueba que el número de candidatos sea razonable antes de una ejecución larga. BTCRecover documenta extractos reducidos para ciertos formatos; usa uno solo si la documentación oficial vigente afirma que no puede gastar por sí mismo y sigue tratándolo como dato privado que permite correlaciones.
Si consigues abrirla, migra. Prepara y verifica una billetera nueva en un equipo de confianza; después mueve los fondos, revisando destino y comisión. Conserva una nota de auditoría sin secretos, no la contraseña recuperada ni las claves privadas. Sigue nuestra auditoría para migrar de gestor de contraseñas si también debes cambiar credenciales relacionadas.

No combines «dejaré que el modelo en la nube inspeccione todo» con «me desconectaré antes de ejecutar la orden final». Para entonces la revelación ya se habrá producido. Una IA alojada solo debe recibir estructura abstracta y marcadores inventados: ni siquiera una lista de candidatos reales aunque no incluyas la billetera. Antes de considerar local a un agente, usa la guía para crear un modelo de amenazas en la era de la IA y revisa alojamiento, registros, extensiones, carpetas sincronizadas e identidad de la cuenta.

Cómo evaluar un servicio de recuperación sin entregar la billetera
#

Evaluar un servicio de recuperación equivale a auditar quién custodiará tus secretos. No importa tanto lo convincente que resulte un caso de éxito como si el proveedor puede hacer trabajo útil sin recibir todas las piezas necesarias para abrir la billetera y mover los fondos.

La advertencia del FBI se centra sobre todo en empresas que prometen recuperar criptomonedas perdidas por fraude de inversión. La guía de la FTC sobre fraudes de recuperación también alerta sobre el contacto no solicitado, los pagos por adelantado, las garantías y las peticiones de información financiera. Ninguna de esas fuentes demuestra que todos los especialistas en contraseñas olvidadas sean fraudulentos; sus señales de peligro sí deben formar parte de tu revisión.

Formula por escrito estas preguntas:

¿Qué formatos y versiones exactas de billetera admiten, y cómo comprueban que hay compatibilidad antes de recibir material secreto?
¿Pueden trabajar con un extracto documentado que no permita gastar por sí solo, y qué datos identificativos o correlacionables sigue revelando? Si no, ¿puedo conservar yo una parte indispensable del conjunto de desbloqueo?
¿Entrará algún archivo de billetera, lista de candidatos, clave, registro o copia de seguridad en almacenamiento en la nube, software de soporte remoto, sistemas de subcontratistas o un proveedor de IA?
¿Cómo calculan los honorarios, qué se paga antes de obtener un resultado y qué define el contrato como «éxito»?
¿Quién controla las claves recuperadas antes de mover los fondos, y puedo dirigir la primera transferencia a una billetera nueva que yo haya preparado?
¿Qué condiciones de borrado, conservación, respuesta a incidentes y responsabilidad figuran por escrito?
¿Pueden demostrar una identidad jurídica estable, un método técnico y una trayectoria independiente sin apoyarse solo en testimonios?

Rechaza las garantías que ignoran el estado de la billetera y la imprevisibilidad de la contraseña. Considera señales de alto riesgo el contacto no solicitado, las prisas, la exigencia de acceso remoto y la petición simultánea de la billetera y su posible contraseña. Ni siquiera un proveedor competente puede recuperar un secreto situado fuera de cualquier espacio de búsqueda viable.

En conclusión: decide por el tipo de fallo y por qué secretos expones
#

Elige primero por el tipo de fallo y después por el límite de exposición. Para una cuenta con custodio, usa la recuperación del proveedor; para una billetera local, un comprobador compatible con su formato; para la IA, reserva únicamente la planificación no secreta.

BTCRecover encaja cuando admite el formato y tus recuerdos pueden expresarse como contraseñas completas o fragmentos. Hashcat puede tener sentido si ya verificaste un modo compatible y entiendes qué contiene el dato extraído. La validación combinada debe permanecer sin conexión.

Si no puedes identificar la billetera, conserva el soporte y busca copias antes de adivinar. Si un modelo alojado recibiría material real de la billetera o cadenas reales de candidatos, detente. Si un servicio recibiría todas las piezas indispensables, trátalo como custodia total de las claves y rediseña el proceso o acepta el riesgo de forma explícita. Una contraseña verdaderamente aleatoria, sin ninguna restricción útil, puede seguir siendo inviable por mucha IA o capacidad de cálculo que emplees.

Puntos clave

Clasifica antes de actuar: el acceso a una cuenta con custodio, la contraseña de un archivo, una passphrase BIP39, un mnemónico incompleto y una copia ausente requieren caminos distintos.
La IA no abre un atajo: puede recuperar contexto y diseñar candidatos; el software determinista debe validarlos, y un secreto fuerte sin límites sigue siendo inviable.
Estructura medida: nuestro laboratorio sintético de 11 ejecuciones redujo 2.080 candidatos a 16, un 99,2308%, sin perder el objetivo ficticio.
El coste de ampliar: cinco clases de erratas produjeron 60 candidatos con un cambio y 1.681 con dos: 28,02 veces más para la misma contraseña ficticia de partida.
Límite de exposición: un agente alojado solo recibe patrones abstractos y marcadores ficticios; la billetera o semilla real y los candidatos reales solo se reúnen sin conexión.

Preguntas frecuentes
#

La IA solo ayuda si tus recuerdos mantienen finito el espacio de candidatos. BTCRecover no puede restablecer una billetera, las passphrases BIP39 requieren un objetivo conocido y cualquier desbloqueo satisfactorio debe terminar en una billetera nueva.

¿Puede la IA recuperar la contraseña olvidada de una billetera Bitcoin?
#

A veces puede ayudarte a reconstruir el contexto necesario para que la búsqueda sea viable: ubicaciones de archivos antiguos, estructura de la contraseña, hábitos al cometer erratas y opciones correctas de la herramienta. No puede deducir de la billetera una contraseña aleatoria difícil de adivinar ni saltarse el cifrado. Un programa fijo aún debe comprobar un candidato que sea realmente correcto.

¿Puede BTCRecover probar por fuerza bruta cualquier contraseña de Bitcoin?
#

No. BTCRecover admite muchos formatos y genera candidatos con eficiencia, pero el resultado depende de tener el material correcto, un formato compatible, un objetivo válido y un espacio de búsqueda lo bastante pequeño para terminar. Que exista la herramienta no garantiza la recuperación.

¿Una passphrase BIP39 es lo mismo que la contraseña de una billetera?
#

No. Una contraseña suele descifrar material de claves almacenado. Una passphrase BIP39 se combina con el mnemónico para derivar una semilla; todas las passphrases producen una semilla válida, pero normalmente corresponden a otra billetera. La recuperación exige el mnemónico exacto y un objetivo conocido, todo tratado sin conexión.

¿Es seguro entregar mi archivo `wallet.dat` a un servicio de recuperación?
#

Un archivo cifrado sigue siendo sensible. Bitcoin Core documenta que su cifrado protege las claves privadas, no todos los campos de la base de datos; la información sobre transacciones continúa visible. Prefiere un extracto reducido solo cuando la documentación oficial confirme que no puede gastar por sí mismo, y trátalo como información privada. Si el proveedor exige el conjunto completo de desbloqueo, considéralo custodia total de las claves.

¿Qué debo hacer justo después de recuperar el acceso?
#

Prepara y verifica una billetera nueva en un equipo de confianza; después mueve los fondos, comprobando destino y comisión. Da por hecho que los ordenadores antiguos, las listas de candidatos, los registros y cualquier tercero implicado ampliaron la exposición. No sigas usando la configuración recuperada solo porque se abrió una vez.

Cora Aegis

Cora Aegis es el seudónimo detrás de CypherpunkGuide. Escribe guías de autocustodia con la privacidad como eje, basadas en fuentes primarias y pruebas sintéticas reproducibles.

Más sobre Cora →

Fuentes y copias archivadas
#

Las afirmaciones se apoyan en documentación oficial de software, especificaciones, advertencias públicas sobre el fraude y un reportaje citado solo para un caso concreto. Todos los originales estaban disponibles el 21 o el 23 de agosto de 2026; el 23 de agosto comprobamos que las doce reproducciones exactas de Wayback indicadas abajo devolvían HTTP 200.

#	Fuente	URL original	Copia archivada
1	Bitcoin Core, «Managing the Wallet»	https://github.com/bitcoin/bitcoin/blob/bf8402c8803f085a50df96cb7956033cd252e9ab/doc/managing-wallets.md	Wayback
2	Repositorio y README de BTCRecover	https://github.com/3rdIteration/btcrecover/tree/1457088acf17630eb12a5b53989982ac34e55f2a	Wayback
3	Guía rápida de recuperación de contraseñas de BTCRecover	https://github.com/3rdIteration/btcrecover/blob/1457088acf17630eb12a5b53989982ac34e55f2a/docs/TUTORIAL.md	Wayback
4	Recuperación asistida por IA de BTCRecover	https://github.com/3rdIteration/btcrecover/blob/1457088acf17630eb12a5b53989982ac34e55f2a/docs/AI_Assisted_Recovery.md	Wayback
5	`SKILL.md` de BTCRecover	https://github.com/3rdIteration/btcrecover/blob/1457088acf17630eb12a5b53989982ac34e55f2a/SKILL.md	Wayback
6	Benchmarks de rendimiento y resultado sin procesar de BTCRecover	https://github.com/3rdIteration/btcrecover/blob/1457088acf17630eb12a5b53989982ac34e55f2a/benchmark-results/benchmark_9e6d7d9006b08e8e_20260704_154622.json	Wayback
7	Hashes de ejemplo y modos de billetera de Hashcat	https://hashcat.net/wiki/doku.php?id=example_hashes	Wayback
8	BIP39, código mnemónico para generar claves deterministas	https://github.com/bitcoin/bips/blob/7fe0b034ec967b52a5a28276419117326df93263/bip-0039.mediawiki	Wayback
9	FBI/IC3, advertencia sobre servicios de recuperación de criptomonedas	https://www.ic3.gov/PSA/2023/psa230811	Wayback
10	FTC, fraudes de reembolso y recuperación	https://consumer.ftc.gov/articles/refund-and-recovery-scams	Wayback
11	CoinDesk, recuperación de una billetera con ayuda de Claude en 2026	https://www.coindesk.com/tech/2026/05/14/claude-helps-recover-usd395-000-in-bitcoin-trapped-on-a-computer-for-years	Wayback
12	Código de cifrado de billeteras de Bitcoin Core	https://github.com/bitcoin/bitcoin/blob/bf8402c8803f085a50df96cb7956033cd252e9ab/src/wallet/wallet.cpp	Wayback

Metodología — cómo KYC Drift registra las declaraciones de la IA alojada

Tue, 14 Jul 2026 00:00:00 +0000

Estado del piloto: Piloto con evidencias: 44 hechos vigentes sobre 8 servicios; 44 son declaraciones del proveedor y 0 observaciones de interfaz. 45 de 136 celdas servicio-dimensión contienen al menos un registro vigente con ámbito definido; no es una cobertura completa de todas las regiones, planes o plataformas.

Divulgaciones: naturaleza de esta página · afiliaciones · correcciones

Esta página es un registro factual — no es consejo, ni recomendación, ni invitación, ni aval. La inclusión no es aprobación. Las políticas cambian; consulta los documentos primarios del proveedor antes de apoyarte en cualquier valor.
Actualmente no tenemos ninguna relación de afiliación con los servicios listados. Si eso cambiara, lo divulgaríamos en el propio texto, no afectaría a qué se lista ni en qué orden, y el cambio quedaría registrado aquí.
¿Eres un proveedor listado y crees que un valor es erróneo? Si nuestra revisión confirma el error, lo corregimos y publicamos la corrección — escribe a editor@cypherpunkguide.com
Cómo se recogen y comprueban estos datos (metodología)

Estado del piloto
#

Esta versión es un piloto con respaldo documental, no una auditoría completa del mercado. Reúne 44 observaciones sobre ocho servicios de IA alojada. Las 44 son declaraciones de los proveedores y ninguna procede de observar directamente la interfaz. El marco define 17 dimensiones, que dan 136 campos posibles al cruzarlas con los servicios. De ellos, 45 contienen al menos un registro actual con alcance definido; 91 no contienen ninguno. Son cifras del inventario, no un porcentaje de exhaustividad ni una afirmación de haber estudiado todos los supuestos.

Qué registra el conjunto de datos
#

La unidad básica es una observación individual de un hecho sobre un servicio, un atributo, una etapa del ciclo de vida y un ámbito de aplicación. Las etapas son registro, uso continuado, pago, recuperación y eliminación. Una observación puede guardar el requisito declarado, cómo se recoge o comprueba la información, con qué queda vinculada, quién la recibe, la región, el plan, la plataforma o el método de registro al que se aplica, sus fechas y la evidencia correspondiente.

Desde el 26 de julio de 2026, el conjunto de datos conserva un historial acumulativo que solo admite nuevas entradas. Cada cambio de política añade una observación nueva que sustituye explícitamente a la anterior; una corrección apunta a la observación corregida. Las 44 observaciones iniciales forman una base heredada y no afirmamos que conserven un historial completo de cambios anterior a esa fecha. Las vistas comparativas actuales se derivan del historial; no lo sustituyen.

Qué queda fuera de alcance
#

Anonimato de red. Direcciones IP, huellas de dispositivo, trato de Tor/VPN y analítica web pertenecen a otra capa. Podemos registrar una declaración publicada sobre datos de red bajo una etiqueta separada, pero ningún campo demuestra que una persona sea anónima en la conexión.
Exposición ante intermediarios de pago. Es posible registrar que un proveedor acepta un medio de pago; lo que el intermediario sabe del pagador queda fuera del conjunto.
Acceso por vía legal. Registramos la entidad y jurisdicción que declara el proveedor. No convertimos esos datos en una afirmación sobre el alcance de una orden judicial o un procedimiento de seguridad nacional.
Aplicación en los sistemas internos. Una política muestra lo que el proveedor publicó, no que el producto o sus sistemas internos actuaran de esa manera.

De dónde salen los valores
#

Los documentos del proveedor y las ejecuciones controladas de la interfaz son funciones probatorias paralelas, no niveles de una sola jerarquía:

Los documentos del proveedor responden qué publicó la empresa en sus políticas, términos o materiales de ayuda. Un hecho declarado por el proveedor queda limitado al texto y al ámbito del documento.
Las ejecuciones controladas de la interfaz responden qué hizo una ruta concreta del producto bajo condiciones registradas: fecha, región, plan, plataforma y método de alta, entre otras. Un hecho observado en la interfaz exige conservar un artefacto revisado de la ejecución y vincular su resumen criptográfico al manifiesto de publicación. No se generaliza fuera de ese ámbito.
Las respuestas de soporte, las copias archivadas de una interfaz y los informes de terceros pueden plantear preguntas o reforzar un registro, pero no se convierten en un valor visible sin registrarse como evidencia válida en la función correspondiente.

Ninguna función sustituye a la otra en silencio. En la fase P0 actual, una discrepancia entre un documento y una ejecución controlada dentro de ámbitos comparables aplaza la publicación. Conservamos por separado ambos flujos de evidencia, pero todavía no publicamos un estado nuevo como «conflictivo». Cuando la fase P1 incorpore una relación de conflicto estructurada al historial que solo admite nuevas entradas, ambos registros podrán mostrarse en paralelo sin que uno sustituya al otro. El piloto actual solo contiene documentos de proveedores; no tiene hechos procedentes de ejecuciones controladas de la interfaz.

Recogida y obligación también se mantienen separadas. Que una política indique que se puede recoger un teléfono no demuestra que sea obligatorio para registrarse. Un valor declarado por el proveedor solo se marca como obligatorio cuando el documento usa lenguaje imperativo. Un valor observado en la interfaz solo se marca así cuando la ejecución controlada demuestra que su ruta definida no avanza sin el dato.

Vocabulario controlado y regla de cero casillas vacías
#

Las celdas utilizan estados como obligatorio · opcional · condicional · disponible · recogido si se facilita · puede recogerse · no evaluado · conflictivo · depende de la región · depende del plan · no aplicable.

no evaluado significa que no existe un registro actual con alcance definido para el servicio y la dimensión mostrados.
conflictivo es un estado reservado y no se usa en el piloto actual. En la fase P0, una discrepancia entre funciones probatorias con ámbitos comparables bloquea la publicación en lugar de convertirse en una celda pública. Solo empezará a usarse cuando la fase P1 disponga de la relación estructurada necesaria para publicar ambos registros en paralelo.
no divulgado es un estado reservado y no se usa en el piloto actual. Exigiría una evaluación registrada de un corpus de documentos definido; que no aparezca en los hechos reunidos hasta ahora no basta.

Ninguna celda queda en blanco. El silencio del documento y una carencia de nuestra investigación son estados distintos; ninguno demuestra que el requisito no exista.

Evidencia, fechas e integridad
#

Para los documentos del proveedor:

Primero se archiva. Las páginas se capturan mediante archivos web. El registro citado es la copia archivada, no una consulta directa nueva desde nuestra infraestructura.
Comprobación del contenido. Una captura solo conserva el papel de evidencia actual si todas las citas usadas por los hechos actuales siguen presentes en el cuerpo archivado y decodificado. La captura de origen y la última revisión que aún sustenta la afirmación se muestran por separado.
Función del SHA-256. El SHA-256 es una huella del cuerpo archivado una vez decodificado. Permite comparar una copia conservada y detectar cambios en sus bytes; no demuestra cuándo existieron esos bytes.
Origen de la fecha de captura. La fecha procede del registro de Wayback. El sellado de tiempo criptográfico aún no está implantado, por lo que las capturas actuales no llevan una prueba criptográfica creada en el momento de captura.
Citas y conservación. Los extractos breves y saneados se conservan en su idioma original. Guardamos los cuerpos utilizados para que un enlace roto no borre el registro.

En una ejecución controlada de la interfaz, el registro debe indicar las condiciones y el resultado, conservar el artefacto designado en la ruta para ejecuciones de interfaz controlada por el repositorio y vincular su resumen al manifiesto de publicación. Los archivos de documentos y los artefactos de interfaz tienen controles de integridad distintos y permanecen en flujos de evidencia separados.

Solo se muestra una fecha de entrada en vigor cuando el proveedor afirma expresamente que la política o el término entra en vigor ese día. La fecha de «última actualización» de una página es una fecha del documento, no de entrada en vigor. La fecha de captura u observación tampoco se convierte en ninguna de las dos.

Origen, integridad, aplicación, actualidad y conflicto
#

Estas etiquetas se mantienen separadas porque responden a preguntas diferentes:

Origen de la afirmación distingue declaraciones del proveedor y observaciones de interfaz.
Integridad de la evidencia indica si se superaron las comprobaciones aplicables al archivo del documento o al artefacto de interfaz.
Aplicación real permanece sin probar salvo que exista una prueba controlada aparte. Un documento archivado nunca basta.
Comprobado hasta del hecho sigue cada flujo citado hasta el sucesor vigente que aún sustenta la afirmación y toma la fecha más antigua entre las últimas comprobaciones de esos flujos.
Comprobado hasta del conjunto es la fecha más antigua entre los hechos actuales. Una actualización parcial no adelanta la fecha de todo el piloto.
Conflicto es una etiqueta reservada. En la fase P0 no describe un valor público: una discrepancia no resuelta dentro de ámbitos comparables detiene la publicación. Cuando la fase P1 incorpore la relación estructurada al historial que solo admite nuevas entradas, la etiqueta señalará el vínculo entre los registros que discrepan y permitirá mostrarlos en paralelo.

Las etiquetas no se combinan en una puntuación de confianza.

Cambios, correcciones y objeciones
#

Una modificación se fecha solo con la precisión que permite la evidencia. La fecha de una captura no se convierte sin más en fecha de entrada en vigor. En la fase P0, una discrepancia entre funciones probatorias con ámbitos comparables bloquea la publicación; no se resuelve por preferencia editorial ni se muestra como un estado nuevo. Cuando la fase P1 incorpore la relación de conflicto estructurada al historial que solo admite nuevas entradas, ambos registros podrán permanecer visibles en paralelo.

Cuando la revisión confirma un error en el conjunto, lo corregimos en público. Proveedores y lectores pueden escribir a editor@cypherpunkguide.com. Normalmente intentamos acusar recibo de una objeción en 14 días y marcar el valor afectado mientras se revisa. Es un objetivo operativo que depende del canal de correcciones supervisado, no un tiempo de respuesta garantizado.

Objetivo de actualización y límite actual
#

El funcionamiento previsto consiste en revisar mensualmente las fuentes y someter los cambios detectados a decisión humana. Esa periodicidad todavía no constituye un acuerdo de nivel de servicio (SLA) activo. Solo se convertirá en compromiso cuando el flujo de captura, validación, detección de diferencias, decisión humana y publicación complete dos ciclos consecutivos equivalentes a producción, con todos los controles aprobados y un indicador observable de funcionamiento. Mientras tanto, las actualizaciones y correcciones son manuales, y las fechas mostradas como «comprobado hasta» son los límites fiables de actualidad.

Por qué no hay puntuaciones
#

Una puntuación compuesta impondría un único modelo de amenazas a todas las personas. El teléfono, el envío a proveedores posteriores, el vínculo con una cuenta y el plazo de retención no son unidades intercambiables. KYC Drift publica hechos, fechas, ámbitos, carencias y fuentes, sin convertirlos en un orden de calidad ni en una recomendación.

Selección y licencia
#

Los ocho servicios forman una muestra de conveniencia para el piloto: en cada caso había al menos una fuente primaria del proveedor cuyo contenido podía verificarse sin crear una cuenta. La selección no agota el mercado de IA alojada ni pretende representarlo. Nuestros metadatos y anotaciones se publican bajo CC BY 4.0; el texto citado sigue perteneciendo a sus titulares. La exportación legible por máquina está en /en/data/kyc-drift/index.json.

Cita sugerida: Cora Aegis, «KYC Drift: identidad y tratamiento de datos en IA alojada — piloto» (v2026.07), https://cypherpunkguide.com/es/data/kyc-drift/, CC BY 4.0

Custodia de Bitcoin bajo coacción: guía para sobrevivientes 2026

Mon, 29 Jun 2026 00:00:00 +0000

Una nota sobre la financiación: CypherpunkGuide no lleva publicidad de vigilancia. Nada de redes publicitarias, píxeles de seguimiento ni contenido patrocinado. Nos sostienen vías transparentes: hoy, las donaciones; más adelante, una suscripción y afiliación alineada con nuestra línea editorial. Respondemos ante nuestras lectoras y lectores, no ante los anunciantes.

Si estás en peligro, tu seguridad va por delante de todo esto. Leer esta página puede dejar un rastro en un dispositivo compartido o vigilado. Ábrela desde un aparato que la persona a la que temes no pueda alcanzar y habla con alguien especializado en violencia de pareja antes de cambiar nada. Un cambio repentino en cuentas, dispositivos o dinero compartidos puede alertar a quien maltrata, y el momento de irse es el más peligroso (WomensLaw). En España puedes llamar al 016 (atención a víctimas de violencia de género, gratuito y sin rastro en la factura). En el resto de países hispanohablantes, busca el servicio oficial de atención a víctimas de violencia de género o de pareja de tu país o región — los nombres y números varían, y la búsqueda “violencia de género [nombre del país] línea de ayuda” te llevará al recurso correcto. Nada de lo que leas aquí sustituye a un plan de seguridad hecho con una persona formada.

Casi todas las guías para custodiar tu propio Bitcoin imaginan al mismo enemigo: un hacker que está lejos y trata de alcanzar tus claves a través de internet. Por eso el consejo está pensado para la distancia: un hardware wallet, una frase semilla anotada en papel, un PIN robusto. Da por sentado, sin decirlo, que estás a solas en una habitación que nadie más controla.

Para muchísimas personas eso no es cierto, y el vacío se abre justo donde más está en juego. El abuso económico —cuando la pareja controla, sabotea o se apropia de tu dinero— afecta a cerca del 15 % de las mujeres, y las que pasan por inseguridad alimentaria tienen más de cuatro veces más probabilidades de sufrirlo (Mellar et al., 2024). La autocustodia se presenta como independencia financiera, pero el manual de siempre nunca nombra a quien comparte tu cama, conoce tu código y puede sencillamente exigirte que desbloquees la billetera. (La coacción física tampoco es algo marginal fuera de casa: los ataques físicos documentados contra personas que tienen Bitcoin crecieron un 169 % en 2025 —CNBC, según la base de incidentes que recopila Jameson Lopp.)

¿Qué cambia, entonces, cuando la amenaza vive contigo? Leímos en paralelo las principales guías de autocustodia y los mejores recursos sobre seguridad digital frente a la violencia de pareja, y descubrimos que casi nunca se cruzan. Este artículo intenta cerrar ese hueco: no con una lista de pasos numerados, sino con una forma de razonar. Un modelo de capacidad del adversario que parte de lo que la persona que tienes cerca puede hacer de verdad, y un plan por etapas que pone tu seguridad física por delante de cualquier decisión sobre la billetera.

Escribimos como investigadoras de privacidad, no como sobrevivientes ni como defensoras. Lo que sigue es un modelo de amenaza y un conjunto de opciones, no una receta. Seguimos el principio del enfoque informado sobre el trauma: ofrecer opciones en lugar de dar órdenes (SAMHSA). Conoces tu situación mejor que cualquier guía, y algunos de los trucos “ingeniosos” que circulan por las comunidades de Bitcoin pueden causarle daño a alguien. Esos los señalamos sin rodeos.

Por qué los consejos habituales de custodia fallan cuando la amenaza vive en casa
#

Los consejos corrientes sobre custodia de Bitcoin parten de un adversario remoto y de una persona físicamente segura en su entorno. Sus movimientos básicos —mantener la frase semilla fuera de internet, usar un hardware wallet, poner un PIN— suponen que nadie en quien confíes te observa mientras tecleas, sostiene tu teléfono o puede presionarte en persona. El maltrato en la pareja rompe todas esas suposiciones a la vez, y por eso “usa un hardware wallet y ya está” puede ser no solo inútil, sino peligroso.

El desajuste es de fondo, no es que falte un consejo suelto. Los recursos habituales de custodia buscan defenderte del robo (alguien que se lleva tus claves sin tu cooperación). La planificación de seguridad pensada para el maltrato busca defenderte del control y la coacción (alguien que te hace actuar en contra de tus propios intereses y luego castiga cualquier desviación). Un hardware wallet resuelve lo primero y puede agravar lo segundo: un dispositivo nuevo a la vista levanta una pregunta que quizá no te conviene responder.

Hay además un fallo más silencioso. Quienes acompañan a víctimas de violencia organizan sus consejos en torno al acceso y la capacidad de presión de quien maltrata; las guías de Bitcoin organizan los suyos en torno a herramientas y procedimientos. Tender un puente entre ambos significa traducir la pregunta “¿qué puede hacer la persona que tengo cerca?” a decisiones concretas de custodia y privacidad. A eso se dedica el resto de este artículo.

La matriz de capacidad del adversario
#

En lugar de preguntarte “¿soy mujer, soy creadora, soy activista?”, pregúntate qué puede hacer en la práctica la persona que te amenaza. Es el cambio más útil: las mismas defensas funcionan para cada capacidad, y casi toda situación real mezcla varias. La matriz de abajo es nuestra forma de ordenarlo; las defensas se resumen aquí y se desarrollan en secciones posteriores.

Capacidad del adversario	Qué significa	Defensa de primer orden	Límite honesto
1. Acceso físico al dispositivo	Puede coger tu teléfono o portátil, o lo compartís	Un dispositivo aparte que no pueda alcanzar; cuidado con el bloqueo de pantalla	Un aparato que ya ha tocado puede estar comprometido
2. Conoce tu PIN o código	Lo vio por encima del hombro, lo exigió o se lo diste antes	Un dispositivo nuevo con un PIN que no conozca	Cambiar un PIN conocido —o quitar la huella o el rostro— es en sí un acto visible, y una huella o una cara se pueden forzar físicamente
3. Puede obligarte a firmar	Violencia o amenazas para que envíes fondos	Retardos de tiempo; no dejar sumas grandes disponibles al instante	La criptografía no detiene una llave inglesa (el “ataque de los 5 dólares con una llave inglesa”, Bitcoin Wiki)
4. Rastrea tu ubicación	Stalkerware, cuentas compartidas, AirTags	Trata el teléfono como vigilado; pide ayuda por otra vía	Encontrar un rastreador puede agravar el peligro
5. Lee tu nube, correo o 2FA	iCloud o Google compartidos, acceso al SIM	Cuentas nuevas en un dispositivo seguro; 2FA por app	Cambiar una cuenta puede avisar a la otra persona
6. Puede exponerte o difundir tus datos	Amenazas de publicar adónde fuiste	Privacidad en la cadena y de las direcciones; tapar datos	El historial público del registro es difícil de deshacer

Lo importante de la matriz es el orden. Las capacidades 1, 2, 4 y 5 no son problemas de Bitcoin: son problemas del dispositivo y de las cuentas que existen antes que cualquier billetera. Si el teléfono que llevas en el bolsillo está vigilado, el hardware wallet más cuidadosamente escogido no sirve de nada: cualquier cosa que configures queda visible en el momento en que la configuras. Por eso el orden de los pasos importa más que la elección de billetera, y por eso la siguiente sección va antes que cualquier consejo de custodia.

Antes de la billetera: asegura el dispositivo y el plan de seguridad
#

Antes de tocar una billetera, hazte con un dispositivo y un plan de seguridad que la otra persona no controle, porque cada paso posterior necesita una base privada desde la que actuar. El stalkerware —aplicaciones que vigilan el dispositivo en secreto y transmiten en silencio ubicación, mensajes, fotos y llamadas— está muy extendido y está diseñado para que cueste detectarlo; la Coalition Against Stalkerware y el proyecto Safety Net de NNEDV documentan su uso habitual en el maltrato: el 97 % de los programas contra la violencia de pareja informa de que quienes maltratan abusan de la tecnología para acosar, hostigar y controlar (encuesta Safety Net de NNEDV, 2014). Si tu dispositivo puede estar vigilado, da por hecho que se ve todo lo que haces en él.

Y algo decisivo: no te apresures a “limpiar” un dispositivo del que sospechas. Quienes acompañan a víctimas advierten de que quitar un programa espía o un rastreador puede delatarte ante quien maltrata y agravar el peligro (Safety Net de NNEDV). Suele ser más seguro dejar que el dispositivo vigilado aparente normalidad y llevar la actividad delicada a un aparato aparte que la otra persona no pueda alcanzar: comprado, configurado y guardado fuera de su alcance.

Una primera secuencia práctica, si sospechas que te vigilan:

Para. No hagas nada brusco en el dispositivo sospechoso. Comportarte de otra manera ya es una señal.
Hazte con un dispositivo aparte. Un teléfono barato —o el aparato de una amistad, pero solo de alguien de quien estés segura de que la otra persona no tiene contacto ni vigila— con un correo nuevo y un autenticador por aplicación, no por SMS (que puede interceptarse con un plan de telefonía compartido).
Pide ayuda por otra vía. Contacta con una persona especializada desde el dispositivo seguro o en persona, nunca por canales que la otra persona pueda leer.
Planifica antes de cambiar nada que esté a su alcance. Sobre todo el dinero: una transferencia repentina desde una cuenta vigilada puede ser el detonante, no la salida.

Solo cuando tienes una base que la otra persona no controla resulta seguro poner en práctica el resto de esta guía. Nuestro trabajo más amplio sobre cómo te ven las herramientas de vigilancia y sobre la verificación de edad y las personas vulnerables profundiza en la parte del dispositivo y los datos.

Opciones de custodia bajo coacción, y sus límites honestos
#

Bajo coacción, el objetivo del diseño de la custodia cambia: ya no se trata de “que no entren los ladrones”, sino de “limitar lo que te pueden arrancar bajo presión sin ponerte en mayor peligro”. Varios trucos populares no superan esa segunda prueba. La verdad más dura de la autocustodia es tajante: guardar tus claves a la perfección no sirve de nada si pueden obligarte a firmar. Es el conocido “ataque de los 5 dólares con una llave inglesa”, y significa que las decisiones de custodia hay que juzgarlas por lo que te pasa a ti, no solo por lo que les pasa a tus monedas.

Abajo están las opciones que más se sugieren, con sus límites reales en un contexto de maltrato. Ninguna de estas es una recomendación; cada una es un compromiso que puede salir mal.

Opción	La idea	El peligro honesto bajo coacción
Billetera señuelo o de coacción	Mostrar un saldo “real” pequeño para satisfacer una exigencia	Si se sospecha o se descubre, la mentira puede desatar más violencia. No existe investigación publicada sobre violencia de pareja que avale los señuelos como algo seguro; quienes acompañan a víctimas advierten de que cualquier desviación que se note puede agravar el peligro. Trátalo como de alto riesgo, no como una astucia.
Passphrase oculta (una palabra secreta extra encima de tu frase semilla; el “25.º término” de BIP-39, el estándar de las frases semilla)	Una sola semilla, dos billeteras; la oculta se puede negar con verosimilitud	Es técnicamente real (BIP-39), pero una passphrase olvidada significa pérdida permanente, y bajo interrogatorio la negación puede fallar. Sube tanto el riesgo de no poder recuperar como el de coacción.
Gasto con retardo o multisig	Un retraso o una clave extra dan margen para cancelar una transacción forzada	El retraso solo ayuda si cancelar después es seguro. Si la otra persona está presente y mirando, una transacción cancelada es una desviación que se nota.
Multisig con un tercero de confianza	Repartir las claves para que ningún dispositivo guarde los fondos solo	Una marca del maltrato es el aislamiento: cortar a la víctima de amistades y familia (NCDV). Esa “persona de confianza” puede no existir, puede ser presionada, o el simple contacto con ella puede ser peligroso.

Dos principios atraviesan todas estas opciones. El primero: las defensas basadas en el engaño son las más peligrosas bajo coacción, porque cuando fallan la consecuencia es una represalia física, no unas monedas perdidas. El segundo: el secreto compite con la recuperabilidad. Se calcula que entre el 11 % y el 18 % de todo el Bitcoin ya se ha perdido por claves olvidadas y planes incompletos (estimación de Chainalysis, vía CryptoSlate), y apilar passphrases ocultas sobre copias de seguridad repartidas en distintos lugares puede dejarte fuera a ti con la misma facilidad que a cualquier otra persona. Un plan que no puedes usar con seguridad no es un plan.

Si tu situación es “necesito sacar fondos antes de irme”, el camino más limpio no suele ser una billetera astuta, sino una billetera nueva en un dispositivo seguro, financiada con cuidado. Puedes ver cómo conseguir monedas de forma privada en comprar Bitcoin sin KYC —KYC es la verificación de identidad que exigen los exchanges—, teniendo en cuenta las advertencias que vienen a continuación sobre el registro público.

El registro público de Bitcoin es su propia exposición
#

Las claves y los dispositivos no son el único frente. Bitcoin tiene un riesgo de privacidad que mucha gente no advierte al principio: el registro es público y permanente, así que los pagos pueden vincularse contigo mucho después de hacerlos. Reutilizar la misma dirección enlaza entre sí todas sus transacciones, y conectar cualquiera de ellas con una retirada de un exchange con KYC puede asociar tu nombre y tu domicilio reales a ese historial (Bitcoin Wiki: Privacy; Coldcard). Para quien intenta irse sin que la rastreen, esto no es abstracto: una dirección de retirada que ha visto quien maltrata, o recuperada de una cuenta compartida, puede convertirse en una pista que alguien use para localizarte.

La exposición va más allá de las direcciones. Las facturas de Lightning (la capa de pagos rápidos de Bitcoin) pueden revelar la clave pública del nodo de quien recibe: un identificador persistente que cualquier atacante puede consultar para ayudar a identificarte (Casa). Las direcciones de envío del hardware wallet, los apartados de correos y las cuentas de exchange vinculadas a una identidad compartida filtran datos de la misma manera. Las medidas de defensa —usar direcciones nuevas, no reutilizarlas, separar con cuidado las monedas con KYC de las que no lo tienen— son válidas, pero conllevan una fricción real: comisiones, límites según el país y una curva de aprendizaje que no es justo exigirle a alguien que ya está en crisis. Explicamos el funcionamiento en privacidad de Bitcoin en la cadena; aquí la conclusión es más concreta: da por hecho que cualquier cosa que pongas en la cadena puede vincularse contigo, y mantén la billetera de la que depende tu seguridad separada de cualquier dirección que la otra persona haya visto alguna vez.

Una respuesta por etapas: ajusta el movimiento al momento
#

La acción acertada depende por completo de lo urgente que sea el peligro. Ajusta tus movimientos a la etapa en que te encuentras, no intentes resolverlo todo de golpe. El error más frecuente en los consejos técnicos es tratar esto como algo que se configura una sola vez y ya está. Vivir bajo coacción es una secuencia, y dar el paso técnico “correcto” en el momento equivocado puede ser el detonante.

Etapa	Prioridad	Movimiento concreto con Bitcoin
Peligro inmediato	La seguridad física, no la tecnología. Llama a una línea de ayuda o a una persona especializada; no hagas cambios que se noten	Ninguno. Una transferencia ahora puede agravar las cosas, no protegerte
El dispositivo parece vigilado	Consigue un dispositivo aparte y privado; deja el vigilado con normalidad	Configura cualquier billetera nueva solo en el dispositivo seguro
Preparando la salida	Preparación silenciosa; documentos, dinero, ruta. Irse es lo de mayor riesgo	Financia una billetera nueva que la otra persona nunca haya visto; deja las cantidades sin nada que llame la atención
Después de separarte	Privacidad de dirección y ubicación; higiene en la recuperación de cuentas	Direcciones nuevas; corta los enlaces con las cuentas compartidas y el historial de retiradas viejo

Esta secuencia recoge el hallazgo central de la planificación de seguridad frente al maltrato: la seguridad viene de un plan, no de ninguna herramienta por sí sola, y el momento de irse es cuando el riesgo de violencia letal es mayor (WomensLaw). Bitcoin puede formar parte de ese plan —disponer de un dinero que quien maltrata no pueda congelar a través de un banco puede marcar la diferencia—, pero va dentro del plan de seguridad, nunca por delante de él.

Cuando Bitcoin no es la respuesta
#

La autocustodia es una opción entre varias, y la honestidad obliga a decir que muchas veces no es la mejor para alguien en crisis. Las fortalezas de Bitcoin —resistencia a la censura, ningún banco que pueda congelar o denunciar tu cuenta— son reales, pero tienen un coste elevado: mucho conocimiento técnico, errores irreversibles y un registro público. Para quien maneja un peligro inmediato, esa fricción puede ser en sí misma un riesgo.

La comparación honesta depende de cada situación, y no hemos encontrado ningún análisis publicado que sopese todo esto específicamente para quienes sobreviven al maltrato, así que tómalo como punto de partida, no como veredicto:

El efectivo es lo más difícil de rastrear y no necesita ningún dispositivo, pero no se puede esconder en cantidades ilimitadas y se puede encontrar o quitar físicamente.
Las tarjetas de prepago esquivan parte de la vigilancia bancaria y de la vinculación con tu identidad, a cambio de comisiones y límites.
Una cuenta bancaria aparte es rastreable y se puede congelar, pero es accesible, reversible si hay un error y familiar.
La autocustodia de Bitcoin resiste la congelación y el embargo, pero exige destreza, filtra datos en un registro público y no perdona los errores.

La combinación acertada depende de la cantidad, de cuán de cerca te vigilen, de lo cómoda que te sientas con las herramientas y de si tienes un lugar seguro donde guardar una copia de seguridad. Si estás valorando estas opciones, hazlo con una persona especializada, no a solas con una guía.

En conclusión: arma un plan que encaje con tu riesgo
#

No hay una única configuración de custodia correcta para vivir bajo coacción, solo decisiones que encajan con tu peligro concreto. Lo que recorre todo lo anterior es que el dispositivo y el plan de seguridad van primero, y la billetera está a su servicio, nunca al revés. Bitcoin puede darle a alguien un recurso que quien maltrata no pueda revocar en silencio, pero solo si la configuración resiste a un adversario que ya está dentro de tu confianza, de tu casa y, a veces, de tu teléfono.

Puntos clave

Modelo de amenaza: los consejos habituales de custodia dan por hecho un hacker remoto; en el maltrato de pareja, quien te amenaza tiene acceso físico, puede conocer tu PIN y puede obligarte a firmar — un problema totalmente distinto.
Orden: asegura un dispositivo privado y un plan de seguridad antes que cualquier billetera; el 97 % de los programas contra la violencia de pareja informa de que quienes maltratan abusan de la tecnología para vigilar y controlar.
El engaño es peligroso: las billeteras señuelo y de coacción no tienen ninguna validación publicada sobre seguridad frente al maltrato; si se descubren, pueden agravar la violencia. Trátalas como de alto riesgo, no como una astucia.
Registro público: reutilizar una dirección, sumado a una retirada con KYC, puede desanonimizar tu historial; mantén cualquier billetera de seguridad separada de las direcciones que la otra persona haya visto.
Bitcoin no siempre es la respuesta: el efectivo, las tarjetas de prepago y las cuentas bancarias intercambian rastreabilidad por accesibilidad — decídelo con una persona especializada, no a solas con una guía.

Preguntas frecuentes
#

¿Me protege un hardware wallet si mi pareja me ve usarlo?
#

Solo en parte. Un hardware wallet protege las claves frente a un atacante remoto, pero si alguien puede verte introducir el PIN, manejar el dispositivo o presionarte para que firmes, esas protecciones quedan anuladas. En esa situación pesa más el problema del dispositivo y del acceso (las capacidades 1 a 3 de la matriz de arriba) que el modelo de billetera. Antes que nada, hazte con un dispositivo privado.

¿Es seguro usar una billetera señuelo o “de coacción” bajo presión?
#

No la recomendamos como medida de seguridad. La idea —mostrar un saldo pequeño para satisfacer una exigencia— parte de que el engaño se sostiene. En el maltrato, una mentira que se note o se descubra puede desencadenar más violencia, y no existe investigación publicada sobre violencia de pareja que avale los señuelos como algo seguro bajo coacción. La planificación de seguridad frente al maltrato advierte de que cualquier cambio que quien maltrata note puede agravar el peligro. Trátala como una opción de alto riesgo, no como una astucia.

¿Debería poner a una amistad o a un familiar en un multisig?
#

Con mucha cautela. La custodia colaborativa (repartir las claves para que ningún dispositivo guarde los fondos solo) es sensata en general, pero da por hecho que existe un tercero de confianza al que puedes contactar. Una táctica que define el maltrato es el aislamiento —apartarte exactamente de esas personas—, así que esa “persona de confianza” puede no existir, puede ser presionada, o el simple hecho de contactarla puede resultar peligroso. Si optas por alguien, elige a quien la otra persona no pueda alcanzar ni influir.

¿Qué hago primero si creo que mi dispositivo está vigilado?
#

No lo borres ni lo “limpies” de golpe: eso puede alertar a la otra persona. Deja que siga aparentando normalidad, lleva la actividad delicada a un dispositivo aparte al que no pueda acceder (con un correo nuevo y 2FA por aplicación) y contacta con una persona especializada en violencia de pareja por otra vía antes de cambiar nada que esté a su alcance, especialmente el dinero.

¿Es mejor Bitcoin que una cuenta bancaria para irse con seguridad?
#

No necesariamente. Bitcoin resiste la congelación y el embargo, lo cual puede importar, pero exige destreza técnica, no perdona los errores y deja un rastro permanente en un registro público. Para mucha gente en crisis, combinar recursos —algo de efectivo, una tarjeta de prepago, una cuenta bancaria aparte y solo una billetera de Bitcoin pequeña y custodiada con cuidado— es más seguro que depender únicamente de la autocustodia. Decídelo con una persona especializada que conozca tu situación.

Referencias
#

#	Fuente	URL	Archivado
1	Mellar et al., abuso económico y salud (2024)	https://pmc.ncbi.nlm.nih.gov/articles/PMC11465629/	https://web.archive.org/web/20260613075557/https://pmc.ncbi.nlm.nih.gov/articles/PMC11465629/
2	Coalition Against Stalkerware	https://stopstalkerware.org/	https://web.archive.org/web/20260623120558/https://stopstalkerware.org/
3	NNEDV Safety Net — recursos para sobrevivientes	https://www.techsafety.org/resources-survivors	https://web.archive.org/web/20260628175219/https://www.techsafety.org/resources-survivors
4	WomensLaw — planificación de seguridad	https://www.womenslaw.org/safety-planning	https://web.archive.org/web/20260505163930/https://www.womenslaw.org/safety-planning
5	NCDV — tácticas de aislamiento en el maltrato	https://www.ncdv.org.uk/isolation-tactics-how-victims-of-domestic-abuse-fall-into-the-trap/	https://web.archive.org/web/20260218092206/https://www.ncdv.org.uk/isolation-tactics-how-victims-of-domestic-abuse-fall-into-the-trap/
6	Bitcoin Wiki — Privacy	https://en.bitcoin.it/wiki/Privacy	https://web.archive.org/web/20260616215546/https://en.bitcoin.it/wiki/Privacy
7	Coldcard — reutilización de direcciones	https://coldcard.com/learn/transaction-security/bitcoin-address-reuse	https://web.archive.org/web/20260629074529/https://coldcard.com/learn/transaction-security/bitcoin-address-reuse
8	Casa — Lightning privacy 101	https://blog.casa.io/lightning-privacy-101/	https://web.archive.org/web/20260314173520/https://blog.casa.io/lightning-privacy-101/
9	CNBC — ataques físicos a tenedores de Bitcoin (2025)	https://www.cnbc.com/2025/04/06/bitcoin-self-custody-crypto-risks.html	https://web.archive.org/web/20260313145505/https://www.cnbc.com/2025/04/06/bitcoin-self-custody-crypto-risks.html
10	SAMHSA — enfoque informado sobre el trauma	https://www.samhsa.gov/mental-health/trauma-violence/trauma-informed-approaches-programs	https://web.archive.org/web/20260508115444/https://www.samhsa.gov/mental-health/trauma-violence/trauma-informed-approaches-programs

Cora Aegis

Escribe sobre privacidad y autocustodia, centrada en los modelos de amenaza que las guías corrientes dejan fuera; aquí, el hueco entre los consejos de custodia de Bitcoin y la seguridad digital frente a la violencia de pareja. Escribe como investigadora, no como sobreviviente ni como defensora, bajo un seudónimo constante por decisión propia y por principio.

Más sobre Cora →

El Manifiesto Cypherpunk: qué dice y por qué sigue vigente

Sun, 28 Jun 2026 00:00:00 +0000

Una nota sobre la financiación: CypherpunkGuide no lleva publicidad de vigilancia. Nada de redes publicitarias, píxeles de rastreo ni contenido patrocinado. Nos sostienen fuentes transparentes: hoy, las donaciones de los lectores; más adelante, una suscripción y afiliados alineados con nuestra línea editorial. Respondemos ante quienes nos leen, no ante los anunciantes.

Esta web lleva el nombre de un movimiento, y el movimiento lleva el nombre de un documento. Antes de que existiera una industria de herramientas de privacidad, antes de Bitcoin, antes de que la palabra «cypherpunk» asomara a un titular, una pequeña lista de correo de criptógrafos de la bahía de San Francisco decidió que la privacidad no era algo que pudieras esperar a que te regalaran. En marzo de 1993, uno de ellos, Eric Hughes, lo puso por escrito en menos de mil palabras. Ese movimiento —los cypherpunks, los activistas de la criptografía que en los años noventa decidieron no esperar la privacidad, sino fabricarla con código— arranca ahí.

Aquel ensayo, Un manifiesto cypherpunk, sigue siendo la formulación más limpia de por qué existe el trabajo por la privacidad, y casi todos los resúmenes lo aplastan hasta dejarlo en una nota a pie de página camino de Bitcoin. Esa lectura se pierde lo importante. Lo releímos línea a línea frente al paisaje de vigilancia que documentamos aquí cada semana —correlación a escala de IA, huellas que no se borran, controles de identidad en la puerta de la web abierta— y no encontramos nostalgia. Encontramos una especificación que 2026 todavía no logra cumplir.

¿Qué dice entonces el manifiesto, quién lo escribió y cuáles de sus afirmaciones sobrevivieron a tres décadas de contacto con la realidad? Esto es la guía: el texto, las personas y un balance honesto de sus predicciones, incluida la mujer cuyo nombre pertenece al comienzo de la historia y que casi siempre queda fuera.

Qué dice de verdad el Manifiesto cypherpunk
#

El Manifiesto cypherpunk es un ensayo de Eric Hughes, de 1993, que sostiene tres cosas: la privacidad es necesaria para una sociedad abierta en la era electrónica, las instituciones no van a concederla y, por tanto, hay que construirla directamente con criptografía. Publicado en la lista de correo de los cypherpunks el 9 de marzo de 1993, es breve, tajante y está armado como una cadena de afirmaciones, no como una petición de leyes. Su fuerza nace de negarse a tratar la privacidad como un favor.

Empieza separando dos ideas que aún hoy se confunden a diario:

«La privacidad no es secreto. Lo privado es lo que no quieres que sepa todo el mundo; lo secreto es lo que no quieres que sepa nadie. La privacidad es el poder de revelarte al mundo de forma selectiva.» — Eric Hughes, Un manifiesto cypherpunk, 1993

Esa distinción carga con todo el peso. Si la privacidad fuera secreto, exigirla parecería que escondes algo. Al definirla como revelación selectiva —el poder de elegir qué muestras y a quién—, Hughes la replantea como la condición para participar en la sociedad en tus propios términos, no como un refugio para el delito. El ejemplo que usa es deliberadamente cotidiano: pagar en efectivo una revista, donde al vendedor no le hace ninguna falta saber quién eres.

A partir de ahí, el manifiesto lanza su afirmación política central, la que separa el pensamiento cypherpunk de la defensa corriente de la privacidad: no hay petición que valga para conseguir privacidad. «No podemos esperar que los gobiernos, las empresas u otras organizaciones grandes y sin rostro nos concedan privacidad por su benevolencia», escribió Hughes. La privacidad que depende de la buena voluntad de una institución es una privacidad que esa institución puede revocar. La conclusión, entonces, no es una propuesta de política pública, sino un encargo de ingeniería: la privacidad en una sociedad abierta exige sistemas de transacción anónimos y, si no existen, quienes se preocupan por ella tienen que construirlos. La frase célebre comprime toda la ética en tres palabras: «Los cypherpunks escriben código.»

Por eso el manifiesto importa todavía como algo más que historia. No es una queja contra la vigilancia; es un principio de diseño. Dice que la privacidad duradera es una propiedad de los mecanismos —matemáticas que puedes verificar—, no de promesas en las que tienes que confiar. Cada herramienta de privacidad honesta desde entonces ha sido un intento de honrar ese principio, o una demostración de lo que ocurre cuando se ignora.

Tres textos, una idea: May, Hughes y Chaum
#

El Manifiesto cypherpunk no salió de la nada: cristalizó ideas que ya circulaban en tres textos fundacionales —el trabajo académico de David Chaum sobre pagos imposibles de rastrear (1985), el Manifiesto criptoanarquista de Tim May (escrito en 1988) y el ensayo de Hughes (1993)—, unidos por la lista de correo de los cypherpunks que Hughes, May y John Gilmore fundaron a finales de 1992. Leídos juntos, los tres revelan que el manifiesto fue la destilación activista de una década de pensamiento criptográfico.

El cimiento intelectual lo puso Chaum. Como criptógrafo académico, había demostrado que privacidad y rendición de cuentas no eran opuestos: que se podían construir sistemas de pago y de credenciales que no revelaran nada más allá de lo estrictamente necesario para una transacción. Su artículo de 1985 en Communications of the ACM llevaba un título que se lee como la tesis de todo el movimiento: Seguridad sin identificación: sistemas de transacción para volver obsoleto al Gran Hermano. Pasó los años siguientes intentando llevarlo al mercado: fundó la empresa DigiCash para sacar un sistema de «dinero electrónico» antes de declararse en quiebra en 1998, una primera y aleccionadora lección de que la parte difícil nunca fue solo la matemática.

Si Chaum era el ingeniero y Hughes el organizador, Tim May era el provocador. Su Manifiesto criptoanarquista, escrito en 1988 y puesto a circular entre los primeros cypherpunks en 1992, abría con una amenaza deliberada: «Un fantasma recorre el mundo moderno, el fantasma de la criptoanarquía.» La aportación de May, y su advertencia, era que la criptografía fuerte haría posibles sistemas plenamente anónimos, estuviera la sociedad lista o no; y fue franco al señalar que eso cortaba por los dos lados, pues anticipó mercados ilícitos junto a la liberación. Una guía honesta mantiene esa ambivalencia a la vista en lugar de limarla.

Texto fundacional	Autor	Año	Idea central
Seguridad sin identificación	David Chaum	1985	Una transacción puede ser segura sin identificar a quienes participan
El manifiesto criptoanarquista	Tim May	1988 (circuló en 1992)	La criptografía hará posibles sistemas anónimos al margen de la ley
Un manifiesto cypherpunk	Eric Hughes	1993	La privacidad hay que construirla con código, no pedírsela a las instituciones

Lo que convirtió tres textos en un movimiento fue la lista de correo. Desde finales de 1992, los cypherpunks se reunían cada mes en la bahía de San Francisco y discutían en abierto en una lista que, hacia finales de los noventa, sumaba miles de suscriptores. El manifiesto fue su documento fundacional no por ser la primera idea, sino por ser la instrucción más clara.

La mujer que le puso nombre: Jude Milhon
#

El término «cypherpunk» lo acuñó Jude Milhon —escritora y programadora autodidacta que firmaba como «St. Jude»— como un juego de palabras entre «cipher» (cifra) y «cyberpunk», y que el nombre del movimiento sea obra suya es el detalle que casi todas las historias rebajan a nota al pie. Restituirlo no es una curiosidad. Corrige un relato que, en silencio, ha borrado a una mujer de la fundación de un movimiento que trata, precisamente, de quién controla la información.

Milhon (1939–2003) no fue una figura secundaria que acertó con un buen juego de palabras. Programaba desde los años sesenta, formó parte del proyecto Community Memory —uno de los primeros tablones de anuncios computarizados de acceso público— y fue editora sénior de la revista de cibercultura Mondo 2000. Su política era explícita y se adelantaba a su tiempo: su grito de combate, «¡Las chicas necesitan módems!», planteaba el acceso a la tecnología como una reivindicación feminista décadas antes de que «brecha digital» se hiciera de uso común. Cuando los criptógrafos de la bahía necesitaron un nombre, fue Milhon quien dio con el que se quedó.

Sacamos esto a la luz por una razón que va más allá de la exactitud. El ideal cypherpunk —que la privacidad es condición previa de la autonomía— golpea más fuerte a quienes quedan más expuestos cuando falla, y esa población no es neutra en cuanto al género. Las superficies de amenaza que cubrimos más de cerca, desde el abuso de identidades sintéticas en OPSEC en la era de la IA hasta la vigilancia de pareja incrustada en los mandatos de verificación de edad, recaen de forma desproporcionada sobre las mujeres y sobre cualquiera con un adversario cercano y motivado. Un movimiento al que dio nombre una mujer, leído desde 2026, apunta justo a los daños que un modelo de amenazas masculinizado, el del «actor solitario», tiende a no ver. Milhon pertenece a la guía, no a las notas al pie.

El balance: las predicciones de 1993 frente a 2026
#

Leído como una serie de predicciones, el manifiesto resulta incómodamente certero: su tesis de que las instituciones no concederían privacidad, de que la vigilancia crecería a escala y de que solo aguantarían los mecanismos incorporados se ha confirmado una y otra vez; mientras que una predicción de su texto hermano, el de Tim May, se invirtió en algo que sus autores no anticiparon. En esta parte vale la pena detenerse, porque el valor del manifiesto hoy está en servir de balance, no de reliquia.

Armamos la tabla de abajo asignando cada idea central a una amenaza que documentamos en otra parte de esta web, no a un titular. Donde el original es una frase de 1993, la columna de 2026 es un mecanismo que de verdad hemos rastreado.

Idea del manifiesto (1993)	Realidad en 2026	Veredicto
Las instituciones no concederán privacidad «por su benevolencia»	El «borrar» de las plataformas cambia lo que se ve, no lo que existe; quedan copias en brokers, cachés y pesos de modelos	✅ Confirmada
La vigilancia superaría los límites manuales	La IA une fragmentos dispersos en perfiles a una escala que ningún investigador humano alcanzaría	✅ Confirmada
La privacidad exige sistemas de transacción anónimos	Se imponen controles de identidad en la puerta de servicios corrientes, lo contrario del acceso anónimo	✅ Confirmada (por su violación)
La reputación sería «central» en los sistemas anónimos (May, 1988)	Existen sistemas de reputación, pero como puntuaciones de identidad controladas por el Estado y las plataformas (controles KYC, calificaciones de riesgo de chain-analytics), no en manos del usuario	⚠️ Invertida

Las tres primeras filas son el manifiesto reivindicado. Su tesis de que borrar no te salvaría es el tema exacto de Tu huella digital no se borra: una vez que tus palabras se absorben en los datos de entrenamiento de un modelo, no hay botón de borrado que alcance los pesos. Su tesis de que la vigilancia rebasaría los límites humanos es la premisa entera del modelo de amenazas de la era de la IA. Y su exigencia de sistemas de transacción anónimos queda confirmada, irónicamente, por el empuje global hacia lo contrario: los controles de verificación de edad y de identidad digital que condicionan la web abierta a enseñar los papeles.

Podemos aportar una pequeña prueba de primera mano sobre la tesis de la escala. Vigilamos los registros de servidor de esta misma web en busca de los rastreadores de IA que se identifican como tales —GPTBot, ClaudeBot, PerplexityBot, Google-Extended y compañía— y llegan sin pausa, a su propio ritmo, indexando una web de privacidad para responder preguntas sobre ella. Ese público lector hecho de máquinas, que Hughes solo podía intuir, hoy se mide en un archivo de registro.

La cuarta fila es el fracaso interesante. May predijo que, en los sistemas anónimos, la reputación se volvería el principio organizador, y acertó en que la reputación pasó a ser central, pero erró en quién sería su dueño. En vez de reputaciones controladas por el usuario y atadas a seudónimos, 2026 funciona con sistemas de reputación gobernados desde arriba: puntuaciones KYC, calificaciones de riesgo de la monitorización de transacciones, las heurísticas de chain-analytics —el análisis que rastrea las transacciones en la cadena— que deciden si tus monedas están «limpias». Los cypherpunks imaginaron la reputación como una herramienta de soberanía individual. Llegó como un instrumento de control institucional. Esa inversión —el mecanismo correcto capturado por el dueño equivocado— es la lección más afilada que las predicciones del manifiesto guardan para cualquiera que construya herramientas de privacidad hoy.

«Los cypherpunks escriben código»: la ética en 2026
#

La frase más citada del manifiesto, «Los cypherpunks escriben código», no es un eslogan sobre programar, sino una forma de conocer —una epistémica, es decir, una postura sobre qué cuenta como verificable—: las afirmaciones de privacidad tienen que poder comprobarse en el mecanismo, no creerse en la promesa, lo que hoy se traduce en «verifica, no confíes» y «prefiere la estructura a la política de la empresa». Tres décadas después, esa ética es lo más práctico que el documento ofrece a quien no programa.

No hace falta que escribas criptografía para vivir según ella. La prueba cypherpunk para cualquier afirmación de privacidad consiste en preguntar dónde vive la garantía. Una promesa en una política de privacidad vive en la buena voluntad de una institución, justo la que Hughes dijo que no aguantaría. Una garantía escrita en código abierto y auditable, o en un protocolo sin operador central al que obligar, vive en las matemáticas y en la estructura. Por eso las defensas duraderas que recomendamos son casi siempre estructurales y no tácticas: elegir una herramienta cuya privacidad sea una propiedad de su diseño le gana a confiar en un servicio que solo dice lo correcto. Es el mismo razonamiento que lleva a tratar cualquier base de datos en manos del Estado como ya filtrada, la postura de «da por hecha la filtración» de Cuando el gobierno filtra tus datos.

La ética explica también por qué el seudonimato —operar con un nombre constante que no es el legal— está en el centro de esta tradición y no en su margen. Escribir con un nombre fijo que no es el de tu documento —como hacían los cypherpunks en su lista, y como hace esta publicación— no es esconderse: es la revelación selectiva que el manifiesto definió como la privacidad misma. Juzgado por el código y el argumento, y no por las credenciales, el trabajo se sostiene o no se sostiene. Esa es la vara que fijaron los cypherpunks, y es más honesta que la autoridad que se arroga por identidad.

En conclusión: por qué un ensayo de 1993 sigue marcando el plano
#

El Manifiesto cypherpunk perdura porque es un principio de diseño, no una pieza de época: «la privacidad se construye, no se concede» es una afirmación que cada año pone a prueba y que ningún año ha refutado todavía. La privacidad es revelación selectiva, no secreto. No te la van a conceder, así que hay que construirla. Y las únicas garantías que aguantan son las escritas en mecanismos que puedes verificar, no en instituciones en las que tienes que confiar.

Para quien lee en 2026, eso se convierte en una forma de mirar. Cuando se anuncie el próximo control de identidad en nombre de la seguridad, el manifiesto te dice que no preguntes «¿confío en este proveedor?», sino «¿este diseño exige confianza siquiera?». Cuando una plataforma te ofrezca un ajuste de privacidad, te dice que busques la garantía en el código, no en el texto del anuncio. El documento tiene treinta años y se lee como escrito esta misma semana, lo que es, o bien un triunfo de la clarividencia, o bien una acusación de lo poco que hemos construido desde entonces. Con toda honestidad, es las dos cosas.

Puntos clave

Qué es: Un manifiesto cypherpunk es el ensayo de Eric Hughes, de 1993, que define la privacidad como el poder de revelarse de forma selectiva y sostiene que hay que construirla con criptografía en lugar de pedírsela a las instituciones.
El trío fundacional: el trabajo de Chaum sobre pagos imposibles de rastrear (1985) y el Manifiesto criptoanarquista de May (1988) prepararon el terreno; el ensayo de Hughes (1993) convirtió las ideas en una instrucción, en la lista de correo de los cypherpunks fundada en 1992.
La autora del nombre: Jude Milhon (1939–2003), conocida como «St. Jude», acuñó «cypherpunk», una aportación femenina que la mayoría de las historias relega injustamente a una nota al pie.
El balance: sus predicciones de que las instituciones no concederían privacidad y de que la vigilancia crecería a escala se confirman; la de May, de que la reputación sería central, se invirtió en la puntuación KYC controlada por el Estado.
La ética que sirve: «Los cypherpunks escriben código» significa verifica el mecanismo, no confíes en la promesa; prefiere las garantías estructurales a las de la política de la empresa, aunque nunca escribas una línea de código.

Preguntas frecuentes
#

¿Qué es el Manifiesto cypherpunk?
#

Es un ensayo breve, escrito por Eric Hughes y publicado en la lista de correo de los cypherpunks el 9 de marzo de 1993. Sostiene que la privacidad es necesaria para una sociedad abierta, que las instituciones no la concederán de buena gana y que, por tanto, hay que construirla directamente con criptografía. Su frase más conocida, «Los cypherpunks escriben código», comprime todo el argumento: la privacidad hay que incorporarla a los mecanismos, no pedirla como un favor.

¿Quién escribió el Manifiesto cypherpunk y quién acuñó la palabra «cypherpunk»?
#

Eric Hughes escribió el manifiesto en 1993. La palabra «cypherpunk» la acuñó por separado Jude Milhon, escritora y programadora conocida como «St. Jude», como un juego entre «cipher» (cifra) y «cyberpunk». Hughes, Tim May y John Gilmore fundaron la lista de correo de los cypherpunks a finales de 1992, y allí se publicó el manifiesto.

¿En qué se diferencia el Manifiesto cypherpunk del Manifiesto criptoanarquista?
#

Son dos textos distintos. El Manifiesto criptoanarquista de Tim May (escrito en 1988) es el más radical: predice que la criptografía haría posibles sistemas anónimos fuera del alcance del Estado, para bien y para mal. El Manifiesto cypherpunk de Hughes (1993) es más constructivo y más concreto: define la privacidad, insiste en que hay que construirla en vez de concederla y llama a sus lectores a escribir el software. May planteó la consecuencia; Hughes planteó el deber.

¿Sigue vigente el Manifiesto cypherpunk en 2026?
#

Sí, y se diría que más que cuando se escribió. Sus predicciones centrales —que las instituciones no concederían privacidad y que la vigilancia rebasaría los límites humanos— se confirman a diario con la correlación de datos a escala de IA, las huellas digitales que no se borran y los controles de identidad obligatorios. Su instrucción central, confiar en mecanismos verificables antes que en promesas institucionales, es una prueba directamente aplicable para evaluar hoy cualquier herramienta o ley de privacidad.

¿Tengo que ser programador para ser cypherpunk?
#

No. «Los cypherpunks escriben código» es una ética, no la descripción de un puesto de trabajo. Para quien no programa se traduce en una costumbre mental: preguntar dónde vive de verdad una garantía de privacidad. Prefiere las herramientas cuya privacidad sea una propiedad de un diseño abierto y auditable, o de un protocolo sin operador central al que obligar, antes que los servicios que solo prometen portarse bien en una política. Elegir la privacidad estructural frente a la de la política de la empresa es practicar el manifiesto sin escribir una sola línea de código.

#	Fuente	URL	Archivo
1	Eric Hughes — Un manifiesto cypherpunk (1993)	https://www.activism.net/cypherpunk/manifesto.html	https://web.archive.org/web/*/https://www.activism.net/cypherpunk/manifesto.html
2	Un manifiesto cypherpunk — Biblioteca del Nakamoto Institute	https://nakamotoinstitute.org/library/cypherpunk-manifesto/	https://web.archive.org/web/*/https://nakamotoinstitute.org/library/cypherpunk-manifesto/
3	Tim May — El manifiesto criptoanarquista	https://www.activism.net/cypherpunk/crypto-anarchy.html	https://web.archive.org/web/*/https://www.activism.net/cypherpunk/crypto-anarchy.html
4	David Chaum — Security Without Identification (CACM 28(10), 1985)	https://www.semanticscholar.org/paper/Security-without-identification%3A-transaction-to-big-Chaum/a6020d6bce5c69e476dfee15bdf63944e2a717b3	https://web.archive.org/web/*/https://dl.acm.org/doi/10.1145/4372.4373
5	Jude Milhon — Wikipedia	https://en.wikipedia.org/wiki/Jude_Milhon	https://web.archive.org/web/*/https://en.wikipedia.org/wiki/Jude_Milhon
6	Cypherpunk — Wikipedia	https://en.wikipedia.org/wiki/Cypherpunk	https://web.archive.org/web/*/https://en.wikipedia.org/wiki/Cypherpunk
7	«Girls Need Modems!» — Jude Milhon (Capitol Technology University)	https://www.captechu.edu/blog/girls-need-modems-battle-cry-of-hacktivist-jude-milhon	https://web.archive.org/web/*/https://www.captechu.edu/blog/girls-need-modems-battle-cry-of-hacktivist-jude-milhon

Cora Aegis

Cora Aegis escribe en CypherpunkGuide guías de OPSEC centradas en la privacidad y vuelve a las fuentes cypherpunk para leer lo que de verdad dijeron sus autores: aquí, por qué el manifiesto de Eric Hughes de 1993 se lee menos como historia y más como una especificación que 2026 todavía no cumple.

Más sobre Cora →

Tu huella digital no se borra: redes sociales en 2026

Thu, 11 Jun 2026 00:00:00 +0000

Para la mayoría de la gente, la huella digital tiene forma de botón. «Eliminar cuenta». «Desactivar». «Descargar tu información». La interfaz tranquiliza: un clic y el pasado deja de existir. En casi dos décadas de redes sociales, miles de millones de personas hemos confiado en que ese botón dice la verdad.

No la dice. En casi todas las plataformas, eliminar cambia lo que se muestra, no lo que se conserva. Tu perfil desaparece de la vista pública mientras las copias siguen ahí: en los respaldos de los servidores, en la bandeja de entrada de cada persona con la que hablaste y en los registros que los data brokers —intermediarios que comercian con datos personales— ya vendieron. Un estudio de la FTC de 2014 encontró que un solo data broker acumulaba 3,000 segmentos de datos sobre casi todos los estadounidenses. Y en 2026 se suma una copia nueva: los corpus que entrenan a los grandes modelos de lenguaje, donde una publicación eliminada puede sobrevivir dentro de los pesos del modelo mucho después de que el original desapareció.

¿Qué persiste entonces cuando pulsas «eliminar», y qué puedes hacer todavía? Esta no es la guía de una herramienta mágica de borrado, porque esa herramienta no existe. Es un manual de auditoría que pone el modelo de amenazas primero: una forma de ver tu huella con claridad, decidir qué importa de verdad y poner tu esfuerzo donde cambia tu exposición real, no donde solo te tranquiliza.

«Eliminar» es una ilusión de la interfaz
#

En la mayoría de las plataformas, eliminar es un cambio de permisos, no un acto de destrucción. La plataforma deja de mostrar tu contenido al público —y a menudo deja de mostrártelo también a ti—, pero los registros de fondo permanecen en sistemas fuera de tu alcance. Entender la distancia entre oculto y desaparecido es el cimiento de toda higiene de la huella digital.

Cuatro depósitos mantienen vivos tus datos «eliminados», y cualquier guía seria de privacidad coincide en ellos:

Depósito	Qué persiste	¿«Eliminar» lo alcanza?	Tu palanca
Respaldos y registros de la plataforma	Los datos de la cuenta y los DM que enviaste (en la bandeja de los destinatarios)	No: se retienen por períodos definidos	Solicitud de supresión (parcial)
Data brokers	Registros ya extraídos, vendidos o redistribuidos	No: las copias derivadas sobreviven a la fuente	Opt-out broker por broker (recurrente)
Perfiles sombra	Lo que se infiere de ti a partir de lo que otros suben y etiquetan	No: se construyen sin tu cuenta	Minimizar lo que otros pueden vincular contigo
Cachés y capturas de pantalla	Todo lo que alguna vez llamó la atención	No: se copió antes de que lo quitaras	Ninguna retroactiva: prevenir al publicar

Hay otra distinción que a las plataformas les conviene que pases por alto: desactivar no es eliminar. Desactivar solo esconde el perfil y lo deja todo listo para tu regreso; únicamente una solicitud explícita de eliminación pone en marcha la purga (parcial). Y antes de eliminar, descarga tu propio archivo: no se puede auditar lo que ya no se ve.

Si vives bajo el GDPR europeo o la CCPA/CPRA de California, aquí tienes una palanca legal: el derecho de supresión —el «derecho al olvido»— y el derecho a eliminar. La usaremos con método en el manual de más abajo. Pero un derecho legal es una solicitud, no una garantía de borrado total, y se detiene en los datos que puedes identificar. Y los registros que el Estado te obliga a entregar se filtran a su propio ritmo: un problema paralelo con su propio manual, que abordo en Cuando el gobierno filtra tus datos: manual de defensa 2026.

El vector de 2026: tus publicaciones ya entrenan modelos de AI
#

Hay algo que los SaaS de privacidad y los centros de ayuda de las plataformas no te cuentan, porque contar esto no vende ningún servicio de borrado: buena parte de la web pública ya fue ingerida para entrenar modelos de inteligencia artificial, y «eliminar la fuente» no quita lo que un modelo ya aprendió.

Publicaciones, descripciones, comentarios e imágenes en abierto llevan años recopilándose en grandes conjuntos de datos a escala de la web —Common Crawl, usado para entrenar los modelos de la mayoría de los grandes laboratorios, es el más conocido— que alimentan modelos de lenguaje y de imagen. Una vez que un texto o una foto quedó absorbido en los parámetros de un modelo, no existe botón de borrado que llegue al interior de los pesos entrenados. Quienes investigan el desaprendizaje automático (machine unlearning) —el problema de hacer que un modelo entrenado olvide datos concretos— lo consideran genuinamente difícil y aún sin resolver a escala; el remedio confiable es reentrenar sin esos datos, algo que los dueños de los modelos casi nunca hacen por la solicitud de un individuo. Por otra parte, investigadores en seguridad ya demostraron que es posible extraer fragmentos de los datos de entrenamiento desde los grandes modelos: la ingestión no es un proceso sin rastro, sino una forma de almacenamiento.

De ahí se siguen tres consecuencias, y reencuadran todo lo de la sección anterior:

Un archivo web es un motor de permanencia, no solo una memoria. La Wayback Machine del Internet Archive y otros rastreadores similares conservan instantáneas de páginas que ya eliminaste, y esas instantáneas pueden a su vez reingerirse en conjuntos de datos futuros. Borrar en la fuente no alcanza a la instantánea.
Anticiparse gana; limpiar llega tarde. Como la ingestión ocurre de forma continua, el único control plenamente eficaz es no publicar lo sensible desde el principio. Toda defensa posterior a la publicación es parcial.
La ley avanza, pero de manera despareja. Marcos como la AI Act de la UE empiezan a regular los datos de entrenamiento y la transparencia, y el derecho de supresión del GDPR se está poniendo a prueba frente al entrenamiento de modelos. Es una frontera viva y en movimiento: vale la pena seguirla de cerca, pero todavía no apoyarse en ella.

La conclusión práctica es incómoda, pero despeja la vista: trata todo lo que publiques en abierto como potencialmente permanente al nivel de la memoria de una máquina. No es un motivo para desesperar. Es el motivo por el que la auditoría de abajo empieza con un modelo de amenazas y no con una ráfaga de borrados.

Lo que el vuelo de 12 horas de Justine Sacco sigue enseñando en 2026
#

Para entender por qué importa la permanencia, conviene mirar el caso que la definió. En diciembre de 2013, Justine Sacco, directora sénior de comunicación corporativa, publicó un único tuit de pésimo gusto ante una audiencia entonces pequeña, justo antes de abordar un vuelo de unas 11 horas de Londres a Ciudad del Cabo.

“Going to Africa. Hope I don’t get AIDS. Just kidding. I’m white!” («Voy a África. Ojalá no me contagie de sida. Es broma. ¡Soy blanca!»)

Lo publicó ante unos 170 seguidores. Cuando su avión aterrizó, la etiqueta #HasJustineLandedYet era tendencia mundial, desconocidos actualizaban la página esperando su llegada y ella ya había perdido su empleo. Nunca tuvo la oportunidad de borrarlo: el mundo ya lo había copiado.

— El caso de Justine Sacco, diciembre de 2013

Se piense lo que se piense del tuit —y se lo juzgó con indignación—, la lección está en el mecanismo, y el mecanismo no ha hecho más que fortalecerse desde entonces. Un mensaje dirigido a unos 170 seguidores se convirtió en un acontecimiento global en cuestión de horas. Borrarlo era ya inútil: antes de que su autora pudiera mover un dedo, el contenido ya estaba capturado en pantalla, citado y convertido en permanente por la prensa. Más de una década después, su nombre sigue trayendo el episodio a la primera página de resultados, al periodismo y, ahora, a los datos de entrenamiento de los modelos a los que la gente le pregunta por ella.

El caso deja tres reglas duraderas. El alcance no se ve en el momento de publicar: una audiencia pequeña no es una exposición pequeña. Borrar es una carrera perdida contra la multitud: cuando llega la atención, las copias ya van adelante. Y la permanencia es asimétrica: un solo minuto malo sobrevive a años de contexto. La defensa no es borrar más rápido. Es una pausa deliberada antes de publicar, que enseguida formalizamos como protocolo de enfriamiento de 24 horas. (La Series E de Cora examina a fondo fallos de OPSEC documentados como este.)

El manual de auditoría de cuentas antiguas: una autoevaluación en seis pasos
#

Esta es la parte que ningún competidor publica, porque no vende nada. Es la auditoría de seis pasos que construí para esta guía y que recomiendo a quienes nos leen: una rutina que va de ver tu huella a darle forma. Hazla una vez a fondo; después, revísala cada año.

Paso	Objetivo	Herramientas de ejemplo
1. Inventario	Ver el mapa completo	Buscar tu nombre y tus alias viejos; Wayback Machine
2. Modelo de amenazas	Ponerles nombre al adversario y al activo	Papel y lápiz; el pilar de Privacidad
3. Triaje	Encontrar lo poco realmente riesgoso	Revisar ubicación, rutinas y vínculos de identidad
4. Borrado deliberado	Eliminar en el orden correcto	Descargar el archivo; eliminar, no desactivar; desvincular apps
5. Supresión y opt-out	Usar las palancas legales	Solicitudes GDPR Art. 17 / CCPA; opt-out de brokers
6. Seudónimo + enfriamiento	Prevenir la permanencia futura	Separación de identidades; la regla de las 24 horas

Paso 1: haz el inventario de lo que de verdad está ahí afuera. Lista cada cuenta que hayas creado, incluidas las abandonadas. Busca tu nombre real, cada nombre de usuario viejo y tus direcciones de correo. Revisa en la Wayback Machine si quedan instantáneas de perfiles que ya eliminaste. Todavía no corrijas nada: estás dibujando el mapa.

Paso 2: modela la amenaza antes de tocar un solo ajuste. Ponles nombre a tu adversario y a tu activo. ¿Te proteges de un futuro empleador, de una expareja, de un acosador, de alguien que practica doxxing o, simplemente, de tu propia reputación futura? La respuesta honesta determina todo lo demás: una profesional con presencia pública y una sobreviviente de abuso necesitan estrategias opuestas. (Este es el hábito de la privacidad como modelado de amenazas que sostiene todo el trabajo de Cora; si te resulta nuevo, empieza por el pilar de Privacidad y OPSEC.)

Paso 3: haz triaje por riesgo real, no por volumen. La mayor parte de tu huella es inofensiva. Encuentra lo poco que no lo es: la ubicación de tu casa o de tu trabajo, fotos que delatan rutinas o relaciones, cualquier cosa que ate un seudónimo a tu identidad legal y cualquier cosa que contradiga la persona que mantienes hoy. Ordénalo por prioridad. Tu esfuerzo, que es limitado, se invierte aquí.

Paso 4: elimina con deliberación, en el orden correcto. Descarga primero tu archivo. Después elimina en lugar de desactivar, desvincula las conexiones con aplicaciones de terceros antes de cerrar una cuenta y quita las publicaciones individuales de alto riesgo incluso en las cuentas que piensas conservar. El orden importa: revoca las aplicaciones conectadas antes de eliminar, o pueden retener el acceso.

Paso 5: ejerce tus derechos de supresión y date de baja de los brokers. Donde la ley te respalde —el derecho de supresión del GDPR, el derecho a eliminar de la CCPA/CPRA—, presenta las solicitudes por escrito y guarda constancia. Envía solicitudes de exclusión (opt-out) y de eliminación a los principales data brokers; es un trámite tedioso y recurrente, no de una sola vez, porque los brokers vuelven a adquirir los datos.

Paso 6: migra a un seudónimo y adopta el protocolo de enfriamiento de 24 horas. De aquí en adelante, separa un seudónimo duradero de tu identidad legal para todo lo que no quieras atado para siempre a tu nombre, y mantén esa separación impecable. E instaura la regla que Sacco nunca tuvo: ante cualquier publicación emocional, política o sobre otra persona, espera 24 horas antes de publicar. El protocolo de enfriamiento es el hábito de mayor palanca de toda la guía, porque es la única defensa que actúa antes de que los motores de permanencia se muevan.

Cuando el riesgo no es simétrico: mujeres y personas en la mira
#

Una guía de huella digital que trata a todos sus lectores por igual les está fallando, en silencio, a quienes más la necesitan. El riesgo de un rastro digital persistente no se reparte de manera uniforme. Para mujeres, sobrevivientes de abuso, activistas y otras personas convertidas en blanco, una publicación vieja que revela una ubicación, una rutina o una relación no es una vergüenza: es una exposición de seguridad física sobre la que un adversario puede actuar.

Aquí la privacidad deja de ser abstracta. Los acosadores y quienes practican doxxing no necesitan vulnerar ningún sistema; arman a su objetivo con la huella que quedó en público: el gimnasio que etiquetas, la escuela al fondo de la foto, el patrón predecible de los viernes. El borrado posterior es más débil justo donde más está en juego, porque un adversario motivado ya copió lo que necesitaba. Para estas lectoras y lectores, la auditoría cambia de énfasis: los pasos 2 y 3 —modelado de amenazas y triaje de ubicación— importan mucho más que la exhaustividad, y el protocolo de enfriamiento de 24 horas se convierte en una disciplina permanente: decidir qué se revela y qué no se revela nunca.

Escribo esto desde una convicción concreta: la privacidad no es secretismo, y tampoco es paranoia. Es —como escribió Eric Hughes en A Cypherpunk’s Manifesto (1993)— el poder de revelarse selectivamente al mundo: elegir qué se ve, quién lo ve y cuándo. Ese poder es una cuestión de dignidad, y su costo no se reparte por igual. Defenderlo con intención no es esconderse: es respeto propio convertido en método. Quien carga con un riesgo asimétrico debería tratar la disciplina de la huella como una práctica continua, y quizá quiera seguir con el pilar de Soberanía, donde el hilo conductor es la autodeterminación sobre la propia vida.

Conclusión: ¿qué enfoque te corresponde?
#

No existe un único nivel correcto de disciplina sobre la huella; existe el nivel que corresponde a tu modelo de amenazas.

Si usas las redes como cualquiera, sin un adversario concreto: haz la auditoría una vez, corrige lo poco realmente riesgoso, adopta el hábito de enfriamiento de 24 horas y detente ahí. La exhaustividad no vale tu fin de semana.
Si tienes presencia pública —una profesión visible, una audiencia, una candidatura—: asume la permanencia, edita con intención, ejerce los derechos de supresión sobre lo peor y trata cada nueva publicación como un pasivo o un activo de largo plazo. El mecanismo Sacco apunta hacia ti.
Si cargas con un riesgo asimétrico —mujeres que enfrentan acoso, sobrevivientes, activistas, cualquiera con un adversario motivado—: prioriza por encima de todo la exposición de ubicación y de relaciones, separa un seudónimo de tu identidad legal, trata el protocolo de enfriamiento como un requisito previo a cada publicación y repite la auditoría en un calendario fijo. Aquí la prevención es el único control confiable.

En los tres casos vale la misma verdad: después del hecho, ningún borrado te devuelve la seguridad de forma confiable. Solo queda mirar con claridad, decidir con intención y publicar menos de aquello que no querrías volver permanente.

Puntos clave

Eliminar ≠ borrar: en la mayoría de las plataformas, eliminar oculta el contenido de la vista pública, mientras respaldos, copias de los destinatarios, data brokers y perfiles sombra lo conservan.
La inteligencia artificial es el vector de permanencia de 2026: una vez que una publicación pública queda absorbida en los datos de entrenamiento de un modelo, ningún botón de borrado alcanza los pesos entrenados; el machine unlearning sigue sin resolverse a escala, así que prevenir vale más que limpiar.
El alcance es invisible al publicar: el tuit de Justine Sacco llegó a unos 170 seguidores y se volvió un acontecimiento mundial en lo que duró un vuelo de 11 horas; una audiencia pequeña no es una exposición pequeña.
Audita antes de borrar: inventario → modelo de amenazas → triaje → borrado deliberado → derechos de supresión → seudónimo + enfriamiento. El esfuerzo se invierte donde vive el riesgo real.
El protocolo de enfriamiento de 24 horas es el hábito de mayor palanca: es la única defensa que actúa antes de que cachés, archivos web y rastreadores de entrenamiento te copien.

Preguntas frecuentes
#

¿Eliminar tu cuenta de redes sociales borra tus datos de verdad?
#

No, no por completo. La eliminación retira tu perfil de la vista pública y pone en marcha la purga interna de la plataforma, pero quedan copias en los respaldos, en las bandejas de entrada de las personas con las que hablaste, en registros de data brokers ya vendidos, en archivos web y, potencialmente, en conjuntos de datos de entrenamiento de AI. Eliminar reduce tu exposición; no garantiza el borrado.

¿Puedo quitar mis publicaciones de los datos de entrenamiento de AI?
#

En la mayoría de los casos, no de forma retroactiva. Una vez que un modelo entrenado ingirió el contenido, no existe un borrado confiable por usuario, porque lograr que un modelo olvide datos concretos —el machine unlearning— es un problema sin resolver a escala. Algunas plataformas y jurisdicciones empiezan a ofrecer exclusiones del entrenamiento futuro, y vale la pena usarlas, pero el control confiable sigue siendo no publicar material sensible desde el principio.

¿El GDPR o la CCPA obligan a las plataformas a borrarlo todo?
#

Te dan una palanca poderosa pero acotada. El artículo 17 del GDPR (derecho de supresión) y el derecho a eliminar de la CCPA/CPRA obligan a las empresas cubiertas a atender solicitudes válidas de eliminación, con excepciones como la retención por obligaciones legales y la defensa de reclamaciones legales en ambos marcos; el GDPR contempla además el interés público, y la CCPA, la detección de incidentes de seguridad. Se aplican a los datos que la empresa puede identificar como tuyos, y su ejecución frente a copias derivadas y al entrenamiento de modelos todavía se está poniendo a prueba. Presenta las solicitudes; no des por hecho que alcanzan cada copia.

¿En qué consiste el protocolo de enfriamiento de 24 horas?
#

Es una regla autoimpuesta: esperar 24 horas antes de publicar cualquier cosa emocional, política o sobre otra persona. Como cachés, archivos web y rastreadores de AI pueden copiar una publicación en minutos, borrar rara vez les gana; la única defensa consistentemente eficaz es la pausa antes de publicar. Es el hábito que, por sí solo, habría evitado la mayoría de los desastres de huella digital documentados.

Referencias
#

#	Fuente	URL	Copia archivada
1	GDPR, artículo 17 — Derecho de supresión («derecho al olvido»)	https://gdpr-info.eu/art-17-gdpr/	https://web.archive.org/web/*/https://gdpr-info.eu/art-17-gdpr/
2	CCPA de California — Derecho a eliminar (Fiscalía General de California)	https://oag.ca.gov/privacy/ccpa	https://web.archive.org/web/*/https://oag.ca.gov/privacy/ccpa
3	Jon Ronson, “How One Stupid Tweet Blew Up Justine Sacco’s Life”, NYT Magazine, 2015 (de pago; también en So You’ve Been Publicly Shamed, Riverhead, 2015)	https://www.nytimes.com/2015/02/15/magazine/how-one-stupid-tweet-blew-up-justine-saccos-life.html	NYT bloquea los rastreadores de archivo (2025–); ver el libro de Ronson (2015)
4	AI Act de la UE — Comisión Europea (oficial)	https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai	https://web.archive.org/web/*/https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
5	FTC de EE. UU. — “Data Brokers: A Call for Transparency and Accountability” (2014)	https://www.ftc.gov/reports/data-brokers-call-transparency-accountability-report-federal-trade-commission-may-2014	https://web.archive.org/web/*/https://www.ftc.gov/reports/data-brokers-call-transparency-accountability-report-federal-trade-commission-may-2014
6	Carlini et al., “Extracting Training Data from Large Language Models” (USENIX Security 2021; preprint arXiv:2012.07805)	https://arxiv.org/abs/2012.07805	https://web.archive.org/web/*/https://arxiv.org/abs/2012.07805
7	Internet Archive — Wayback Machine	https://web.archive.org/	— (el archivo mismo)
8	Eric Hughes, “A Cypherpunk’s Manifesto” (1993)	https://www.activism.net/cypherpunk/manifesto.html	https://web.archive.org/web/*/https://www.activism.net/cypherpunk/manifesto.html

Matriz del piloto — todos los servicios y las 17 dimensiones definidas

Wed, 15 Jul 2026 00:00:00 +0000

Divulgaciones: naturaleza de esta página · afiliaciones · correcciones

Esta página es un registro factual — no es consejo, ni recomendación, ni invitación, ni aval. La inclusión no es aprobación. Las políticas cambian; consulta los documentos primarios del proveedor antes de apoyarte en cualquier valor.
Actualmente no tenemos ninguna relación de afiliación con los servicios listados. Si eso cambiara, lo divulgaríamos en el propio texto, no afectaría a qué se lista ni en qué orden, y el cambio quedaría registrado aquí.
¿Eres un proveedor listado y crees que un valor es erróneo? Si nuestra revisión confirma el error, lo corregimos y publicamos la corrección — escribe a editor@cypherpunkguide.com
Cómo se recogen y comprueban estos datos (metodología)

Desplázate en horizontal para ver las 8 columnas de servicios →

Dimensión	ClaudeAnthropic	DeepSeekDeepSeek	GeminiGoogle	Le ChatMistral AI	ChatGPTOpenAI	OpenRouterOpenRouter	PerplexityPerplexity	VeniceVenice
Identidad al registrarse y al usar Qué datos de identidad exige o recoge el proveedor en cada punto de contacto.
Cuenta obligatoria	condicionaldeclarado por el proveedor pasar a un plan de pago · global por defecto · gratuito/de pago · web/API	sin registro vigente con alcance definido	condicionaldeclarado por el proveedor uso con sesión iniciada · global por defecto · gratuito/de pago · web/aplicación	condicionaldeclarado por el proveedor según el producto (algunos productos requieren cuenta) · global por defecto · gratuito/de pago · web/aplicación	sin registro vigente con alcance definido	obligatoriodeclarado por el proveedor global por defecto · gratuito/de pago · web/API	sin registro vigente con alcance definido	opcionaldeclarado por el proveedor global por defecto · demo · web
Identificadores de registro	sin registro vigente con alcance definido	correo o teléfonodeclarado por el proveedor global por defecto · gratuito/de pago · web	obligatoriodeclarado por el proveedor global por defecto · gratuito/de pago · web/aplicación	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	obligatoriodeclarado por el proveedor global por defecto · gratuito/de pago · web	sin registro vigente con alcance definido
Teléfono al registrarse	obligatoriodeclarado por el proveedor ubicaciones admitidas · gratuito/de pago · web/escritorio/móvil · Google SSO/correo	correo o teléfonodeclarado por el proveedor global por defecto · gratuito/de pago · web	sin registro vigente con alcance definido	se recoge si lo aportasdeclarado por el proveedor global por defecto · gratuito/de pago · web/aplicación	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido
Correo al registrarse	condicionaldeclarado por el proveedor elegir la vía de registro por correo (la alternativa es Google SSO) · ubicaciones admitidas · gratuito/de pago · web/API	correo o teléfonodeclarado por el proveedor global por defecto · gratuito/de pago · web	sin registro vigente con alcance definido	se recogedeclarado por el proveedor global por defecto · gratuito/de pago · web/aplicación	sin registro vigente con alcance definido	condicionaldeclarado por el proveedor global por defecto · gratuito/de pago · web/API	sin registro vigente con alcance definido	sin registro vigente con alcance definido
Métodos de acceso (SSO/cartera)	inicio de sesión único de Google (SSO) o enlace de acceso por correodeclarado por el proveedor global por defecto · gratuito/de pago · web/escritorio/móvil	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	correo, acceso mediante red social o cartera Web3declarado por el proveedor crear una cuenta (la demo no la necesita) · global por defecto · gratuito/de pago · web
Edad mínima	18+declarado por el proveedor global por defecto · gratuito/de pago · web/API	sin registro vigente con alcance definido	sin registro vigente con alcance definido	13+declarado por el proveedor global por defecto · gratuito/de pago · web/aplicación	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido
Verificación posterior de identidad o teléfono	condicionaldeclarado por el proveedor a discreción del proveedor ('en determinadas circunstancias') · global por defecto · gratuito/de pago · web/API	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido
Pago e identidad de facturación	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	obligatoriodeclarado por el proveedor pasar a un plan de pago · global por defecto · de pago · web	acepta criptomonedasdeclarado por el proveedor global por defecto · de pago · web/API	sin registro vigente con alcance definido	sin registro vigente con alcance definido
Tratamiento de datos Qué ocurre con tus consultas y datos: si se almacenan, cuánto se conservan, si se usan para entrenar, se revisan o se comparten.
Envío de consultas a proveedores posteriores	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	enviado a un proveedor de modelos posteriordeclarado por el proveedor global por defecto · gratuito/de pago · web/API	sin registro vigente con alcance definido	retención cero de datos (exigida a proveedores posteriores)declarado por el proveedor global por defecto · gratuito/de pago/demo · web
Uso de entradas para entrenar	activado por defecto; opción de exclusión disponibledeclarado por el proveedor global por defecto · gratuito/de pago · web	activado por defecto; no se declara una opción de exclusióndeclarado por el proveedor global por defecto · gratuito/de pago · web	sin registro vigente con alcance definido	activado por defecto; opción de exclusión disponibledeclarado por el proveedor global por defecto · gratuito · web/aplicación	activado por defecto; opción de exclusión disponibledeclarado por el proveedor global por defecto · gratuito/de pago · web	varía según el proveedor posterior; puedes elegirlodeclarado por el proveedor global por defecto · gratuito/de pago · web/API	contenido de correos excluidodeclarado por el proveedor global por defecto · gratuito/de pago · web	sin registro vigente con alcance definido
Revisión humana de chats	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sídeclarado por el proveedor global por defecto · gratuito/de pago · web/aplicación	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido
Retención	sin registro vigente con alcance definido	sin registro vigente con alcance definido	hasta 3 añosdeclarado por el proveedor conversación seleccionada para revisión humana · global por defecto · gratuito/de pago · web/aplicación	hasta que lo borresdeclarado por el proveedor global por defecto · gratuito/de pago · web/aplicación	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	no se retienedeclarado por el proveedor global por defecto · gratuito/de pago/demo · web
Eliminación y reutilización de identificadores	disponibledeclarado por el proveedor global por defecto · gratuito/de pago · web	disponibledeclarado por el proveedor global por defecto · gratuito/de pago · web	sin registro vigente con alcance definido	disponibledeclarado por el proveedor global por defecto · gratuito/de pago · web/aplicación	disponibledeclarado por el proveedor global por defecto · gratuito/de pago · webreutilizable tras el borradodeclarado por el proveedor global por defecto · gratuito/de pago · web	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido
Controles de privacidad opcionales	sin registro vigente con alcance definido	sin registro vigente con alcance definido	disponibledeclarado por el proveedor global por defecto · gratuito/de pago · web/aplicación	disponibledeclarado por el proveedor global por defecto · gratuito/de pago · web/aplicación	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido
Jurisdicción del responsable del tratamiento	sin registro vigente con alcance definido	China (CN)declarado por el proveedor global por defecto · gratuito/de pago · web	sin registro vigente con alcance definido	Francia (FR)declarado por el proveedor global por defecto · gratuito/de pago · web/aplicación	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido
Capa de red (aparte) Queda fuera del alcance principal sobre la identidad vinculada al proveedor. Solo se registra como un hecho aparte. La IP, los datos del dispositivo y la analítica pertenecen a la capa de red.
Analítica de terceros en el sitio	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	presentedeclarado por el proveedor global por defecto · gratuito/de pago · web	sin registro vigente con alcance definido	sin registro vigente con alcance definido
Metadatos recopilados (IP, etc.)	sin registro vigente con alcance definido	sin registro vigente con alcance definido	se recogedeclarado por el proveedor global por defecto · gratuito/de pago · web/aplicación	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	sin registro vigente con alcance definido	se recogedeclarado por el proveedor global por defecto · demo · web

Las columnas van en orden alfabético. · Las declaraciones del proveedor y las observaciones controladas de interfaz se etiquetan por separado; ninguna sustituye a la otra. · Una celda con valor significa que existe al menos un registro delimitado, no que estén cubiertas todas las regiones, planes o plataformas. · sin registro vigente con alcance definido = el piloto no contiene un registro vigente con ámbito definido; esto NO demuestra que el requisito no exista · ⚠ = fuentes en conflicto · ↻ = cambió con el tiempo · Sin puntuaciones, sin rankings, sin recomendaciones.

Cómo leer esto
#

Cada valor visible procede de una función probatoria registrada. Los documentos registran lo que publicó el proveedor. Una ejecución controlada registraría lo ocurrido en una ruta concreta bajo sus condiciones declaradas. Las dos funciones se muestran por separado; ninguna sustituye a la otra en silencio. El piloto actual solo contiene valores declarados por proveedores.
El alcance forma parte del valor. Región, plan, plataforma, método de registro y demás condiciones mostradas limitan lo que un registro puede sostener. Un registro con alcance definido no establece todas las variantes de un servicio.
«No evaluado» significa que no hay un registro actual con alcance definido. El conjunto no tiene un registro actual para ese servicio y dimensión en el ámbito mostrado. No demuestra que el requisito no exista, y la tabla nunca transforma el silencio en «sin requisito».
⚠ está reservado para conflictos y no se usa en el piloto actual. En la fase P0, una discrepancia entre evidencias registradas con ámbitos comparables aplaza la publicación; la matriz todavía no muestra ambos registros como un estado nuevo. El marcador solo se activará cuando la fase P1 incorpore la relación de conflicto estructurada que permita mostrar ambas funciones en paralelo sin que una sustituya a la otra.
↻ marca una deriva. Los requisitos cambian. Cuando tenemos evidencia de un estado anterior, la página del servicio muestra qué cambió y el intervalo que pudimos acotar.
Las columnas van en orden alfabético. No hay ranking, puntuación ni «mejor». Qué grado de vinculación resulta aceptable depende de tu modelo de amenazas, no del nuestro. Los hallazgos del piloto explican los datos; la metodología explica cada marcador y comprobación de evidencia.

Volver: índice de servicios · hallazgos · metodología

Ocho servicios de IA alojada: tres contrastes en un piloto de 44 hechos

Tue, 14 Jul 2026 00:00:00 +0000

Divulgaciones: naturaleza de esta página · afiliaciones · correcciones

Esta página es un registro factual — no es consejo, ni recomendación, ni invitación, ni aval. La inclusión no es aprobación. Las políticas cambian; consulta los documentos primarios del proveedor antes de apoyarte en cualquier valor.
Actualmente no tenemos ninguna relación de afiliación con los servicios listados. Si eso cambiara, lo divulgaríamos en el propio texto, no afectaría a qué se lista ni en qué orden, y el cambio quedaría registrado aquí.
¿Eres un proveedor listado y crees que un valor es erróneo? Si nuestra revisión confirma el error, lo corregimos y publicamos la corrección — escribe a editor@cypherpunkguide.com
Cómo se recogen y comprueban estos datos (metodología)

KYC Drift reúne hoy 44 observaciones sobre ocho servicios de IA alojada. Las 44 proceden de términos, políticas de privacidad o materiales de ayuda del proveedor y enlazan evidencia archivada. Aún no hay observaciones obtenidas mediante una ejecución controlada de la interfaz. Esta página, por tanto, analiza lo que publican las empresas; no describe lo ocurrido en un registro nuevo ni en una prueba controlada.

Qué permite sostener el piloto actual
#

El marco cruza 8 servicios con 17 dimensiones: 136 campos posibles. Cuarenta y cinco contienen al menos un registro actual con alcance definido; 91 no contienen ninguno. Son cifras del inventario actual, no un porcentaje de exhaustividad ni una afirmación de que se hayan estudiado todos los supuestos. Cada registro solo respalda la región, el plan, la plataforma, el método de registro y las demás condiciones que muestra.

Cuarenta y cuatro observaciones con evidencia bastan para mostrar diferencias concretas entre reglas publicadas. No bastan para colocar los servicios en una sola escala de privacidad. Los contrastes siguientes responden a dimensiones distintas. Para una persona, el teléfono puede ser decisivo; para otra, lo será el envío de consultas a un tercero. El piloto aporta evidencia fechada para esas decisiones, pero no combina criterios incompatibles en una puntuación global.

Tres contrastes que conviene juzgar por separado
#

Los documentos de los proveedores describen identificadores distintos al crear una cuenta. La ayuda de Anthropic afirma que la verificación telefónica por SMS se aplica a todos los usuarios nuevos de Claude, no se puede omitir, rechaza números de telefonía por internet (VoIP) y otros tipos de número, y asocia una cuenta a cada número. La política de privacidad de DeepSeek señala que, al configurar una cuenta, puede recopilar una dirección de correo electrónico y/o un número de teléfono. Es un contraste entre dos declaraciones oficiales, no la afirmación de que hayamos reproducido ninguna de esas rutas. Las fichas de Claude y DeepSeek muestran el alcance exacto y el texto archivado; el piloto no contiene una ejecución de interfaz para ninguna de ellas.

«Eliminar» remite a reglas de retención diferentes. Venice declara que no conserva consultas ni respuestas. Claude y ChatGPT señalan plazos para retirar de sus sistemas los datos que el usuario ha borrado, sujetos a las excepciones que publican. Mistral indica que los chats permanecen hasta que la persona los borra y asigna plazos más largos a ciertos datos de cuenta e identidad. Gemini declara que algunas conversaciones revisadas por personas pueden conservarse hasta tres años incluso después de borrar la actividad. DeepSeek permite eliminar el historial, pero formula la retención general como «mientras sea necesario». Son declaraciones de proveedores, no pruebas de que cada sistema aplicara su política.

Los servicios de enrutamiento reparten la responsabilidad entre dos proveedores. OpenRouter y Venice declaran que las consultas pueden llegar a proveedores de modelos posteriores (downstream). OpenRouter dice que la retención y el entrenamiento dependen del destino elegido y ofrece controles para seleccionar proveedores con determinadas políticas de datos. Venice afirma que impone la retención cero de datos (zero-data-retention) a sus proveedores posteriores. La pregunta útil no es qué arquitectura «gana», sino quién recibe la consulta, qué compromiso escrito se aplica y si alguien lo ha probado de forma independiente. En este piloto, la aplicación real sigue sin probarse en ambos casos.

Qué no puede establecer el piloto
#

No mide anonimato de red, exposición ante intermediarios de pago ni acceso por vía legal. Tampoco prueba la interfaz, confirma disponibilidad regional ni audita la aplicación en los sistemas internos. La etiqueta declarado por el proveedor significa que la afirmación aparecía en el cuerpo archivado cuando se comprobó. No significa que CypherpunkGuide haya verificado el sistema del proveedor.

Los 91 campos sin un registro actual con alcance definido importan tanto como los demás. No evaluado significa que no hay un registro actual para ese servicio, dimensión y ámbito mostrado; nunca significa que el requisito o la práctica no existan. Las fichas muestran esos huecos para evitar que una documentación escasa parezca un resultado favorable.

La revisión mensual es un objetivo operativo, no un compromiso de nivel de servicio ya activo. Solo pasará a ser una cadencia comprometida cuando el flujo de captura, validación, detección de diferencias, decisión humana y publicación complete dos ciclos consecutivos equivalentes a producción, con todos los controles aprobados y un indicador observable de funcionamiento. Hasta entonces, la fecha «comprobado hasta» de cada hecho se calcula de forma conservadora a partir de sus flujos de evidencia vigentes. La fecha del piloto entero es la más antigua de ellas, de modo que una actualización parcial no hace que todo el conjunto parezca más reciente.

Para correcciones, objeciones o servicios ausentes, consulta la metodología. Puedes escribir a editor@cypherpunkguide.com. Si la revisión confirma un error, publicamos la corrección. Normalmente intentamos acusar recibo de una objeción en 14 días, pero se trata de un objetivo operativo, no de un plazo garantizado.

¿Cómo está la IA cercando la web abierta en 2026?

Tue, 30 Jun 2026 00:00:00 +0000

La web abierta —aquella en la que cualquiera podía publicar en una URL y cualquiera podía encontrarlo siguiendo un enlace— lleva dos años reorientándose en silencio en torno a la IA. El cambio es fácil de pasar por alto porque no hubo anuncio alguno y ningún muro se levantó de la noche a la mañana. Lo que ocurrió, en cambio, se mide en los registros de tráfico. Cuando Google muestra una respuesta generada por IA, la fracción de búsquedas que envía un clic a un sitio externo cae de cerca del 15% a alrededor del 8% (Pew Research, 2025); en miles de sitios de noticias, las visitas llegadas desde buscadores cayeron alrededor de un tercio en el año que terminó a finales de 2025 (datos de Chartbeat, recogidos por el Reuters Institute); y las herramientas de IA que absorbieron esa atención devuelven, a cambio, en torno al 0,1–0,5% de las visitas web.

Así que la web se lee más que nunca, solo que no la leen personas y no de una forma que regrese a la fuente. ¿Está muriendo entonces la web abierta? Vale la pena sostener la pregunta un momento, porque la respuesta decide qué haces a continuación: llorarla, optimizar para las máquinas que la leen, o construir algo que no puedan cercar. «Morir» resulta ser una palabra demasiado dramática y, a la vez, demasiado reconfortante; el diagnóstico honesto es más estrecho, y apunta hacia la construcción antes que hacia la nostalgia o la rendición.

Una nota sobre nuestra posición: esta web se publica tal como este artículo va a terminar recomendando —alojada por nosotros mismos, distribuida por RSS y por protocolos sociales abiertos, sin depender de ninguna plataforma para existir—. No es una vuelta de honor. Es un experimento pequeño y práctico, y lo que sigue es tan honesto sobre sus límites como sobre sus argumentos.

La web se lee más que nunca, solo que no la leen personas
#

El cambio no es que la web se rastree —siempre se rastreó—, sino que el rastreo ya no devuelve una visita: la búsqueda era un directorio que llevaba a las personas hasta las fuentes, mientras que los motores de respuesta de IA son un punto final que pone fin al recorrido en la propia respuesta. Esa distinción es el argumento entero, y es fácil entenderla mal.

Sería un error señalar el puro volumen del rastreo de IA como el daño. Algunos rastreadores son extraordinariamente extractivos —un análisis situó la proporción de un rastreador de IA importante, en 2025, en más de veinte mil páginas descargadas por cada visitante que devolvía—, pero los buscadores siempre han rastreado mucho más de lo que enviaban en tráfico. Rastrear más de lo que devuelves es normal; así funciona la indexación. La cifra que importa no es la proporción, sino la vía de regreso cortada: la página se lee, la respuesta se sirve y el lector nunca llega.

Ese corte es lo que aíslan las cifras más limpias. La misma búsqueda, con y sin resumen de IA, pierde más o menos la mitad de sus clics hacia fuera (de alrededor del 15% baja al 8%), y solo cerca del 1% de los usuarios pulsa las citas que hay dentro de una respuesta de IA (Pew Research, 2025). Las búsquedas sin clic —las que terminan sin visitar nada— subieron de cerca del 56% al 69% en el año que terminó en mayo de 2025 (datos de Similarweb, vía Search Engine Roundtable). Por justicia con los datos, la caída general de las visitas tiene varias causas a la vez —plataformas sociales que estrangulan los enlaces salientes, cambios en los algoritmos principales, muros de pago, públicos que migran a las apps—, de modo que la afirmación causal honesta se apoya en la comparación con y sin IA, no en culpar a la IA de cada visita perdida.

	La web como directorio (búsqueda)	La web como punto final (respuesta de IA)
Para qué sirve el rastreo	Indexar, para dirigir a una persona a la página	Ingerir, para sintetizar una respuesta en el sitio
Qué recibe el lector	Una lista de fuentes que visitar	Una respuesta acabada; las fuentes son opcionales
Qué recibe a cambio la fuente	Una visita: atención, suscriptores, ingresos	Una cita que casi nadie pulsa (~1%)
El trato	Permitir la indexación a cambio de descubrimiento	Permitir la ingesta a cambio de un ~0,1–0,5% de visitas

Pero la gente elige la caja de respuestas
#

La verdad incómoda que la historia del cercamiento tiende a saltarse es que la mayoría prefiere la respuesta a los diez enlaces azules, y no le falta razón. Cualquier argumento que trate a los lectores como puras víctimas de la búsqueda con IA va a malinterpretar por qué ganó esa búsqueda, y será fácil de descartar justo por eso.

La web abierta que los usuarios están dejando era, muy a menudo, un lugar hostil donde aterrizar: relleno optimizado para buscadores que enterraba la respuesta bajo una anécdota personal, bloques de anuncios que desplazaban el texto mientras cargaba, avisos de cookies, ventanas emergentes de boletines, vídeos que se reproducían solos. Una respuesta que se salta todo eso es una mejora genuina en la vida diaria, no un truco a costa de los incautos. Reconocerlo es el precio de que te tomen en serio.

Pero de ahí se siguen dos cosas que la comodidad no cancela. La primera: la respuesta se arma a partir de un trabajo que el motor de respuesta no hizo y que, cada vez más, ni paga ni devuelve con un enlace; el coste se traslada a quienes escribieron las páginas de origen, sin mecanismo alguno para recuperarlo. La segunda, y más corrosiva a largo plazo, es la paradoja de la sostenibilidad: una caja de respuestas que mata de hambre a sus fuentes acaba sin nada fresco ni verdadero que resumir. Para mediados de 2025, investigadores de Stanford, el Imperial College y el Internet Archive calcularon que el 17,6% de los sitios web recién publicados eran enteramente generados por IA —un subconjunto del 35% aproximado que estaba generado o asistido por IA (recogido por Gizmodo, 2025)—; «slop» —contenido de baja calidad generado en masa por IA— fue nombrada palabra del año 2025 por Merriam-Webster. Una web que cada vez más se lee y se reescribe a sí misma es una galería de espejos. El problema, entonces, no es que los usuarios se equivoquen al querer respuestas. Es que el arreglo actual va gastando en silencio un bien común que nadie está reponiendo.

Cada salida disponible es una petición o un parche
#

Las salidas que hoy se discuten —bloquear a los rastreadores, cobrarles, optimizar para ellos o demandarlos— comparten un supuesto oculto: que una web bajo tu control puede recuperarse persuadiendo a quienes la cercan, o a un nuevo intermediario, de que se porten bien. Cada uno merece un examen serio, y cada uno, examinado en serio, se queda corto a la hora de devolver el control.

Bloquear es el reflejo, y el más débil. Una regla en robots.txt es una petición, no una valla: por sí sola no tiene fuerza legal fiable, y un rastreador con buena financiación puede ignorarla o, sencillamente, reetiquetar su tráfico. La versión más eficaz delega el bloqueo en un intermediario —Cloudflare empezó a bloquear por defecto a los rastreadores de IA en los sitios nuevos en julio de 2025 (Cloudflare)—, lo cual funciona, pero solo trasladando la puerta a Cloudflare.

Cobrar es la respuesta que más se parece a una solución, y merece la versión más fuerte de su defensa. El mercado de «pago por rastreo» de Cloudflare (lanzado en julio de 2025) y los grandes acuerdos de licencia —los ~60 millones de dólares al año de Reddit con Google, el pacto de News Corp con OpenAI por más de 250 millones a cinco años— no son nada despreciables. Son la primera compensación real que muchos editores han tenido jamás por la lectura automática, y una señal de precio donde antes solo había extracción gratuita. El problema es estructural. El pago por rastreo instala un peaje central como interfaz entre cada sitio y cada modelo; concede el principio de que el acceso está bien siempre que pagues al guardián; y dirige el dinero al puñado de editores con la fuerza para negociar, dejando a la web independiente con una versión más barata de la misma dependencia. Es un cercamiento con reparto de ingresos —llámalo Cercamiento 2.0—, no una web que el editor controle.

Optimizar para la búsqueda con IA («optimización para motores generativos») es una adaptación que ya ha aceptado las condiciones. Y litigar, la vía más institucional, tiene consecuencias reales: las demandas por derechos de autor contra OpenAI están vivas —un juez ordenó a la empresa entregar veinte millones de registros de ChatGPT en enero de 2026 (National Law Review)—, el regulador de competencia del Reino Unido ya permite a los editores excluirse de los resúmenes de IA de Google (Press Gazette, 2026), y las obligaciones de transparencia que le quedan a la EU AI Act, incluidas las normas de divulgación del contenido generado por IA, alcanzan su fase de aplicación en agosto de 2026. Todo esto importa, y la sección siguiente no es un argumento en su contra. Pero son lentas, atadas a una jurisdicción e inciertas, y todas le piden a una institución que conceda lo que los cypherpunks llevan tiempo diciendo que las instituciones no conceden por bondad.

Salida	Qué hace en realidad	Su mérito honesto	Por qué sigue siendo una petición
Bloqueo con `robots.txt`	Pide con cortesía a los bots que no lean	Gratis, simple, respetado por los bots formales	Sin fuerza legal por sí solo; ignorado o reetiquetado por rastreadores agresivos
Pago por rastreo / licencias	Cobra a las máquinas vía un CDN o un acuerdo	Primera compensación real; una señal de precio	Nuevo peaje central; concede «acceso si pagas»; favorece a los grandes
Optimización para búsqueda con IA	Da formato al contenido para la caja de respuestas	Algo de visibilidad dentro del cercamiento	Acepta las condiciones; ahora optimizas para el guardián
Litigio por derechos de autor	Demanda por el entrenamiento o el uso	Puede rehacer las licencias y la divulgación	Lento, jurisdiccional, incierto; pide a las instituciones que concedan el control

La web abierta ya estaba cercada, y ese es justo el punto
#

Antes de llorar la web abierta, conviene admitir que ya había sido cercada una vez: durante quince años, casi todo el descubrimiento pasó por una sola caja de búsqueda y casi todo el dinero por un solo mercado de anuncios. La IA no pavimentó un bien común libre. Es el segundo cercamiento, y se está llevando el único consuelo que el primero dejó a los editores: la visita de regreso.

Esa corrección importa porque mata la nostalgia, y la nostalgia es la trampa. La meta nunca fue restaurar la web de la era Google, que ya era el peaje de otro. La enseñanza útil es más antigua y quedó escrita en 1993: la privacidad —y, resulta, también la apertura— no es algo que se pida a las instituciones para que lo concedan, porque la privacidad que depende de la buena voluntad de una institución es una privacidad que esa institución puede revocar. La conclusión cypherpunk es incorporar la garantía a un mecanismo en su lugar, que es el argumento de el Manifiesto cypherpunk aplicado ahora a la web misma y no al mensaje en tránsito.

Quien antes vio la forma de esto fue Richard Stallman. Su relato de 1997, The Right to Read, imaginaba un futuro cercano en el que el acto de leer se mide y el acceso al texto lo controla quien sea dueño del software —no es mala descripción de una web donde leer pasa cada vez más por un servicio que consultas en lugar de páginas que abres—. Y su objeción a ese tipo de servicio es concreta, no meramente retórica. Sostiene que hacer tu computación en el servidor de otro «destroza inherentemente tu libertad informática», porque no puedes obtener una copia de una IA alojada y ejecutarla tú mismo; la única forma de usarla es en una máquina que no controlas. Sobre su fiabilidad es aún más tajante: se niega a llamarla inteligencia siquiera, y prefiere «generador de tonterías» para un sistema que, en sus palabras, «genera texto con indiferencia hacia la verdad». No hace falta adoptar la polémica para quedarse con el punto estructural, que es el cypherpunk: una capacidad que no puedes ejecutar, inspeccionar ni bifurcar es una capacidad que controla otro.

«La privacidad que depende de la buena voluntad de una institución es una privacidad que esa institución puede revocar.» Lo mismo vale ahora para el acceso, el descubrimiento y la lectura. La versión duradera de cualquiera de ellos tiene que ser una propiedad de un mecanismo, no una promesa.

La vía real hacia una web soberana
#

La respuesta constructiva no es abandonar mañana la web mayoritaria —casi nadie puede—, sino construir una capa paralela cuya apertura no necesite el permiso de ninguna empresa, empezando por cómo lees y terminando por cómo publicas. Lo que distingue esto del habitual consejo de «usa la web descentralizada» es que nombra los límites con la misma claridad que las herramientas.

Leer con soberanía viene primero, porque es la mitad más fácil:

Sigue las fuentes directamente con RSS, el sistema circulatorio que aún sobrevive en la web abierta. Es un flujo que tú controlas, sin ningún algoritmo decidiendo qué ves y sin métricas de interacción moldeando lo que se escribe; el interés por él vuelve a subir a medida que los lectores buscan una salida a los flujos algorítmicos.
Lee a través de Tor Browser para un acceso sin intermediarios a la web y a los servicios onion. Esto es estructural, no marginal: el New York Times, el Guardian y Der Spiegel mantienen servicios onion para sus fuentes.
Responde tus propias preguntas con un modelo local de pesos abiertos, el paso que la mayoría de las guías de «descentralízalo todo» se saltan. Descentralizar tus datos logra poco si la única inteligencia que puede leerlos es un modelo de frontera corriendo en las GPU de otro, que es donde hoy se concentra de verdad el poder. Ejecutar un modelo más pequeño en local, sobre índices y flujos que tú eliges, es lo que hace soberana la lectura en vez de meramente reubicada. La soberanía sobre el modelo importa tanto como la soberanía sobre los datos.

Publicar con soberanía es la mitad más difícil, y la más importante:

Aloja tú mismo en un servidor virtual barato, un hogar que ninguna plataforma puede borrar.
Distribuye por RSS y por protocolos sociales abiertos —Nostr y el ActivityPub del Fediverse—, donde el vínculo con tu público no es algo que una plataforma pueda revocar.
Ofrece un espejo onion si tus lectores necesitan alcanzarte desde algún lugar hostil.

Nada de esto está libre de fricción, y fingir lo contrario es exactamente lo que hizo perder credibilidad a la última década de consejos del tipo «sé dueño de tu plataforma». Los límites, sin rodeos: el Fediverse tiene del orden de uno o dos millones de usuarios activos al mes, no mil millones; es un pueblo, no un continente. IPFS paga su resistencia a la censura con latencia real y una curva de aprendizaje pronunciada. Alojar tú mismo exige tiempo y destreza antes que cualquier otra cosa. Nada de esto reemplaza el alcance de la búsqueda mayoritaria ni de una gran plataforma social, y quien te diga que una migración masiva es inminente te está vendiendo algo.

Por eso construir esta capa no sustituye a la acción política. La aplicación de las leyes antimonopolio, las licencias obligatorias por ley, el tipo de exclusión que el regulador británico acaba de conseguir, los índices de búsqueda de interés público, los fideicomisos de datos —todo merece pelearse, y el código no reemplaza nada de ello—. La web soberana es el suelo bajo esa pelea: lo que aguanta cuando la ley va lenta o está capturada, para que no estés indefenso mientras tanto. La tesis cypherpunk nunca fue que el software reemplace a la acción colectiva; es que los derechos que puedes ejercer tú mismo no dependen de ganar antes la política.

Aquí esto no es teórico. Esta web se aloja por nosotros mismos, se publica en Nostr y en el Fediverse y se alcanza sin el permiso de ninguna plataforma; también vemos llegar a diario a nuestros propios registros de servidor a los rastreadores de IA que se identifican como tales, como señalábamos en nuestra introducción al manifiesto. El informe honesto es que la web soberana es un lugar donde plantarse, todavía no un lugar donde ganar: más pequeña y más lenta de encontrar de lo que sería si optimizáramos solo para la caja de respuestas. Para ser claros sobre nuestros propios intereses: un sitio independiente puede beneficiarse de que lo citen en una respuesta de IA, y no estamos en contra de eso. La idea no es rechazar a las máquinas, sino rechazar la dependencia de un canal que una empresa puede cerrar. Sé citable; no te dejes capturar. La misma lógica recorre el resto de nuestro trabajo sobre la vigilancia a escala de IA —desde el modelo de amenazas de la era de la IA hasta cómo el borrado ya no alcanza los datos de entrenamiento de un modelo en la permanencia de tu huella— y atraviesa los controles de identidad que se alzan a la puerta de la web en la pelea por la verificación de edad.

Capa	El movimiento	Lo que te da	El límite honesto
Leer — flujos	Lector de RSS que tú controlas	Descubrimiento sin algoritmo ni métricas	Lo seleccionas tú; sin motor de descubrimiento aleatorio
Leer — acceso	Tor Browser + servicios onion	Lectura sin intermediarios y resistente a la censura	Más lento; algunos sitios maltratan el tráfico de Tor
Leer — inteligencia	Modelo local de pesos abiertos	Respuestas de software que tú ejecutas, no de un servicio que te registra	Más pequeño y menos capaz que los modelos de frontera
Publicar — alojamiento	Alojar tú mismo en un VPS barato	Un hogar que ninguna plataforma puede borrar	El tiempo, la destreza y el mantenimiento corren de tu cuenta
Publicar — alcance	Nostr + Fediverse + RSS	Un vínculo con tu público que no posee ninguna plataforma	Escala de ~1–2 millones de activos, no alcance masivo

En conclusión: construye, no pidas
#

La web abierta no está muriendo por causas naturales; la están cercando por segunda vez, y la respuesta más honesta no es la nostalgia ni la adaptación, sino la construcción. La búsqueda fue el primer cercamiento; la caja de respuestas de IA es el segundo, y elimina la visita de regreso que el primero había dejado atrás. Los lectores prefieren de verdad las respuestas, que es justo por lo que la web de origen tiene que defenderse sobre la base de la sostenibilidad y la soberanía, no del sentimiento. Las peticiones y los parches disponibles —bloquear, cobrar, optimizar, demandar— dejan en cada caso a un guardián al mando. Lo que siempre ha valido es también lo que dura: incorpora la apertura a mecanismos que nadie pueda revocar —el modelo además de los datos— y trátala como el suelo bajo la ley y la acción colectiva, no como su reemplazo. No le ganará en escala a la caja de respuestas este año. Sigue siendo, aun así, un lugar donde plantarse cuando los muros terminen de levantarse.

Puntos clave

El daño es una vía de regreso cortada, no el rastreo en sí: con un resumen de IA presente, los clics hacia fuera se reducen casi a la mitad (de alrededor del 15% al 8%), y solo el ~1% de la gente pulsa las citas dentro de una respuesta de IA.
Es el segundo cercamiento: la web anterior a la IA ya pasaba por una sola caja de búsqueda y un solo mercado de anuncios, así que la meta no es la nostalgia de la era Google, sino la apertura incorporada a mecanismos que nadie pueda revocar.
Los usuarios no se equivocan al preferir respuestas, pero una caja de respuestas que mata de hambre a sus fuentes choca con una paradoja de sostenibilidad, con un ~17,6% de los sitios nuevos ya enteramente generados por IA a mediados de 2025.
Cada salida mayoritaria deja a un guardián al mando: robots.txt no tiene fuerza legal por sí solo, el pago por rastreo instala un peaje central, la optimización acepta las condiciones, y el litigio es lento y jurisdiccional.
La soberanía necesita el modelo, no solo los datos: descentralizar el contenido mientras la única inteligencia es un modelo de frontera en las GPU de otro cambia poco; un modelo local de pesos abiertos es lo que hace soberana la lectura en vez de reubicada.

Preguntas frecuentes
#

¿De verdad la IA está cerrando la web abierta, o solo la está cambiando?
#

Las dos cosas, pero la afirmación exacta es más acotada que «la web está muriendo». El contenido de la web es más accesible para las máquinas que nunca; lo que se cierra es la vía de regreso hacia las personas y hacia los sitios que lo produjeron. Cuando aparece una respuesta de IA, los clics hacia fuera caen más o menos a la mitad, y las herramientas de IA que capturaron esa atención devuelven apenas un 0,1–0,5% del tráfico web. La web se lee más que nunca, solo que no la leen personas de un modo que regrese a la fuente. «Cercamiento» encaja mejor que «muerte»: el bien común sigue ahí, pero el acceso a su valor se está vallando y midiendo.

¿Qué es el «pago por rastreo» y resuelve el problema?
#

El pago por rastreo es un sistema —Cloudflare lanzó un mercado para ello en julio de 2025— que permite a un sitio cobrar a los rastreadores de IA por el acceso en vez de bloquearlos, junto a acuerdos directos de licencia entre grandes editores y empresas de IA. Es una mejora real frente al raspado sin compensar y el primer dinero que muchos editores han visto por la lectura automática. Pero no devuelve el control de la web a los editores: instala un intermediario central como peaje entre cada sitio y cada modelo, acepta el principio de que el acceso está bien si pagas al guardián, y favorece a los grandes editores con fuerza para negociar. Es un cercamiento con reparto de ingresos, no una web abierta.

¿Debería bloquear a los rastreadores de IA con robots.txt?
#

Puedes, y los rastreadores formales suelen respetarlo, pero entiende lo que es: una petición, no una valla. Una directiva en robots.txt no tiene fuerza legal fiable por sí sola, y los rastreadores agresivos o reetiquetados pueden ignorarla. Bloquear también renuncia a cualquier posibilidad de ser citado en las respuestas que la gente sí lee. Una postura más duradera que bloquear-o-permitir es dejar de depender de cualquier canal único que no controles: publica donde el vínculo con tu público no pueda revocarse, y trata la política de rastreo como una táctica, no como una estrategia.

¿Qué es la «web soberana», en términos reales?
#

Es el conjunto de formas de leer y publicar que no dependen del permiso de ninguna empresa: RSS para los flujos, Tor y los servicios onion para el acceso, modelos de pesos abiertos ejecutados en local para las respuestas, y el alojamiento propio más los protocolos sociales abiertos (Nostr, el Fediverse) para publicar. Hoy sigue siendo minoritaria: el Fediverse tiene del orden de uno o dos millones de usuarios activos al mes, alojar tú mismo exige tiempo y destreza, e IPFS intercambia resistencia a la censura por latencia. No reemplazará la búsqueda ni las redes mayoritarias este año. Su valor reside en ser una infraestructura paralela y resiliente —un lugar donde plantarse—, no un sustituto ya terminado.

¿Hay que saber de tecnología para escapar de la web de las respuestas automáticas?
#

No, al menos para empezar. El movimiento de menor esfuerzo y mayor retorno es recuperar cómo lees: instala un lector de RSS y sigue las fuentes directamente, para que un algoritmo y una caja de respuestas dejen de decidir qué te llega. Tor Browser es una descarga de un clic para el acceso sin intermediarios. Los pasos más técnicos —ejecutar un modelo local, alojar tú mismo, ofrecer un espejo onion— son una escalera que puedes subir con el tiempo, no un requisito previo. El principio no exige código: elige las herramientas y los protocolos cuya apertura es una propiedad de su diseño, no servicios que solo prometen portarse bien.

#	Fuente	URL	Archivo
1	Pew Research — los clics caen cuando aparece un resumen de IA (2025)	https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/	https://web.archive.org/web/2025/https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/
2	Reuters Institute — Journalism Trends 2026 (caída de visitas de ~un tercio, Chartbeat)	https://reutersinstitute.politics.ox.ac.uk/journalism-media-and-technology-trends-and-predictions-2026	https://web.archive.org/web/2026/https://reutersinstitute.politics.ox.ac.uk/journalism-media-and-technology-trends-and-predictions-2026
3	Search Engine Roundtable — Similarweb sin clic 56%→69%	https://www.seroundtable.com/similarweb-google-zero-click-search-growth-39706.html	https://web.archive.org/web/2025/https://www.seroundtable.com/similarweb-google-zero-click-search-growth-39706.html
4	Cloudflare — controlar el uso del contenido para entrenar IA (julio de 2025)	https://blog.cloudflare.com/control-content-use-for-ai-training/	https://web.archive.org/web/2025/https://blog.cloudflare.com/control-content-use-for-ai-training/
5	Cloudflare — registro de cambios de Pay Per Crawl (2025-07-01)	https://developers.cloudflare.com/changelog/2025-07-01-pay-per-crawl/	https://web.archive.org/web/2025/https://developers.cloudflare.com/changelog/2025-07-01-pay-per-crawl/
6	The Decoder — acuerdo Reddit–Google de datos de entrenamiento (~60M$/año)	https://the-decoder.com/reddit-signs-60-million-annual-training-data-deal-with-google/	https://web.archive.org/web/2024/https://the-decoder.com/reddit-signs-60-million-annual-training-data-deal-with-google/
7	Variety — acuerdo de licencia News Corp–OpenAI	https://variety.com/2024/digital/news/news-corp-openai-licensing-deal-1236013734/	https://web.archive.org/web/2024/https://variety.com/2024/digital/news/news-corp-openai-licensing-deal-1236013734/
8	Gizmodo — 17,6% de los sitios nuevos enteramente generados por IA (Stanford/Imperial/Internet Archive)	https://gizmodo.com/dead-internet-theory-is-17-of-the-way-to-becoming-reality-study-finds-2000751718	https://web.archive.org/web/2025/https://gizmodo.com/dead-internet-theory-is-17-of-the-way-to-becoming-reality-study-finds-2000751718
9	Merriam-Webster — Palabra del Año 2025 («slop»)	https://www.merriam-webster.com/wordplay/word-of-the-year	https://web.archive.org/web/20251201000000*/https://www.merriam-webster.com/wordplay/word-of-the-year
10	National Law Review — un tribunal ordena 20M de registros de ChatGPT (enero de 2026)	https://natlawreview.com/article/openai-loses-privacy-gambit-20-million-chatgpt-logs-likely-headed-copyright	https://web.archive.org/web/2026/https://natlawreview.com/article/openai-loses-privacy-gambit-20-million-chatgpt-logs-likely-headed-copyright
11	Press Gazette — exclusión de editores de los resúmenes de IA (CMA del Reino Unido, enero de 2026)	https://pressgazette.co.uk/platforms/google-regulation-uk/	https://web.archive.org/web/2026/https://pressgazette.co.uk/platforms/google-regulation-uk/
12	GNU Project — Richard Stallman, The Right to Read (1997)	https://www.gnu.org/philosophy/right-to-read.en.html	https://web.archive.org/web/2025/https://www.gnu.org/philosophy/right-to-read.en.html
13	stallman.org — Razones para no usar ChatGPT	https://stallman.org/chatgpt.html	https://web.archive.org/web/2025/https://stallman.org/chatgpt.html
14	Tor Project — sitio oficial / servicios onion	https://www.torproject.org/	https://web.archive.org/web/2025/https://www.torproject.org/

Comprar Bitcoin sin KYC en 2026: 5 mercados P2P comparados

Tue, 23 Jun 2026 00:00:00 +0000

Una nota sobre la financiación: CypherpunkGuide no lleva publicidad de vigilancia. Nada de redes publicitarias, píxeles de seguimiento ni contenido patrocinado. Nos sostienen vías transparentes: hoy, las donaciones; más adelante, una suscripción y afiliación alineada con nuestra línea editorial. Respondemos ante nuestras lectoras y lectores, no ante los anunciantes.

Comprar bitcoin suele implicar entregar una identificación con foto a un exchange regulado que guarda un registro permanente con tu nombre ligado a cada moneda que retiras. Los mercados entre pares son la alternativa: negocias directamente con otra persona, sin subir ningún documento, con tus claves y tus monedas siempre en tu poder. La demanda es real: uno de los primeros resultados al buscar «comprar bitcoin sin KYC» es un hilo de foro titulado «¿Dónde comprar BTC SIN KYC de verdad?», y ese de verdad dice mucho.

Esa frustración está justificada, y es la medida incómoda de la amenaza: tres de los mercados que las listas de «mejores opciones sin KYC» todavía recomiendan —LocalBitcoins, Paxful y LocalMonero— cerraron entre 2023 y 2025, y uno de los supervivientes perdió 11.59 BTC por un exploit en mayo de 2026. Elegir de una lista desfasada puede significar enviar dinero al clon de una marca muerta, o calcular muy mal dónde están realmente tus monedas mientras una operación sigue abierta.

¿Entonces cuál de los mercados supervivientes te conviene? La respuesta honesta es que depende de tres cosas que las listas aplastan en una valoración de estrellas: el modelo de custodia (dónde están tus monedas mientras dura la operación), cómo se resuelven las disputas y qué significa de verdad «sin KYC» en cada servicio. Compro y guardo bajo seudónimo, así que trato cualquier rastro documental de KYC (la verificación de identidad obligatoria) como un lastre permanente e irreversible. Para esta guía cotejé el diseño de custodia y las reglas de disputa de cada mercado con su propia documentación y su código fuente, y luego volví a comprobar cuáles siguen existiendo. Abajo está ese desglose para HodlHodl, Bisq, RoboSats, Peach y Vexl.

Lo que dice la lista	La realidad de 2026
«Usa LocalBitcoins o Paxful»	Ambos cerraron (2023, 2025); una búsqueda todavía puede llevarte a un clon
«Sin custodia significa que tus monedas están seguras»	Cuatro modelos de custodia distintos, cada uno con su propio modo de fallar
«Sin KYC significa que nunca te pedirán identificación»	Todavía pueden exigírtela: en una disputa, o por encima de un límite de gasto
«Bisq está más que probado»	Bisq v1 perdió 11.59 BTC por un exploit en mayo de 2026 (reembolsado; v2 es aparte)

Qué significa de verdad «sin KYC» en 2026 (y qué no)
#

Operar sin KYC significa que puedes abrir una cuenta y negociar sin presentar identificación oficial, pero no es la promesa de que nunca vayan a exigirte que te identifiques. El disparador cambia según el mercado: algunos solo pueden pedir identificación durante una disputa, otro aplica un umbral de gasto por encima del cual entra en juego la verificación, y un par de ellos no la piden nunca. Tratar «sin KYC» como un único interruptor de sí o no es el primer error, porque la excepción es justo el punto por donde tu privacidad puede romperse.

La distinción importa porque el sentido de comprar sin KYC es evitar un registro permanente que ate tu identidad a tus monedas. Un servicio capaz de exigir identificación durante una disputa crea ese registro en el momento en que algo va mal, que es precisamente cuando menos margen tienes para marcharte sin más. La versión honesta de la comparación es una tabla de disparadores, no una hilera de marcas verdes de verificación.

Mercado	¿Sin KYC para operar?	Cuándo aún pueden pedirte identificación
HodlHodl	Sí (correo + contraseña)	En una disputa, o ante sospecha de fraude/AML; negarte puede suspender la cuenta
Bisq 2 (Easy)	Sí (sin cuenta central)	Nunca ante la plataforma; en una disputa, la otra parte puede ver datos de pago
RoboSats	Sí (Tor, identidad de robot aleatoria)	Nunca ante la plataforma
Peach	Sí, hasta un tope diario bajo	Por encima del límite sin KYC, o si optas por más volumen (normas suizas)
Vexl	Sí (construido sobre tus contactos)	Nunca, pero tampoco hay custodia que te proteja

Un detalle que conviene sopesar si te importa la privacidad: como Peach opera como empresa suiza regulada, declara que conserva ciertos datos de disputa, dispositivo y pago durante diez años tras el borrado de la cuenta para cumplir la ley suiza contra el blanqueo de capitales. «Sin KYC» y «sin registro» no son la misma promesa.

Dónde están de verdad tus monedas: la cuestión de la custodia
#

Todos los mercados P2P se presentan con la etiqueta «sin custodia», pero esa sola palabra comprime cuatro diseños de escrow muy distintos, y es el diseño, no el marketing, lo que determina qué puede salir mal. La pregunta que de verdad importa es quién puede mover tus monedas durante los minutos u horas que una operación permanece abierta. Trato el modelo de custodia como la primera pregunta, antes que la marca, porque es lo único que no puedes arreglar después de que una operación salga mal.

Hay cuatro modelos en juego entre estos mercados, y se reparten en un espectro que va de «un mediador que no puede actuar solo» a «ningún escrow en absoluto». El escrow multisig (multifirma) inmoviliza las monedas en una dirección que necesita varias firmas para moverse; un hold-invoice de Lightning (una factura retenida) bloquea un pago que solo se liquida al confirmarse; un modelo de reputación renuncia al escrow central a cambio de una garantía social; y un servicio de presentación no guarda absolutamente nada.

Mercado	Modelo de custodia	Quién puede mover los fondos durante la operación	Si falla
HodlHodl	Multisig 2 de 3	Dos cualesquiera de {tú, la otra parte, HodlHodl}	HodlHodl media, pero no puede quedarse con los fondos por sí solo
Peach	Multisig 2 de 2	Tú y la otra parte	Ninguno actúa solo; una disputa necesita la cooperación de ambos (riesgo de bloqueo)
RoboSats	Hold-invoice de Lightning	El coordinador bloquea; libera al confirmarse	Los fondos quedan expuestos solo durante la ventana de liquidación (por defecto, ~3 horas)
Bisq 2 (Easy)	Reputación / depósito de garantía	Tú conservas tus claves todo el tiempo	La confianza se pondera por reputación; pensado para importes pequeños
Vexl	Ninguno, solo presentación	Tú, siempre	Sin escrow; liquidas directamente, con la sola protección de la confianza social

La conclusión es que «sin custodia» es información necesaria, pero no suficiente. Un multisig 2 de 3 te da un mediador que puede deshacer un bloqueo pero no robarte; un 2 de 2 elimina por completo al tercero, pero implica que una contraparte que desaparece o no coopera puede congelar la operación; un hold-invoice limita tu exposición a una ventana corta; y una app de pura presentación como Vexl no te da ningún recurso si la otra persona simplemente no paga. Ninguno es «el más seguro» en abstracto: cada uno cambia un riesgo por otro.

Cinco mercados sin KYC, comparados
#

Los cinco mercados que aún merece la pena usar en 2026 ocupan nichos realmente distintos —privacidad nativa de Lightning, comodidad móvil regulada, autocustodia de escritorio, escrow multisig sólido y pura presentación social—, así que la elección correcta depende de tu modelo de confianza, no de un ranking único. Aquí está el cara a cara, seguido de la versión honesta de una línea para cada uno.

Mercado	Custodia	Límite sin KYC	Postura regulatoria	Vías	¿Activo en 2026?
HodlHodl	Multisig 2 de 3	Ninguno (pero identificación en disputa)	Empresa británica (Hodlex Ltd)	On-chain + Lightning	Sí, en marcha desde 2016
Bisq 2 (Easy)	Reputación / depósito	Ninguno	No busca licencia	On-chain (+ Lightning)	Sí, escritorio, con nueva app de Android
RoboSats	Hold-invoice LN	Ninguno	Sin entidad central (federación)	Nativo de Lightning	Sí, desarrollo activo, con varios coordinadores
Peach	Multisig 2 de 2	Tope diario bajo	Empresa suiza, regulada por FINMA	Móvil primero, 100+ métodos fiat	Sí
Vexl	Ninguno (grafo social)	Ninguno	Checa (grupo SatoshiLabs)	Lo arreglas directamente	Sí, decenas de miles de usuarios

HodlHodl es el veterano: una plataforma web con escrow multisig 2 de 3 y un equipo humano de mediación, funcionando desde 2016 y con la liquidez más profunda de este grupo. A cambio: puede pedir identificación en una disputa y bloquea a los residentes de EE. UU.
Bisq 2 (Bisq Easy) es de escritorio, autocustodial y enruta por Tor (la red de anonimato) de forma predeterminada. Bisq Easy es un protocolo basado en reputación, pensado deliberadamente para compras pequeñas, sin escrow central: comodidad y privacidad a cambio de no ser el lugar para operaciones grandes.
RoboSats es la opción de privacidad nativa de Lightning: solo por Tor, identidades de robot desechables y un escrow de tipo hold-invoice. En 2026 funciona como federación —varios coordinadores independientes bajo un mismo cliente—, algo resistente, pero que implica que eliges un coordinador y heredas su reputación.
Peach es la opción móvil y regulada: una empresa suiza con multisig 2 de 2, más de 100 métodos de pago fiat y un tope sin KYC de unos CHF 1.000 al día (CHF 1.000 al mes para métodos anónimos como el efectivo, y CHF 100.000 al año) según la ley suiza. Ideal para compras pequeñas y regulares; la menor fricción; el mayor lastre regulatorio (incluida la retención de datos durante diez años ya mencionada).
Vexl es la rareza: una app sin escrow del grupo SatoshiLabs que te empareja con personas de tu red ampliada de contactos. No guarda nada y no rastrea nada, lo que también significa que no ofrece ninguna protección de escrow. Es para operaciones en las que ya confías en la otra parte.

Cuando una operación sale mal: resolución de disputas comparada
#

El momento que separa un mercado sólido de uno peligroso no es la operación que sale bien, sino la disputa, y aquí los modelos de custodia divergen con fuerza. Uno de ellos arrastra un riesgo de bloqueo que casi ninguna reseña menciona, y dos no ofrecen ningún plazo publicado. Antes de enviar dinero fiat a un desconocido, conviene que sepas exactamente quién arbitra y cuánto tiempo pueden quedar congeladas tus monedas.

Mercado	Quién arbitra	Plazo declarado	El riesgo a tener en cuenta
HodlHodl	Equipo de mediación de HodlHodl	Hasta 60 días; primera respuesta en ~12 h	Pueden pedir identificación como prueba en la disputa
Peach	Necesita a ambas partes (2 de 2)	No publicado	Bloqueo si una parte desaparece; datos guardados 10 años
RoboSats	El coordinador que elegiste	No publicado, depende del coordinador	Te toca verificar a ti la reputación del coordinador
Bisq 2 (Easy)	Mediación basada en reputación	No publicado	Pueden revelarse datos de pago; diseño para importes pequeños
Vexl	Sin arbitraje	—	Sin recurso: la confianza social es la única protección

HodlHodl es el único de los cinco que publica una política de disputas concreta: un equipo de mediación, un tope de 60 días y una primera respuesta de unas 12 horas. Es una ventaja real, aunque ese mismo proceso sea el punto donde pueden pedirte identificación. La federación de RoboSats aguanta sin problemas que cualquier coordinador concreto quede fuera de servicio, pero te traslada una carga real: la gestión de disputas vale tanto como el coordinador específico que hayas elegido, y no hay garantía de servicio para toda la red. Y el diseño 2 de 2 de Peach, por elegante que sea para eliminar al intermediario, implica que resolver una disputa necesita la cooperación de la otra parte: una contraparte que desaparece puede dejar las monedas atascadas.

Qué cambió en 2026 y los mercados que murieron
#

Una guía sin KYC solo es de fiar si está al día, porque este rincón de Bitcoin cambia muy rápido. Dos hechos reordenan el panorama de 2026: un incidente de seguridad grave en una plataforma de confianza desde hace años, y la muerte silenciosa de tres servicios que las listas viejas —e incluso las respuestas de la IA— todavía recomiendan. Cuando volví a comprobar los nombres que aún encabezan los resultados de «mejores opciones sin KYC», la brecha entre las listas y la realidad era lo bastante grande como para perder dinero por el camino.

Empecemos por el incidente, dicho sin rodeos porque importa a cualquiera que esté sopesando Bisq:

El 1 de mayo de 2026, un atacante explotó un fallo de validación en el protocolo de operaciones de Bisq v1 y robó 11.59 BTC a un pequeño número de usuarios. El proyecto reembolsó a los afectados y reforzó el protocolo en la v1.10.0 (16 de mayo de 2026). Bisq 2 (Bisq Easy) es una implementación aparte y no se vio afectada, pero su propio refuerzo de seguridad está previsto que termine hacia agosto de 2026, así que «Bisq 2 está reforzado» es un todavía-no, no un hecho.

La lección no es «evita Bisq»: el equipo reveló el fallo, reembolsó a los usuarios y publicó una corrección, que es más de lo que logran la mayoría de las plataformas. La lección es usar el cliente actual, mantener Bisq Easy para importes pequeños tal como fue diseñado, y no dar por hecho que una base de código independiente hereda una madurez que aún no ha alcanzado.

Y luego están los fantasmas. Las guías viejas, y algunos resúmenes actuales de la IA, todavía mandan a la gente a mercados que ya no existen:

LocalBitcoins cerró el 17 de febrero de 2023. LocalMonero echó el cierre en 2024. Paxful cesó operaciones el 1 de noviembre de 2025. Buscar sus nombres puede sacar a flote clones de phishing que se aprovechan de la confianza en una marca muerta. Comprueba que estás en un servicio vivo y oficial antes de enviar nada: una plataforma cerrada o suplantada es una de las formas más fáciles de perder fondos en este terreno.

Un nombre más pertenece a la columna de «verifica primero» en lugar de a la comparación: AgoraDesk, el sucesor de LocalMonero, anunció su cierre en 2024 y su estado actual no está claro, y está orientado a Monero antes que a Bitcoin, así que lo dejé fuera de la tabla de arriba en lugar de recomendar un servicio cuya disponibilidad no pude confirmar. Esa misma disciplina —nunca enviar a un servicio que no hayas confirmado que está vivo— es el hábito de seguridad más barato de toda esta guía.

Hay una razón de fondo para que todo esto se mueva tanto: la presión legal documentada en cómo funciona el rastreo on-chain de Bitcoin en 2026 recayó sobre los coordinadores y los transmisores de dinero, y los mercados hechos para sobrevivir a ella son los que no tienen coordinador y los autocustodiales. Comprar sin KYC es, además, solo la mitad de mantener la privacidad: si vuelves a atar tu identidad en cuanto esas monedas tocan una dirección reutilizada, o describes la operación en una publicación de foro que un modelo puede leer, la privacidad se esfuma. La mitad on-chain está en esa misma guía; la mitad off-chain, la de la inferencia, es cómo la desanonimización a escala de IA deshace la privacidad que creías tener.

En conclusión: ¿cuál te conviene?
#

No hay un único mercado sin KYC «mejor»; está el que encaja con tu modelo de confianza —cuánto valoras la privacidad de Lightning, cómo de grandes son tus operaciones, cuánta protección de escrow necesitas y si ya confías en la otra parte—. Define eso primero, porque elegir mal es donde la gente pierde privacidad o fondos. Ajusta el mercado a tu situación, no a un ranking.

Compras pequeñas y regulares con la menor fricción: Peach (móvil, más de 100 vías fiat, un tope diario sin KYC) o Bisq Easy (basado en reputación, pensado para importes pequeños). Ambos aceptan unos límites modestos a cambio de comodidad.
Máxima privacidad, nativa de Lightning: RoboSats, solo por Tor, identidades desechables y exposición de escrow corta. Asume que debes elegir un coordinador y confiar en él, y que no hay un plazo de disputa publicado.
Operaciones más grandes y el escrow más sólido: HodlHodl, multisig 2 de 3 y un proceso de mediación real. Asume que pueden pedirte identificación en una disputa y que los residentes de EE. UU. están bloqueados.
Ya confías en la otra parte (un amigo, un meetup): Vexl, pero entra con los ojos abiertos: no hay escrow; el grafo social es la única protección.

Elijas el que elijas, la secuencia es la misma: confirma que el servicio está vivo, júzgalo por su modelo de custodia y de disputa antes que por su valoración de estrellas, mantén pequeñas las primeras operaciones y —una vez que tengas monedas adquiridas sin KYC— protégelas on-chain para no deshacer en el libro mayor lo que protegiste en el punto de compra. El marco para ese último paso es el complemento de esta guía: párate a definir tu modelo de amenazas en la era de la IA y luego defiende los eslabones concretos que te importan.

Puntos clave

Las listas viejas son peligrosas: LocalBitcoins (2023), Paxful (2025) y LocalMonero (2024) ya no existen; una búsqueda todavía puede sacar a flote el clon de una marca muerta, una forma muy real de perder fondos.
«Sin custodia» esconde cuatro modelos de escrow: multisig 2 de 3 (HodlHodl), 2 de 2 (Peach), un hold-invoice de Lightning (RoboSats) y ninguno en absoluto (Vexl); el modelo decide qué puede salir mal.
«Sin KYC» no es absoluto: HodlHodl puede pedir identificación en una disputa, Peach es sin KYC solo hasta un tope diario bajo, y Peach conserva los datos de disputa durante diez años por la ley suiza.
El incidente de Bisq en 2026 es real, pero gestionado: Bisq v1 perdió 11.59 BTC por un fallo de protocolo en mayo de 2026 (usuarios reembolsados; corregido en la v1.10.0); Bisq 2 es una base de código independiente con su propio refuerzo previsto hacia agosto de 2026.
Ajusta el mercado a tu modelo de confianza: RoboSats para privacidad de Lightning, Peach o Bisq Easy para compras pequeñas, HodlHodl para un escrow más sólido, y Vexl solo cuando ya confías en la otra parte.

Preguntas frecuentes
#

¿Es legal comprar Bitcoin sin KYC?
#

Esto no es asesoramiento legal, y depende de tu jurisdicción y tu conducta. En la mayoría de los sitios, comprar bitcoin entre pares es lícito, y los procesos estadounidenses de 2024-2025 se dirigieron contra los operadores de servicios de mezcla y transmisión de dinero, no contra particulares que buscan privacidad en sus transacciones. Pero obligaciones como la declaración de impuestos siguen vigentes para ti, sin importar cómo adquiriste las monedas; consulta a un profesional cualificado para tu caso.

¿Sigue siendo seguro usar Bisq tras el hackeo de mayo de 2026?
#

El exploit afectó a Bisq v1, donde un fallo de validación en el protocolo de operaciones permitió a un atacante robar 11.59 BTC a un pequeño número de usuarios; el proyecto los reembolsó y reforzó el protocolo en la v1.10.0. Bisq 2 (Bisq Easy) es una implementación aparte que no se vio afectada, aunque su propio trabajo de seguridad está previsto que termine hacia agosto de 2026. Si usas Bisq, ejecuta el cliente más reciente y mantén pequeñas las operaciones de Bisq Easy, tal como está diseñado el protocolo.

¿Cuál es el modelo de escrow más seguro para una operación P2P?
#

Depende del riesgo que más quieras evitar. Un multisig 2 de 3 (HodlHodl) suma un mediador que puede deshacer un bloqueo pero no quedarse con tus fondos por sí solo. Un multisig 2 de 2 (Peach) elimina al tercero por completo, pero puede bloquearse si una contraparte desaparece. Un hold-invoice de Lightning (RoboSats) limita tu exposición a una ventana de liquidación corta. Sin escrow alguno (Vexl), la confianza social es tu única protección.

¿Qué mercado sin KYC es mejor para importes pequeños?
#

Peach y Bisq Easy están pensados ambos para compras pequeñas y regulares. Peach es móvil primero, con un tope diario sin KYC y muchos métodos de pago fiat; Bisq Easy es un protocolo de escritorio basado en reputación, sin escrow central. Para obtener privacidad sobre Lightning en cantidades pequeñas, RoboSats es la opción más sólida.

¿Siguen funcionando ahora que LocalBitcoins y Paxful han cerrado?
#

Sí. HodlHodl, Bisq, RoboSats, Peach y Vexl están todos activos en 2026. La advertencia es la contraria: LocalBitcoins (2023), Paxful (2025) y LocalMonero (2024) han cerrado, así que comprueba que estás en un servicio vivo y oficial; los clones que se aprovechan del nombre de una marca muerta son una forma habitual de perder fondos.

#	Fuente	URL	Copia archivada
1	Bisq — «Where Bisq Stands After the Security Incident» (mayo de 2026)	https://bisq.network/blog/where-bisq-stands-after-security-incident/	https://web.archive.org/web/*/https://bisq.network/blog/where-bisq-stands-after-security-incident/
2	LocalBitcoins — Aviso de cierre del servicio (febrero de 2023)	https://localbitcoins.com/service_closure/	https://web.archive.org/web/*/https://localbitcoins.com/service_closure/
3	Paxful — Anuncio de cierre (noviembre de 2025)	https://paxful.com/blog/paxful-closure-announcement	https://web.archive.org/web/*/https://paxful.com/blog/paxful-closure-announcement
4	RoboSats — Documentación del escrow (hold-invoice de Lightning)	https://learn.robosats.org/docs/escrow/	https://web.archive.org/web/*/https://learn.robosats.org/docs/escrow/
5	RoboSats — Modelo de federación	https://github.com/RoboSats/robosats/blob/main/federation.md	https://web.archive.org/web/*/https://github.com/RoboSats/robosats/blob/main/federation.md
6	Peach Bitcoin — Cómo comprar BTC sin KYC	https://peachbitcoin.com/how-to-buy-btc-no-kyc/	https://web.archive.org/web/*/https://peachbitcoin.com/how-to-buy-btc-no-kyc/
7	HodlHodl — Reglas de disputa	https://hodlhodl.com/pages/dispute_rules	https://web.archive.org/web/*/https://hodlhodl.com/pages/dispute_rules
8	Bisq — Bisq 2 / Bisq Easy (wiki)	https://bisq.wiki/Bisq_2	https://web.archive.org/web/*/https://bisq.wiki/Bisq_2
9	LocalMonero / AgoraDesk — cobertura del cierre (2024)	https://www.tftc.io/agoradesk-shuts-down-after-seven-years/	https://web.archive.org/web/*/https://www.tftc.io/agoradesk-shuts-down-after-seven-years/

Cuando el gobierno filtra tus datos: manual de defensa 2026

Fri, 12 Jun 2026 00:00:00 +0000

Puedes eliminar una cuenta de redes sociales. No puedes eliminarte de la agencia tributaria, del sistema de salud ni del registro nacional de identidad. Los datos que entregas a un gobierno no son una decisión que puedas reconsiderar: son el precio de existir como ciudadano. Ahí está todo el problema, en esa asimetría. Cuando una empresa pierde tus datos puedes, al menos en principio, marcharte. Cuando los pierde el Estado, sigues obligado a entregar más.

Y en 2026 el Estado los está perdiendo a gran escala. En apenas unas semanas de esta primavera, un contratista de la propia agencia de ciberdefensa de Estados Unidos dejó durante seis meses las claves de administración de sistemas gubernamentales en la nube a la vista, en un repositorio de código público; una agencia federal de salud publicó los números de la Seguridad Social de varios médicos en un directorio en línea; y el Servicio Nacional de Salud británico (NHS) confirmó que el personal de una empresa privada de análisis de datos podía llegar a registros identificables de pacientes. Ninguno fue un ataque sofisticado de un Estado-nación. Fueron fallos institucionales corrientes, de los que se repiten porque los incentivos que los producen nunca cambian.

Entonces, si no puedes evitar la filtración ni negarte a dar los datos, ¿qué puedes hacer de verdad? Esta no es una guía para confiar en mejores instituciones. La escribí como un manual construido sobre un modelo de amenazas claro —una descripción sencilla de qué proteges, de quién y qué ocurre cuando se filtra— y sobre una sola premisa: toda base de datos que contenga tus datos terminará siendo vulnerada, así que tu defensa tiene que vivir en capas que tú controlas, no en las promesas de la institución.

Los tres fallos de 2026
#

Empieza por las pruebas, porque el patrón solo se vuelve accionable cuando lo ves repetirse. Tres incidentes documentados de 2026, en dos gobiernos y a ambos lados de la frontera público-privada, muestran la misma debilidad estructural desde tres ángulos. Una filtración (breach) significa aquí que datos sensibles quedaron al alcance de alguien que no debía tenerlos, ya sea por error, por exposición o por un acceso demasiado amplio.

Incidente	Qué quedó expuesto	Causa de fondo	Estado
Filtración de CISA en GitHub	Claves de administrador de 3 cuentas gubernamentales en la nube + contraseñas en texto plano (844 MB)	El contratista sincronizó archivos de trabajo por un repositorio público, con el escaneo de secretos desactivado	Repositorio retirado; revisión de la agencia en curso
Directorio de Medicare (CMS)	Números de la Seguridad Social de profesionales médicos	Los SSN se escribieron en el campo equivocado de una base de datos pública	Portal dado de baja
Acceso de Palantir × NHS	Registros identificables de pacientes al alcance del personal de un proveedor	Acceso administrativo por contrato, no un ataque	Contrato activo; acceso vigente

La filtración de CISA es el caso más claro. Un contratista de la Cybersecurity and Infrastructure Security Agency (CISA, la agencia de ciberdefensa de Estados Unidos) —el organismo encargado precisamente de defender las redes estadounidenses— mantenía en GitHub (un popular sitio de alojamiento de código) un repositorio público con credenciales de administrador de tres cuentas gubernamentales en la nube, archivos de contraseñas en texto plano, certificados de firma y tokens de acceso: alrededor de 844 megabytes de material interno. Según KrebsOnSecurity, el empleado usaba el repositorio para sincronizar archivos entre su equipo del trabajo y el de casa, y había desactivado a propósito la protección integrada de la plataforma que impide subir secretos. La exposición duró cerca de seis meses, hasta que la firma de seguridad GitGuardian la descubrió; según se informó, las claves de la nube siguieron siendo válidas unas 48 horas después de que el repositorio se retirara.

La filtración de CMS muestra el mismo descuido con el único identificador que nunca podrás reemplazar. Los Centros de Servicios de Medicare y Medicaid (CMS, la agencia estadounidense que gestiona el seguro médico público para personas mayores y de bajos ingresos) publicaron un nuevo directorio público de proveedores de Medicare y, como informó The Hill después de que el Washington Post lo sacara a la luz primero, al menos varias decenas de números de la Seguridad Social de esos proveedores —más de un centenar, según informes posteriores— quedaron expuestos porque los números se habían introducido en el campo equivocado. La agencia retiró el portal. Para los estadounidenses, el número de la Seguridad Social (SSN, un identificador único y permanente de cada persona) es lo más parecido a una llave maestra de la identidad: una vez público, queda comprometido de por vida.

El caso Palantir–NHS es distinto en su naturaleza, y la distinción importa. Esto no fue un ataque. Como informó The Register, NHS England confirmó que el personal de Palantir (la gran empresa estadounidense de análisis de datos) —el contratista privado que opera su Federated Data Platform de 330 millones de libras esterlinas (la plataforma central de datos de pacientes del NHS)— podía tener acceso administrativo a información identificable de pacientes. No hizo falta ningún atacante; el acceso estaba escrito en el propio funcionamiento del sistema. El grupo de la sociedad civil Medact documentó la preocupación resultante, y el Gran Mánchester siguió siendo el único organismo regional que se negó a sumarse. La lección no es «entró un villano». Es que concentrar los registros de salud de toda una nación bajo un único proveedor es, en sí mismo, la exposición, antes de que nadie haga un uso indebido de ellos.

No son los únicos. Retrocede un año y vuelve a aparecer la misma forma: a partir de finales de 2024 y descubierta a comienzos de 2025, la contratista gubernamental Conduent —que opera sistemas de Medicaid, de pensión alimenticia y de ayuda alimentaria para varios estados— sufrió una filtración que expuso los datos de la Seguridad Social y de salud de más de 25 millones de estadounidenses. Sus sistemas se restablecieron, aunque los litigios continúan y los identificadores filtrados no caducan. Varios incidentes esta primavera, uno el año anterior, dos países, lo público y lo privado: cambian los actores y el fallo no.

Por qué los gobiernos filtran de forma estructural
#

La explicación cómoda es la mala suerte: un empleado descuidado, un error de dedo, un mal proveedor. La explicación útil es que esto no son accidentes, sino productos de cómo están construidos los sistemas. Cuatro fuerzas estructurales hacen que la fuga de datos del gobierno sea casi inevitable, y ponerles nombre es lo que te permite defenderte de la categoría en lugar de perseguir cada titular.

Fuerza estructural	Mecanismo	Visto en
Dependencia de contratistas	La responsabilidad se diluye con cada traspaso a un proveedor externo	Claves de CISA en manos de un contratista; datos del NHS en manos de Palantir
Shadow IT	Herramientas no autorizadas sacan los secretos fuera de las salvaguardas	El repositorio público de GitHub del contratista
Agregación	Un solo error expone a millones cuando los registros están centralizados	Plataforma del NHS; los 25 millones de registros de Conduent
Rendición de cuentas asimétrica	La institución paga una multa; tú heredas el riesgo permanente	Los tres casos de 2026

La dependencia de contratistas diluye la responsabilidad. Los Estados modernos no operan la mayor parte de su propia tecnología: la subcontratan. Las claves de CISA estaban con un contratista; los registros del NHS, con Palantir; los 25 millones de registros, con Conduent. Cada traspaso suma una organización cuya seguridad no puedes ver y cuyos incentivos no son los tuyos. La agencia es dueña de la consecuencia; el contratista, del portátil.

El shadow IT —las herramientas que la gente usa sin aprobación— saca los secretos fuera de las salvaguardas. El repositorio público del empleado de CISA era shadow IT: una comodidad no autorizada que sorteaba todos los controles que la agencia creía tener. Cada vez que un proceso es demasiado lento, las personas construyen un atajo a su lado, y el atajo rara vez tiene barreras de protección.

La agregación convierte un error pequeño en una catástrofe. Cuando los registros están dispersos, un error expone a unos pocos. Cuando una plataforma federada o un directorio nacional los concentran, el mismo error expone a millones. La centralización se vende como eficiencia; también es un único punto de fallo catastrófico.

La rendición de cuentas es asimétrica. Cuando ocurre una filtración, la institución emite un comunicado, quizá paga una multa y sigue adelante. Tú heredas el riesgo permanente. Este desequilibrio es la razón más profunda para asumir la filtración: la parte que pierde tus datos no carga con el costo de perderlos, así que nunca tiene motivos suficientes para detenerse.

Junta todo esto y la conclusión no es cinismo: es una guía de diseño. No puedes reformar cuatro fuerzas estructurales desde fuera. Lo que sí puedes es construir una arquitectura personal que dé por hecho que fallarán.

La arquitectura de defensa: asume el 100 % de filtración
#

Aquí está la parte que ninguna lista de respuesta a incidentes te da, porque no se puede vender como un arreglo único: una arquitectura permanente que asume que toda institución que guarda tus datos terminará perdiéndolos. Piénsala como cinco capas, ordenadas de la mentalidad a lo mecánico. No las completarás todas de golpe; las construyes como construyes cualquier defensa, una capa a la vez, más fuerte allí donde tu exposición es mayor.

Capa 1: adopta la mentalidad de asumir la filtración. Un modelo de amenazas es, sin más, una respuesta clara a «qué protejo, de quién y qué pasa si se filtra». El cambio aquí es dejar de modelar las instituciones como seguras y empezar a modelarlas como custodios temporales de datos que terminarán escapándose. No es paranoia; es lo que muestra el historial de 2026. Una vez que das por hecho que la base de datos se filtrará, cada decisión posterior —qué envías, bajo qué identidad, con qué plan de respaldo— se vuelve más fácil.

Capa 2: revela lo mínimo. No puedes negarte a la agencia tributaria, pero la mayor parte de la extracción de datos no es legalmente obligatoria. El programa de fidelización, el campo opcional del perfil, el «verifica con tu documento de identidad» en un servicio que no lo necesita: cada uno es un depósito que puede filtrarse más adelante. Trata cada revelación opcional como un futuro aviso de filtración con tu nombre encima. El control de privacidad más eficaz es el dato que nunca se recolectó. Para una auditoría práctica de lo que ya se escapó tras años de redes sociales —y de por qué eliminar rara vez lo borra— mira hasta qué punto es permanente tu huella digital.

Capa 3: compartimenta tu identidad. Yo mantengo una dirección de correo distinta para cada contexto importante —finanzas, salud, vida pública— para que una base de datos filtrada no pueda enlazarse con las demás. Un gestor de contraseñas como el de código abierto Bitwarden hace viables las credenciales únicas por sitio, y un proveedor como Proton Mail admite alias por servicio que puedes quemar si se filtran. Compartimentar no detiene una filtración; impide que una filtración se convierta en todas. (Para la versión más profunda de esto —seudónimos y separación jurisdiccional— mira el trabajo de Cora sobre la identidad autosoberana.)

Capa 4: blinda los identificadores que no puedes cambiar. Algunos datos son permanentes: tu número de la Seguridad Social, tu fecha de nacimiento, tus datos biométricos. Como no puedes rotarlos, los defiendes en el punto de uso. En Estados Unidos, congela tu crédito en las tres grandes agencias de crédito de EE. UU. —Equifax, Experian y TransUnion (las empresas que guardan tu historial crediticio)—, lo que bloquea la apertura de cuentas nuevas a tu nombre; es gratis y reversible. Suma alertas de fraude. Y pasa tus accesos importantes a la autenticación multifactor por hardware (MFA, una segunda verificación además de la contraseña; aquí, una llave de seguridad física, el factor más fuerte), para que un número robado por sí solo no abra la puerta. Esta es la única capa donde las listas de respuesta a incidentes y esta arquitectura coinciden; la diferencia es que aquí es higiene permanente, no una reacción de pánico.

Capa 5: separa tus herramientas y tus jurisdicciones. Reparte tu confianza entre proveedores y regímenes legales que no estén todos al alcance del mismo actor. Mensajería cifrada para las conversaciones sensibles, una VPN (red privada virtual, que enmascara tu conexión) sin registros como Mullvad para romper el vínculo entre tu red y tu actividad, y almacenamiento que no esté concentrado bajo una sola empresa o un solo gobierno. La meta es que ninguna filtración, citación judicial o relación con un proveedor exponga el cuadro completo.

Fíjate en lo que esta arquitectura no exige: no exige que la institución sea de fiar. Ese es el punto. Cada capa es un control que tú sostienes, no una promesa que te dan.

Si ya estás expuesto
#

Si tus datos están en una de estas filtraciones —y, estadísticamente, ya lo están—, los pasos inmediatos son pocos, pero vale la pena darlos hoy, antes de la arquitectura permanente de más arriba. Estos son los pasos que trato como no negociables; tómalo como triaje, no como el tratamiento completo.

Congela tu crédito en los tres burós (gratis, en línea, reversible). Es la acción individual de mayor palanca.
Activa alertas de fraude en tus cuentas financieras y enciende las notificaciones de transacciones.
Da por comprometidos los identificadores permanentes. Un número de la Seguridad Social filtrado no caduca; rota todo lo que puedas (contraseñas, números de cuenta) y defiende el resto en el punto de uso.
Pasa a MFA por hardware primero en el correo y en las finanzas: el correo es la vía de recuperación de todo lo demás.
Vigila el phishing dirigido. Los datos filtrados vuelven personales las estafas; quien te llama conociendo tus datos reales está usando información filtrada, no una prueba de legitimidad.

Estos pasos cierran la ventana inmediata. La arquitectura por capas es lo que impide que la próxima filtración —y la habrá— te cueste de la misma manera dos veces.

Puntos clave

Asume la filtración: no puedes optar por no darle tus datos al Estado, así que modela cada base de datos del gobierno como un custodio temporal que terminará filtrándose.
El patrón es estructural: la dependencia de contratistas, el shadow IT, la agregación y la rendición de cuentas asimétrica hicieron predecibles —no fortuitos— los fallos de 2026 en CISA, CMS y Palantir-NHS.
Defiéndete en capas que tú controlas: revela lo mínimo, compartimenta la identidad (correos únicos + gestor de contraseñas) y blinda los identificadores permanentes (congelar el crédito + MFA por hardware).
No hay un remedio legal fiable: la inmunidad soberana y los topes a las indemnizaciones vuelven los litigios por filtración lentos e inciertos; tu arquitectura por capas es el remedio que de verdad controlas.
Triaje hoy, arquitectura mañana: si ya estás expuesto, congela el crédito y pasa a MFA por hardware ahora; después construye la defensa permanente de cinco capas.

Preguntas frecuentes
#

¿Puedo demandar al gobierno por filtrar mis datos?
#

A veces, pero rara vez es un remedio con el que puedas contar. Las reglas de inmunidad soberana, los topes a las indemnizaciones y la dificultad de probar un daño concreto vuelven lentos e inciertos los litigios por filtración del gobierno. Trata la acción legal como un posible añadido, no como una defensa: tu arquitectura por capas es lo que de verdad reduce tu exposición.

¿Basta con congelar el crédito?
#

No, pero es la mejor acción individual. Congelar el crédito bloquea la mayoría del fraude de apertura de cuentas, pero no hace nada contra el robo de identidad médica, el fraude fiscal o el uso indebido de un número de la Seguridad Social filtrado fuera de las solicitudes de crédito. Combínalo con alertas de fraude, MFA por hardware y compartimentación de la identidad.

Si los datos ya se filtraron, ¿no es inútil defenderse?
#

No. La mayor parte del daño de una filtración ocurre después de la exposición, cuando los datos filtrados se usan para abrir cuentas, suplantarte o armar estafas dirigidas. Congelar el crédito y reforzar tus accesos bloquea el paso de la explotación incluso cuando los datos de base ya están fuera.

¿Esto solo se aplica a Estados Unidos?
#

Los detalles cambian —congelar el crédito es un mecanismo estadounidense y el caso del NHS es británico—, pero la arquitectura es universal. Todos los países agregan datos de sus ciudadanos y externalizan su tratamiento. La minimización, la compartimentación y la protección de los identificadores permanentes valen vayas donde vayas.

Referencias
#

#	Fuente	URL	Copia archivada
1	CISA Admin Leaked AWS GovCloud Keys on GitHub — KrebsOnSecurity	https://krebsonsecurity.com/2026/05/cisa-admin-leaked-aws-govcloud-keys-on-github/	archivada
2	How We Got a CISA GitHub Leak Taken Down — GitGuardian	https://blog.gitguardian.com/how-we-got-a-cisa-github-leak-taken-down-in-26-hours/	archivada
3	CMS Publishes Social Security Data — The Hill	https://thehill.com/policy/healthcare/5860959-cms-publishes-social-security-data/	archivada
4	Medicare Portal Exposed Providers’ SSNs — Washington Post	https://www.washingtonpost.com/health/2026/04/30/medicare-portal-social-security-numbers-exposed/	archivada
5	NHS England Confirms Palantir Staff Can Access Patient Data — The Register	https://www.theregister.com/databases/2026/05/12/nhs-england-confirms-palantir-staff-can-access-patient-data/5238712	archivada
6	Briefing: Palantir and NHS Data Systems — Medact	https://www.medact.org/2026/resources/briefings/briefing-palantir-fdp/	archivada
7	Right to Erasure (Art. 17) — GDPR	https://gdpr-info.eu/art-17-gdpr/	archivada

Vigilamos a los rastreadores de IA: 17 días de registros (2026)

Wed, 08 Jul 2026 00:00:00 +0000

Toda guía para mantener a los modelos de IA lejos de lo que escribes termina en las mismas tres palancas: añade el nombre del rastreador al robots.txt (el archivo de texto que pide con cortesía a los bots qué no visitar), publica un llms.txt (una versión más reciente de esa misma idea, pensada para la IA) o dile a tu proveedor de alojamiento que «bloquee GPTBot». Las tres dan por sentado lo mismo: que el bot que llama a tu puerta es quien su user-agent dice ser. Y un user-agent no es más que una línea de texto que un programa envía para anunciarse; se teclea, no se demuestra, y cualquier cosa puede teclear cualquier cosa.

Así que dejamos de teorizar y miramos. Durante 17 días —del 19 de junio al 5 de julio de 2026— registramos cada rastreador de IA que se identificó como tal al tocar este sitio: 1635 solicitudes repartidas entre 14 user-agents comerciales de IA distintos, desde ClaudeBot y GPTBot hasta nombres que la mayoría de los editores no ve jamás. Entonces dimos el paso que el consejo se salta: cotejamos la dirección de origen real de cada solicitud contra la lista de direcciones que publica la propia empresa nombrada. El resultado se divide con nitidez en tres grupos, y solo uno de ellos trae buenas noticias. Esta es la medición detrás de una promesa que hicimos antes —que vigilamos los propios registros de rastreadores de este sitio— y es el suelo empírico bajo el cercamiento de la web abierta que defendimos en otro lugar.

El hallazgo incómodo no es que los rastreadores de IA mientan. Es que los que más quieres frenar son justo los que tus herramientas no pueden tocar, porque todo el régimen de exclusión funciona solo cuando el rastreador es a la vez bastante honesto para obedecer y bastante transparente para dejarse comprobar. Lo que sigue es lo que 17 días de registros de un sitio pequeño revelaron sobre cuál es cuál.

Qué medimos, y cómo lo reproducirías tú
#

Recogimos 17 días consecutivos de registros de borde, agrupamos cada solicitud por su cadena de user-agent y nos quedamos con las 14 que nombran un sistema comercial de IA. Esa es la afirmación en bruto: un bot dijo «soy GPTBot». Verificarlo es otra cuestión, más difícil, y tiene una respuesta objetiva: ¿cae la IP de origen de la solicitud dentro del rango de direcciones que OpenAI, Anthropic, Google o Amazon publica para su propio rastreador? Todo gran operador difunde esa lista precisamente para que los servidores distingan un bot real de un impostor.

Las 1635 visitas se ordenaron en una jerarquía nítida. El recuento completo por agente acompaña a este artículo como un resumen en texto plano —solo cifras agregadas, ningún dato de visitantes, las redes de rastreo nombradas únicamente a nivel de /24—; un /24 es un bloque de 256 direcciones IP consecutivas, la unidad más pequeña en que se reparten estas redes (resumen de verificación).

User-agent de IA	Solicitudes (17 días)	Se verifica contra las IP publicadas	Fuente de verificación (a fecha de)
ClaudeBot	553	546 (99 %)	Lista de bots de Anthropic (2026-05)
Amazonbot	344	120 (35 %)	IP de rastreadores de Amazon (2026-04)
GPTBot	310	301 (97 %)	Lista GPTBot de OpenAI (2025-10)
meta-externalagent	179	sin método publicado	—
Bytespider (ByteDance)	112	sin método publicado	—
PerplexityBot	24	5 (21 %)	Lista de bots de Perplexity (2025-02)
GoogleOther	12	12 (100 %)	Lista de rastreadores de Google (2026-06)

Otros siete agentes de bajo volumen —101 solicitudes más— completan los 14; la lista íntegra está en el archivo de resumen.

Una solicitud verificada es aquella cuya IP de origen queda respaldada por la empresa nombrada. Los porcentajes están ponderados por número de solicitudes y, cuando el volumen de un bot es pequeño, lo decimos sin rodeos: el «21 %» de PerplexityBot son 5 visitas de 24, demasiado pocas para acusar a una empresa, y así lo tratamos más abajo. Dos salvedades atan cada cifra de aquí: esto es un solo sitio nuevo y de poco tráfico a lo largo de 17 días, no toda la web; y una lista de direcciones publicada vale solo hasta la fecha que lleva —la de Perplexity tiene 17 meses, y volveremos a ella—.

Los rastreadores declarados son casi todos reales
#

Empecemos por la buena noticia, porque es real e importa: cuando el rastreador de un gran laboratorio se anuncia, casi siempre dice la verdad. GPTBot se verificó al 97 %, ClaudeBot al 99 % y GoogleOther al 100 % contra los rangos de direcciones que publica cada empresa. La abrumadora mayoría del tráfico de «GPTBot» y «ClaudeBot» salió de verdad de la infraestructura de OpenAI y Anthropic. Una advertencia para quien haya venido aquí a excluirse en concreto del entrenamiento de IA: GoogleOther es un rastreador de Google de propósito general, un token distinto de Google-Extended, que es el que de verdad rige el entrenamiento de Gemini; y cada visita de Google-Extended que registramos vino del grupo suplantador de más abajo, no de Google.

Aquí es donde se equivoca la lectura cínica. Si añades GPTBot a tu robots.txt o bloqueas los rangos de Anthropic en tu borde, sí detendrás al GPTBot real y al ClaudeBot real: publican sus direcciones (OpenAI, Anthropic), respetan el archivo, y los datos independientes de toda la red coinciden en que los grandes rastreadores declarados son los actores dominantes, aunque su cuota individual se mueva de un año a otro (Cloudflare, 2025). El rastreador honesto es un problema resuelto. Si cada bot de IA se comportara como GoogleOther —con nombre, con rango, comprobable—, este artículo sería una nota al pie.

Un rastreador declarado se resiste a esta clasificación limpia, y la honestidad obliga a nombrarlo. Solo 5 de nuestras 24 visitas de PerplexityBot cayeron dentro del rango publicado por Perplexity; pero 24 visitas son demasiado pocas para juzgar a una empresa, y la propia lista de Perplexity tiene 17 meses, así que un fallo puede no significar más que un archivo caducado. De fondo hay una disputa viva: Cloudflare informó en agosto de 2025 de que Perplexity usaba rastreadores sigilosos y no declarados para colarse pese a las reglas de no rastreo (Cloudflare, 2025), y Perplexity rechazó en público ese encuadre (Perplexity, 2025): sostiene que un «agente» que trae una página a petición del usuario no es lo mismo que un «bot» que se adelanta, y que Cloudflare le había atribuido por error el tráfico de un servicio ajeno de navegador en la nube. A partir de una IP y nada más no podemos distinguir a un impostor externo del propio recolector no declarado de una empresa; así que, con 24 visitas, no concluimos nada sobre Perplexity y nos limitamos a señalarlo como el rastreador declarado que peor supera nuestras comprobaciones.

La cifra que se nos quedó grabada es otra, más afilada: el minúsculo resto entre los rastreadores que sí se verificaron. Las 7 visitas sin verificar de ClaudeBot y las 9 de GPTBot no eran ruido al azar. Todas y cada una llevaban al mismo lugar; un lugar que no tenía por qué reclamar ninguno de los dos nombres.

Una red vistió catorce rostros
#

Este es el hallazgo que dio nombre al artículo. Cuatro de aquellos bloques de direcciones —cuatro /24— quedaban por completo fuera del rango publicado de toda empresa, y en 17 días esos cuatro bloques por sí solos produjeron 99 solicitudes que portaban los user-agents de 14 empresas de IA distintas. Un solo /24, 185.213.174.0/24, suplantó él solito a las catorce: GPTBot, ClaudeBot, PerplexityBot, Amazonbot, Google-Extended, Bytespider, cohere-ai y siete más, todos desde una misma red pequeña.

Ponlo ahora al lado de un rango legítimo. Dos bloques contiguos de Anthropic —216.73.216.0/24 (281 solicitudes) y su vecino 216.73.217.0/24 (265)— enviaron entre ambos 546 solicitudes, y todas y cada una decían ClaudeBot: una entidad, una identidad, inspecciones el bloque que inspecciones. Averigua quién es el dueño de cada red y el contraste remata la idea. La titularidad sale de RDAP, el registro público que asigna una IP a la organización a la que se le adjudicó:

Red (/24)	Qué reclamaba	Registrada a nombre de (RDAP)
`216.73.216.0/24`	ClaudeBot, 281× y nada más	Anthropic, PBC (EE. UU.)
`185.213.174.0/24`	14 empresas de IA distintas	NextGenWebs, un alojamiento web (Países Bajos)
`45.45.237.0/24`	parte del grupo suplantador	Infraly, LLC (EE. UU.)
`23.161.169.0/24`	parte del grupo suplantador	Infraly, LLC (EE. UU.) — el mismo dueño
`154.58.229.0/24`	parte del grupo suplantador	Limestone Networks (EE. UU.)

Los bloques legítimos caen dentro del propio rango publicado de Anthropic, y el que resolvimos en RDAP devuelve Anthropic, PBC. Las subredes suplantadoras están registradas a nombre de empresas comerciales de alojamiento —infraestructura que cualquiera alquila por horas— y dos de las cuatro llevan a la misma empresa alquilada: la firma de un único operador que hace funcionar una sola caja de disfraces. Un rastreador real lleva una identidad porque es una entidad. Un suplantador viste todos los rostros porque el rostro es la parte barata. El user-agent no es un carné de identidad; es un disfraz, y el robots.txt es un cartel que solo el disfrazado puede elegir leer.

Amazonbot: el bot que no distingues de un servidor alquilado
#

Con Amazonbot la verificación se vuelve de verdad difícil, y es instructivo justo porque Amazon no se esconde. La empresa publica una lista de direcciones de rastreo como las demás; y aun así, solo el 35 % de nuestras 344 visitas de «Amazonbot» (120 de ellas) coincidió con esa lista. El otro 65 % —224 solicitudes desde 179 direcciones distintas— no figuraba en absoluto en la lista de Amazon.

La razón es estructural. El rastreador real de Amazon corre sobre la misma nube —AWS EC2, los servidores en la nube que Amazon alquila a cualquiera— así que, en la capa de red, un impostor en EC2 se parece mucho a lo auténtico. La propia respuesta de Amazon a esto es una segunda comprobación: una prueba de DNS inverso (FCrDNS: confirmar que el nombre de la IP resuelve de vuelta a un host oficial crawl.amazonbot.amazon, en ambos sentidos). La aplicamos a una muestra de 18 de las direcciones que no coincidían. Las 18 resolvieron a hosts genéricos ec2-*.compute-1.amazonaws.com —servidores alquilados corrientes— y ninguna al dominio de rastreo de Amazon (método de verificación de Amazon). No eran IP nuevas de Amazon sin listar: no pasaron la propia prueba de Amazon para ser Amazon.

La lección va más allá de un solo bot: un rastreador que corre sobre nube alquilada es el más fácil de falsificar, porque el falsificador alquila esa misma nube idéntica. Ahí la verificación no puede detenerse en una lista de direcciones: necesita una prueba criptográfica o anclada en el DNS que el operador controle. Amazon al menos ofrece una. Algunos no ofrecen nada.

Los rastreadores que no puedes comprobar en absoluto
#

El grupo más difícil no es el de los mentirosos: es el de los rastreadores que no tienes forma de verificar en ningún sentido. meta-externalagent (el rastreador de IA de Meta) envió 179 solicitudes y Bytespider (el de ByteDance) envió 112, y de ninguna de las dos empresas pudimos hallar un rango de IP publicado ni un método oficial de DNS inverso contra el que comprobar una sola. Cuando hicimos la búsqueda inversa de una muestra de las direcciones de Meta (9 de ellas), devolvieron NXDOMAIN: ningún nombre registrado en absoluto. No hay nada con qué cotejar, sea por diseño o por descuido; se te pide confiar en la cabecera y no se te da manera de hacerlo.

Este es el núcleo callado de todo el problema, y es un problema de privacidad, no una molestia para el administrador de un sitio. La exclusión que te vendieron —robots.txt, «bloquea el bot», incluso el nuevo llms.txt— vale solo lo que tu capacidad de saber si funcionó. Divide el mundo de los rastreadores de IA en tres, y tus herramientas alcanzan solo al primero:

Grupo	Quién (en nuestros registros)	¿Puedes verificarlo?	¿Funciona la exclusión?
Publicados y honestos	GPTBot, ClaudeBot, GoogleOther	Sí — lista de direcciones + DNS inverso	Sí — el bloqueo surte efecto
Con nombre pero incomprobables	meta-externalagent, Bytespider	No — sin método publicado	Indeterminable — confías en una cabecera
Impostores	el grupo suplantador (14 nombres, hosts alquilados)	No — y dicen ser todos	No — ignoran el archivo por completo

Y el arreglo más nuevo, el específico para IA, no sale mejor parado en nuestros propios registros. Publicamos un llms.txt; a lo largo de los 17 días, los rastreadores de IA trajeron nuestras páginas cientos de veces —GPTBot por sí solo 310 veces— y trajeron el archivo llms.txt exactamente cero veces. Un estudio de 300.000 dominios llegó al mismo veredicto a gran escala: los archivos llms.txt no muestran correlación medible alguna con el comportamiento de los rastreadores de IA (SE Ranking, 2025). El estándar que se pide leer a los bots, no lo están leyendo.

En resumen: qué te protege de verdad
#

Si el objetivo es mantener tus textos, fotos y publicaciones públicas fuera de los sistemas de IA, este corte de 17 días dice algo llano y algo desolador: los controles funcionan mejor con los rastreadores que se habrían portado bien de todas formas, y nada en absoluto con los que más temes. No es razón para quitar el robots.txt —frenar a la mayoría honesta sigue importando, y es la diferencia entre que tus palabras entren o no en los grandes modelos—. Es razón para dejar de confundir el cartel de la puerta con una cerradura.

De ahí se siguen tres conclusiones honestas. Primera: usa las palancas, pero ordénalas por quién obedece. El robots.txt y bloquear en el borde los rangos publicados frenan de verdad a GPTBot, ClaudeBot y Google, que son la mayor parte del volumen declarado. Segunda: verifica, no te fíes de la etiqueta. Si vas a actuar según tus registros, coteja las IP de origen contra las listas publicadas de los operadores y el DNS inverso, exactamente como hicimos nosotros, y no contra la cadena de user-agent. Tercera, la que sostiene todo lo demás: da por hecho que cualquier cosa que publiques en abierto ya es legible por sistemas que no puedes auditar. El grupo impostor y los rastreadores sin método no van a honrar un archivo de texto; el único control de privacidad duradero es elegir qué entra en el registro público desde el principio, la misma lógica de permanencia que trazamos para las publicaciones que no puedes despublicar y para lo que las máquinas infieren a partir de fragmentos.

Un estándar emergente llamado Web Bot Auth aspira a resolver el problema del disfraz de raíz: firmas criptográficas que un rastreador no puede falsificar, de modo que la identidad se demuestra en lugar de teclearse (Cloudflare, 2025). Es temprano y no está muy adoptado, y solo ayudará con los rastreadores que quieren ser identificados. Los que visten catorce rostros nunca fueron el objetivo de un estándar de confianza.

Puntos clave

Los rastreadores declarados de los grandes laboratorios son casi todos auténticos: en 17 días, GPTBot se verificó al 97 %, ClaudeBot al 99 % y GoogleOther al 100 % contra los rangos de IP que publica cada empresa; así que bloquearlos en el robots.txt sí funciona.
El user-agent es un disfraz: cuatro redes de alojamiento alquilado, fuera de todo rango publicado, vistieron los nombres de 14 empresas de IA distintas en 17 días; un solo /24 suplantó a las catorce, mientras que dos bloques contiguos de Anthropic enviaron entre ambos 546 solicitudes bajo un único nombre.
Los rastreadores que corren en la nube son los más fáciles de falsificar: solo el 35 % de las visitas de «Amazonbot» coincidió con la lista de Amazon; el resto vino de servidores EC2 alquilados y genéricos que no pasaron la propia comprobación de DNS inverso de Amazon (18 de 18 en la muestra).
Algunos rastreadores no pueden verificarse en absoluto: los bots de Meta y ByteDance no publican lista de IP ni método de DNS inverso —las direcciones de Meta no devolvieron ningún nombre registrado—, así que «excluirse» de ellos es un acto de fe.
El arreglo específico para IA no se está leyendo: los rastreadores de IA trajeron nuestras páginas cientos de veces y nuestro llms.txt cero veces, en línea con un estudio de 300.000 dominios que no halló efecto medible alguno.

Preguntas frecuentes
#

¿Puedes bloquear a los rastreadores de IA con robots.txt?
#

En parte, y depende por entero de la honestidad del rastreador. En nuestros registros de 17 días, los grandes rastreadores declarados —GPTBot, ClaudeBot, GoogleOther— se verificaron como auténticos entre el 97 % y el 100 % de las veces y sí respetan el robots.txt, así que incluirlos ahí los detiene. Pero el robots.txt es una petición voluntaria, no una regla que se imponga: un rastreador que la ignora, o que viste un user-agent falso, pasa de largo sin más. El archivo frena al cortés e informa al honesto; a un impostor no le dice nada.

¿Cómo verificas que un rastreador de IA es de verdad GPTBot o ClaudeBot?
#

No te fíes de la cadena de user-agent: comprueba la IP de origen. OpenAI, Anthropic, Google y Amazon publican cada uno los rangos de direcciones que usan sus rastreadores, así que una solicitud real de GPTBot viene de una IP que está dentro de la lista publicada por OpenAI. Para los rastreadores sobre nube compartida (como Amazonbot en AWS), añade una comprobación de DNS inverso: confirma que el nombre de host de la IP resuelve de vuelta al dominio oficial de rastreo del operador, en ambos sentidos (FCrDNS). Si una visita de «GPTBot» viene de una dirección que OpenAI nunca publicó, no es GPTBot.

¿Mantiene el llms.txt a la IA fuera de mi contenido?
#

Según nuestras pruebas, no. Publicamos un archivo llms.txt y, a lo largo de 17 días, los rastreadores de IA trajeron nuestras páginas reales cientos de veces mientras traían el llms.txt cero veces: GPTBot leyó 310 páginas y el archivo, ni una sola vez. Un estudio aparte de 300.000 dominios no halló correlación medible entre tener un llms.txt y cambio alguno en el comportamiento de los rastreadores de IA. Es un estándar propuesto que los rastreadores a los que se dirige, en su mayoría, aún no leen.

¿Qué es un rastreador de IA suplantado?
#

Es una solicitud que lleva el nombre de user-agent de una empresa de IA real pero no viene de esa empresa. En nuestros registros, cuatro redes comerciales de alojamiento —de las que cualquiera puede alquilar— enviaron tráfico etiquetado como 14 empresas de IA distintas, incluida una red que suplantó a las catorce ella sola. Como un user-agent no es más que una cadena de texto que elige quien la envía, la suplantación es trivial; solo cotejar la IP de origen contra los rangos publicados te dice si el nombre está ganado o puesto.

Si no puedo frenar a todos los rastreadores, ¿qué protege de verdad mi privacidad?
#

El único control que sobrevive a un rastreador incomprobable o deshonesto es decidir qué haces público desde el principio. El robots.txt y bloquear los rangos publicados frenarán a la mayoría honesta, y vale la pena hacerlo. Pero para los rastreadores que no puedes verificar —y los impostores que ignoran toda regla—, da por hecho que cualquier cosa publicada en abierto ya es legible por sistemas que no puedes auditar, y trata la publicación misma como el punto de decisión.

Referencias
#

#	Fuente	URL	Copia archivada
1	OpenAI — Documentación de GPTBot y de rastreadores (con lista de IP publicada)	https://developers.openai.com/api/docs/bots	https://web.archive.org/web/*/https://developers.openai.com/api/docs/bots
2	Anthropic — ¿Rastrea Anthropic la web y cómo bloquear ClaudeBot?	https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler	https://web.archive.org/web/*/https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler
3	Google — Verificar Googlebot y otros rastreadores de Google	https://developers.google.com/search/docs/crawling-indexing/verifying-googlebot	https://web.archive.org/web/*/https://developers.google.com/search/docs/crawling-indexing/verifying-googlebot
4	Amazon — Lista publicada de direcciones IP de Amazonbot	https://developer.amazon.com/amazonbot/ip-addresses/	https://web.archive.org/web/*/https://developer.amazon.com/amazonbot/ip-addresses/
5	Amazon (AWS re:Post) — Cómo identificar y verificar Amazonbot (FCrDNS)	https://repost.aws/questions/QUKdLk-sznTDOe-cyN-AyXGQ/how-to-identify-amazonbot	https://web.archive.org/web/*/https://repost.aws/questions/QUKdLk-sznTDOe-cyN-AyXGQ/how-to-identify-amazonbot
6	Cloudflare — De Googlebot a GPTBot: quién rastrea en 2025	https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/	https://web.archive.org/web/*/https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/
7	Cloudflare — Perplexity usa rastreadores sigilosos y no declarados	https://blog.cloudflare.com/perplexity-is-using-stealth-undeclared-crawlers-to-evade-website-no-crawl-directives/	https://web.archive.org/web/*/https://blog.cloudflare.com/perplexity-is-using-stealth-undeclared-crawlers-to-evade-website-no-crawl-directives/
8	Perplexity — ¿Agentes o bots? Entender la IA en la web abierta (respuesta)	https://www.perplexity.ai/hub/blog/agents-or-bots-making-sense-of-ai-on-the-open-web	https://web.archive.org/web/*/https://www.perplexity.ai/hub/blog/agents-or-bots-making-sense-of-ai-on-the-open-web
9	Cloudflare — Web Bot Auth (identidad criptográfica de rastreadores)	https://blog.cloudflare.com/web-bot-auth/	https://web.archive.org/web/*/https://blog.cloudflare.com/web-bot-auth/
10	SE Ranking — Estudio sobre la eficacia de llms.txt (300.000 dominios)	https://seranking.com/blog/llms-txt/	https://web.archive.org/web/*/https://seranking.com/blog/llms-txt/

Nuestro material de prueba: el resumen de verificación —recuentos agregados de solicitudes por user-agent, recuentos verificados y titularidad de las redes a nivel de /24, de la ventana de registros del 19 de junio al 5 de julio de 2026—. No incluye ningún dato de visitantes; las IP de los rastreadores son infraestructura pública, revelada con una granularidad no más fina que el /24.

Una nota sobre lo que esto es y lo que no. Es un solo sitio nuevo y de poco tráfico a lo largo de 17 días: un estudio de caso, no un censo. Los porcentajes describen nuestros registros, no la web. Lo que se generaliza no son las cifras, sino el método y su veredicto: verifica contra la identidad publicada y el mundo de los rastreadores se parte en comprobables y no comprobables. Repetiremos la misma medición a los 90 días y publicaremos la diferencia: si el grupo impostor crece, si los rastreadores sin método llegan a ser verificables alguna vez y si los honestos siguen siendo honestos.

Este es el complemento, del lado de los rastreadores, a nuestro argumento de que la web abierta se está cercando —leída más por máquinas que por personas— y la continuación empírica del modelo de amenazas de la era de la IA que abrió esta serie. Si quieres ver qué podría armar una de esas máquinas sobre ti a partir de lo que ya es público, nuestra herramienta de autoauditoría aplica esa misma disciplina de verificar en vez de confiar a tu propia huella.

Privacidad on-chain de Bitcoin en 2026: cómo funciona el rastreo

Mon, 22 Jun 2026 00:00:00 +0000

Una nota sobre la financiación: CypherpunkGuide no lleva publicidad de vigilancia. Nada de redes publicitarias, píxeles de seguimiento ni contenido patrocinado. Nos sostienen vías transparentes: hoy, las donaciones; más adelante, una suscripción y afiliación alineada con nuestra línea editorial. Respondemos ante nuestras lectoras y lectores, no ante los anunciantes.

Circula un mito cómodo: que Bitcoin es dinero anónimo. Nunca fue cierto, y en 2026 lo es menos que nunca. Cada pago que has hecho en tu vida vive en un libro mayor público que cualquiera puede descargar, y existe una industria de miles de millones dedicada a leerlo. La pregunta que importa no es si la cadena puede analizarse —siempre puede—, sino dónde se forja en realidad el vínculo entre una cadena de caracteres y tu nombre, y qué puedes hacer en cada punto.

Escribo bajo seudónimo, así que trato mis propias monedas como si un analista bien financiado estuviera observando: la suposición no cuesta nada y la alternativa es irreversible. Aquí está la medida incómoda de la amenaza: el análisis de blockchain es un campo comercial maduro —empresas como Chainalysis venden herramientas de rastreo a gobiernos y exchanges—, y el trabajo académico que lo fundó (Meiklejohn et al., 2013) redujo cerca de 12 millones de claves públicas de Bitcoin a unos 3,3 millones de grupos de propiedad —clusters— usando apenas dos heurísticas; y eso hace más de una década, antes de que la tecnología madurara. El libro mayor no olvida, y analizarlo solo se vuelve más barato.

¿Entonces la privacidad es una causa perdida? No, pero es condicional, y la mayoría de las guías se equivocan en las condiciones. La respuesta honesta es que la privacidad on-chain es un conjunto de técnicas, cada una protege algo concreto y deja otras cosas al descubierto, y todas se sostienen frente a un modelo de amenazas específico. Abajo: cómo funciona el rastreo de verdad (con sus límites reales de confianza), qué cambiaron los procesos contra los mixers de 2024 y una tabla sin adornos de lo que cada herramienta de 2026 protege —y lo que no—.

La suposición	La realidad	Dónde se forja el vínculo
«Mi dirección es solo caracteres al azar»	Las direcciones son permanentes y públicamente enlazables	El clustering une tus direcciones en una sola cartera
«Nunca publiqué mi nombre»	Las monedas se cruzan con la identidad en el borde regulado	El exchange con KYC donde compraste o vendiste
«Usé una cartera de privacidad, así que soy anónima»	Cada herramienta protege una capa, no todas	Las fugas off-chain que las herramientas on-chain nunca tocan
«El rastreo es prueba segura»	Las heurísticas tienen confianza, no certeza	CoinJoin y PayJoin rompen las suposiciones de base

Cómo funciona en realidad el rastreo on-chain
#

El análisis de cadena es el oficio de desanonimizar Bitcoin aplicando heurísticas estadísticas al libro mayor público —no rompe la criptografía, sino que explota los patrones de cómo gastan las carteras—. La técnica más importante de todas es la heurística common-input-ownership: cuando varias direcciones se usan juntas como entradas de una misma transacción, el analista da por hecho que comparten dueño. Esa única suposición, aplicada a toda la cadena, es lo que convierte millones de direcciones inconexas en un mapa de carteras agrupadas.

Unas pocas heurísticas hacen casi todo el trabajo, y lo honesto es decirlo así: cada una lleva un nivel de confianza, no una certeza.

Heurística	Confianza	Qué revela	Qué la rompe
Common-input-ownership	Alta, en gastos corrientes	Las entradas gastadas juntas pertenecen a una cartera	CoinJoin y PayJoin, donde varios dueños comparten una transacción
Detección de cambio	Media	Cuál de las salidas es tu cambio —el dinero que tu cartera se devuelve a sí misma, no a quien pagaste—	Tipos de script mezclados (Legacy/SegWit/Taproot), montos de salida idénticos
Reutilización de direcciones	Alta, cuando aparece	Cada transacción de una dirección reutilizada, unidas todas	Las carteras modernas (Sparrow, Cake) generan una dirección nueva cada vez
Peeling chain	Media	Una cartera que mueve fondos en una secuencia repetida de «paga un poco, reenvía el resto»	Los datos en crudo, por sí solos, no distinguen con fiabilidad pago de cambio

La common-input-ownership es el núcleo del clustering y, al mismo tiempo, la suposición que las transacciones colaborativas están diseñadas precisamente para desbaratar. La detección de cambio parte de un detalle del funcionamiento de las carteras que vale entender: cuando gastas parte de una moneda, el cambio sobrante vuelve a una dirección recién creada que controla tu propia cartera —no a quien recibe el pago— (es la change address). Por eso un solo pago puede generar dos direcciones que el analista intentará unir a tu cluster.

Lo honesto —lo que casi ninguna guía dice— es que todas estas son atribuciones probabilísticas, no pruebas. Un análisis revisado por pares de 2023 sobre los patrones de peeling chain subraya cuánto depende todo de heurísticas que se degradan cuando los patrones de gasto son inusuales. Eso importa en lo legal y en lo práctico: el clustering reduce el grupo de sospechosos; por sí solo, no te pone nombre.

Dónde las direcciones se cruzan con la identidad
#

Una dirección solo se convierte en ti cuando toca un registro que lleva tu nombre, y en 2026 ese punto es casi siempre un exchange con KYC. En lo criptográfico, la cadena es seudónima; la desanonimización ocurre en el borde regulado, donde demostraste tu identidad para comprar o vender y donde ese exchange conserva un mapa permanente entre tu identidad verificada y las direcciones a las que retiraste. Por eso «nunca publiqué mi nombre real» es un consuelo falso: se lo entregaste a un exchange, con documento de identidad en mano (KYC, la verificación de identidad), el día que abriste la cuenta.

A partir de ese vínculo inicial, el rastreo se expande hacia fuera. El exchange conoce la dirección de retiro; el clustering enlaza esa dirección con el resto de tu cartera; y cualquier interacción posterior con otro servicio regulado reconfirma la identidad. Las filtraciones de datos lo empeoran: una base de datos de KYC filtrada le regala al analista la capa de identidad, la misma dinámica de fuga off-chain que recorre cómo las filtraciones de datos del gobierno y las empresas te exponen. Y hay un segundo ataque, enteramente off-chain, contra el que las herramientas on-chain no hacen nada: un modelo puede inferir quién eres a partir de tu escritura —las publicaciones en foros donde describes tu nodo, tu zona horaria, tus opiniones—. Esa cadena de inferencia es el tema de la desanonimización con IA, y corre en paralelo al análisis de cadena. El modelo mental correcto es aditivo: la privacidad on-chain es necesaria, y no suficiente.

Qué cambiaron de verdad las caídas de 2024
#

En 2024 el terreno legal se movió: la fiscalía de Estados Unidos fue tras los coordinadores de los servicios de mezcla de Bitcoin, y el mapa de la privacidad se reorganizó en torno a esa presión en lugar de desaparecer. La lección no es «la privacidad ha muerto», sino «la arquitectura de la privacidad se desplazó» —lejos de la mezcla coordinada de forma central y hacia diseños sin un coordinador a quien detener—. Dos hechos definen el giro.

En abril de 2024, la Fiscalía Federal del Distrito Sur de Nueva York detuvo a los fundadores de Samourai Wallet y los acusó de conspiración para el blanqueo de capitales y de transmisión de dinero sin licencia; el coordinador del CoinJoin Whirlpool del servicio cerró (DOJ, 2024). Ambos fundadores se declararon luego culpables y, en noviembre de 2025, fueron condenados a cinco y cuatro años de prisión. Semanas después de las detenciones iniciales, el 1 de junio de 2024, zkSNACKs —la empresa que coordinaba el CoinJoin de Wasabi Wallet— suspendió ese servicio, alegando incertidumbre regulatoria (zkSNACKs, 2024); la propia Wasabi siguió funcionando. Por un momento pareció que el CoinJoin coordinado estaba acabado.

No lo estaba. En cuestión de días, coordinadores comunitarios independientes retomaron el protocolo WabiSabi que zkSNACKs había soltado, y los CoinJoin coordinados de Wasabi siguieron funcionando (monitores como LiquiSabi los muestran en tiempo real). El coordinador oficial se retiró; la coordinación se descentralizó. Los resúmenes que circulan se equivocan en dos puntos más, y los detalles cambian tus decisiones:

«Silent Payments reemplazó a CoinJoin y se volvió mayoritario.» No del todo. Silent Payments (lo vemos más abajo) resuelve un problema distinto —la privacidad al recibir— y en 2026 se describe mejor como emergente, no dominante. No mezcla montos como hace CoinJoin, y trae un costo de escaneo real para quien recibe. Es un complemento, no un sustituto directo.
«JoinMarket se está muriendo.» Lo contrario es más cercano a la verdad. Porque JoinMarket no tiene coordinador —es un mercado entre pares de makers y takers, sin nadie central a quien procesar—, su red siguió en marcha mientras caían los servicios coordinados. (Su repositorio original se archivó en abril de 2026, pero un sucesor que mantiene compatibilidad de protocolo, joinmarket-ng, sigue en desarrollo activo con becas de OpenSats y la HRF.) Su debilidad está en la usabilidad y la liquidez, no en la fragilidad legal.

Lo que se sostiene: los procesos de 2024 fueron contra coordinadores y transmisión de dinero, no contra el hecho de guardar monedas con privacidad. Las arquitecturas que eliminan al coordinador (JoinMarket) o que desplazan la privacidad a la capa del protocolo (Silent Payments) son las que resistieron la presión.

El kit de privacidad de 2026: qué protege y qué no cada técnica
#

No existe un único interruptor que «haga privado a Bitcoin». Cada técnica defiende una capa —el vínculo al recibir, el grafo de transacciones, el monto, la ruta de red— y no dice nada sobre las demás. Elegir bien significa ajustar la herramienta al eslabón concreto del rastro que más te urge cortar, no acumularlas todas. La tabla de abajo es la versión honesta de la comparación que casi todas las guías aplastan en un «usa una cartera de privacidad».

Técnica	Qué protege	Qué no toca	Estado en 2026
Silent Payments (BIP-352)	La privacidad al recibir: una dirección estática que puedes publicar, sin vínculo on-chain entre los pagos que llegan a ella	Los montos; la privacidad del emisor; la identidad off-chain	Emergente; costo de escaneo para quien recibe; en Sparrow, Cake y otras
PayJoin (BIP-78)	Rompe la common-input-ownership: ambas partes aportan entradas, así que el clustering lee mal la transacción	La privacidad del monto; exige a las dos partes en línea (un obstáculo de alojamiento)	Especificación estable; la variante asíncrona (BIP-77) alivia el requisito de estar en línea
CoinJoin (JoinMarket)	El grafo de transacciones y la correlación de montos, mediante mezcla colaborativa	Las fugas off-chain; el vínculo KYC de identidad; la curva de aprendizaje es alta	Red intacta, sin coordinador; el mantenimiento pasó a joinmarket-ng (2026)
Lightning Network	Mantiene los montos de los pagos fuera de la cadena pública	El `payment_hash` se comparte a lo largo de la ruta; la confabulación entre nodos puede desanonimizar	Mayoritaria; las rutas a ciegas (BOLT 12) mejoran la privacidad del enrutamiento
Coin control / hábitos básicos con las UTXO	Permite evitar fusionar monedas de orígenes distintos (frena el clustering que tú mismo/a provocas)	Todo lo off-chain; nada automático	Integrado en Sparrow, Cake; el hábito más barato y más ignorado

Unas advertencias honestas que la tabla comprime. Silent Payments (BIP-352, Bitcoin Optech) es el cambio más prometedor en años para la privacidad al recibir: publicas una sola dirección reutilizable y cada emisor deriva para ti una dirección on-chain única, de modo que quien observa no ve un destino común; pero quien recibe debe escanear la cadena para hallar los pagos, algo que las implementaciones de cliente ligero aún están resolviendo. Lightning es de verdad mejor que la cadena para la privacidad de los montos, pero no es privada por defecto (como detalló un análisis técnico de 2022): cada nodo en la ruta de un pago aprende el mismo payment hash, y un grupo de nodos de enrutamiento confabulados —o un solo nodo que combine su posición con el sondeo de canales— puede identificar al emisor o al receptor con una probabilidad nada trivial. Y la técnica más barata —coin control, la función de la cartera que te permite elegir qué monedas (las UTXO, las unidades discretas que tu cartera almacena) entran en cada pago— es la que casi nadie pone en práctica: basta con no gastar a la vez monedas de origen KYC y monedas privadas para evitar el clustering que, de lo contrario, le estarías regalando al analista. Igual que tu huella en redes sociales, un error on-chain es permanente: no hay botón de borrar para una transacción.

Una práctica de base: lee la cadena como la lee un analista
#

La mejor manera de entender el análisis de cadena es practicarlo un poco tú misma, en un explorador de bloques público, antes de que alguien lo aplique contra ti. No hacen falta herramientas de pago: las mismas heurísticas que impulsan el rastreo comercial están a la vista de cualquiera que sepa leer las entradas y salidas de una transacción. Yo trato cada moneda que tengo como ya observada, y el hábito empezó con una tarde leyendo mis propias transacciones como lo haría un adversario.

Este es el método, reproducible, con cualquier explorador público (mempool.space, por ejemplo: sin cuenta, sin conectar la cartera):

Abre una transacción y cuenta las entradas. Dos o más entradas gastadas juntas son la señal de common-input-ownership: el analista tratará esas direcciones como una sola cartera. Pregúntate si esa suposición es cierta en tu caso, y si la creaste tú al mezclar monedas.
Encuentra el cambio. ¿Dos salidas, una de ellas un monto raro y no redondo que vuelve a una dirección recién creada del mismo tipo de script? Eso es, casi con seguridad, tu cambio. Ahora el analista tiene otra dirección en tu cluster.
Retrocede un salto. Pincha en la transacción anterior de una de las entradas. Si llegó directamente con el patrón de retiro típico de un exchange conocido, el vínculo de identidad está a un solo salto de distancia: ahí es donde importa el rastro.
Detecta un CoinJoin. Una transacción con muchas entradas y muchas salidas de igual valor es colaborativa: aquí la heurística de common-input-ownership falla a propósito, y por eso eleva la incertidumbre del analista en lugar de confirmar la propiedad.

Cuando leí mis propias transacciones así por primera vez, lo que me sorprendió no fue lo que la cadena revelaba, sino lo poco que costaba verlo: un explorador gratuito, ninguna herramienta especial. Hazlo con diez transacciones y la amenaza abstracta se vuelve concreta: puedes ver qué hábitos crean clusters y cuáles los cortan. De eso se trata el ejercicio —no de paranoia, sino de calibrar con precisión qué revela tu propio libro mayor—. Todo lo que aparece en la tabla de herramientas de arriba es, simplemente, una forma ordenada de eliminar las señales que detectas en los pasos 1 a 3.

En conclusión: qué enfoque de privacidad encaja con tu modelo de amenazas
#

La configuración de privacidad adecuada para Bitcoin depende por completo de contra quién te defiendes, y el error más habitual es comprar herramientas antes de definir la amenaza. La privacidad funciona por capas: resuelve primero el eslabón más barato y de mayor impacto —casi siempre el KYC y los hábitos básicos con tus monedas— antes de recurrir a las transacciones colaborativas avanzadas. Ajusta tu esfuerzo a tu adversario real, no al ataque más sofisticado que puedas imaginar.

Si buscas privacidad financiera cotidiana frente a los corredores de datos pasivos y quienes vigilan la cadena: prioriza la adquisición sin KYC donde sea lícita, un coin control disciplinado y una cartera que nunca reutilice direcciones. Eso elimina los clusters más fáciles y el vínculo de identidad principal —la mayor parte de la exposición real— a un costo casi nulo.
Si mantienes un seudónimo público (creadora, escritor o activista): haz todo lo anterior, luego añade Silent Payments para recibir y trata tu escritura como el riesgo mayor. El ataque más barato contra un seudónimo con nombre es la inferencia de texto off-chain, no el análisis de cadena; acompaña esta guía con la desanonimización con IA.
Si te enfrentas a un adversario dirigido y con muchos recursos: da por hecho que combinará las heurísticas con registros de exchanges obtenidos por orden judicial y bases de datos filtradas. Ninguna herramienta basta por sí sola; suma transacciones colaborativas, privacidad de montos vía Lightning, protección en la capa de red y una compartimentación off-chain rigurosa, y acepta que el objetivo honesto es «mejor privacidad», no «anonimato».

Sea cual sea tu nivel, la secuencia no cambia: define al adversario, resuelve primero el KYC y los hábitos básicos con tus monedas, y luego incorpora herramientas de protocolo solo donde cubran un eslabón que realmente necesites proteger.

Puntos clave

Seudónimo, no anónimo: el libro mayor de Bitcoin es público; las heurísticas de clustering que lo fundaron (Meiklejohn et al., 2013) funden direcciones «separadas» en una sola cartera sin romper ninguna criptografía.
El vínculo de identidad central es el exchange con KYC: las monedas se cruzan con tu nombre real en el borde regulado, donde queda retenido el documento de identidad; cierra este eslabón antes de añadir cualquier herramienta avanzada.
Las caídas de 2024 reordenaron la arquitectura, no el objetivo: a los fundadores de Samourai los acusaron en abril de 2024 (y los condenaron en 2025), el coordinador oficial de Wasabi se retiró en junio de 2024 (coordinadores descentralizados continuaron los CoinJoin), pero JoinMarket —sin coordinador— siguió en marcha y Silent Payments emergió como opción de protocolo.
Cada herramienta protege una capa: Silent Payments = recibir; PayJoin/CoinJoin = el grafo de transacciones; Lightning = los montos; coin control = los clusters que tú misma causas. Ninguna cubre el texto off-chain.
El coin control es la defensa más barata y más ignorada: no gastar a la vez monedas KYC y monedas privadas frena el clustering que, de otra forma, le estarías entregando al analista sin que lo pida.

Preguntas frecuentes
#

¿Se pueden rastrear las transacciones de Bitcoin?
#

Sí. Bitcoin es seudónimo, no anónimo: cada transacción es pública para siempre, y las empresas de análisis de cadena rastrean la actividad con heurísticas de clustering —sobre todo la suposición de common-input-ownership— combinadas con los registros de identidad que guardan los exchanges con KYC. El rastreo explota patrones, no una criptografía rota.

¿Usar una dirección nueva cada vez me hace anónima?
#

Ayuda, pero no es suficiente. Las direcciones nuevas neutralizan la heurística de reutilización de direcciones, pero gastar varias monedas en una sola transacción sigue enlazándolas por common-input-ownership, y el exchange con KYC del que retiraste conserva el vínculo de identidad. Cuidar las direcciones es necesario, pero parcial.

¿Silent Payments reemplazó a CoinJoin en 2026?
#

No: es una lectura equivocada muy común. Silent Payments (BIP-352) resuelve la privacidad al recibir, con una dirección estática reutilizable; no mezcla montos como hace CoinJoin y le impone un costo de escaneo a quien recibe. Tras las caídas de los coordinadores en 2024 emergió como un complemento importante, no como un sustituto directo, y sigue siendo emergente más que dominante.

¿Cuál es el paso de privacidad más importante en Bitcoin?
#

Resuelve el vínculo de identidad y los hábitos básicos con tus monedas antes de cualquier otra cosa. Adquirir bitcoin sin KYC donde sea lícito, y no gastar nunca a la vez monedas etiquetadas con KYC y monedas privadas, elimina los clusters más fáciles y el nudo de identidad más fuerte a un costo casi nulo: más impacto real que cualquier herramienta avanzada montada sobre una base con fugas.

¿Son legales las herramientas de privacidad de Bitcoin?
#

Esto no constituye asesoramiento legal, y la respuesta varía según tu jurisdicción y conducta. Los casos estadounidenses de 2024-2025 procesaron a los operadores de servicios de mezcla por transmisión de dinero sin licencia y blanqueo de capitales vinculados al manejo de fondos de origen delictivo, no a particulares que buscan privacidad en sus transacciones. Usar software orientado a la privacidad es lícito en muchos países, pero las obligaciones fiscales siguen vigentes; consulta a un profesional cualificado en tu jurisdicción.

#	Fuente	URL	Copia archivada
1	Meiklejohn et al. — “A Fistful of Bitcoins: Characterizing Payments Among Men with No Names” (IMC 2013)	https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf	https://web.archive.org/web/*/https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf
2	BIP-352 — Silent Payments (especificación)	https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki	https://web.archive.org/web/*/https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki
3	U.S. DOJ (SDNY) — Detención y acusación de los fundadores de Samourai Wallet (abril de 2024)	https://www.justice.gov/usao-sdny/pr/founders-and-ceo-cryptocurrency-mixing-service-arrested-and-charged-money-laundering	https://web.archive.org/web/*/https://www.justice.gov/usao-sdny/pr/founders-and-ceo-cryptocurrency-mixing-service-arrested-and-charged-money-laundering
4	zkSNACKs — Suspensión del servicio de coordinación del CoinJoin de Wasabi (1 de junio de 2024)	https://blog.wasabiwallet.io/zksnacks-is-discontinuing-its-coinjoin-coordination-service-1st-of-june/	https://web.archive.org/web/*/https://blog.wasabiwallet.io/zksnacks-is-discontinuing-its-coinjoin-coordination-service-1st-of-june/
5	Bitcoin Optech — Tema: Silent Payments	https://bitcoinops.org/en/topics/silent-payments/	https://web.archive.org/web/*/https://bitcoinops.org/en/topics/silent-payments/
6	Bitcoin Magazine — “The State of Bitcoin’s Lightning Network Privacy” (2022)	https://bitcoinmagazine.com/technical/state-of-bitcoin-lightning-network-privacy	https://web.archive.org/web/*/https://bitcoinmagazine.com/technical/state-of-bitcoin-lightning-network-privacy
7	U.S. DOJ (SDNY) — Condena de los fundadores de Samourai Wallet a cinco y cuatro años (noviembre de 2025)	https://www.justice.gov/usao-sdny/pr/founders-samourai-wallet-cryptocurrency-mixing-service-sentenced-five-and-four-years	https://web.archive.org/web/*/https://www.justice.gov/usao-sdny/pr/founders-samourai-wallet-cryptocurrency-mixing-service-sentenced-five-and-four-years
8	Análisis revisado por pares de los patrones de peeling chain en Bitcoin (ScienceDirect, 2023)	https://www.sciencedirect.com/science/article/pii/S2666281723001269	https://web.archive.org/web/*/https://www.sciencedirect.com/science/article/pii/S2666281723001269

Tres hilos del resto de esta web se conectan aquí directamente. La privacidad on-chain es solo la mitad del cuadro: el ataque más barato contra un seudónimo con nombre es la inferencia de texto off-chain, cartografiada en Desanonimización con IA: cómo la inferencia deshace tu anonimato —este artículo es su contraparte on-chain, y los dos se suman—. Dado que el vínculo de identidad es muy frecuentemente un registro institucional filtrado, el manual complementario es Cuando el gobierno filtra tus datos. Y dado que un error on-chain es tan permanente como cualquier cosa que hayas publicado, la auditoría de lo que sobrevive al borrado vive en ¿Hasta qué punto es permanente tu huella digital?.

Audita tu propio historial como lo haría una IA (2026)

Thu, 25 Jun 2026 00:00:00 +0000

Escribo bajo seudónimo, y el artículo hermano de este —Desanonimización con IA: cómo la inferencia deshace tu anonimato— explica cómo un modelo convierte publicaciones dispersas en un nombre y cómo compartimentar de aquí en adelante. Este otro trata de la mitad a la que la prevención no llega: los años de publicaciones que ya hiciste. Ese archivo está en público ahora mismo, y es exactamente el corpus que lee el ataque. La pregunta honesta no es «qué publicaré con cuidado a partir de ahora», sino «qué suma todo lo que ya he dicho». Y la única forma de saberlo es mirarlo como lo mira la máquina.

La buena noticia es que puedes. Tu exportación solo la puedes descargar tú, y leerla con ojos de adversario es una destreza, no un secreto. La mala noticia es que la forma más natural de hacer esa lectura —pegarla en una IA y preguntar «¿qué revela esto sobre mí?»— es justo lo que más probabilidades tiene de empeorar las cosas. Ya llegaremos a por qué. Empecemos por aquello que no se ve desde dentro de tu propio perfil.

El mosaico es lo que no llegas a ver
#

El peligro no es una publicación descuidada; es el conjunto. La reidentificación funciona apilando muchas señales inofensivas por separado —un trayecto, una palabra de jerga, una marca de tiempo— hasta que se cruzan en una sola persona. Es el «efecto mosaico», y no se aprecia desde dentro de tu propio feed, porque cada tesela parece inofensiva por sí sola. El efecto mosaico no es nada nuevo. En el año 2000, Latanya Sweeney demostró que cerca del 87 % de los estadounidenses podía identificarse de forma única con apenas tres datos públicos: código postal, sexo y fecha de nacimiento (sobre el censo de 1990; un reanálisis de 2006 lo situó más cerca del 63 %, y el patrón se sostiene en ambos casos). En 2006, un periodista del New York Times puso nombre a una usuaria «anónima» de AOL solo con sus registros de búsqueda; en 2008, unos investigadores reidentificaron a usuarios de Netflix cruzando las valoraciones «anonimizadas» del servicio con reseñas públicas de IMDb. Ninguno usó IA. Usaron agregación.

Lo que la IA cambió es el precio. En un estudio revisado por pares presentado en ICLR 2024, Beyond Memorization, investigadores de ETH Zurich mostraron que modelos comerciales al alcance de cualquiera infieren atributos —ubicación, ocupación, sexo, ingresos— a partir de texto corriente de Reddit con un acierto en torno al 85 % en su primera conjetura, promediado entre ocho atributos (con amplia variación entre ellos), a un coste unas 100 veces menor y 240 veces más rápido que un investigador humano. El trabajo más reciente lo lleva a escala industrial: AutoProfiler (Du et al., ACL 2026) encadena cuatro agentes que extraen un historial seudónimo de publicaciones —a través de las API de la plataforma— y montan un perfil de forma automática, «a escala web». La cuestión no es que una sola publicación te delate. Es que ahora una máquina puede permitirse leerlas todas a la vez y reparar en el cruce que tú nunca llegaste a ver.

En X, la fuga rara vez son las palabras
#

En Reddit el mosaico es sobre todo texto. En X es sobre todo metadatos, y un modelo mental centrado solo en el texto es un consuelo peligroso. El campo de ubicación que tú mismo pusiste, tus horas de publicación, los datos EXIF de tus imágenes (la información que la cámara incrusta en cada foto), tus enlaces salientes y a quién respondes suelen decir más que lo que de verdad escribiste. Una cuenta seudónima puede cuidar sus frases y aun así filtrar por el andamiaje que las rodea. La concentración de horarios es el ejemplo más claro: si tu cuenta «anónima» se mueve en horario de oficina, el histograma de cuándo publicas delata sin ruido tu zona horaria y las horas en que estás despierto.

Las imágenes son peores de lo que la gente cree, y en dos capas. La mayoría de las plataformas borra el GPS de los EXIF al subir una imagen en público, pero no por todas las vías: los mensajes directos, algunas API, ciertas herramientas de programación de publicaciones y los modos de «archivo» de los chats pueden conservarlo, así que conviene revisar el material más antiguo. Y aun cuando la etiqueta GPS ya no está, la imagen misma geolocaliza: un estudio de 2024, Image-Based Geolocation Using Large Vision-Language Models, halló que los modelos de visión y lenguaje sitúan fotos solo por su contenido visual —ganando el 85,37 % de los duelos al estilo GeoGuessr sobre 50.000 imágenes, a veces con un margen de 0,3 km—. Quitar los metadatos es necesario, pero no basta.

Capa de metadatos (sobre todo en X)	Qué revela en silencio	Dónde mirar en tu exportación
Campo de «ubicación» que tú pusiste	Una región real, en tus propias palabras	`profile.js` / tu biografía
Marcas de tiempo de las publicaciones	Zona horaria y rutina diaria	`created_at` en `tweets.js`
EXIF de la imagen + contenido de la foto	Lugar exacto; dispositivo; geolocalización incluso sin EXIF	imágenes en `tweets_media/`
Enlaces salientes	Tus otros sitios e identidades	entidades de URL en las publicaciones
Respuestas y menciones	El grafo social que ya te conoce	entidades de mención

Lee tu propio historial como un adversario
#

La auditoría es un cambio de mirada deliberado: deja de leer tu historial como quien recuerda viejos tiempos y empieza a leerlo como un desconocido que va a la caza. Descarga tu exportación completa y recórrela categoría por categoría, preguntándote no «¿esto es embarazoso?», sino «¿esto acota quién soy?». Puedes pedir tus datos a Reddit (Ajustes → Privacidad → solicitar una copia) y a X (Ajustes → Tu cuenta → descargar un archivo). Ambos te llegan como un archivo estructurado que puedes leer sin conexión. Luego ve repasando las categorías de más abajo y ten en cuenta también las señales débiles, no solo las evidentes, porque el mosaico se construye precisamente con las débiles.

Una disciplina útil: juzga cada hallazgo por su aporte al riesgo, no por lo revelador que parezca aislado. Veintiocho publicaciones que mencionan cada una un punto de referencia del barrio son un problema mayor que una sola que nombre a tu empleador una vez, porque las veintiocho se cruzan. Busca patrones repetidos y constancia —el mismo identificador, los mismos giros de frase, la misma franja de las siete de la mañana—, porque la constancia es justo lo que aprovecha una fase posterior de búsqueda y cotejo para dar con la coincidencia que te delata.

Categoría	Qué buscar en tu propio historial	Cómo suavizarlo
Ubicación	Trayectos, eventos locales, «cerca de…», puntos de referencia del barrio, fotos geoetiquetadas	Generaliza a una región; elimina u omite el EXIF de las imágenes; deja más impreciso el campo de la biografía
Empleo / ingresos	Puesto + tamaño del equipo + tecnología que usas, «estamos contratando», pistas sobre tu sueldo o tu patrimonio	Renuncia a la combinación que te hace identificable; no busques personal desde tu cuenta
Familia	Edades y colegios de los hijos, pareja, rutinas	Quita los detalles; recuerda que tus familiares no han consentido en ser localizables
Horarios	Horas fijas cada día, «todos los días laborables», concentración de horarios	Varía las horas; nunca uses un alias siguiendo tu horario real
Enlaces de identidad	Identificador reutilizado, enlaces a una web personal, modelo de dispositivo en el EXIF	No reutilices identificadores; quita los enlaces personales salientes; elimina las etiquetas del dispositivo

La auditoría de privacidad que te desanonimiza
#

Aquí está la trampa, y casi nadie la menciona. La forma obvia de auditar tu historial es pegarlo en una IA potente y preguntarle qué revela. Si la cuenta que revisas es un seudónimo que mantienes separado de tu nombre legal —y has iniciado sesión en esa IA con tu identidad real—, acabas de entregarle a una misma empresa las dos mitades del vínculo que tratabas de proteger. La auditoría se convierte en la brecha. Piénsalo bien. Un proveedor en la nube tiene ahora, bajo tu cuenta con nombre real, el historial completo de publicaciones de tu identidad «anónima», acompañado de una consulta que le pide explícitamente que conecte las dos. Esa asociación puede salir a la luz más adelante por una citación judicial, una filtración o un infiltrado: justo el fallo que querías evitar con la auditoría, solo que esta vez lo has provocado tú.

Esto no significa que la IA en la nube esté prohibida. El riesgo depende del caso. Si auditas tu cuenta pública, la que lleva tu nombre real, no hay ninguna identidad anónima que dejar al descubierto, de modo que el riesgo de desanonimización ni siquiera se plantea. Aun así, mandar una exportación completa a cualquier servicio en la nube significa que un tercero procesa su contenido según sus propias condiciones, así que revisa primero qué incluye la tuya. El peligro real está, en concreto, en juntar una cuenta anónima con una cuenta de IA a tu nombre real. En ese caso, mantén el análisis donde nadie más pueda verlo.

Si auditas…	IA en la nube (cuenta con nombre real)	Modelo local (sin conexión)
Tu cuenta pública / con nombre real	Sin riesgo de desanonimización, pero revisa antes el contenido de la exportación	Bien, solo más lento
Un seudónimo estricto que mantienes aparte	Evítalo: crea el enlace real↔alias	Recomendado: nada sale de tu máquina

La versión limpia de esta auditoría se hace en tu propio equipo: una herramienta de código abierto y de funcionamiento local, que analiza tu exportación e indica, por categoría, qué filtra, sin enviar tus publicaciones a ninguna parte y sin dejar en el disco ningún perfil tuyo. (He creado una precisamente para esto; pondré aquí el enlace cuando la publique.) Y si no te queda más remedio que usar un modelo en la nube con una cuenta sensible, elige —dentro de sus propios términos— un servicio pensado para el pago con criptomonedas y el registro con identidad mínima, en lugar de la cuenta de un servicio masivo atada a tu nombre real y tu tarjeta. A fecha de junio de 2026, por ejemplo, OpenRouter ofrece una API compatible con OpenAI que acepta USDC y solo pide un correo o una billetera, y Venice tiene un enfoque centrado en la privacidad, con una vía de pago en cripto sin cuenta y una API compatible con OpenAI; ambos encajan directamente en la opción de nube de esta herramienta. Nada de esto es anonimato real: pueden quedar una billetera, un correo o metadatos de red, tus prompts siguen llegando a un tercero (con un enrutador como OpenRouter, también al proveedor del modelo que hay detrás), y estas promesas de privacidad son en su mayoría declaraciones del propio proveedor, no auditadas de forma independiente. Revisa los términos vigentes de cada servicio y recuerda que ejecutarlo en local es la única vía que no envía absolutamente nada.

Qué hacer con lo que encuentres
#

Resiste el impulso de borrarlo todo de golpe. Eliminar una publicación rara vez elimina el patrón que te delató, y borrar no es lo mismo que hacer desaparecer: los archivos, las cachés de los buscadores, las capturas de pantalla y las copias que otros han guardado siguen ahí mucho después de pulsar el botón. Lo más eficaz es generalizar y reescribir los elementos que más suben el riesgo —convertir «el ferri de las 8:07 desde mi barrio» en «mi trayecto»— y, a partir de ahí, cambiar lo que publicas. Si quieres el panorama completo de qué sobrevive de verdad a un borrado, lee Tu huella digital no se borra; para el lado de la prevención —compartimentar identidades para que el mosaico no tenga nada con qué enlazar—, el manual está en Desanonimización con IA, y la reconstrucción más amplia de las premisas se traza en OPSEC en la era de la IA.

Conviene ser honestos sobre los límites. Auditar tu propia exportación es un ejercicio de conjunto cerrado: solo abarca lo que tú aportaste, no el mundo abierto del que se sirve un adversario —intermediarios de datos (los llamados data brokers), filtraciones, el grafo de respuestas o tu forma de escribir, que te delata de una plataforma a otra—. Un estudio de 2025 con 240 personas (Wang et al.) halló que los usuarios juzgaban cuáles de sus propios fragmentos eran arriesgados apenas algo mejor que el azar, y que sus reescrituras lograron reducir la inferencia solo en el 28 % de los casos. Así que toma la auditoría como una reducción de riesgo, no como un certificado de salud, y vuelve a revisar después de editar, porque bajar la puntuación es la única prueba de que un cambio funcionó.

A quién le importa más
#

La resistencia a la inferencia es higiene de datos para la mayoría y seguridad física para algunos. La auditoría retroactiva importa sobre todo a quienes un adversario ya tiene un motivo para buscar. El doxxing (la exposición de tu identidad real) por motivos de acoso, la suplantación de identidad y las imágenes manipuladas caen de forma desproporcionada sobre las mujeres, y esa misma exposición retroactiva amenaza a supervivientes de maltrato, a personas LGBTQ en entornos hostiles, a disidentes y a las fuentes de los periodistas: cualquiera para quien una publicación vieja y olvidada suponga un riesgo aquí y ahora. Los casos que recoge Cómo se hace doxxing a los streamers dejan el patrón a la vista; si ese es tu modelo de amenazas, la auditoría no es una limpieza opcional, sino un mantenimiento que conviene programar.

Puntos clave

Audita el archivo, no solo lo que publiques en el futuro. Tu historial existente es el corpus que lee el ataque; descarga tu exportación de Reddit y X y léela como un adversario, por categoría.
El mosaico es la amenaza. La reidentificación apila señales débiles (Sweeney 2000: ~87 % de los estadounidenses identificables por código postal + sexo + fecha de nacimiento); la IA solo abarató el poder leerlas todas (Staab et al., ICLR 2024: hasta un 85 % en la primera conjetura).
En X los metadatos filtran más que las palabras —campo de ubicación, horas de publicación, EXIF, enlaces, respuestas—. Y quitar el EXIF no basta: los modelos geolocalizan la propia imagen (Liu et al., 2024).
No audites un seudónimo a través de una IA en la nube con tu nombre real: le entregarías a un proveedor el enlace real↔alias. Usa un modelo local, sin conexión, para las cuentas sensibles.
Generaliza, no lo borres todo de golpe. Borrar ≠ hacer desaparecer; reescribe los elementos de mayor riesgo y cambia lo que publicas de ahora en adelante. La auditoría reduce el riesgo, no te da el anonimato.

Preguntas frecuentes
#

¿Cómo consigo mi historial de Reddit y de X para auditarlo?
#

Pide una exportación a cada plataforma. En Reddit: Ajustes → Privacidad y seguridad → «Solicitar una copia de tus datos», que devuelve archivos CSV con tus comentarios y publicaciones. En X: Ajustes → Tu cuenta → «Descargar un archivo de tus datos», que devuelve una carpeta con tweets.js, account.js, profile.js y una carpeta de imágenes tweets_media. Las dos te permiten leer tu historial completo sin conexión, que es la forma segura de analizarlo: no se lo entregas a un tercero solo para echarle un vistazo.

¿Es seguro pedirle a ChatGPT u otra IA en la nube que revise mis publicaciones?
#

Depende por completo de la cuenta. Si auditas tu perfil público, el de tu nombre real, no hay ninguna identidad anónima que exponer y un modelo en la nube te sirve sin problema. Si auditas un seudónimo que mantienes separado de tu nombre legal, enviar su historial a una IA en la que has iniciado sesión con tu identidad real vincula a ambas en los servidores de ese proveedor: justo la desanonimización que querías evitar. Para ese caso, usa un modelo local, sin conexión, o una cuenta en la nube abierta y pagada de forma anónima.

¿No basta con borrar mis publicaciones antiguas?
#

En general, no del todo. Eliminar una sola publicación rara vez borra el patrón que te expuso, y borrar no es lo mismo que hacer desaparecer: los archivos, las cachés y las capturas siguen ahí, y las plataformas conservan el contenido borrado en sus propios servidores durante un tiempo (Reddit, por ejemplo, en torno a 90 días) que un proceso legal todavía puede alcanzar. Lo más eficaz es generalizar o reescribir los elementos de mayor riesgo (una hora y un lugar concretos pasan a ser algo vago) y cambiar lo que publicas de ahora en adelante. Después, vuelve a auditar para confirmar que el cambio rebajó de verdad tu exposición.

¿No me basta con quitar el EXIF de mis fotos y listo?
#

Quita el EXIF —es necesario—, pero no basta. Los modelos de visión y lenguaje pueden geolocalizar una foto solo por su contenido visual, sin ningún metadato (Liu et al., 2024, halló aciertos con un margen de 0,3 km en algunos casos). El escaparate de una tienda, el perfil de la ciudad al fondo, un cartel del transporte público o la vista desde una ventana pueden situar una imagen aun después de borrar todas las etiquetas. Lo que sale de fondo, y no solo los metadatos, también forma parte de lo que una foto revela.

¿Cómo de buena es la IA en esto, de verdad?
#

Lo bastante buena como para tomársela en serio, y lo bastante barata como para aplicarla a cualquiera. Un trabajo revisado por pares (Staab et al., ICLR 2024) situó a GPT-4 en torno al 85 % de aciertos en su primera conjetura, promediando entre ocho categorías de atributos (con amplia variación de unas a otras), a partir de texto corriente de Reddit; un preprint de 2026 (aún no revisado por pares) vinculó cerca de dos tercios de una muestra de usuarios de Hacker News (el foro de la comunidad tecnológica) con su perfil real de LinkedIn, con una precisión del 90 % y por entre uno y cuatro dólares por persona. Las cifras varían según la tarea y no son perfectas, pero la barrera que antes te protegía —tener que dedicarle horas de trabajo humano— ya no existe.

#	Fuente	URL	Copia archivada
1	Staab et al. — “Beyond Memorization: Violating Privacy via Inference with LLMs” (ICLR 2024)	https://arxiv.org/abs/2310.07298	https://web.archive.org/web/*/https://arxiv.org/abs/2310.07298
2	Du et al. — “Automated Profile Inference with Language Model Agents” / AutoProfiler (ACL 2026 Findings)	https://arxiv.org/abs/2505.12402	https://web.archive.org/web/*/https://arxiv.org/abs/2505.12402
3	Lermen et al. — “Large-scale online deanonymization with LLMs” (preprint de arXiv, 2026)	https://arxiv.org/abs/2602.16800	https://web.archive.org/web/*/https://arxiv.org/abs/2602.16800
4	Liu et al. — “Image-Based Geolocation Using Large Vision-Language Models” (2024)	https://arxiv.org/abs/2408.09474	https://web.archive.org/web/*/https://arxiv.org/abs/2408.09474
5	Wang et al. — “Beyond PII: How Users Attempt to Estimate and Mitigate Implicit LLM Inference” (2025)	https://arxiv.org/abs/2509.12152	https://web.archive.org/web/*/https://arxiv.org/abs/2509.12152
6	Electronic Frontier Foundation — Surveillance Self-Defense	https://ssd.eff.org/	https://web.archive.org/web/*/https://ssd.eff.org/

Cómo los datos ocultos de una foto revelan tu domicilio (2026)

Mon, 06 Jul 2026 00:00:00 +0000

Una fotografía son dos cosas a la vez. Está la imagen que ves y está el archivo que envías, que lleva en silencio una segunda carga: la hora a la que se abrió el obturador, el aparato que lo disparó, el número de serie de ese aparato y, si tenías la ubicación activada, la latitud y la longitud del suelo que pisabas. Esa carga se llama EXIF: el bloque de metadatos —datos sobre los datos— que casi todas las cámaras y todos los móviles escriben en la foto por defecto.

No es una filtración teórica. En 2012, la policía dio con un hacker buscado en casa de su novia porque una foto que él había subido aún conservaba su posición GPS (Gizmodo, 2012); lo condenaron a 27 meses de prisión federal (FBI, 2012). Ese mismo año, la foto que una revista tomó de John McAfee —entonces huido de las autoridades de Belice— llevaba incrustadas unas coordenadas que lo situaban en Guatemala, cerca de la frontera (NPR, 2012); un punto concreto junto a un río, según los periodistas que la hicieron (The Next Web, 2012). Y en paralelo, unos investigadores académicos demostraron que podían pasar de una foto cualquiera de un anuncio de segunda mano a la dirección del vendedor (Friedland y Sommer, USENIX HotSec 2010).

Así que la pregunta no es si los metadatos de una foto pueden revelar tu domicilio —los expedientes lo dejan zanjado—, sino por qué siguen encontrando a gente que cree haberlo resuelto. La respuesta incomoda: casi todos los consejos se quedan en «las plataformas ya lo borran por ti», y eso solo es cierto con excepciones lo bastante tajantes como para desmentirlo. El 6 de julio de 2026 escribimos en una foto de prueba una coordenada GPS conocida, dos números de serie y una miniatura; luego la limpiamos y comprobamos el resultado byte a byte. La guía paso a paso que sigue es ese experimento, y es el eslabón que falta en casi todas las guías: no quitar los datos, sino demostrar que ya no están. Esta es la mitad de metadatos de un problema de dos capas; la otra mitad —lo que delata la propia escena visible— está trazada en Lo que la geolocalización con IA descubre en una sola foto.

Los expedientes: a tres personas las delató un mismo archivo
#

Los tres casos están cerrados, documentados y enseñan algo distinto: uno muestra el mecanismo con toda la fuerza de un adversario real, otro lo muestra venciendo a alguien cuya vida dependía de no aparecer, y el tercero lo muestra actuando sobre una persona que no tenía ningún adversario.

El hacker: Higinio Ochoa, 2012
#

Higinio O. Ochoa III, que firmaba como w0rmer en CabinCr3w, un grupo afín a Anonymous, atacó webs policiales de Estados Unidos en febrero de 2012. La prueba burlona que publicó incluía una foto hecha con el iPhone de su novia, y el archivo aún llevaba su bloque GPS, que apuntaba a una casa de Wantirna South, un barrio a las afueras de Melbourne, Australia (Gizmodo, 2012; CSO Online, 2012). A partir de ahí, los investigadores ligaron esa ubicación con su novia y, a través de ella, con Ochoa. Lo detuvieron aquel marzo, se declaró culpable y lo condenaron a 27 meses de prisión federal (FBI, 2012). A alguien que esquivaba al FBI de forma activa y dominaba el oficio de la intrusión, lo ubicó un ajuste por defecto de la cámara de un teléfono.

El fugitivo: John McAfee, 2012
#

En diciembre de 2012, mientras McAfee se escondía de las autoridades en Belice, Vice publicó una foto suya titulada «We Are with John McAfee Right Now, Suckers». El iPhone 4S con el que la hicieron incrustó unas coordenadas —15°39'29.4"N, 88°59'31.8"W, la zona de Río Dulce, en Guatemala— en el archivo publicado (The Next Web, 2012). McAfee sostuvo primero que había manipulado los datos; un día después admitió que las coordenadas eran auténticas (NPR, 2012), y poco después lo detuvieron en Guatemala. Aquí el fallo no fue suyo: fue la cámara de otra persona la que publicó su ubicación. Tu exposición por metadatos incluye todos los dispositivos que te apuntan.

El presentador: Adam Savage, 2010
#

Adam Savage, de MythBusters, publicó una foto de su camioneta con el pie «Now it’s off to work» («ahora, a trabajar»), y la geoetiqueta situó el vehículo frente a su casa mientras el propio texto anunciaba que la vivienda iba a quedarse vacía (The New York Times, 2010). Sin adversario, sin persecución: solo un ajuste por defecto que convirtió una publicación cualquiera en una dirección y, encima, en un horario. La mayoría de quienes leen esto no son fugitivos ni hackers; este es el caso que te retrata.

Qué hay de verdad dentro del archivo de una foto
#

El EXIF (Exchangeable Image File Format) es el estándar de metadatos que las cámaras escriben en los JPEG y en casi todos los archivos raw, definido por la CIPA, el organismo de la industria fotográfica (DC-008). La imagen es lo que ves; el EXIF es lo que el archivo recuerda, y recuerda más que tu ubicación.

Un archivo de foto lleva la imagen que ves más un bloque EXIF invisible: coordenadas GPS, marcas de tiempo, números de serie de la cámara y una miniatura incrustada.

Campo EXIF	Qué revela	Quién lo ha usado
Latitud / longitud / altitud GPS	Dónde se disparó la foto, con precisión de unos metros	El FBI (Ochoa); cualquiera con un visor
Fecha y hora original	Cuándo; junto al GPS, dibuja una rutina	El caso Savage: la dirección y, además, «no está en casa»
Números de serie del cuerpo y del objetivo	Qué cámara física en concreto; se puede buscar por toda la web	Hay servicios que indexan las fotos por la cámara
Marca / modelo / software	La huella del dispositivo y de la edición	Acota la identidad; delata los archivos editados
Miniatura incrustada	Una versión en miniatura de la imagen; a veces, el original sin editar	Los incidentes de las miniaturas de 2003 (más abajo)

Dos de esas filas merecen que nos detengamos en ellas, porque casi ninguna guía general las menciona.

Los números de serie enlazan unas fotos con otras. Muchas cámaras —y algunos móviles— escriben un número de serie del cuerpo o del objetivo en cada archivo que producen (muchos móviles no lo ponen, y algunas plataformas lo borran, así que es un riesgo que conviene comprobar, no una certeza). Cuando está presente, existen servicios como Stolen Camera Finder que rastrean la web en busca de fotos que lleven un número dado: nacieron para recuperar cámaras robadas, pero sirven igual de bien para hilar todas las fotos sin limpiar que una misma cámara haya publicado. Si mantienes identidades separadas —pongamos, un nombre profesional y una cuenta seudónima—, una sola cámara que suba archivos sin limpiar a las dos ya las ha unido en la capa de los metadatos. Ese vínculo es el pariente discreto de las cadenas de doxxing que documentamos en Cómo se hace doxxing a los streamers.

La miniatura puede delatar la edición. El EXIF lleva una miniatura incrustada —una copia en miniatura de la imagen, dentro del propio archivo— que se genera al hacer la foto. En 2003, la presentadora de TechTV Cat Schwartz publicó unas fotos que había recortado, pero la herramienta de edición de la época no regeneraba esa miniatura, así que los originales sin recortar viajaron dentro de los archivos publicados y hubo lectores que los extrajeron (MetaFilter, 2003). Los editores modernos del propio sistema operativo suelen rehacer la miniatura; los de terceros no siempre. La lección no es «no recortes nunca», sino que una edición que sí ves no prueba nada sobre unos datos que no ves, y por eso verificar (más abajo) es el paso que lo sostiene todo.

Dónde te traicionan los ajustes por defecto
#

El consuelo que más vas a oír —«las plataformas ya borran el EXIF»— es más o menos cierto para lo que se muestra en público y peligrosamente incompleto como defensa. Falla en los bordes, y los bordes son justo donde ocurren los casos de este artículo.

La tabla de abajo recoge dónde falla el borrado y cómo lo pillarías: el hábito de verificación sobre el que se apoya todo este artículo. El comportamiento es el que probamos en 2026 y cambia según la versión de la app, el dispositivo y el modo de subida; tómalo como «dónde mirar», no como una garantía permanente.

Adónde lo envías	Qué sobrevive	Cómo lo pillarías
Publicación pública — Instagram / Facebook / X	La copia pública se recodifica, pero el original se guarda en el servidor (política de Meta)	No puedes inspeccionar la copia del servidor; da por hecho que la plataforma guarda el archivo sin limpiar y bórralo antes de subirlo
Subida a TikTok	La copia pública se recodifica	La ubicación se sigue recogiendo por otras vías; un archivo limpio no es un archivo sin rastrear
Mensajería en modo foto — WhatsApp / Signal / Telegram	La compresión suele tirar el EXIF	Envíate a ti mismo una foto de prueba y lee los metadatos de lo que llega de verdad
Mensajería en modo documento / archivo	Los metadatos pasan intactos: es la vía que se elige por calidad (lo vemos más abajo)	Trata cualquier «enviar como archivo» como no limpiado hasta que un lector demuestre lo contrario
Correo, enlaces en la nube, anuncios de segunda mano	A menudo no se borra nada	Eres la única capa que limpia; verifica tú mismo cada archivo

Tres patrones convierten esa tabla en incidentes reales. El primero es la trampa del documento: las apps de mensajería borran los metadatos cuando envías una «foto», porque recomprimen la imagen, pero la opción de enviar como archivo —esa que la gente elige a propósito para no perder calidad— lo conserva todo. La propia documentación de la comunidad de Signal confirma que su borrado abarca la vía normal de envío de fotos, pero no los archivos enviados como adjunto genérico (Signal Community); WhatsApp y Telegram se comportan igual en las pruebas de la comunidad, y ninguna de las tres te avisa. El segundo es el problema del primer salto: la plataforma borra lo que enseña al público, pero ella misma recibió el archivo completo; limpiarlo en tu dispositivo es lo que mantiene la coordenada también fuera de sus servidores. El tercero es el problema de cuando no hay plataforma: los anuncios clasificados, las fichas de los mercados de segunda mano, los adjuntos de los foros y el correo dejan pasar los archivos con garantías mucho más débiles. Este es el riesgo sistemático que Friedland y Sommer bautizaron como cybercasing en 2010: usar la ubicación de fotos públicas para «hacer el trabajo previo» de un robo en el mundo real. Partiendo de anuncios corrientes de Craigslist, cruzaron las coordenadas de las fotos con el callejero y llegaron directos a casa de los vendedores (ICSI, 2010). Quien vende fotografiando objetos de valor dentro de su propia casa está componiendo justo el archivo que quiere un ladrón: qué merece la pena llevarse y dónde está.

Y hay un mito que conviene jubilar en los dos sentidos: hacer una captura de una foto sí genera un archivo nuevo sin el EXIF original —un arreglo de metadatos de verdad—, pero no cambia nada de lo que la imagen muestra. Como lo dijimos en el artículo hermano: una captura cambia el archivo, no lo que aparece en la imagen.

El protocolo de verificar en vez de confiar (nuestra prueba)
#

Todas las guías te dicen que borres los metadatos. Casi ninguna te dice que lo compruebes. Así que el 6 de julio de 2026 recorrimos el ciclo entero sobre un archivo de prueba —escribir una coordenada conocida dentro, borrarla, verificar— con ExifTool 12.57 (la versión empaquetada por nuestra distribución; upstream ya va por la 13.59), la herramienta de línea de comandos, gratuita, que es el estándar para leer y escribir metadatos de imagen, en una máquina Linux. Lo que sigue es la secuencia real, con la salida de la herramienta recortada a los campos que importan; cada paso se puede reproducir, y el registro completo sin editar —cada línea— acompaña a este artículo (registro del experimento).

Paso 1: ver qué lleva el archivo. Le pusimos a nuestra foto de prueba una carga realista: una posición GPS (48.8584 N, 2.2945 E, la Torre Eiffel, un punto de referencia neutro a propósito), los números de serie del cuerpo y del objetivo, marcas de tiempo y una miniatura incrustada. Luego le preguntamos al archivo qué le contaría a un desconocido:

$ exiftool -a -gps:all -SerialNumber -LensSerialNumber -Model photo.jpg
GPS Latitude : 48 deg 51' 30.24" N
GPS Longitude : 2 deg 17' 40.20" E
GPS Altitude : 35 m
Serial Number : SN-TEST-123456
Lens Serial Number : LENS-TEST-789
Camera Model Name : TC-1

Basta un parámetro (-n) para pasar eso a decimal —48.8584, 2.2945— y pegarlo tal cual en cualquier mapa. La miniatura incrustada también estaba ahí: una copia completa de 948 bytes de la imagen, que se extrae con una sola orden. En total, 1.510 bytes de metadatos —invisibles en cualquier visor de imágenes— cargaban con la ubicación, la identidad del hardware y la vista previa.

Paso 2: borrarlos. El borrado local de referencia es una sola orden:

$ exiftool -all= photo.jpg

Alternativas de escritorio que envuelven la misma operación: ExifCleaner (de código abierto, de arrastrar y soltar, sin telemetría; v4.0 a fecha de 2026), o las opciones de compartir del propio sistema que verás más abajo.

Paso 3: verificar. Este es el paso que separa creer de saber. Lanza la misma consulta del Paso 1 contra el archivo ya limpio:

$ exiftool -a -gps:all -SerialNumber -LensSerialNumber -ThumbnailImage photo.jpg
(no output)

Una salida vacía es la condición para aprobar: no ha sobrevivido ni el GPS, ni los números de serie, ni la miniatura. Tras -all= solo queda la estructura del archivo —dimensiones, codificación, tamaño—, nada que identifique un lugar, un dispositivo ni una versión anterior de la imagen.

Paso 4: pon los ajustes por defecto de tu parte. En el iPhone, en la hoja de compartir, el interruptor Opciones → Ubicación quita la coordenada de lo que envías, y en Ajustes → Privacidad y seguridad → Localización → Cámara → Nunca impides que se escriba siquiera (Apple). En Android, el permiso de ubicación de la propia cámara decide si llega a registrarse una coordenada, pero conviene conocer un límite tajante: Google Fotos solo puede editar o quitar las ubicaciones que estima por su cuenta o que añadiste a mano. Según la propia página de ayuda de Google, una coordenada que la cámara escribió en el archivo no se puede quitar desde Google Fotos de ninguna manera: sigue ahí, intacta, por debajo de lo que la app te enseña (Google). Ese hueco es todo el argumento a favor del Paso 3: que un archivo exportado esté de verdad limpio depende de la app y del camino que haya recorrido, así que fíate de la salida vacía de un lector de metadatos, no de un interruptor ni de lo que veas en pantalla.

Hábitos según el nivel de amenaza
#

El ciclo de borrar y verificar de arriba es mecánico; lo que cambia según el nivel es con qué frecuencia lo repites y hasta dónde lo llevas. Ajusta la fila a quién podría importarle dónde estás: esto es el equivalente, en la capa de los metadatos, de las reglas de composición y de cuándo publicar de nuestra guía de geolocalización con IA, no una repetición de ellas.

Nivel	Quién	El hábito
Básico	Quien comparte de forma casual	Ubicación de la cámara desactivada; deja que las plataformas limpien las publicaciones públicas, pero no te fíes de eso para los archivos que envías: nada de fotos en «modo documento» sin borrarlas antes
Vendedor	Quien usa mercados de segunda mano o clasificados	Borra todas las fotos del anuncio y verifica la primera de cada dispositivo; no fotografíes objetos de valor con fondos que te identifiquen: el cybercasing empieza aquí
Identidades separadas	Cuenta seudónima, creadora, activista, superviviente	Borra y verifica todo; trata los números de serie como identificadores que enlazan tus identidades; da por hecho que cualquier foto que te hagan otros lleva coordenadas (la lección de McAfee); para quien sobrevive al acecho o a la violencia de pareja, una sola foto sin limpiar puede darle a un agresor una dirección actual, y por eso este nivel trata cada archivo como sensible

El patrón, en todos los niveles: el hábito cuesta segundos y el fallo que evita es de los que no se pueden deshacer. Una coordenada, una vez publicada, pasa a formar parte del registro permanente; la misma lógica de lo permanente que trazamos para las publicaciones en Tu huella digital no se borra.

En conclusión: el archivo es lo que de verdad compartes
#

La imagen es lo que querías compartir; el archivo es lo que compartiste de verdad. Todos los casos de este artículo —el hacker, el fugitivo, el presentador, las miniaturas recortadas, los vendedores a los que les hicieron el trabajo previo— se reducen a esa única grieta, y la grieta tiene un arreglo mecánico: limpia en local y luego verifica con una herramienta que lea el archivo en sí. Dos décadas de incidentes documentados, desde las miniaturas de 2003 hasta hoy, dicen que quien sale escaldado no es quien nunca oyó el consejo, sino quien dio por hecho que ya estaba resuelto.

Puntos clave

El mecanismo está probado, no es teoría: el bloque GPS de una foto llevó a los investigadores hasta el hacker Higinio Ochoa (condena de 27 meses, 2012), y una coordenada incrustada por la cámara de otra persona destapó el escondite de John McAfee en Guatemala (2012).
El EXIF lleva más que la ubicación: los números de serie de la cámara enlazan fotos —y cuentas seudónimas— por toda la web, y las miniaturas incrustadas han llegado a viajar con la imagen sin editar (2003).
El borrado de las plataformas es solo de cara a la galería: las publicaciones públicas se recodifican, pero «enviar como documento o archivo» conserva el EXIF completo, las plataformas pueden guardar el original en sus servidores, y los mercados de segunda mano y el correo a menudo no borran nada.
Verificar es el paso que falta: en nuestra prueba de julio de 2026, exiftool -all= quitó los 1.510 bytes de metadatos identificativos, y la misma consulta que encontró el GPS es la que demuestra que ya no está.
La cámara de otro también cuenta: a McAfee lo ubicó el teléfono de un periodista; tu exposición incluye todas las fotos tuyas que no se han limpiado.

Preguntas frecuentes
#

¿Cómo compruebo qué metadatos lleva una foto?
#

Pregúntaselo al archivo directamente. Instala ExifTool y ejecuta exiftool photo.jpg para verlo todo, o exiftool -a -gps:all -SerialNumber photo.jpg para los campos que más importan. En el iPhone, desliza hacia arriba sobre una foto para ver la ubicación; en Android, abre los detalles de la foto en Google Fotos. Las vistas integradas enseñan solo una parte; la línea de comandos enseña lo que ve un adversario.

¿Las redes sociales no quitan el EXIF por su cuenta?
#

Para las imágenes que se muestran en público, en general sí: X, Facebook, Instagram y TikTok recodifican lo que subes, y eso elimina los metadatos que ven los demás usuarios. Pero la plataforma recibió tu original y puede guardar esos datos en sus servidores; y en las apps de mensajería, las opciones de «enviar como documento o archivo» (WhatsApp, Signal, Telegram) se saltan la recodificación y entregan el EXIF completo. Las fichas de los mercados de segunda mano y el correo a menudo no borran nada. Límpialo en local primero y la pregunta deja de importar.

¿Recortar o desenfocar una foto le quita los metadatos?
#

No: editar los píxeles y editar los metadatos son operaciones distintas. Una foto recortada o desenfocada puede conservar entero su bloque EXIF y, en el caso clásico de 2003, la miniatura incrustada en los metadatos aún contenía el original sin recortar. Algunos editores modernos rehacen la miniatura y otros borran los metadatos al exportar; la única forma de saberlo es verificar el archivo resultante con un lector de metadatos.

¿Pueden los metadatos de una foto enlazar mi cuenta anónima con la real?
#

Sí, a través de identificadores del hardware. Los cuerpos de cámara y los objetivos escriben su número de serie en el EXIF, y existen buscadores que indexan por ese número (creados para recuperar cámaras robadas). Una sola cámara que publique fotos sin limpiar en dos identidades ya las ha conectado: sin reconocimiento facial, sin análisis del estilo de escritura, solo con el archivo. Si llevas identidades separadas, borrar los metadatos no es una higiene opcional; es arquitectura de identidad.

¿Cómo quito los metadatos de una foto desde el móvil, sin ordenador?
#

En el iPhone, abre la hoja de compartir, toca Opciones arriba y desactiva Ubicación antes de enviar o guardar: eso quita la coordenada de la copia que se exporta. En Android depende de la app de galería, y hay una pega importante: Google Fotos no puede quitar una coordenada que escribió la propia cámara —solo las que estima o añadiste a mano—, así que ese valor puede sobrevivir a lo que sea que te enseñe la app (Google). Cuando la vía integrada no te dé confianza, usa un borrador específico como ExifCleaner y confirma luego el resultado con un lector de metadatos. La prueba es el archivo, no el interruptor.

Fuentes
#

Nuestros materiales de prueba: el registro sin editar del experimento de la sesión de borrar y verificar del 6 de julio de 2026 (ExifTool 12.57; las coordenadas de prueba son las de la Torre Eiffel, elegida como punto de referencia neutro).

Este artículo es la mitad de metadatos del hilo sobre privacidad fotográfica de este sitio. Lo que delata la escena visible —y por qué esa mitad no se puede borrar— está trazado en Lo que la geolocalización con IA descubre en una sola foto. Cómo se arman de verdad las cadenas de doxxing en torno a una persona está documentado en Cómo se hace doxxing a los streamers, y qué sobrevive a tu botón de borrar, en Tu huella digital no se borra.

¿Qué sabe ChatGPT de ti? Auditoría de privacidad con IA 2026

Sat, 20 Jun 2026 00:00:00 +0000

Escribo en una caja de chat con el mismo cuidado con que hablaría junto a un micrófono cuyo cable no veo: doy por hecho que está grabando, porque la suposición segura más barata es la que termina siendo cierta. Casi todo el mundo hace lo contrario. El asistente responde con una voz tranquila, de charla; la ventana se siente íntima, y por eso le contamos lo que le diríamos a un médico o a un abogado: la preocupación de salud, el borrador de la carta de renuncia, el plan a medio fraguar, la contraseña que no deberíamos estar pegando. La interfaz está hecha para sentirse como una conversación. El motor de atrás está hecho para guardar un registro.

Son dos cosas distintas, y en el hueco entre ambas es donde vive el problema de privacidad. Pew Research (instituto de encuestas de EE. UU.) halló en marzo de 2026 que el 50 % de los adultos estadounidenses siente más inquietud que entusiasmo ante la expansión de la IA —frente al 37 % de 2021—, y una encuesta anterior encontró que una gran mayoría espera que su información personal acabe usándose de maneras que le resultarían incómodas. Y aun así, estas mismas herramientas recogen, por diseño, un flujo de confidencias más íntimo de lo que jamás recogió una búsqueda. Una consulta de búsqueda son unas pocas palabras clave; un chat es una confesión con preguntas de seguimiento. Lo que le ocurre después a ese registro no lo decide el tono amable de la respuesta, sino la política de datos de cada proveedor, su calendario de retención, su línea de revisión humana y —cada vez más— órdenes judiciales que el proveedor no controla.

Así que la pregunta que vale la pena responder no es «¿es privado mi asistente de IA?»: ese planteamiento invita a un sí o un no de folleto publicitario. La pregunta útil es: ¿qué guarda en concreto cada asistente; qué frena de verdad apagar el «entrenamiento»; y qué sobrevive a todos los ajustes que puedes alcanzar? Abajo tienes esa auditoría, proveedor por proveedor, a mediados de 2026, con la advertencia honesta de que estas políticas cambian a menudo: las afirmaciones con fecha son un punto de partida para verificar contra la página actual de cada empresa, no un sustituto de ella.

Lo que sugiere la interfaz	Lo que el sistema hace en realidad
Una conversación privada, del momento	Un registro guardado y ligado a tu cuenta
«Eliminar» lo borra de verdad	«Eliminar» te lo oculta a ti; algunas copias pueden quedar
Apagar el entrenamiento te protege	El entrenamiento es un uso; retención, revisión y entrega son otros
La respuesta es solo para mí	Personas pueden leer muestras para «mejorar el modelo»

Por qué un chat es un registro, no una conversación
#

Un chat con IA es un registro de datos sujeto al menos a cinco usos distintos —entrenamiento del modelo, revisión humana, retención, entrega por seguridad y procesamiento biométrico de voz o imágenes— y un ajuste de privacidad suele gobernar solo el primero. Tratar el «desactivar el uso en entrenamiento» como «hacerlo privado» es el error central, porque los otros cuatro usos corren con reglas propias, y los más dañinos son justo los que ningún interruptor toca. Nombrar los cinco usos por separado es lo que convierte un malestar difuso en una lista de verificación que de verdad puedes auditar.

El primer uso es el entrenamiento: tus conversaciones se vuelven material que da forma a versiones futuras del modelo. El segundo es la revisión humana: para medir la calidad y atajar abusos, los proveedores dejan que personal formado o contratistas lean una muestra de conversaciones reales, una práctica que todo laboratorio importante reconoce en algún punto de su política. El tercero es la retención: incluso después de que elimines un chat, suele quedar copia en los sistemas de monitoreo de abusos, en las copias de seguridad y bajo conservación por litigio durante un plazo definido, o más si una conversación queda marcada. El cuarto es la entrega: un registro que existe puede ser reclamado por citación judicial, aportado en un pleito o cedido bajo una orden de conservación, y nada de eso lo controlas tú. El quinto, el que crece más rápido, es el procesamiento biométrico: la voz que dictas y las imágenes que subes llevan datos —una huella vocal, una cara— duraderos de un modo en que el texto no lo es.

Mantén esos cinco usos separados y el resto de este artículo es solo rellenar una cuadrícula: para cada asistente, qué usos vienen activados por defecto, cuáles puedes apagar y cuáles no. El telón regulatorio también se mueve —el EU AI Act (Reglamento de IA de la UE) empezó a aplicar deberes de transparencia a los modelos de propósito general en agosto de 2025, y sus disposiciones más amplias alcanzan plena aplicación el 2 de agosto de 2026—, pero la regulación avanza despacio y de forma desigual, así que la defensa práctica sigue siendo conocer la cuadrícula y actuar tú mismo.

Qué guarda en realidad cada asistente
#

A mediados de 2026 los grandes asistentes de consumo comparten un comportamiento por defecto que casi nadie nota —entrenan con tus chats salvo que hagas opt-out, con excepciones regionales como la UE y el Reino Unido— y todos retienen algún dato tras la eliminación y se reservan una vía de revisión humana. La tabla de abajo es el resumen entre plataformas; los párrafos que la siguen llevan el matiz, porque una celda de una palabra («Sí») esconde condiciones que importan. Lee la celda y luego lee la salvedad.

Asistente	Entrena con chats por defecto (consumo)	Vía de opt-out	Lo que destaca tras eliminar
ChatGPT (OpenAI)	Sí	Ajustes → Controles de datos	Copias de monitoreo de abusos; datos bajo conservación por litigio
Claude (Anthropic)	Sí, salvo opt-out (desde sep. 2025)	Ajustes de privacidad / datos	Contenido marcado por seguridad; datos bajo conservación por litigio
Gemini (Google)	Sí (vía «Actividad de las apps de Gemini»)	Desactivar la Actividad	Muestras revisadas por personas, hasta 3 años
Copilot (Microsoft)	Sí, salvo opt-out (UE/RU: apagado por defecto)	Interruptor en ajustes	Ventana móvil de ~18 meses
Meta AI	Sí (tus chats con la IA)	Limitado; ninguno fuera de UE/RU	Contenido usado para anuncios/personalización

ChatGPT (OpenAI). En las cuentas gratuita, Plus y Pro, las conversaciones se usan por defecto para mejorar los modelos; lo apagas en Ajustes → Controles de datos. Las propias páginas de ayuda de OpenAI describen una retención de monitoreo de abusos que persiste un tiempo tras la eliminación, y la empresa ha declarado que las cuentas Team, Enterprise y de API no se usan para entrenar por defecto. La lección más importante de 2025 queda por completo fuera de la página de ajustes: en el pleito del New York Times (la demanda del NYT), un tribunal ordenó a OpenAI conservar datos de salida, incluido contenido que los usuarios creían haber eliminado. Un interruptor que tú controlas no sirve de nada frente a una orden de conservación que no controlas.

Claude (Anthropic). Desde un cambio en los términos de consumo que entró en vigor a finales de septiembre de 2025, Anthropic entrena con los chats de las cuentas Free, Pro y Max salvo que hagas opt-out en tus ajustes de datos: la misma postura de opt-out que ChatGPT, no el opt-in que muchos aún suponen. Dos salvedades lo agravan: las conversaciones marcadas para revisión de seguridad o de políticas pueden usarse y conservarse incluso después de hacer opt-out, y Anthropic no publica qué dispara una marca. Lo escribo como autora cuyas propias palabras se producen con Claude, y por eso mismo no voy a suavizarlo: lee la página de privacidad vigente en lugar de fiarte de cualquier resumen, este incluido.

Gemini (Google). Google liga el entrenamiento a tu ajuste de Actividad de las apps de Gemini; con él activado, las conversaciones pueden usarse para mejorar los servicios, y apagarlo lo frena, a costa de tu historial de chat. El detalle que casi todos pasan por alto es la retención de revisión: una muestra de conversaciones elegidas para revisión humana se desliga de tu cuenta pero, según las páginas de ayuda de Google, puede guardarse durante un periodo largo —hasta tres años— al margen de tu borrado automático habitual. Las cuentas de Workspace (de trabajo o estudio) se rigen por términos distintos, por lo general más estrictos.

Copilot (Microsoft). Las preguntas frecuentes de privacidad de Microsoft dicen que, salvo para ciertas categorías de usuarios o quienes hayan hecho opt-out, la empresa usa las interacciones en Bing, MSN y Copilot para entrenar la IA; así que el comportamiento por defecto de consumo no es de manos fuera, aunque los usuarios de la UE, el Reino Unido y Suiza quedan excluidos por defecto. El historial de consumo corre con una ventana por defecto de 18 meses que puedes vaciar. Microsoft 365 Copilot dentro de una cuenta de trabajo o estudio es otro producto: las indicaciones y respuestas se tratan como datos de la organización bajo términos de empresa y no se usan para entrenar los modelos de base. El nivel gratuito de consumo y el nivel de trabajo no son el mismo régimen de privacidad, aunque el icono se vea idéntico.

Meta AI. Meta usa las interacciones con su IA —tus chats con el asistente y, además, las publicaciones públicas— para entrenar y, según su actualización de finales de 2025, para personalizar anuncios y feeds. Meta ha declarado que no usa el contenido de los mensajes privados con amigos y familia para esto, pero tus conversaciones con el asistente Meta AI sí entran, y fuera de la UE y el Reino Unido no hay en la práctica opt-out del uso publicitario, solo una exclusión para categorías de temas sensibles como salud y política. De los cinco, este es donde la línea entre «asistente» y «plataforma de anuncios» es más fina.

El manual del opt-out y sus límites
#

Lo más valioso que puedes hacer es encontrar el control de entrenamiento de cada asistente y configurarlo a tu gusto antes de tu próximo chat sensible, pero entiende el opt-out como reducir un flujo de exposición, no como volver privada la conversación. Hazlo de todos modos: reducir la superficie de entrenamiento es un beneficio real y bien vale los dos minutos. Solo no confundas una tubería más silenciosa con una tubería cerrada. Esta es la ruta en cada uno, a mediados de 2026, con el recordatorio permanente de verificar contra la página de ajustes en vivo.

ChatGPT — Ajustes → Controles de datos, y apaga la opción de mejorar el modelo. Para preguntas sensibles puntuales, usa un Chat temporal, que queda fuera del entrenamiento y se autoelimina, teniendo en cuenta que la retención de monitoreo de abusos puede seguir aplicándose un tiempo.
Claude — abre tus ajustes de privacidad o de datos y apaga el control de entrenamiento; desde finales de septiembre de 2025 el comportamiento de consumo por defecto es opt-out, no opt-in, así que la elección te corresponde a ti, no algo que puedas dar por supuesto.
Gemini — apaga la Actividad de las apps de Gemini para frenar el uso en entrenamiento; ten presente que esto también vacía el historial en curso, y que las muestras de revisión humana ya seleccionadas siguen su propio reloj de retención.
Copilot — apaga los interruptores de mejora del modelo y de personalización en los ajustes (fuera de la UE y el Reino Unido, el comportamiento de consumo por defecto incluye tus interacciones en el entrenamiento); para trabajo de verdad sensible, una cuenta gestionada de Microsoft 365 (de trabajo) se trata con más protección que la app gratuita de consumo.
Meta AI — aplica cualquier control regional de opt-out y de ajustes de anuncios que te corresponda, y opera desde la suposición de que este es el asistente más integrado con publicidad del conjunto.

Hay dos hábitos transversales que ganan a cualquier interruptor suelto. Primero, no pegues lo que no puedas permitirte que quede guardado —secretos, documentos de identidad completos, datos privados de otra persona—, porque la defensa duradera está aguas arriba del modelo, en el punto de entrada. Segundo, separa las cuentas por propósito, para que una pregunta de trabajo y una preocupación de salud no se acumulen contra un mismo perfil. Para la disciplina más amplia en la que esto se inscribe, la Autodefensa contra la Vigilancia de la EFF es una referencia con los pies en la tierra.

Lo que el opt-out no alcanza
#

Hacer opt-out del entrenamiento impide que la mejora futura del modelo use tus datos; no borra el pasado, no deshace la retención, no evita una filtración ni bloquea una citación judicial, y esas son las exposiciones de mayores consecuencias. Esta es la sección que las páginas de marketing se saltan, y es la que debería dar forma a lo que tecleas. Cuatro cosas quedan fuera del alcance de todos los interruptores en todas las plataformas, y nombrarlas es el sentido de toda la auditoría.

La primera es el pasado. Lo que ya se usó para entrenar un modelo en producción no puede sacarse de él; el opt-out mira hacia adelante, nunca hacia atrás. La segunda es la retención tras la eliminación: los almacenes de monitoreo de abusos, las copias de seguridad y la conservación por litigio guardan copias en calendarios que no fijas tú, y una conversación marcada por seguridad puede durar mucho más que tu historial normal. La tercera es la entrega: un registro que existe es localizable, y como demostró en 2025 la orden de conservación contra OpenAI, «lo eliminé» no es un estado que un tribunal esté obligado a respetar. La cuarta es una filtración: la política interna más sólida del mundo no es mejor que la seguridad que rodea la base de datos, y una confesión almacenada es un pasivo almacenado para quien la custodia.

Aquí entra la regulación, y aquí conviene mantener expectativas sobrias. Los deberes de transparencia del EU AI Act para la IA de propósito general (GPAI, IA de propósito general) —documentación, un resumen de los datos de entrenamiento, deberes de derechos de autor— empezaron en agosto de 2025 y se inscriben en su plena aplicación del 2 de agosto de 2026, lo que es un progreso real en transparencia sobre los sistemas. No es, en cambio, un botón de borrado para tus datos, y los modelos de código abierto cargan con deberes más livianos. Las reglas elevan el suelo con el tiempo; no dejan sin decir, hacia atrás, lo que ya tecleaste. La conclusión de trabajo es poco vistosa y duradera: el único dato que no puede filtrarse, ser reclamado por citación ni retenerse más de la cuenta es el que nunca metiste en la caja.

El riesgo desigual: voz, imagen y quién paga más
#

La voz y las imágenes elevan lo que está en juego porque llevan datos biométricos —una huella vocal, la geometría de un rostro— duraderos y exclusivamente tuyos, y el daño de su captura cae con más fuerza sobre las mujeres y otras personas ya señaladas. El texto puede reescribirse; una huella vocal filtrada no se reemite como una contraseña. A medida que los asistentes suman modos de voz y comprensión de imágenes, la auditoría tiene que ir más allá de las palabras, hasta la capa biométrica, porque ahí se concentran ahora los peores desenlaces.

El mecanismo es simple y está bien documentado. Tan poco como 10 a 15 segundos de la voz de alguien —OpenAI dijo que a su propio Voice Engine le bastaban 15— alcanzan hoy para generar una voz sintética convincente, y por eso la FCC (regulador de telecomunicaciones de EE. UU.) dictaminó en febrero de 2024 que las voces generadas por IA en llamadas automáticas son «artificiales» bajo la TCPA (la ley estadounidense que regula esas llamadas) y requieren consentimiento previo. Dale tu voz a un asistente de forma rutinaria y estarás normalizando la captura del material exacto que la suplantación necesita. Las fotos que subes extienden la misma lógica a los rostros. Nada de esto exige mala fe del proveedor; solo exige que el dato exista y que, algún día, se filtre o se use mal.

Y la carga no se reparte por igual. La suplantación, las imágenes íntimas fabricadas y el embudo del acoso al doxxing recaen de forma desproporcionada sobre las mujeres, sobre las profesionales de cara al público y sobre las activistas, la misma asimetría que tracé en el argumento para tratar tu imagen como una credencial y en cómo defenderte de un doxxing coordinado. Para quien carga con ese riesgo, la regla práctica es más estricta que para el usuario general: mantén la voz y la cara fuera de los asistentes de consumo que no tengas que usar, prefiere el texto y trata cualquier entrada biométrica como prácticamente permanente en cuanto sale de tu dispositivo.

En resumen: ¿cuánto deberías blindar?
#

La defensa adecuada escala con tu modelo de amenazas, no con un único ajuste universal: el usuario común necesita tres hábitos, los profesionales necesitan cuentas separadas y niveles más estrictos, y quien carga con un riesgo asimétrico debería tratar la voz y la entrada biométrica como terreno vedado en los asistentes de consumo. El nivel adecuado depende de quién es aquel de quien te proteges: no hay respuesta universal, solo un modelo de amenazas y unos pocos hábitos que rinden en todos los niveles.

Si no tienes un adversario concreto: apaga el entrenamiento en los asistentes que uses, prefiere un modo de chat temporal o de incógnito para las consultas sensibles puntuales y mantén los secretos y los documentos de identidad por completo fuera de la caja. Eso cubre la mayor parte del riesgo realista para la mayoría de la gente.
Si manejas datos de otros o trabajo sensible: usa una cuenta de trabajo gestionada, donde los términos son más estrictos, separa las cuentas por propósito y da por hecho que cualquier cosa que teclees podría luego retenerse, revisarse o entregarse al margen de tus ajustes.
Si cargas con un riesgo asimétrico —mujeres que enfrentan acoso, activistas, profesionales de cara al público—: mantén la voz y la cara fuera de los asistentes de consumo, reduce al mínimo lo que le confías a cualquiera de ellos y trata la entrada biométrica como permanente.

Bajo los tres casos late un principio que ningún cambio de política va a derribar: un opt-out moldea cómo se usan tus datos, pero solo la contención frente al teclado decide si esos datos existen. Audita los ajustes, por supuesto, y luego escribe como si el registro sobreviviera al ajuste, porque así es.

Puntos clave

Registros, no chats: las conversaciones con IA son registros de datos sujetos a cinco usos distintos —entrenamiento, revisión humana, retención, entrega judicial y procesamiento biométrico— y un interruptor de privacidad suele gobernar solo el primero.
Los comportamientos por defecto convergen: a mediados de 2026, ChatGPT, Claude (desde sep. 2025), Gemini, Copilot y Meta AI entrenan todos con chats de consumo salvo que hagas opt-out —con excepciones regionales como la UE y el Reino Unido— y todos retienen algún dato tras la eliminación.
El opt-out mira hacia adelante: apagar el entrenamiento nunca quita lo que ya entrenó a un modelo, y una orden judicial de 2025 obligó a OpenAI a conservar salidas que los usuarios creían haber eliminado.
Ningún ajuste alcanza una citación judicial ni una filtración: los almacenes de retención, la conservación por litigio y los fallos de seguridad quedan fuera de todo interruptor de consumo; el control duradero es no teclear el secreto en absoluto.
La voz y la imagen son biométricas: unos segundos de audio bastan para generar clones de voz convincentes; este riesgo cae con más fuerza sobre las mujeres, las activistas y las figuras públicas, que deberían mantener la voz y la cara fuera de los asistentes de consumo.

Preguntas frecuentes
#

¿ChatGPT usa mis conversaciones para entrenar sus modelos?
#

Por defecto, sí, en las cuentas gratuita, Plus y Pro, a mediados de 2026; puedes apagarlo en Ajustes → Controles de datos. Apagarlo frena el uso futuro en entrenamiento, pero no borra los datos pasados ya usados, y las propias páginas de OpenAI describen copias de monitoreo de abusos que persisten un tiempo tras la eliminación. Los niveles de empresa (Team, Enterprise, API) no se usan para entrenar por defecto. Como estas políticas cambian, confirma el ajuste vigente en la página de controles de datos de OpenAI en lugar de fiarte de cualquier resumen.

Si elimino un chat con IA, ¿desaparece de verdad?
#

Por lo general, no del todo. La eliminación quita la conversación de tu historial visible, pero suele quedar copia en los sistemas de monitoreo de abusos, en las copias de seguridad y en cualquier conservación por litigio, cada una con un calendario de retención que no controlas. Una conversación marcada para revisión de seguridad puede durar aún más. La orden de conservación de 2025 en el caso del New York Times contra OpenAI es la ilustración más clara de que «eliminado» no siempre es permanente cuando hay un tribunal de por medio.

¿Cuál es el asistente de IA más privado por defecto?
#

A mediados de 2026 la respuesta honesta es «ninguno, por defecto»: ChatGPT, Claude (desde su cambio de términos de consumo de septiembre de 2025), Gemini, Copilot y Meta AI entrenan todos con chats de consumo salvo que hagas opt-out, con salvedades regionales como la UE y el Reino Unido. Las diferencias que importan están en los detalles sobre los que tienes que actuar: dónde vive el opt-out, cuánto se guardan las muestras revisadas por personas y qué puede pasar por encima una marca de seguridad. Todos los proveedores, además, retienen algún dato tras la eliminación y se reservan una vía de revisión humana y de entrega judicial, así que «privado por defecto» es lo que no hay que buscar; hacer opt-out y confiar menos es el control que de verdad tienes en la mano.

¿Es seguro usar el modo de voz o subir fotos a un asistente de IA?
#

Trátalo como de mayor riesgo que el texto. La voz y las imágenes llevan datos biométricos —una huella vocal, la geometría de un rostro— duraderos y singularmente identificadores, y unos segundos de audio pueden bastar para generar un clon de voz convincente. El riesgo es que el dato exista, al margen de la intención del proveedor. Si cargas con un riesgo elevado de suplantación o acoso, prefiere el texto y mantén la voz y la cara fuera de los asistentes de consumo que no estés obligado a usar.

¿El EU AI Act volverá privados a los asistentes de IA?
#

No: mejora la transparencia, no el borrado de datos personales. Sus deberes de transparencia para la IA de propósito general —documentación técnica, un resumen de los datos de entrenamiento— empezaron en agosto de 2025 y se inscriben en la plena aplicación del Reglamento del 2 de agosto de 2026, lo que te ayuda a entender los sistemas. No quita hacia atrás los datos que ya enviaste, y los modelos de código abierto cargan con deberes más livianos. La regulación eleva el suelo con el tiempo; no sustituye a la contención sobre lo que tecleas.

#	Fuente	URL	Copia archivada
1	OpenAI — Preguntas frecuentes sobre Controles de datos	https://help.openai.com/en/articles/7730893-data-controls-faq	https://web.archive.org/web/*/https://help.openai.com/en/articles/7730893-data-controls-faq
2	Anthropic — Política de privacidad	https://www.anthropic.com/legal/privacy	https://web.archive.org/web/*/https://www.anthropic.com/legal/privacy
3	Anthropic — Actualizaciones de los términos de consumo y la política de privacidad (2025)	https://www.anthropic.com/news/updates-to-our-consumer-terms	https://web.archive.org/web/*/https://www.anthropic.com/news/updates-to-our-consumer-terms
4	Google — Las apps de Gemini y tus datos	https://support.google.com/gemini/answer/13594961	https://web.archive.org/web/*/https://support.google.com/gemini/answer/13594961
5	Microsoft — Preguntas frecuentes de privacidad de Copilot	https://support.microsoft.com/en-us/microsoft-copilot/privacy-faq-for-microsoft-copilot	https://web.archive.org/web/*/https://support.microsoft.com/en-us/microsoft-copilot/privacy-faq-for-microsoft-copilot
6	Meta — Política de privacidad	https://www.facebook.com/privacy/policy/	https://web.archive.org/web/*/https://www.facebook.com/privacy/policy/
7	Comisión Europea — Marco regulatorio sobre IA (AI Act)	https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai	https://web.archive.org/web/*/https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
8	Pew Research — Hallazgos clave sobre cómo ven los estadounidenses la IA (marzo de 2026)	https://www.pewresearch.org/short-reads/2026/03/12/key-findings-about-how-americans-view-artificial-intelligence/	https://web.archive.org/web/*/https://www.pewresearch.org/short-reads/2026/03/12/key-findings-about-how-americans-view-artificial-intelligence/
9	NYT contra OpenAI — orden judicial de conservación (cobertura)	https://decrypt.co/323950/openai-challenges-court-order-user-data-nyt-lawsuit	https://web.archive.org/web/*/https://decrypt.co/323950/openai-challenges-court-order-user-data-nyt-lawsuit
10	FCC — Las voces generadas por IA en llamadas automáticas son ilegales (2024)	https://www.fcc.gov/document/fcc-makes-ai-generated-voices-robocalls-illegal	https://web.archive.org/web/*/https://www.fcc.gov/document/fcc-makes-ai-generated-voices-robocalls-illegal
11	Electronic Frontier Foundation — Autodefensa contra la Vigilancia	https://ssd.eff.org/	https://web.archive.org/web/*/https://ssd.eff.org/

Esta auditoría es una mitad de un mapa más grande. El modelo de amenazas que convierte la IA en un adversario de primer orden —y las premisas que rompe— está expuesto en OPSEC en la era de la IA: rehaz tu modelo de amenazas, y la inmersión a fondo en cómo los modelos infieren tu identidad a partir de lo que publicas está en Desanonimización con IA: cómo la inferencia deshace tu anonimato. Cuando el registro se le toma a una institución en vez de teclearlo tú, el manual emparentado es Cuando el gobierno filtra tus datos; y para lo que está en juego en lo biométrico, ve Tu cara y tu voz son ahora credenciales.

Desanonimización con IA: cómo la inferencia deshace tu anonimato (2026)

Wed, 17 Jun 2026 00:00:00 +0000

Escribo bajo seudónimo, así que el ataque de este artículo es el que más me ronda la cabeza. La vieja premisa detrás de todo alias es sencilla: si mantengo mi nombre fuera de la página, el trecho entre «Cora Aegis» y la persona que teclea sigue siendo caro de cerrar. Durante dos décadas de vida digital esa premisa se sostuvo casi siempre, porque cerrar el trecho exigía que un humano leyera miles de publicaciones a mano. El anonimato por omisión —basta con dejar el nombre fuera— le bastaba a casi todo el mundo en la mayoría de los casos.

Ya no basta, y la razón está medida, no es hipotética. En un estudio revisado por pares y presentado en ICLR 2024, Beyond Memorization, investigadores de ETH Zurich mostraron que modelos de lenguaje de los que cualquiera dispone infieren atributos como ubicación, ingresos y sexo directamente de texto corriente de Reddit, alcanzando hasta un 85 % de acierto en su primera conjetura y hasta un 95,8 % dentro de sus tres primeras. Un preprint de seguimiento de 2026 pasó de los atributos a la identidad: un modelo agéntico vinculó al 67 % de un conjunto de usuarios de Hacker News con su perfil real de LinkedIn, con una precisión del 90 % —nueve de cada diez de sus coincidencias positivas eran correctas— por en torno a uno a cuatro dólares por persona. La fricción que antes te protegía —que enlazar cuentas le costaba horas a una persona— es justo lo que la IA eliminó.

¿Qué protege entonces un seudónimo ahora? No un botón de borrado: la inferencia sobrevive a cualquier publicación que retires. Lo proteges como defenderías cualquier sistema cuya puerta principal ya no cierra con llave: dejas de tratar el «yo no lo dije» como defensa y empiezas a romper la cadena que convierte señales dispersas y de apariencia inofensiva en un nombre. Abajo está esa cadena, etapa por etapa, por qué la privacidad on-chain de Bitcoin no la cubre y la compartimentación que sí.

Lo que parece inofensivo	Lo que en realidad filtra	Cómo lo usa un modelo
Un nombre de usuario reutilizado o una muletilla al escribir	Un enlace entre dos identidades «separadas»	Funde tus cuentas en un solo perfil
Marcas de tiempo de «buenos días», jerga local	Tu zona horaria y tu ciudad	Acota la ubicación sin una dirección dicha
Una afición, un trayecto, una pista sobre tu empleo	Banda de ingresos, horario, lugar de trabajo	Cruza datos contra perfiles candidatos
El fondo de una foto o sus metadatos	Lugar y hora exactos	Confirma una conjetura que el texto ya sugería

The machine deanonymization chain: scattered public posts are turned into a name through extract, search, and verify stages — break any one link to fall below the attacker's cost budget.

El anonimato era caro de romper; entonces la IA lo abarató
#

La desanonimización es el trabajo de volver a enlazar un seudónimo o una cuenta anónima con una identidad real —por correlación e inferencia entre muchas señales pequeñas, no por un único desliz—. Lo primero que hay que entender es que no se volvió tanto más lista como más barata. Las técnicas —correlacionar cuentas, inferir hechos no enunciados, cotejar un estilo de escritura— son antiguas; lo que cambió es que ahora una máquina las ejecuta a un costo de unos pocos dólares por persona en vez de las horas facturables de un humano. Ese desplome del precio es toda la historia, porque casi ningún anonimato fue jamás criptográficamente fuerte. Lo protegía el hecho de que a nadie le compensaba molestarse.

Las cifras vuelven concreto el cambio. El equipo de ETH Zurich, en Beyond Memorization (ICLR 2024), probó modelos contra perfiles reales de Reddit y halló que el mero hecho de escribir con naturalidad filtra lo suficiente para que un modelo adivine dónde vives y cuánto ganas, y que las mitigaciones de costumbre —herramientas de anonimización de texto y el «alineamiento» del modelo— no lo frenaban de forma fiable. El preprint de 2026 Large-scale online deanonymization with LLMs —que lista entre sus autores a un investigador entonces en Anthropic y que aún no está revisado por pares— fue más lejos: construido como agente autónomo, el sistema extrajo pistas de comentarios de Hacker News, buscó personas que encajaran y verificó candidatos contra LinkedIn, acertando al 67 % de los usuarios con una precisión del 90 %, con un costo total del experimento por debajo de los dos mil dólares.

Lee esos dos resultados juntos y la conclusión es incómoda pero clara: la protección era el precio, y el precio se acabó. Un adversario motivado ya no necesita interesarse por ti en particular. Puede correr el ataque contra todos los de un foro y ver quién cae.

La cadena de desanonimización: cómo una máquina va de publicaciones a un nombre
#

La desanonimización automática corre como una cadena de tres etapas —extraer, buscar, verificar— y no tienes que vencerla entera para estar a salvo; tienes que romper un solo eslabón lo bastante bien como para empujar tu perfil por debajo del presupuesto de esfuerzo del adversario. Ver la cadena como etapas discretas es lo que convierte un temor vago («la IA puede encontrarme») en un mapa defendible, porque cada etapa tiene un punto débil distinto.

Etapa uno: extraer e incrustar. El modelo lee lo que escribes en público y extrae señal estructurada: una región probable a partir de modismos y marcas de tiempo, una ocupación a partir del vocabulario, una banda de ingresos a partir de las cosas que mencionas comprar y —lo más duradero— una huella lingüística, la forma estadística de tu manera de escribir. Nada de esto exige que lo hayas enunciado. El trabajo de ETH Zurich es la prueba de que esta etapa, por sí sola, ya expone ubicación, ingresos y sexo a partir de texto llano.

Etapa dos: buscar y clasificar. Esas señales se convierten en una consulta contra un conjunto de identidades candidatas —otras plataformas, perfiles públicos, conjuntos de datos filtrados— y el sistema ordena quién es más probable que seas. Este es el paso que escala: una búsqueda por incrustaciones sobre decenas de miles de candidatos es barata y se degrada con elegancia, acotando en lugar de fallar cuando los datos escasean.

Etapa tres: verificar y enlazar. Un modelo de razonamiento toma a los candidatos más fuertes y los coteja —¿encaja este historial laboral de LinkedIn con las aficiones de aquellas publicaciones de Reddit? ¿cuadra la cronología?— hasta que uno sobrevive. En el preprint de 2026, este es el paso agéntico que produjo la coincidencia entre Hacker News y LinkedIn. Es también donde se pone a prueba una premisa de seguridad: el entrenamiento de rechazo atrapa la petición burda —«desanonimiza a esta persona»— con mucha más fiabilidad que ese mismo objetivo perseguido a través de una cadena de subtareas de apariencia inocua.

La lección práctica es que la cadena es más fuerte allí donde tú eres más constante. El mismo identificador, los mismos giros de frase, el mismo ritmo de publicación entre contextos son lo que permite a la etapa dos encontrar una unión. La inconsistencia —introducida a propósito— es lo que la rompe.

Por qué un alias de Bitcoin perfecto sigue sin ser anónimo
#

La privacidad on-chain y la privacidad frente a la inferencia de texto son dos modelos de amenazas distintos, y las herramientas que resuelven uno no hacen nada por el otro. CoinJoin, Silent Payments y Monero protegen el grafo de transacciones; no tocan las publicaciones en foros, las solicitudes de soporte ni las respuestas sociales que enlazan tu alias contigo. Esta es la brecha que más a menudo veo que se le escapa a la orientación sobre privacidad de Bitcoin: trata el anonimato como una propiedad on-chain cuando, para un seudónimo con nombre, el ataque más barato es enteramente off-chain.

Piénsalo así. Puedes romper a la perfección el enlace entre tus monedas y tu identidad —UTXO pasadas por coinjoin, una dirección nueva por pago, ningún KYC en ninguna parte—. Nada de eso importa si además llevas una cuenta seudónima donde describes la configuración de tu nodo, tu zona horaria y tus opiniones con una voz que un modelo puede cotejar con tu otra escritura. La cadena de la sección anterior no lee la blockchain en absoluto; te lee a ti. El análisis de cadena y la inferencia de texto pueden incluso correr en paralelo —uno agrupa tus transacciones, el otro adhiere una persona al grupo—, pero no necesitas la mitad on-chain para que funcione la mitad off-chain.

Así que el modelo mental correcto es aditivo, no de uno u otro. La privacidad on-chain es necesaria y vale la pena hacerla; sencillamente no es suficiente para alguien cuyo modelo de amenazas incluye que lo nombren. Si mantienes un seudónimo de Bitcoin, el OPSEC de texto de la próxima sección es la mitad del trabajo que la conversación sobre las monedas de privacidad suele dejar fuera.

Técnica de privacidad	Qué protege	Qué no toca
CoinJoin / Silent Payments	El grafo on-chain de transacciones	Publicaciones en foros, estilo de escritura, marcas de tiempo
Monero / monedas de privacidad	Montos, emisor y receptor on-chain	El texto off-chain que nombra a quien gasta
VPN / Tor	La correlación de IP a nivel de red	Lo que de verdad escribes, en cualquier sitio
Solo separar cuentas	El enlace de nombre obvio	El enlace inferible a partir de patrones

Romper la cadena: un manual de compartimentación para la era de la IA
#

La defensa que funciona es la compartimentación apuntada a la cadena de inferencia, no a una publicación cualquiera: lograr que tus contextos compartan los menos rasgos vinculables posibles, para que la etapa dos no tenga nada que unir. El borrado no está en esta lista, porque quitar una publicación rara vez quita el patrón que te expuso; la prevención en el momento de publicar es el único control que se sostiene del todo.

Separa las identidades en todas las capas. Un seudónimo solo es tan fuerte como su capa menos separada: distinto nombre de usuario, distinto correo, distinto dispositivo o perfil de navegador, distinta red. La infraestructura compartida es la unión más fácil de todas.
Diversifica la huella lingüística. Esta es la defensa que casi todos se saltan. Varía el registro entre identidades —formal en una, informal en otra— y evita las frases que te firman, los hábitos de emoji y las muletillas de puntuación que un modelo usa para agrupar tu escritura. Reutilizar un giro memorable entre dos cuentas puede deshacer cualquier otra precaución.
Aleatoriza los horarios. Publicar con un horario diario fijo en tu zona horaria real es una señal de ubicación y de rutina. Reparte la actividad, añade ruido y no dejes que tu cuenta «anónima» guarde horario de oficina en tu propia ciudad.
Quita los metadatos antes de que algo salga de tus manos. La ubicación EXIF de las fotos, las propiedades de los documentos y una correlación de ISP constante son confirmaciones que un modelo usa de buena gana. Elimínalas en la fuente.
Retira seudónimos según un calendario. Una identidad acumula historia inferible cuanto más vive. Para las personas de mayor riesgo, retirar y volver a establecer periódicamente un identificador reinicia la línea base que un adversario haya construido.

Ninguna de estas medidas es exótica; juntas marcan la diferencia entre ser el perfil más barato de resolver de un foro y ser uno que el ataque se salta. Para la capa de herramientas —una VPN sin registros, un buzón aparte, utilidades de separación de identidades— la Autodefensa contra la Vigilancia de la EFF es una referencia con los pies en la tierra, y el principio es el mismo que esta web se aplica a sí misma: usa el menor conjunto de herramientas que de verdad rompa un enlace, y decláralas con honestidad en lugar de perseguir una lista de la compra.

Antes de la IA, esto exigía un humano y mucho tiempo
#

Conviene ser precisos sobre qué cambió, porque los casos sonados que todo el mundo recuerda no fueron IA en absoluto: fueron trabajo lento, manual, humano. El giro que introduce la IA no es tanto una capacidad nueva como la eliminación del costo y la paciencia que aquellos casos exigían. Encuadrar con honestidad los incidentes antiguos es justo el punto: muestran cuánta fricción te protegía antes y, por tanto, cuánto pierdes cuando desaparece.

Al streamer conocido como Dream lo localizaron en 2021 cuando unos seguidores cotejaron la foto de una cocina con un anuncio inmobiliario en Zillow —ojos humanos, una base de datos pública, ningún modelo de inferencia a la vista—. La campaña de acoso contra la activista Keffals en 2022 funcionó con OSINT recopilado a mano y el esfuerzo colectivo de un foro, no con una máquina. El doxxing de 2023 a unos estudiantes por una declaración en el campus se sostuvo en investigación manual de archivos y publicidad pagada y segmentada. Cada uno de estos exigió gente motivada y tiempo real. Ese era el peaje que mantenía a salvo a la mayoría de los seudónimos: un adversario tenía que quererlo lo bastante como para gastar horas.

La cadena de desanonimización elimina el peaje. Lo que una turba de foro le hacía antes a un solo objetivo a lo largo de días, un agente puede ahora intentarlo contra una comunidad entera por unos pocos dólares por cabeza, y lo hace sin cansarse ni aburrirse nunca. Esto también cae de forma desigual. La suplantación, las imágenes íntimas fabricadas y el embudo del acoso al doxxing recaen de forma desproporcionada sobre las mujeres y sobre cualquiera con un antagonista motivado, lo que convierte la resistencia a la inferencia en una cuestión de seguridad física y reputacional, no solo de higiene de datos. Las protecciones de la sección anterior importan más, precisamente, para las personas a quienes la versión antigua y costosa de este ataque ya tomaba como blanco.

En resumen: ¿cuánta compartimentación necesitas de verdad?
#

El nivel de esfuerzo correcto es el que encaja con aquello de lo que te proteges; no hay un único ajuste, solo un modelo de amenazas.

Si no tienes un adversario concreto: las jugadas de mayor palanca son lingüísticas y temporales. No reutilices un identificador o un estilo de escritura distintivos entre cuentas que quieras mantener apartadas, y no publiques tu identidad «anónima» en tu propio reloj. Reserva las herramientas más pesadas para cuando tengas un motivo.
Si mantienes un seudónimo real —una creadora, un escritor, cualquiera cuyo nombre y alias no deban conectarse—: compartimenta sin concesiones entre dispositivo, red e idioma, y da por hecho que la mitad on-chain de tu privacidad no hace nada por la mitad off-chain.
Si cargas con un riesgo asimétrico —mujeres que enfrentan acoso, activistas, profesionales de cara al público—: trata la diversificación lingüística y la verificación por canal aparte como innegociables, y planea la retirada de identidades antes de necesitarla.

En los tres casos rige la misma verdad que regía antes de que entraran las máquinas: después del hecho, no puedes borrar tu camino hacia la seguridad de forma fiable. Solo puedes modelar al adversario que de verdad tienes, romper la cadena en el eslabón que puedas permitirte defender y publicar menos de aquello que una máquina conservaría con gusto.

Puntos clave

Inferencia: los modelos de lenguaje infieren ubicación, ingresos y sexo a partir de texto corriente con hasta un 85 % de acierto en su primera conjetura (Staab et al., ICLR 2024); el anonimato por omisión ya no se sostiene.
Escala: un modelo agéntico vinculó al 67 % de unos usuarios de Hacker News con su perfil de LinkedIn, con una precisión del 90 %, por en torno a 1-4 dólares cada uno (Lermen et al., preprint de 2026 no revisado por pares); la fricción humana se acabó.
Vector independiente: la privacidad on-chain (CoinJoin, Silent Payments, Monero) protege el grafo de transacciones, no las publicaciones en foros ni el estilo de escritura que enlazan un alias con una persona.
Defensa: rompe la cadena —separa identidades entre dispositivo y red, diversifica tu registro de escritura, aleatoriza los horarios de publicación y quita los metadatos—; borrar una publicación no elimina el patrón inferible.
Daño desigual: la desanonimización por acoso y la suplantación caen con más dureza sobre las mujeres y los seudónimos públicos, lo que vuelve innegociables la verificación por canal aparte y la separación lingüística.

Preguntas frecuentes
#

¿De verdad la IA puede desanonimizarme a partir de publicaciones anónimas?
#

A menudo, sí. El anonimato por omisión —dejar tu nombre fuera de una publicación— es débil ante la inferencia, porque un modelo puede derivar tu ubicación, tu empleador y otros atributos a partir de patrones en cómo y cuándo escribes, y luego cotejar esas señales contra perfiles públicos. En pruebas revisadas por pares (Staab et al., ICLR 2024) los modelos infirieron atributos personales a partir de texto llano de Reddit con hasta un 85 % de acierto en su primera conjetura. La verdadera imposibilidad de vincularte viene de la compartimentación —nombres de usuario, dispositivos y redes separados, y un estilo de escritura variado—, no de callar tu nombre.

¿Borrar mis publicaciones antiguas detiene la inferencia?
#

En general, no. Quitar una sola publicación rara vez quita el patrón que te expuso, porque la inferencia se nutre de señales constantes —tu estilo de escritura, tus horarios de publicación y tus temas recurrentes— repartidas por todo lo que has publicado. El borrado puede reducir la materia prima en el margen, pero el arreglo duradero es impedir la señal vinculable en el momento de publicar, no limpiar después.

¿Me protegen de esto CoinJoin o una VPN?
#

Protegen una capa distinta. CoinJoin y las monedas de privacidad defienden el grafo on-chain de transacciones; una VPN o Tor defienden la correlación de IP a nivel de red. Ninguno toca las publicaciones en foros, los mensajes de soporte y las respuestas que un modelo lee para enlazar un seudónimo con una persona. Vale la pena usarlos y, sencillamente, no bastan por sí solos: el OPSEC de texto de este artículo es la mitad complementaria.

¿Qué eleva más el costo de la desanonimización?
#

La compartimentación lingüística y contextual. La cadena de desanonimización es más fuerte allí donde eres más constante, así que el hábito de mayor palanca es impedir que las identidades que no deben conectarse compartan un estilo de escritura, un horario de publicación y una misma infraestructura. No es glamuroso, y es lo que de verdad eleva el costo de un adversario por encima de los pocos dólares que el ataque automático exige ahora.

#	Fuente	URL	Copia archivada
1	Staab et al. — “Beyond Memorization: Violating Privacy via Inference with Large Language Models” (ICLR 2024)	https://arxiv.org/abs/2310.07298	https://web.archive.org/web/*/https://arxiv.org/abs/2310.07298
2	Lermen et al. — “Large-scale online deanonymization with LLMs” (preprint de arXiv, 2026)	https://arxiv.org/abs/2602.16800	https://web.archive.org/web/*/https://arxiv.org/abs/2602.16800
3	Simon Lermen — “Large-Scale Online Deanonymization” (explicación del autor, 2026)	https://simonlermen.substack.com/p/large-scale-online-deanonymization	https://web.archive.org/web/*/https://simonlermen.substack.com/p/large-scale-online-deanonymization
4	Electronic Frontier Foundation — Surveillance Self-Defense (guías de modelado de amenazas y compartimentación)	https://ssd.eff.org/	https://web.archive.org/web/*/https://ssd.eff.org/

Dos hilos del resto de esta web conectan aquí directamente. Las cuatro premisas que la IA rompe —la inferencia entre ellas— están cartografiadas en OPSEC en la era de la IA: rehaz tu modelo de amenazas, del que este artículo es la inmersión a fondo en la inferencia. Y como la inferencia se alimenta de todo lo que has publicado alguna vez, la auditoría de lo que de verdad sobrevive al borrado vive en Tu huella digital no se borra. Cuando los datos que se correlacionan fueron tomados de una institución en vez de publicados por ti, el manual emparentado es Cuando el gobierno filtra tus datos; para la inferencia aplicada dentro del trabajo, ve Qué ve en realidad la vigilancia de Slack de tu empleador.

Doxxing a candidatos: audita tu huella digital (2026)

Thu, 30 Jul 2026 00:00:00 +0000

Un currículum no es solo un documento profesional. Reúne varios datos que identifican de forma estable: tu nombre legal, ciudad, correo, teléfono, centro de estudios, antiguos empleadores y fechas. Un reclutador puede seguirlos hasta un perfil profesional. Una campaña de doxxing —publicar datos que identifican a alguien para exponerlo o convertirlo en blanco— puede usarlos para atribuirte una acusación. Una empresa de informes de antecedentes puede emplearlos para asociarte un registro público, bien o mal. Los mismos datos que acreditan tu experiencia también facilitan conectar partes separadas de la web.

Por eso no basta con el consejo genérico de hacer privadas las publicaciones. Una huella permanente en redes sociales puede sobrevivir al borrado, y una autoauditoría desde la perspectiva de un adversario puede mostrar lo que revela tu propio archivo. El riesgo no es abstracto: en 2023, unos folletos sin firma identificaron, según la información periodística, a 26 estudiantes presuntamente vinculados a nueve grupos. Esta guía responde a otra pregunta: cómo se atribuye material externo a la persona que figura en una candidatura y qué puede comprobar esa persona antes de una entrevista.

Construimos una matriz de 15 filas. Contiene 12 puntos de evidencia repartidos entre una publicación pública que llegó hasta un empleador, una campaña organizada que atribuyó a varias personas una afiliación discutida e informes comerciales que, según las alegaciones de un regulador estadounidense, contenían errores. Las tres filas restantes son controles de decisión: un procedimiento común, la ruta española y la mexicana. Cada observación está marcada como confirmada, recogida por una fuente, alegada, no confirmada o sustentada por una norma o guía oficial; así, un titular llamativo no se convierte en un hecho. Puedes descargar y revisar la Matriz de exposición del candidato.

Usa el método para localizar la atribución más débil, no para prometerte que todo rastro desaparecerá.

Cómo se convierte una huella digital en una señal de contratación
#

Un resultado solo influye en una contratación después de que alguien lo atribuya al candidato y lo use para decidir. Audita las cuatro etapas —Ancla, Conexión, Atribución y Decisión— porque encontrar una página no demuestra que hable de ti.

Ancla: la candidatura aporta datos estables como nombre, correo, teléfono, ciudad, centro de estudios o empleador.
Conexión: quien investiga sigue uno de esos datos hasta un alias, una imagen, una lista de grupos, un registro público o un informe de búsqueda de personas.
Atribución: una o varias coincidencias se tratan como prueba de que el resultado pertenece al candidato.
Decisión: el material atribuido influye en una entrevista, una oferta, un rechazo u otra decisión de contratación.

Este marco es la Secuencia de asociación de identidad del candidato (Applicant Identity-Attachment Chain). Permite separar tres vías que suelen confundirse:

Vía	Cómo se establece la conexión	Punto débil	Mejor control para el candidato
Búsqueda pública directa	El equipo de contratación busca por su cuenta en la web abierta	Homónimos, falta de contexto, páginas antiguas	Crea una referencia profesional inequívoca y documenta las coincidencias falsas
Doxxing organizado	Una campaña publica nombres, afiliaciones o contactos del empleador	Una vinculación no verificada se amplifica como si fuera cierta	Conserva pruebas, pide la corrección y prepara un expediente breve de verificación
Informe de un tercero	El empleador encarga la búsqueda o el informe a una empresa externa	Datos de origen erróneos, asociación con otra persona u origen y recorrido opacos entre proveedores	Identifica a la empresa, su función y los derechos que reconoce la ley aplicable; usa la FCRA solo cuando corresponda en EE. UU.

Las tres vías pueden cruzarse, pero no se corrigen del mismo modo. Un correo al editor quizá sirva para una página pública; no modifica el expediente de contratación ni el archivo de una empresa de informes. Una impugnación al amparo de la Fair Credit Reporting Act (FCRA, ley federal estadounidense sobre informes crediticios y de consumidores) puede corregir un informe cubierto en EE. UU., pero no retirar una captura viral ni crear derechos equivalentes en otro país. Antes de actuar, identifica la vía y la jurisdicción.

Tres formas documentadas en que falla la atribución
#

Los tres casos muestran fallos distintos: una afiliación discutida, una publicación pública que circuló dentro de una empresa y un informe comercial que, según un regulador, dio un significado erróneo a ciertos registros. Los hechos y los remedios de cada caso deben mantenerse separados.

Harvard, 2023: una afiliación se trató como identidad
#

En octubre de 2023, una declaración atribuida a más de 30 organizaciones estudiantiles de Harvard desencadenó una campaña organizada para identificar a personas vinculadas a esos grupos. The Harvard Crimson informó después sobre sitios dedicados al doxxing, un vehículo que mostraba nombres y rostros de estudiantes y folletos sin firma que identificaban a 26 estudiantes presuntamente relacionados con nueve grupos. Algunas personas negaron tener relación con la declaración; según el artículo, una de ellas ya no pertenecía a la organización nombrada. Una persona que cursaba estudios de posgrado, citada de forma anónima, dijo al Crimson que una empresa retiró la oferta que le había hecho después de investigar.

Son hechos distintos y no deben fundirse. La información publicada no demuestra que el vehículo, un sitio concreto o un folleto concreto causaran la retirada de una oferta. Figurar en una lista tampoco prueba que un estudiante redactara, aprobara o conociera la declaración. El caso acredita un mecanismo más limitado: la afiliación a un grupo puede conectar un centro de estudios y un nombre con una acusación pública, aunque esa atribución siga discutida.

La lección para un candidato no es ocultar toda asociación. Comprueba si los resultados presentan una vinculación con más certeza de la que permiten las pruebas. Si es así, guarda la afirmación, la URL, la fecha y los documentos que la contradicen antes de pedir una corrección.

Cisco, 2009: una publicación entró en la red interna de contactos
#

En 2009, Network World conservó un breve intercambio público. Una persona que había recibido una oferta de Cisco escribió que estaba sopesando el salario frente a lo poco que le gustaba el trabajo. Un empleado vinculado a Cisco respondió en público y preguntó quién era el responsable de la contratación. El intercambio pronto se convirtió en la historia de «Cisco Fatty».

Lo que está documentado es el recorrido de la publicación, no el desenlace laboral. La fuente no confirma que Cisco retirara la oferta. Presentarlo como un despido demostrado repetiría precisamente el error de atribución que este artículo busca evitar.

El caso sí muestra que una vía directa puede necesitar muy pocos datos. El nombre de la empresa en la publicación aportó el ancla; un empleado creó la conexión interna; el responsable de contratación era el destino. No hizo falta una empresa de verificación ni acceder a una cuenta privada. Una publicación pública puede llegar a quien decide una contratación a través de la propia red social de la organización.

FTC, 2023: un informe puede dar a un registro el significado equivocado
#

La tercera vía funciona de otra manera. En 2023, la Federal Trade Commission (FTC, autoridad federal estadounidense de protección del consumidor y la competencia) alegó que TruthFinder e Instant Checkmate engañaron a los usuarios sobre la exactitud de sus informes de antecedentes e infringieron la FCRA. Según la agencia, algunas alertas comerciales presentaban una multa de tráfico como antecedente penal o registro de detención; la FTC también alegó que las empresas no verificaban los datos de terceros. Una orden acordada por las partes, firmada por el juez e incorporada al expediente el 11 de octubre de 2023 impuso una multa civil conjunta de 5,8 millones de dólares. Los demandados no admitieron ni negaron las alegaciones de fondo, salvo en lo necesario para establecer la jurisdicción.

No se trata simplemente de un resultado de búsqueda deficiente. Cuando un empleador obtiene un informe de consumidores de una empresa dedicada a recopilar información de antecedentes, la legislación federal de EE. UU. suele exigir una secuencia formal: comunicación y autorización escrita antes del informe; copia del informe y Resumen de derechos antes de una posible medida desfavorable; y, después de la decisión, notificación e información para impugnar. Las leyes estatales y locales pueden añadir requisitos.

Vía documentada	Información confirmada	Qué sigue incierto o discutido	Pruebas útiles para defenderte
Caso Harvard	Campaña pública, listas de grupos, 26 nombres en folletos enviados por correo, una retirada de oferta relatada de forma anónima	Si cada persona estaba afiliada; qué causó el resultado laboral	Registros de la organización, capturas fechadas, correspondencia sobre la corrección
Caso Cisco	Publicación pública y respuesta de un empleado vinculado a Cisco	Si la oferta fue retirada	Contexto de la publicación original, estado de la oferta, correspondencia fechada
Caso de la FTC	Demanda de la agencia, expediente y orden firmada con multa conjunta	La conducta de fondo fue alegada, no admitida	Informe de consumidores, registros de origen, expediente de impugnación, notificaciones del empleador

Al aplicar las cuatro etapas a nuestra matriz, una búsqueda por nombre podría encontrar una publicación propia como la del caso Cisco. No resolvería las afiliaciones discutidas de Harvard ni revelaría que una empresa de informes había asociado el registro equivocado. Buscarte en Google sirve como primer paso, pero no constituye por sí solo una auditoría.

Qué miden realmente las encuestas sobre redes sociales y contratación
#

No existe un único porcentaje fiable para 2026. Las encuestas estudian poblaciones distintas y mezclan captación, investigación de candidatos y verificación formal; sirven para demostrar que la práctica existe, no para predecir qué hará un empleador concreto.

Una encuesta de 2015 de la Society for Human Resource Management recibió 410 respuestas de profesionales de recursos humanos en total. Entre las respuestas válidas a las preguntas sobre verificación, el resultado combinado de SHRM fue que el 43 % de las organizaciones usaba redes sociales públicas o búsquedas en línea para evaluar candidatos. Entre las organizaciones que empleaban ese método, el 36 % había rechazado a una persona por información encontrada. Es una referencia histórica, no una estimación de la prevalencia actual.

Otra encuesta de Harris Poll de 2022, encargada por Express Employment Professionals, preguntó a 1.002 responsables de contratación de EE. UU. El 70 % declaró usar redes sociales para investigar posibles candidatos, el 17 % afirmó hacerlo con todos y el 80 % señaló que la propia empresa realizaba la investigación. Además, el 51 % dijo no haber encontrado nunca contenido que le hiciera descartar una contratación. El estudio muestra hasta dónde puede llegar la práctica bajo una definición concreta, pero fue encargado por un patrocinador, se limita a Estados Unidos y no representa una tasa universal para 2026.

Considera posible que te investiguen en público; no des por hecho que siempre ocurrirá.

Qué puede encontrar un empleador y qué proceso jurídico corresponde
#

La distinción clave no es internet, sino quién recopiló el dato, con qué fin y bajo qué ley. Una búsqueda directa y un informe de terceros pueden mostrar lo mismo, pero no activan los mismos avisos, derechos ni autoridades.

Fuente de información	Qué puede aparecer	Primera pregunta que debes hacer	Límite importante
Buscador y perfiles públicos	Homónimos, publicaciones, biografías, imágenes, páginas de organizaciones	¿Quién hizo la búsqueda y qué dato se incorporó al expediente?	Una coincidencia no prueba identidad; que una página sea visible tampoco elimina las reglas de protección de datos que puedan aplicarse
Contenido público de redes sociales	Publicaciones, respuestas, fotos visibles, conexiones públicas	¿El empleador buscó directamente o contrató un servicio?	Una cuenta abierta no da acceso general a mensajes privados ni a cuentas cerradas; las capturas y republicaciones pueden circular fuera de ellas
Informe de una empresa externa	Datos de identidad, registros públicos e información laboral o educativa	¿Qué empresa lo preparó y actuó por cuenta del empleador o como responsable independiente?	No existe un procedimiento mundial equivalente a la FCRA; las facultades de acceso, copia e impugnación dependen del país y del producto
Página de doxxing o acusación de un tercero	Nombres, supuestas afiliaciones, datos de contacto, imágenes copiadas	¿Qué parte es verificable y quién puede corregir la fuente?	Publicar y repetir una acusación no la verifica ni obliga por sí solo a un empleador a aceptarla

El uso discriminatorio también se analiza bajo la ley que rige la vacante y la decisión. En EE. UU., la Equal Employment Opportunity Commission (EEOC, organismo federal contra la discriminación laboral) y la FTC distinguen el informe de consumidores de la búsqueda directa. España y México separan además la vía de protección de datos de la vía laboral o antidiscriminatoria. Ninguna de esas rutas convierte automáticamente una injusticia en una infracción concreta: primero hay que identificar el dato usado, la decisión y la norma aplicable.

Auditoría en siete pasos antes de una entrevista
#

Audita antes de presentar una candidatura importante, pero no borres primero. Registra qué podría atribuirte quien evalúa; después aporta contexto, corrige, retira, separa identidades o reclama. Usa un dispositivo personal, no una cuenta laboral.

1. Fija los datos de identidad que incluirás en la candidatura
#

Anota exactamente las formas de tu nombre, el dominio del correo, el teléfono, la ciudad, los centros de estudios, los empleadores, los puestos, las fechas, el dominio de tu portafolio y las URL de perfiles que vas a presentar. Esa será tu hoja de anclas. No añadas identificadores sensibles que la candidatura no necesite.

Marca cuáles son poco comunes. Un nombre frecuente combinado con un empleador y una ciudad poco comunes puede identificar mejor que un nombre distintivo por sí solo. Incluye también antiguos nombres o transliteraciones que podrían figurar legítimamente en un registro.

2. Acota la búsqueda pública
#

Busca el nombre exacto entre comillas y combínalo después con un solo dato de la candidatura cada vez: centro de estudios, empleador, ciudad o alias profesional. Consulta al menos dos buscadores porque sus índices difieren. Revisa las imágenes y las primeras páginas de resultados; continuar sin límite aumenta la ansiedad mucho más deprisa que la cobertura.

Busca el correo y el teléfono públicos de la candidatura solo si al hacerlo no expones un dato sensible ante un sitio dudoso. Nunca introduzcas un número de la Seguridad Social estadounidense, pasaporte o fecha de nacimiento completa en un servicio de búsqueda que no hayas verificado.

3. Dibuja un mapa de conexiones
#

Para cada resultado, anota qué dato permitió encontrarlo y qué nueva conexión expone: otro alias, grupo, imagen, dominio, dirección o registro. Detente cuando la conexión salga del modelo de amenazas de la contratación. No necesitas cartografiar toda tu vida, sino detectar qué dato de la candidatura lleva a un contexto arriesgado.

Este paso también descubre la desanonimización asistida por IA: reutilizar un alias o un patrón de escritura puede vincular dos identidades aunque tu nombre legal no aparezca nunca en la cuenta seudónima.

4. Clasifica cada resultado relevante
#

Usa tres etiquetas:

Mío: el resultado te pertenece y el contexto es sustancialmente correcto.
No es mío: pertenece a un homónimo, a alguien que suplanta tu identidad o a un registro sin relación contigo.
Ambiguo: algunos datos coinciden, pero no se ha demostrado que el resultado te pertenezca ni que el contexto sea correcto.

No conviertas «ambiguo» en «mío» solo porque el resultado te resulte incómodo. La auditoría debe cuestionar la atribución. Anota qué datos confirman o contradicen la coincidencia.

5. Conserva las pruebas antes de cambiar nada
#

Si un resultado es falso, amenazante o puede tener consecuencias, guarda una captura fechada, la URL completa, el título de la página, el autor o editor visible y una nota breve que explique el error. Cuando sea legal y seguro, conserva también la página o el PDF. Hazlo en un dispositivo personal, no en un equipo gestionado por tu empleador.

Puede que una solicitud de retirada funcione mientras sobreviven copias, o que la página cambie después de la impugnación. Por eso necesitas preservar las pruebas. Si existe una amenaza física creíble, prioriza la seguridad y la ayuda profesional local sobre una documentación perfecta.

6. Corrige antes de minimizar
#

Sigue este orden: conserva la prueba → corrige la fuente y el expediente → reduce la exposición que sí controlas. Si la publicación es tuya y correcta, añade contexto, restringe su visibilidad, deja de reutilizar alias entre contextos o elimínala después de conservar lo necesario. Ante una página falsa, usa el proceso del editor para corregir la información o denunciar una suplantación y, cuando corresponda, solicita al buscador que deje de indexarla. Si se trata de doxxing organizado, no discutas en público de un modo que amplifique la página: documenta, denuncia y pide a alguien de confianza que la vigile si verla te perjudica.

Una corrección en la fuente no actualiza por sí sola la copia que ya guarda un empleador o una empresa externa. Pide también que rectifiquen el expediente de contratación. Para rastros que perduran, aplica el protocolo sobre la permanencia de la huella social. Esta auditoría no repite su procedimiento para cachés, archivos y copias posteriores.

7. Prepara el expediente e identifica a los responsables
#

Redacta un documento corto para responder si un empleador pregunta: incluye la afirmación discutida, por qué es falsa o incompleta, la prueba que lo respalda y una persona de contacto o fuente oficial que pueda confirmarlo. Limítate a los hechos. Un reclutador necesita resolver una discrepancia, no conocer toda tu historia de acoso.

Pregunta por escrito qué dato se usó, de dónde salió, para qué finalidad, durante cuánto tiempo se conservará, quién lo recibió y si una herramienta automatizada influyó en la decisión. Si intervino un tercero, pide su nombre y averigua si actuó por cuenta del empleador o como responsable independiente. Conserva los avisos, el informe si lo recibes, tu solicitud, los justificantes y el acuse de entrega. No des por hecho que todas las jurisdicciones obligan a entregar una copia previa o reconocen el mismo procedimiento de impugnación.

Procedimiento común y rutas jurídicas para España y México
#

Hablar español no determina tus derechos. Conserva pruebas, identifica al responsable y la ley de la vacante, pide acceso o corrección por la vía local y acude a la autoridad competente. España, México y EE. UU. no comparten un procedimiento único.

A fecha del 30 de julio de 2026, lo que sigue es información general, no asesoramiento jurídico. La residencia del candidato, el país del empleador, el lugar del puesto, dónde se trataron los datos y la función de una empresa externa pueden cambiar la norma aplicable. Si la decisión tiene consecuencias graves, busca asistencia jurídica cualificada en la jurisdicción correspondiente.

Al contrastar las fuentes oficiales de ambos países, encontramos una diferencia que impide copiar una plantilla: España habla de acceso, rectificación, supresión, oposición y limitación; México agrupa acceso, rectificación, cancelación y oposición bajo el nombre ARCO.

Un procedimiento común que no depende del nombre del derecho
#

Conserva la prueba. Guarda el resultado, la URL, la fecha, el aviso del empleador y cualquier informe antes de pedir cambios.
Identifica a quien trató el dato. Pregunta al empleador y al proveedor externo qué información usaron, su fuente, finalidad, conservación, destinatarios y participación de sistemas automatizados.
Comprueba el expediente. Solicita acceso o una copia cuando la ley aplicable lo permita y compara nombres, fechas, identificadores, resoluciones y contexto.
Corrige en dos lugares. Rectifica la fuente original y, por separado, la copia que guarden el empleador o la empresa externa. Conserva la respuesta y el comprobante de entrega.
Minimiza después. Cuando la prueba y la corrección estén a salvo, reduce la exposición controlable sin destruir el registro que necesitarías para reclamar.

Un derecho de rectificación corrige datos personales inexactos; no equivale a un derecho automático a que te contraten ni obliga por sí solo a revocar una decisión laboral. La discriminación, el incumplimiento de las reglas de protección de datos y una fuente difamatoria pueden requerir vías distintas.

España: perfil público no significa uso sin límites
#

La guía de la Agencia Española de Protección de Datos sobre relaciones laborales indica que el hecho de que un perfil sea público no basta para que el empleador trate su contenido sin límites. Debe existir una base jurídica, el dato ha de ser necesario y pertinente para el puesto y el candidato debe recibir información sobre el tratamiento. La misma guía rechaza que el empleador envíe una solicitud de amistad para entrar en una cuenta cerrada. No confundas esto con una prohibición absoluta de mirar la web: la cuestión jurídica es la recopilación y el uso del dato en la selección.

Si participa una empresa de selección, puede actuar como encargada del tratamiento, es decir, por cuenta del empleador, o como responsable independiente, si decide sus propias finalidades y medios. Pide que identifiquen esa función. Los derechos explicados por la AEPD incluyen acceso, rectificación, supresión, oposición y limitación, pero la supresión admite excepciones y no siempre produce un borrado inmediato. Un certificado de antecedentes penales tampoco es un requisito general: la AEPD limita su solicitud a los casos autorizados por una norma española o europea aplicable.

Dirígete primero al responsable por un medio que deje constancia. Si no responde o la respuesta es insuficiente, la AEPD explica cómo presentar una reclamación. Cuando el problema sea una decisión discriminatoria en el acceso al empleo, la vía laboral es distinta: el Estatuto de los Trabajadores prohíbe decisiones discriminatorias y la Inspección de Trabajo y Seguridad Social (ITSS) recibe denuncias y comunicaciones dentro de su competencia.

México: pide el aviso de privacidad y usa la vía ARCO
#

En México, la norma vigente es la Ley Federal de Protección de Datos Personales en Posesión de los Particulares de 2025, reformada por última vez el 14 de noviembre de 2025. Exige principios como licitud, finalidad, información, proporcionalidad y responsabilidad. No trates una cuenta abierta de una red social como si fuera automáticamente una fuente de acceso público en el sentido legal: la definición de la ley es más estrecha y se refiere a sistemas o archivos que pueden consultarse públicamente por disposición legal, salvo límites aplicables.

Pide el aviso de privacidad y compáralo con el uso real. Si intervino un proveedor, pregunta si actuó como encargado del tratamiento por cuenta del empleador o si recibió los datos como responsable independiente; una transferencia y un encargo no son lo mismo. Los derechos ARCO permiten solicitar acceso, rectificación, cancelación y oposición. La cancelación puede incluir un periodo de bloqueo y excepciones por obligaciones o responsabilidades legales, de modo que tampoco garantiza una eliminación instantánea.

El organismo competente ya no es el antiguo INAI. Las funciones sobre datos personales en manos de particulares pasaron a la Secretaría Anticorrupción y Buen Gobierno, ante la que puede iniciarse el procedimiento de protección de derechos después de acudir al responsable. Si el problema es una negativa discriminatoria, el Consejo Nacional para Prevenir la Discriminación (CONAPRED) recibe quejas contra particulares y autoridades federales; la Procuraduría Federal de la Defensa del Trabajo (PROFEDET) ofrece orientación y representación laboral gratuitas dentro de su competencia. Los certificados federales de antecedentes se expiden bajo supuestos concretos, y los certificados estatales siguen reglas propias: pide siempre la base legal y la relación con el puesto.

País o situación aplicable	Primera solicitud	Escalación principal	Lo que no debes dar por hecho
España	Fuente, base jurídica, necesidad para el puesto, conservación, destinatarios y función de cualquier empresa externa	AEPD para protección de datos; ITSS para discriminación laboral	Que un perfil público sea de libre uso o que la supresión obligue a borrar todo de inmediato
México	Aviso de privacidad, datos tratados, finalidad, fuente, transferencias y función del proveedor	Secretaría Anticorrupción y Buen Gobierno para datos; CONAPRED para discriminación; PROFEDET para orientación laboral	Que una cuenta abierta sea automáticamente una fuente de acceso público o que la cancelación revierta la contratación
EE. UU., si se usó un informe de consumidores cubierto	Aviso, autorización, copia del informe y datos de la agencia según la fase	FTC, EEOC o la autoridad estatal según el problema	Que la FCRA se aplique a toda búsqueda directa o fuera de EE. UU.
Otro país	Identidad del responsable, fuente, finalidad, conservación, destinatarios y norma aplicada	Autoridad local de protección de datos, inspección laboral o entidad antidiscriminatoria	Que leer este artículo en español active los derechos de España o México

La guía de la FTC para empleadores sigue siendo útil cuando una empresa estadounidense obtiene un informe de consumidores cubierto: normalmente distingue el aviso y la autorización previos, la copia antes de una posible medida desfavorable y la impugnación posterior. La guía de la FTC para candidatos añade, en esa vía concreta, la posibilidad de pedir otra copia gratuita dentro de los 60 días posteriores a la decisión. Es una regla estadounidense, no una plantilla mundial.

Lo que la limpieza no puede reparar
#

Limpiar reduce la exposición, pero no demuestra que algo nunca ocurrió ni permite retirar una acusación que ya se ha copiado. El objetivo es reducir y corregir las conexiones que pueden atribuirte material, no dejar impecable la primera página de resultados.

Una publicación borrada puede permanecer en capturas, archivos o citas de terceros. La corrección puede convivir con el titular original. Un informe impugnado puede reconstruirse más adelante a partir de la misma fuente errónea. Incluso una identidad bien compartimentada puede sufrir un ataque si alguien ya conoce la conexión. Por eso la auditoría deja constancia de lo ocurrido, además de servir para retirar contenido.

También existe un límite humano. Buscar una y otra vez páginas de acoso puede convertirse en otra fuente de daño. Si ya eres el blanco, encarga la vigilancia a una persona de confianza con instrucciones precisas, en lugar de comprobar esas páginas de forma compulsiva. Cuando aparezcan datos del domicilio o una amenaza física, deja de tratarlo como un problema de reputación y prepara un plan de seguridad. Las defensas frente a la vigilancia en el trabajo responden a otra amenaza, posterior a la contratación, y no sustituyen una respuesta al doxxing.

En conclusión: aplica la defensa que corresponda a la vía y al país
#

Actúa según la vía y el país: conserva el material discutido, corrige la fuente y el expediente, y solo después reduce la exposición. Usa la ruta española, mexicana, estadounidense o local sin trasladar derechos de una jurisdicción a otra.

La pregunta más útil no es «¿qué dato vergonzoso puede encontrar un empleador?». Pregunta: ¿qué dato de mi candidatura conduce a qué afirmación, qué solidez tiene la coincidencia, quién trató la información y qué autoridad puede revisar ese uso? Así, una huella digital difusa se convierte en un conjunto limitado de conexiones que puedes comprobar.

Puntos clave

Una candidatura es un mapa de identidad: nombre, ciudad, centro de estudios, empleador, correo y teléfono son anclas que facilitan conectar otros registros.
Audita cuatro etapas: Ancla → Conexión → Atribución → Decisión. Un resultado no demuestra por sí solo que te pertenezca.
Mantén el orden operativo: conserva la prueba, corrige la fuente y el expediente por separado, y minimiza después la exposición controlable.
Elige la ruta por jurisdicción: en España, AEPD e ITSS atienden problemas distintos; en México, la Secretaría Anticorrupción y Buen Gobierno, CONAPRED y PROFEDET tampoco son intercambiables.
No confundas corrección con contratación: rectificar datos inexactos no obliga automáticamente a un empleador a contratarte ni crea fuera de EE. UU. el procedimiento de la FCRA.

Preguntas frecuentes
#

Estas respuestas separan la búsqueda pública, el acceso a cuentas privadas, los informes de terceros y los derechos locales. El procedimiento depende de quién recopiló el dato y de qué país rige la vacante, no del idioma en el que leas esta guía.

¿Todos los empleadores buscan en Google a cada candidato?
#

Ninguna fuente fiable permite afirmar que lo hagan todos. Una encuesta de Harris Poll de 2022 entre 1.002 responsables de contratación de EE. UU. indicó que el 70 % usaba redes sociales para investigar candidatos y el 17 % lo hacía con todos. Las definiciones y prácticas varían. Considera posible una búsqueda pública, no universal, y audita las conexiones más claras que parten de tu candidatura.

¿Puede un empleador ver cuentas o mensajes privados en redes sociales?
#

Una búsqueda normal en la web pública no abre mensajes privados ni una cuenta cerrada. Sin embargo, respuestas públicas, publicaciones copiadas, capturas, contactos compartidos y páginas que antes eran públicas pueden revelar material fuera de la configuración actual. Un candado no borra el pasado de forma retroactiva. En España, la guía laboral de la AEPD añade que el empleador no queda legitimado para enviar una solicitud de amistad con el fin de entrar en un perfil privado.

¿Necesita mi permiso un empleador para buscar mi nombre en internet?
#

No existe una respuesta mundial. En España, que el perfil sea público no elimina la necesidad de una base jurídica, la pertinencia para el puesto ni el deber de informar. En México, no debes suponer que una cuenta abierta es automáticamente una fuente de acceso público en el sentido de la LFPDPPP: pide el aviso de privacidad. En EE. UU., la autorización escrita de la FCRA suele corresponder al informe de consumidores preparado por un tercero, no a toda búsqueda directa. Comprueba siempre qué ley rige la vacante.

¿Qué hago si un informe de antecedentes pertenece a un homónimo?
#

Pide que identifiquen la fuente, los campos usados y la empresa que preparó el informe. Aporta solo las pruebas necesarias para separar tu identidad de la otra persona y solicita la rectificación tanto al proveedor como al empleador que conserva la copia. Guarda el informe si lo recibes, los avisos, tu solicitud, los documentos justificativos y el comprobante de entrega. En EE. UU., una copia previa puede formar parte del procedimiento FCRA; en España y México debes usar los derechos locales. Corregir el dato no obliga automáticamente a revertir la decisión laboral.

¿Debo borrar publicaciones antiguas antes de solicitar un empleo?
#

Revísalas, pero no empieces con un borrado masivo. Conserva primero las pruebas de cualquier atribución falsa, suplantación, acoso o contexto que pueda ser relevante para una impugnación. Después, reduce la exposición cierta y controlable según la vía. Borrar reduce el riesgo, no garantiza la desaparición: pueden quedar cachés, archivos, capturas y copias citadas.

Referencias
#

Las nueve fuentes globales y las fuentes jurídicas de España y México conservan su URL oficial y un enlace exacto de Internet Archive ya verificado.

Cora Aegis

Cora Aegis escribe en CypherpunkGuide guías de OPSEC centradas en la privacidad. Para este artículo reconstruyó 12 puntos de evidencia entre búsquedas públicas, doxxing organizado e informes de terceros, y añadió tres controles de decisión —procedimiento común, España y México— sin convertir una norma nacional en una promesa universal.

Más sobre Cora →

Lo que la geolocalización con IA descubre en una sola foto (2026)

Sat, 04 Jul 2026 00:00:00 +0000

Publico bajo un seudónimo y con un retrato generado por IA, así que «basta con no salir de cara» nunca iba a resolver por sí solo mi privacidad de ubicación. Lo incómodo es lo que hay detrás de la cara. En abril de 2025, un desarrollador enfrentó al modelo o3 de OpenAI contra un Master de GeoGuessr —GeoGuessr es el juego de adivinar dónde se tomó una imagen de Street View, y un Master es un humano de primerísimo nivel— y ganó la máquina: 23.179 puntos contra 22.054. Acertó el país en las cinco rondas y, en dos de ellas, cayó a unos pocos cientos de metros del lugar exacto. En esas mismas pruebas, o3 ignoró unas coordenadas GPS falsas plantadas en los metadatos del archivo y dedujo la ubicación real usando solo los píxeles.

Ese último detalle lo resume todo. Durante veinte años, el consejo estándar para la privacidad de las fotos fue «borra el EXIF» —el EXIF son los datos que la cámara incrusta en la foto, que pueden incluir la ubicación—; en concreto, quitar la etiqueta GPS oculta que tu teléfono escribe en el archivo. Era un buen consejo contra lo que hoy es la mitad fácil del problema. La mitad difícil es que una máquina puede leer los tejados, las plantas, la pintura del asfalto, el ángulo del sol y la tipografía del letrero de una tienda, y ubicarte sin un solo metadato. Un modelo de Stanford llamado PIGEON —un sistema de geolocalización— identifica el país de una foto corriente el 91,96 % de las veces y venció a un campeón mundial de GeoGuessr en seis partidas seguidas. En un test de 2025, un modelo Gemini de propósito general acertó la ciudad exacta el 64,3 % de las veces; los humanos con los que se comparó llegaron al 1,7 %.

Así que la pregunta aquí no es «si la IA puede encontrar tu ubicación» —puede—, sino qué cambia de verdad tu exposición una vez que puede. Repasando los benchmarks públicos y las guías de campo de Bellingcat —el medio de investigación de fuentes abiertas—, rastreé cómo un localizador va acotando una foto y luego recorrí esa cadena al revés para convertirla en defensa. En resumen: la ubicación se filtra ahora en dos capas, y cada una se arregla de otra manera. La capa de metadatos puedes limpiarla. La capa visible solo puedes gestionarla: controlando qué entra en la imagen y cuándo sale, igual que un investigador de fuentes abiertas trabajaría el problema a la inversa.

Lo que delata una sola foto ahora que la IA la lee
#

La geolocalización con IA es deducir dónde se tomó una foto a partir de su contenido visible —edificios, vegetación, marcas viales, ángulo del sol, letreros— y no de una etiqueta GPS. Ese es el cambio que importa: hasta hace poco esto era «una afición para humanos con talento» y ha pasado a ser «una conjetura barata, rápida y automática», y el salto se dio frente a jugadores expertos, no novatos. Las cifras que siguen vienen de benchmarks con revisión por pares y de un duelo directo muy reproducido, no del marketing de ningún fabricante.

El tamaño de la brecha entre máquina y humano es lo que casi todo el mundo subestima. En un benchmark académico de 2025, un modelo Gemini alcanzó un 83,7 % de acierto a nivel de país y un 64,3 % a nivel de ciudad, mientras que las personas que hicieron el mismo test sacaron un 9,5 % y un 1,7 %. Alguien a quien esto se le da bien —un jugador de GeoGuessr con ranking— todavía compite de tú a tú, y precisamente por eso resulta alarmante que o3 venciera a un Master y que PIGEON barriera a un campeón: lo que alquila un adversario es el techo, no la media.

Sistema	Nivel de país	Nivel de ciudad	Nota
PIGEON (Stanford, 2024)	91,96 %	mediana del error ~44 km	Barrió a un campeón de GeoGuessr por 6 a 0
Gemini (benchmark de 2025)	83,7 %	64,3 %	Mismo benchmark; humanos: 9,5 % / 1,7 %
GPT-4o (benchmark de 2025)	74,0 %	63,3 %	Modelo de consumo, mismo conjunto de comparación con humanos
o3 (2025, duelo directo)	las 5 rondas	a unos cientos de m ×2	Venció a un Master humano; ignoró EXIF falso

Dos matices, para no exagerar. Primero, el acierto es desigual: los modelos rinden mucho mejor en Norteamérica y Europa Occidental que en regiones poco representadas, así que «la IA no sabría situar mi pueblo» a veces es cierto y nunca es algo con lo que puedas contar. Segundo, las herramientas especializadas llegan más lejos que los chatbots generales. GeoSpy, un sistema comercial de Graylark Technologies, se entrenó con decenas de millones de imágenes a pie de calle; la empresa asegura precisión a nivel de calle cuando las imágenes de entrada son buenas. Su historia es su propia advertencia: tras el lanzamiento, hubo usuarios que subieron vídeos pidiéndole que localizara a mujeres concretas, y la empresa retiró el acceso público y limitó la herramienta a clientes policiales, empresariales y gubernamentales. La capacidad es tan real que sus propios creadores decidieron que no podían confiársela al público.

Cómo localiza una foto un investigador — y por qué eso te ayuda
#

Un investigador de fuentes abiertas no necesita IA para ubicar una foto; la disciplina de la geolocalización —confirmar dónde se tomó una imagen a partir de pruebas visibles— le lleva una década de ventaja a estos modelos. Entender su método importa porque una buena defensa no es más que su método al revés: las pistas que ellos cazan son exactamente las que tú quieres fuera de tu encuadre. Bellingcat, el medio de investigación que formalizó buena parte de esta práctica, lo enseña como una lista de comprobación por capas.

Las capas van de lo grueso a lo fino. La cronolocalización usa las sombras: la longitud y la dirección de una sombra, cruzadas con una calculadora de posición solar para una fecha candidata, acotan a la vez la hora del día y la latitud. La arquitectura y la infraestructura acotan el país: el diseño de los postes de electricidad, la forma de los semáforos, los estilos de bordillos y bolardos cambian según la jurisdicción, y hay bases de datos de referencia que catalogan esas diferencias. La vegetación distingue climas y regiones. Los letreros y la escritura muchas veces entregan la ciudad, o una calle concreta, sin más. Y los reflejos —el escaparate de una tienda, el retrovisor de un coche, unas gafas de sol— pueden revelar aquello a lo que la cámara daba la espalda. Cuando Bellingcat confirmó la ruta del convoy del MH17 —el rastreo del camión que transportó el misil que derribó un avión de pasajeros sobre Ucrania en 2014—, lo hizo exactamente con este apilamiento: análisis de sombras más coincidencia de puntos de referencia, fijado a un tramo exacto de carretera.

Lo que la IA cambió no es el método, sino el coste. Un investigador humano dedica horas a cada imagen; un modelo hace la misma inferencia en segundos por unos céntimos, y se le puede poner a analizar miles de imágenes a la vez. La conclusión defensiva es concreta y hasta libera un poco: no tienes que derrotar a un genio, tienes que retirar las pistas que se acumulan. Cada capa que niegas —ningún letrero, ninguna silueta urbana reconocible, ninguna superficie reflectante, ninguna sombra despejada— es una capa que el localizador, humano o máquina, ya no puede usar.

Las dos capas por las que se filtra la ubicación
#

Este es el marco que reordena todo lo demás, y el que casi todas las guías dejan borroso: una foto filtra la ubicación por dos capas independientes, y solo una de ellas es un problema resuelto. Confundirlas es la razón por la que «ya borré los metadatos» da a la gente una confianza que no se ha ganado.

La Capa 1 son los metadatos: el bloque EXIF que tu cámara escribe en el archivo, con las coordenadas GPS exactas incluidas si tenías la ubicación activada. Esta capa tiene solución. Es un dato concreto, ocupa un lugar conocido dentro del archivo y puedes eliminarlo por completo antes de que la foto salga siquiera de tu dispositivo. Lo borras y esa coordenada, sencillamente, deja de existir.

La Capa 2 es el contenido: la escena visible en sí. Es lo que leen los modelos de visión, y no se puede quitar, porque no está pegada a la foto: es la foto. No puedes borrar la arquitectura sin borrar la imagen. Cuando o3 ignoró la etiqueta GPS falsa y ubicó la imagen por sus píxeles, estaba demostrando que la Capa 2 ya se sostiene sola: un adversario que no saca nada de la Capa 1 aún tiene todo el encuadre visible con el que trabajar.

Eso replantea toda la defensa. La Capa 1 es un problema de limpieza: un solo gesto mecánico, repetido cada vez. La Capa 2 es un problema de composición: se decide cuando pulsas el disparador y cuando pulsas publicar, y ninguna herramienta posterior arregla una silueta urbana que ya publicaste. El resto de este artículo las trata por separado, porque tratarlas juntas es justo el error.

«Pero si ya borré los metadatos»: qué arregla eso en realidad
#

Borrar los metadatos es necesario y ya no basta. Cierra la Capa 1 con limpieza y no hace nada por la Capa 2; y aun dentro de la Capa 1, eso en lo que casi todos confían —lo que hace la plataforma por su cuenta— es más limitado de lo que la gente cree. Hay que desmontar dos creencias: que las redes sociales ya se encargan de esto por ti, y que una captura rápida deja la foto limpia.

La mayoría de las grandes plataformas sí recodifican las subidas públicas y eliminan el bloque EXIF de la versión que otros usuarios pueden descargar, pero las garantías tienen condiciones. A fecha de 2026, los servicios independientes que analizan metadatos informan de que la excepción se repite en todas las apps: los modos «enviar como documento» o «enviar como archivo» saltan la recodificación y lo conservan todo, a un toque del camino seguro y sin ningún aviso. Y borrar la copia pública no es lo mismo que eliminarla: la propia política de privacidad de Meta señala que retiene los datos originales de la imagen en sus servidores para sus propios fines. La tabla de abajo combina el comportamiento probado y la política oficial; léela como «dónde están las trampas», no como una promesa sobre ninguna subida concreta.

Vía	EXIF público	La trampa
Instagram / Facebook (publicación pública)	Se borra en la copia descargable	El original se retiene en el servidor; los envíos de mayor calidad por MD pueden variar
X (publicación pública)	Se borra	Retención interna; la programación y los clientes de API de terceros no están verificados
Reddit (nativo `i.redd.it`)	Se borra al recodificar	Los alojamientos de imágenes externos (p. ej., enlaces de imgur) pueden conservar el GPS
TikTok (publicación)	Se borra	La app recoge la ubicación por otras vías; borrar ≠ sin rastreo
WhatsApp / Signal / Telegram (modo foto)	Se borra por compresión	«Documento / enviar como archivo» conserva el EXIF completo, sin aviso

El mito de la captura merece su propia línea, porque los buscadores no dejan de recomendarlo. Hacer una captura sí genera un archivo nuevo sin la etiqueta GPS original: es un arreglo real de la Capa 1. Y no hace absolutamente nada por la Capa 2: la captura sigue mostrando la misma calle, la misma silueta urbana, el mismo letrero de la tienda, y un modelo los lee igual de bien en una captura que en el original. Una captura cambia el archivo, no lo que aparece en la imagen.

Un protocolo de defensa a la medida de tu modelo de amenazas
#

Aquí no hay una única dosis correcta de cautela: el protocolo adecuado depende de quién podría estar mirando y de qué podría hacer con un acierto. Las reglas de brocha gorda tipo «no publiques nunca al aire libre» son invivibles y, para casi todo el mundo, innecesarias; lo útil es ajustar el esfuerzo a la amenaza, la misma lógica de modelado de amenazas sobre la que se construye Surveillance Self-Defense, el proyecto de la EFF —la Electronic Frontier Foundation—. Los niveles de abajo van subiendo: todo el mundo debería cumplir el básico, y cada nivel superior se suma al anterior en lugar de sustituirlo.

La línea que separa los niveles es la consecuencia. Para quien comparte de forma casual, una foto localizada es un rasguño en la privacidad. Para una creadora pública, o para una mujer que ya sufre acoso, es un paso hacia un encuentro en el mundo real; y esto no es hipotético, porque la geolocalización con IA alimenta las mismas amenazas de acecho y de violencia de pareja que Privacy International cataloga —Privacy International es una ONG británica de privacidad— en su taxonomía de riesgos, y porque ya vimos por qué los creadores de GeoSpy cerraron la puerta al público. Para un activista, un periodista o un superviviente de maltrato, un solo fotograma geolocalizado puede ser un asunto de seguridad física. Sitúate primero en esa escalera y aplica luego la fila que te corresponde.

Nivel	Quién	Suma estos hábitos
Básico (todos)	Quien comparte de forma casual	Borra el EXIF en local antes de subir (no te fíes de la plataforma); no publiques nunca en tiempo real tu casa, tu trabajo ni el colegio de tu hijo; recuerda que una captura no es segura
Elevado	Figura pública, creadores, cualquiera que sufra acoso	Retrasa la publicación para que «aquí ahora» se vuelva «aquí la semana pasada»; limpia los fondos —ventanas, reflejos, matrículas, siluetas urbanas reconocibles—; evita los lugares recurrentes de tu rutina
Alto	Activista, periodista, superviviente de violencia de pareja, denunciante	Da por hecho que cualquier foto publicada es geolocalizable para siempre; haz una revisión de «qué revela este encuadre» antes de publicar, no después; mantén un dispositivo y una cuenta aparte que nunca lleven imágenes con ubicación

Tres técnicas necesitan una etiqueta honesta para que no te fíes de ellas más de la cuenta. Borrar el EXIF conviene hacerlo en local y de forma mecánica: la herramienta de línea de comandos ExifTool lo quita todo de una pasada (exiftool -all= photo.jpg) y, como corre en tu máquina, la foto nunca sale de ella. Retrasar la publicación neutraliza la filtración en tiempo real —el adversario que quiere saber dónde estás ahora mismo—, pero no hace nada contra el análisis a posteriori, porque el fondo sigue resolviéndose a un lugar cada vez que alguien lo examina. Y desenfocar el fondo es más débil de lo que parece: un desenfoque suave puede revertirse en parte con técnicas de deblurring —que deshacen el desenfoque—, así que las opciones honestas son un pixelado fuerte o, sencillamente, no incluir el elemento. Nombra cada técnica por la capa que aborda y dejarás de confundir «hice algo» con «estoy a cubierto».

En conclusión: ¿cuánto deberías hacer en realidad?
#

Para casi todo el mundo, el protocolo entero se reduce a dos hábitos: borrar los metadatos en local por reflejo, y dejar de publicar en tiempo real los sitios a los que vuelves —casa, trabajo, la ida al colegio—. Eso cierra la Capa 1 del todo y le niega a la Capa 2 su pista más valiosa, que es un lugar rutinario sobre el que un adversario puede actuar. Todo lo que va por encima depende de tu modelo de amenazas, y quienes necesitan el nivel alto suelen saber ya quiénes son.

El cambio de mentalidad es lo que perdura. La vieja pregunta —«¿me acordé de desactivar el geoetiquetado?»— es una pregunta de Capa 1, y la Capa 1 es casi automática en cuanto ExifTool se te hace costumbre. La pregunta que hoy te protege es de Capa 2: ¿qué dice este encuadre sobre dónde estoy, y se lo entregaría a un desconocido que quisiera encontrarme? Cuando reviso una foto antes de que salga, esa es la única pregunta que me hago, porque es la única que ya no puedo impedir que las máquinas respondan por mí.

Puntos clave

Dos capas, dos arreglos: los metadatos EXIF tienen solución (bórralos en local); el fondo visible no se puede quitar y solo se gestiona con la composición y el momento de publicar.
La IA vence a expertos, no solo a novatos: PIGEON identifica el país de una foto el 91,96 % de las veces y barrió a un campeón de GeoGuessr por 6-0; un modelo Gemini alcanzó el 64,3 % a nivel de ciudad donde los humanos sacaron un 1,7 %.
Borrar los metadatos es necesario, no suficiente: o3 ubicó fotos después de que se falsearan sus etiquetas GPS, leyendo solo los píxeles; y una captura quita el EXIF pero mantiene todo el encuadre geolocalizable.
El borrado que hacen las plataformas tiene trampas: las publicaciones públicas suelen recodificarse, pero los modos «enviar como documento/archivo» conservan el EXIF completo, y las plataformas pueden retener el original en sus servidores.
Ajusta el esfuerzo a la amenaza: todos deberían borrar el EXIF y evitar publicar en tiempo real su casa o su trabajo; los creadores y quienes sufren acoso añaden el retraso y la limpieza del fondo; los activistas y los supervivientes tratan cada foto publicada como localizable para siempre.

Preguntas frecuentes
#

¿Borrar los datos EXIF oculta mi ubicación?
#

Resuelve la mitad del problema. Quitar el EXIF elimina la coordenada GPS exacta que incrustó tu cámara: un arreglo real y valioso. Pero los modelos de visión actuales deducen la ubicación a partir de la escena visible —arquitectura, vegetación, ángulo del sol, letreros— sin un solo metadato. En pruebas documentadas, el o3 de OpenAI ubicó fotos incluso después de sustituir sus etiquetas GPS por otras falsas. Borra los metadatos como base y trata luego el contenido real de la imagen como la capa más difícil y aún sin resolver.

¿Es seguro publicar una captura en vez de la foto original?
#

Una captura quita el EXIF original, así que cierra la capa de metadatos, pero no cambia nada de la imagen en sí. La calle, la silueta urbana y cualquier letrero legible siguen en el encuadre, y una IA los lee en una captura igual de bien que en el archivo original. Una captura cambia el archivo, no lo que aparece en la imagen; no es una defensa de geolocalización.

¿De verdad la IA localiza una foto mejor que una persona?
#

Sí, y frente a personas hábiles, no solo novatos. Un modelo de Stanford, PIGEON, identifica el país de una foto el 91,96 % de las veces y venció a un campeón mundial de GeoGuessr en seis partidas. En un benchmark de 2025, un modelo Gemini alcanzó un 64,3 % de acierto a nivel de ciudad donde las personas del test sacaron un 1,7 %. El acierto es desigual según la región, pero el techo —lo que un adversario decidido puede alquilar— es altísimo.

¿Desenfocar el fondo me protege?
#

Solo si es lo bastante fuerte. Un desenfoque suave o un pixelado flojo pueden revertirse en parte con técnicas de deblurring, que recuperan texto y detalle. Si un elemento del fondo delataría tu ubicación —un letrero de calle, un edificio característico, un reflejo—, las opciones fiables son un pixelado fuerte o excluirlo por completo del encuadre, no un desenfoque leve.

¿Cuál es el hábito que más protege?
#

Deja de publicar los lugares recurrentes de tu vida real —casa, trabajo, el colegio de tu hijo, el gimnasio al que vas con horario fijo—, sobre todo en tiempo real. Una foto suelta de vacaciones es menos riesgo que una rutina sobre la que un adversario puede actuar. Combínalo con borrar el EXIF en local antes de subir la foto y habrás cerrado la capa de metadatos y le habrás negado a la capa de contenido su pista más accionable.

#	Fuente	URL	Archivo
1	Privacy International — “Nowhere to Hide? Privacy Risks and Policy Implications of AI Geolocation” (2026)	https://privacyinternational.org/report/5736/nowhere-hide-privacy-risks-and-policy-implications-ai-geolocation	https://web.archive.org/web/*/https://privacyinternational.org/report/5736/nowhere-hide-privacy-risks-and-policy-implications-ai-geolocation
2	Haas et al. — “PIGEON: Predicting Image Geolocations” (Stanford, CVPR 2024)	https://arxiv.org/abs/2307.05845	https://web.archive.org/web/*/https://arxiv.org/abs/2307.05845
3	Huang et al. — “AI Sees Your Location, But With A Bias Toward The Wealthy World” (VLMs as GeoGuessr Masters, arXiv, 2025)	https://arxiv.org/abs/2502.11163	https://web.archive.org/web/*/https://arxiv.org/abs/2502.11163
4	Sam Patterson — “Can o3 beat a GeoGuessr Master?” (2025)	https://sampatt.com/blog/2025-04-28-can-o3-beat-a-geoguessr-master/	https://web.archive.org/web/*/https://sampatt.com/blog/2025-04-28-can-o3-beat-a-geoguessr-master/
5	Simon Willison — “o3 beats a GeoGuessr master” (2025)	https://simonwillison.net/2025/Apr/28/o3-geoguessr/	https://web.archive.org/web/*/https://simonwillison.net/2025/Apr/28/o3-geoguessr/
6	Bellingcat — “Using the Sun and the Shadows for Geolocation” (2020)	https://www.bellingcat.com/resources/2020/12/03/using-the-sun-and-the-shadows-for-geolocation/	https://web.archive.org/web/*/https://www.bellingcat.com/resources/2020/12/03/using-the-sun-and-the-shadows-for-geolocation/
7	TechNADU — “GeoSpy Sparks Privacy Concerns After Public Misuse” (2025)	https://www.technadu.com/ai-powered-tool-geospy-sparks-privacy-concerns-after-public-misuse/570730/	https://web.archive.org/web/*/https://www.technadu.com/ai-powered-tool-geospy-sparks-privacy-concerns-after-public-misuse/570730/
8	Electronic Frontier Foundation — Surveillance Self-Defense	https://ssd.eff.org/	https://web.archive.org/web/*/https://ssd.eff.org/
9	Meta — Privacy Policy (image metadata retention)	https://www.facebook.com/privacy/policy/	https://web.archive.org/web/*/https://www.facebook.com/privacy/policy/

Este artículo es el complemento —centrado en la foto— de un hilo más amplio en este sitio. La misma inferencia automática, aplicada a tu texto y no a tus imágenes, está trazada en Desanonimización con IA: cómo la inferencia deshace tu anonimato, y los supuestos que la IA rompe en todo tu modelo de amenazas quedan expuestos en OPSEC en la era de la IA: rehaz tu modelo de amenazas. Puesto que una foto localizada no se despublica una vez publicada, la auditoría de lo que de verdad sobrevive al borrado vive en Tu huella digital no se borra. Para esa misma amenaza apuntada a tu cuerpo y no a tu fondo, mira Tu voz y tu rostro ya son contraseñas; y para ver cómo estas técnicas convergen sobre un objetivo real, Cómo se hace doxxing a los streamers y el manual del seudónimo.

Tu voz y tu rostro ya son contraseñas: OPSEC frente a la clonación con IA (2026)

Thu, 18 Jun 2026 00:00:00 +0000

Escribo bajo seudónimo y soy mujer, así que esta es la amenaza que sopeso antes de grabar nada. La vieja premisa detrás de una voz o un rostro conocidos era que se autenticaban solos: si tu madre oía tu voz por teléfono, eras tú, porque falsificarla exigía tu participación. Esa premisa se acabó. Los mismos rasgos biométricos que tomas como prueba de que eres «tú» —el timbre de tu voz, la geometría de tu cara, hasta el ritmo de tu escritura— son ahora materia prima con la que un modelo puede suplantarte, a partir de muestras que tú misma publicaste.

Esta es la cuarta premisa rota del modelo de amenazas de la era de la IA, y merece un tratamiento aparte porque la defensa es inusual: es casi por completo preventiva. No puedes retirar una muestra de voz y, como veremos, tampoco puedes hacer que un modelo la olvide de forma fiable. Por eso el trabajo va por delante: lo que publicas y lo que acuerdas de antemano con las personas a las que podrían atacar a través de ti. Abajo está la doble naturaleza del problema, por qué recae de forma desigual sobre las mujeres y sobre cualquiera que publique con un nombre, la reducción de muestras que baja tu exposición y el protocolo completo de verificación que el artículo anterior solo dejó prometido.

Tu biometría se volvió a la vez llave de acceso y blanco
#

Una credencial es algo que prueba quién eres; una superficie de ataque es algo que un adversario puede aprovechar. La voz, el rostro y el estilo de escritura son ahora las dos cosas: los mismos rasgos que responden por ti permiten también a un modelo falsificarte. El derrumbe es reciente y está medido. En 2023, investigadores de Microsoft mostraron que su modelo VALL-E podía sintetizar la voz de una persona a partir de una muestra de tres segundos; un puñado de fotos basta para un parecido sintético convincente; un montón de tus publicaciones basta para imitar cómo escribes. Nada de esto requiere tu cooperación más allá de haber publicado en primer lugar.

Lo que convierte esto en un problema de credenciales, y no solo de falsificación, es que las instituciones empezaron a confiar en la biometría justo cuando se volvió barata de falsear. Los bancos desplegaron autenticación telefónica por huella de voz; las familias se fían de una voz reconocida; los asistentes se desbloquean ante un rostro. La Comisión Federal de Comercio de EE. UU. (FTC) señaló la consecuencia sin rodeos: lanzó un Voice Cloning Challenge en noviembre de 2023 y publicó Approaches to Address AI-enabled Voice Cloning en abril de 2024. Aquello que te autentica es ahora aquello que te compromete.

Tu rasgo biométrico	Hoy se confía en él como credencial para	Ahora también es superficie de ataque porque
Voz	Identificación bancaria por teléfono, confianza familiar, asistentes de voz	Un fragmento de unos 3 segundos produce un clon convincente
Rostro	Verificación con foto de identidad, prueba social, desbloqueo del dispositivo	Un puñado de imágenes produce un parecido sintético
Estilo de escritura	«Suena a esa persona»	Un conjunto de publicaciones permite transferir el estilo

La consecuencia defensiva es que dejes de pensar en estos rasgos como algo que se autentica solo. Una voz al teléfono ya no es prueba; un rostro en un vídeo ya no es prueba. Todo lo que sigue en este artículo parte de aceptar eso.

Por qué golpea con más fuerza a las mujeres y a los seudónimos
#

Este riesgo no se reparte por igual. La suplantación, las imágenes íntimas fabricadas y el fraude por voz recaen de forma desproporcionada sobre las mujeres y sobre cualquiera que tenga un acosador motivado, lo que lo convierte en una cuestión de soberanía corporal y reputacional, no en una simple higiene de datos. La evidencia es consistente entre fuentes. Un estudio de Deeptrace de 2019 halló que el 96 % de los vídeos deepfake eran pornográficos y que, en la práctica, todas las personas atacadas eran mujeres; una encuesta sectorial de 2023 de Security Hero, firma de rastreo de deepfakes, situó la proporción pornográfica en el 98 %, con un 99 % de blancos mujeres. Son estudios de rastreo, no datos oficiales, pero su dirección la corrobora un periodismo más sólido.

En diciembre de 2024, el American Sunlight Project halló que en torno a una de cada seis mujeres del Congreso de EE. UU. —cerca del 16 %— había sido representada en imágenes deepfake sin consentimiento, y que a las mujeres se las tomaba como blanco unas 70 veces más a menudo que a los hombres (lo reportó primero The 19th). ONU Mujeres, al repasar el patrón más amplio, señala que más de la mitad de las víctimas de deepfakes en Estados Unidos contemplaron el suicidio y que la violencia digital se desborda con frecuencia hacia el acoso fuera de la red. El daño no es un riesgo reputacional abstracto; es dirigido, tiene género y está diseñado para silenciar.

Para una creadora seudónima, el aprieto se cierra en una contradicción. Una persona con nombre se construye sobre la voz y la presencia —un pódcast, una charla, un rostro que vuelve humano el trabajo—, y sin embargo cada grabación limpia y cada foto de frente son también datos de entrenamiento para quien quiera suplantar esa identidad o pegarla a mi yo legal. La reducción de muestras, primera defensa de abajo, choca de frente con el alcance. No voy a fingir que esa tensión no existe; voy a mostrar cómo gestionarla en lugar de dejar que ella me gestione a mí.

Primero prevenir: reduce las muestras que publicas
#

La primera palanca es la reducción de muestras: baja el volumen y la nitidez del material biométrico en bruto que pones en público, asumiendo que esto es mitigación, no cura. Es la misma lógica que rige la desanonimización a escala de IA: el ataque más barato lee lo que ya publicaste, así que el control de mayor palanca está aguas arriba de cualquier retirada. La calidad de un clon está acotada por su material de entrenamiento. Las grabaciones largas, limpias y en solitario son la muestra ideal; el audio corto, con ruido y con varias voces a la vez es una muestra pobre. Tú eliges cuál entregas.

En concreto, eso significa separar la media de la persona con nombre de la captura biométrica de alta fidelidad siempre que puedas, y quitar los metadatos que clavan una muestra a una hora y un lugar. Para una creadora pública la meta no es el silencio: es degradar a propósito la calidad de la muestra en relación con el alcance. Audio con copresentador en vez de monólogo en solitario; un avatar ilustrado que lleve la identidad con nombre en vez de un rostro atado a un nombre legal; y un rechazo tajante a que tu voz haga las veces de factor de autenticación.

Lo que publicas	El riesgo que crea	Alternativa de menor exposición
Grabaciones de voz largas, limpias y en solitario	Una muestra de entrenamiento de alta fidelidad	Fragmentos más cortos; audio con copresentador; ruido o música de fondo bajo la voz
Fotos de frente atadas a tu nombre legal	Un parecido y un enlace de identidad	Un avatar ilustrado para la persona con nombre; mantén cualquier rostro real lejos del nombre legal
Huella de voz como factor de banca o de acceso	Un clon se convierte en credencial que funciona	Desactiva la autenticación por voz; usa un segundo factor no biométrico

Nada de esto es una cura, y decir lo contrario sería deshonesto. Las muestras ya públicas siguen públicas, y un adversario decidido puede trabajar con material pobre. La reducción baja la probabilidad y la fidelidad de un clon exitoso; no las lleva a cero. Por eso mismo se acompaña de la segunda palanca, que da por hecho que el clon acabará existiendo.

El protocolo de verificación, completo
#

La segunda palanca es la confianza acordada de antemano: pacta, por adelantado y por un canal aparte, un paso de verificación con las personas a las que podrían atacar a través de ti, para que una voz clonada no pueda fabricar urgencia. Casi todos los consejos se quedan en «elige una palabra clave familiar». Es el instinto correcto y un protocolo incompleto. Una palabra clave funciona no porque sea secreta, sino porque obliga a una segunda comprobación, por un canal que el atacante no controla, justo en el momento en que se convierte la urgencia en arma. Construye todo el mecanismo en torno a ese principio, no en torno a una sola frase compartida.

La regla de diseño es sencilla: la verificación nunca debe viajar por el mismo canal que la petición. Una voz clonada controla la llamada entrante; no controla una devolución de llamada a un número que ya tienes, ni un recuerdo privado con el que nunca fue entrenada. La memoria episódica —un momento compartido concreto, no un dato que cualquiera podría publicar— es la parte de ti que un modelo no puede sintetizar.

Elemento del protocolo	Cómo montarlo	Por qué un clon no puede vencerlo
Regla de canal aparte	Verifica por un canal distinto a aquel por el que llegó la petición (una llamada → un mensaje a un número conocido)	El clon controla un canal, no un segundo independiente
Reto de memoria vivida	Una pregunta que solo se responde desde una experiencia compartida, nunca publicada; rótala	Los modelos sintetizan la voz, no la memoria episódica privada
Disciplina de devolución de llamada	Cuelga; vuelve a llamar al número que ya tienes guardado	Anula el identificador de llamada falseado y la presión del tiempo
Señal de coacción	Una palabra pactada que significa «me están obligando: cumple y busca ayuda»	Cubre el caso en que la persona es real pero está coaccionada
Extensión para seudónimos	Para contactos seudónimos, comparte de antemano un código de un solo uso por un canal aparte, no atado a la identidad legal	Permite a un seudónimo verificarse sin des-seudonimizarse

Esa última fila es la pensada para gente como yo, y la que ninguna guía de «palabra clave familiar» cubre. Si tus contactos de confianza te conocen solo como un seudónimo, no puedes recurrir a una historia familiar compartida sin romper el muro entre persona pública y persona real. Un código de verificación de un solo uso —intercambiado una vez por un canal cifrado y usado para arrancar un reto rotativo— permite que una red de colaboradores seudónimos se autentiquen entre sí sin que nadie llegue a saber un nombre legal. El protocolo escala desde un hogar de dos personas hasta una red distribuida de activistas o creadores precisamente porque nunca depende de una identidad legal compartida, sino solo de un secreto compartido establecido por un canal aparte.

«Bórralo y ya» no funciona, y por eso la prevención lo es todo
#

Aquí el peso lo carga la prevención porque el borrado no sostiene la estructura. Quitar una voz o un parecido de un modelo ya entrenado es, a escala de producción, todavía una capacidad en fase de investigación —no un botón que puedas pulsar hoy—, así que el control que de verdad funciona es no soltar la muestra. Es el mismo relevo que la permanencia de tu huella publicada: el momento gana a la limpieza, porque la ingesta es continua y la eliminación, parcial.

La investigación es honesta sobre sus propios límites. MIT Technology Review informó en julio de 2025 de que se puede hacer que un modelo de texto a voz «desaprenda» a un hablante concreto, pero el proceso tarda días, degrada un poco las voces permitidas del modelo y, en palabras de los propios investigadores, «necesitaría soluciones más rápidas y escalables» para un uso real. Así que la afirmación exacta no es «el borrado es imposible»: es que el desaprendizaje automático (machine unlearning) sigue siendo una capacidad en fase de investigación, no un botón que puedas pulsar hoy. Trata cualquier oferta de «retira mi voz» como algo parcial y orientado al futuro, no como un deshacer.

Lo que reordena todo. Si la muestra, una vez pública, es en la práctica permanente, entonces el único control plenamente efectivo está antes de la publicación, y el segundo mejor es el protocolo de verificación que da por hecho que el clon existe. Las herramientas de detección y los servicios de retirada tienen su sitio, pero son el anillo exterior, el más débil. Los anillos interiores —reducir y acordar la confianza de antemano— son los que controlas por completo.

Conclusiones clave
#

La voz, el rostro y la escritura son ya credenciales y superficies de ataque a la vez. Deja de tratar una voz o un rostro reconocidos como prueba que se autentica sola.
La defensa es preventiva, no reactiva. Un fragmento de unos 3 segundos clona una voz; no puedes retirar una muestra, y el desaprendizaje aún no está listo para producción.
La amenaza tiene género. Las imágenes íntimas sintéticas y la suplantación recaen de forma abrumadora sobre las mujeres y los seudónimos públicos: es soberanía corporal y reputacional, no mera higiene de datos.
Reduce la calidad de la muestra en relación con el alcance. Audio con copresentador, avatares para la persona con nombre, sin accesos por huella de voz, metadatos quitados.
Acuerda de antemano un paso de verificación por un canal aparte. Disciplina de devolución de llamada, un reto de memoria vivida, una señal de coacción y —para seudónimos— un código de un solo uso que verifica sin des-seudonimizar.

Preguntas frecuentes
#

¿De verdad la IA puede clonar mi voz a partir de un fragmento corto?
#

Sí. Un modelo de investigación de Microsoft de 2023 demostró la síntesis de voz a partir de una muestra de tres segundos, y hoy hay herramientas comerciales que ofrecen una clonación similar con muestras cortas. En un estudio de la UC Berkeley de 2025 (Barrington y Farid, Scientific Reports), los oyentes confundieron esos clones con voces reales en torno al 80 % de las veces. La lección práctica es tratar cualquier grabación limpia y pública de tu voz como una muestra utilizable, y reducir cuántas de ellas existen.

¿De verdad funcionan las «palabras clave» familiares?
#

Funcionan cuando obligan a una comprobación por un canal que el atacante no controla, y por eso la versión más fuerte es una devolución de llamada a un número conocido más una pregunta que solo se responde desde una memoria privada y compartida, no una única frase fija. Una contraseña se puede adivinar, oír por casualidad o sacar con ingeniería social; un reto rotativo de memoria vivida más una señal de coacción es mucho más resistente. La frase es la semilla del protocolo, no el protocolo entero.

¿Puedo retirar mi voz o mi rostro de los modelos de IA que ya se entrenaron con ellos?
#

Hoy, no de forma fiable ni a escala. Se puede hacer que un modelo «desaprenda» a un hablante, pero el proceso es lento, imperfecto y aún no está desplegado en sistemas de producción (según MIT Technology Review, 2025). Las exclusiones y las señales de «no entrenar» afectan sobre todo a la ingesta futura, allí donde las plataformas las respetan. Trata la retirada como algo parcial y orientado al futuro, que es justo por lo que reducir lo que publicas importa más que cualquier retirada.

¿Por qué plantear esto en concreto como un problema de mujeres?
#

Porque los datos están desequilibrados. Los estudios de rastreo sitúan a las mujeres como la abrumadora mayoría de los blancos de pornografía deepfake, y un estudio del American Sunlight Project halló que cerca de una de cada seis mujeres del Congreso aparecía representada en imágenes sin consentimiento, unas 70 veces la tasa de los hombres. Una defensa que ignore a quién se ataca de verdad protegerá de menos a las personas en mayor riesgo, así que el protocolo de aquí está construido para el modelo de amenazas del acoso y la suplantación, no solo para el del fraude.

¿Cuál es el paso aislado más efectivo?
#

Deja de permitir que tu voz o tu rostro actúen como factor de autenticación: desactiva la banca por huella de voz y los accesos biométricos de «algo que eres» allí donde exista un segundo factor no biométrico. Es la única jugada que retira de inmediato una credencial funcional del alcance del atacante, mientras la reducción de muestras y el protocolo de verificación hacen el trabajo estructural, más lento.

Auditoría de seguridad del router doméstico: guía OPSEC de 2026

Fri, 28 Aug 2026 00:00:00 +0000

Una nota sobre la financiación: CypherpunkGuide no lleva publicidad de vigilancia. Nada de redes publicitarias, píxeles de rastreo ni contenido patrocinado. Nos sostienen fuentes transparentes: hoy, las donaciones de los lectores; más adelante, una suscripción y afiliados alineados con nuestra línea editorial. Esta guía no recomienda ningún proveedor ni contiene enlaces de afiliado de routers o VPN.

Tu conexión doméstica puede seguir funcionando mientras el router trabaja para otra persona. En marzo de 2026, una alerta técnica FLASH del FBI sobre AVrecon indicó que AVrecon se había observado en dispositivos de aproximadamente 163 países. En una estimación distinta, el FBI consideró que SocksEscort había comprometido y vendido acceso a unos 369.000 dispositivos desde 2020. El organismo señaló que AVrecon tenía como objetivo cerca de 1.200 modelos de routers y dispositivos del internet de las cosas (IoT), y que la gran mayoría de las infecciones observadas afectaba a routers de pequeñas oficinas y hogares (SOHO). El propósito no siempre era interrumpir la conexión del propietario. Podía consistir en convertir el equipo en un proxy residencial, es decir, en un servicio que hace pasar tráfico ajeno por una dirección IP doméstica corriente.

Por eso no basta con el consejo habitual de cambiar la contraseña, activar WPA3 y contratar una VPN. La seguridad operacional (OPSEC) protege información y sistemas al examinar qué puede observar y aprovechar un adversario. Esas medidas no contestan las preguntas decisivas: ¿sigue teniendo soporte esta revisión exacta del router? ¿Se puede abrir su panel de administración desde internet? ¿Alguien cambió sin autorización el DNS, las cuentas o los reenvíos de puertos? Si algo no encaja, ¿conviene reforzar la configuración, reconstruirla a partir de valores verificados o sustituir el equipo?

Revisé la documentación vigente del FBI, el Departamento de Justicia de Estados Unidos (DOJ), la Comisión Federal de Comercio estadounidense (FTC) y el Instituto Nacional de Estándares y Tecnología (NIST). A partir de esas fuentes preparé la Auditoría de evidencias del router doméstico, con 18 filas. También planteé la misma pregunta a cuatro sistemas de IA actuales. Los cuatro devolvieron una lista conocida; varios confundieron el reinicio eléctrico, el restablecimiento de fábrica y la eliminación de malware. Esta guía separa esas acciones y conserva como desconocida toda evidencia que no pueda comprobarse.

Descarga la Auditoría de evidencias del router doméstico antes de empezar. Es una hoja de trabajo, no un escáner: no necesita tu archivo de configuración, dirección IP pública, contraseña de Wi-Fi ni número de serie del router.

Qué significa que un router doméstico esté comprometido en 2026
#

Un router doméstico está comprometido cuando alguien obtiene control no autorizado sobre el dispositivo que comunica tu red con internet. Puede cambiar ajustes, retransmitir tráfico mediante tu IP, atacar otros equipos locales o incorporar el router a una campaña más amplia.

El compromiso no demuestra que el atacante pueda leer todas las contraseñas o páginas cifradas. HTTPS —el cifrado que utiliza la mayoría de los sitios modernos— y una VPN de cliente bien configurada aún pueden proteger el contenido en tránsito. Tampoco una conexión lenta demuestra una intrusión. Lo útil es verificar que el router conserva soporte, está actualizado y tiene la configuración prevista; si falta una prueba, el resultado sigue siendo desconocido.

Las fuentes primarias recientes muestran vías diferentes:

Conjunto de evidencias	Escala comunicada	Función del router	Lo que la evidencia no demuestra
FLASH del FBI sobre AVrecon, marzo de 2026	El FBI consideró que SocksEscort había comprometido y vendido acceso a unos 369.000 dispositivos desde 2020; AVrecon se observó en unos 163 países y tenía como objetivo cerca de 1.200 modelos	Proxy residencial, consola de comandos remota, cargador de otros programas y nodo de botnet —una red de dispositivos controlados por un atacante—	Que todos los modelos de la lista o todas las unidades domésticas estuvieran infectados
Operación del DOJ contra botnets de IoT, marzo de 2026	Según documentos judiciales, las cuatro botnets habrían secuestrado más de tres millones de dispositivos en todo el mundo	Los routers Wi-Fi eran uno de los tipos de IoT empleados en ataques distribuidos de denegación de servicio (DDoS), que saturan un objetivo con tráfico	Que los tres millones fueran routers, que cada dispositivo fuera un router o que todas las órdenes de ataque tuvieran éxito
Alerta del FBI sobre routers en fin de vida, mayo de 2025	Sin cifra universal de dispositivos	Algunos routers al final de su vida útil (EOL), con administración remota activada, se utilizaron como proxies de TheMoon	Que un router antiguo concreto esté infectado solo por su edad
Operación del DOJ contra GRU, febrero de 2024	Una red de cientos de routers SOHO	El servicio de inteligencia militar ruso GRU reutilizó infecciones criminales de Moobot en routers Ubiquiti EdgeOS que seguían usando contraseñas administrativas predeterminadas conocidas públicamente	Que cada router extrajera directamente tokens de acceso a Microsoft Office

El problema no se limita a una familia de malware. En una operación de marzo de 2026, el DOJ citó documentos judiciales según los cuales cuatro botnets habrían secuestrado más de tres millones de dispositivos en todo el mundo. Los routers Wi-Fi eran solo una clase dentro de una población mixta que también incluía cámaras, grabadores y otros equipos.

La última limitación corrige una simplificación frecuente en los titulares. El comunicado del DOJ sobre la operación contra GRU dice que la red de routers ocultó y facilitó campañas de spearphishing —engaños dirigidos a personas concretas— y de obtención de credenciales. No afirma que un router doméstico sin parchear robara directamente tokens de acceso a Office. El router formaba parte de la infraestructura de una operación mayor.

Esa diferencia cambia la respuesta defensiva. Un router utilizado discretamente para retransmitir tráfico puede no mostrar las señales aparatosas que suelen asociarse a un «hackeo». Hace falta comprobar que el equipo mantiene soporte y la configuración prevista, no esperar un síntoma dramático.

Empieza por decidir si el equipo aún tiene soporte
#

El soporte es el primer criterio de decisión: ningún ajuste puede corregir las vulnerabilidades de un producto cuyo fabricante o proveedor de servicios de internet (ISP) ya no distribuye actualizaciones de seguridad. Comprueba el modelo y la revisión de hardware exactos; la edad por sí sola no decide nada.

Hazlo desde un dispositivo bajo tu control y conectado a la red local del router. No copies la configuración completa, el número de serie, la IP pública ni las credenciales en un formulario web o chatbot para buscar información.

Anota quién es responsable del router. Si lo suministró el ISP, pregunta si controla el firmware y la administración remota. No desactives un canal de gestión obligatorio ni instales firmware para equipos comprados por separado en un router administrado por el ISP.
Registra la identidad exacta. Consulta la etiqueta y la página de estado para anotar fabricante, modelo, revisión de hardware y firmware instalado. Un nombre parecido no basta para elegir una imagen de firmware.
Busca la página oficial del ciclo de vida. Localiza esa revisión exacta en el sitio de soporte del fabricante o ISP. Guarda la URL y la fecha de consulta.
Busca el registro oficial del firmware. Compara la versión y fecha instaladas con la versión oficial vigente. Confirma si las actualizaciones son automáticas, manuales o dependen del ISP.

La alerta del FBI de 2025 dice que los routers de 2010 o anteriores probablemente ya no reciben actualizaciones. Es un indicador orientativo, no una caducidad universal. Un producto más reciente también puede haber perdido el soporte, y un equipo antiguo administrado por un ISP podría seguir recibiendo correcciones. A fecha del 28 de agosto de 2026, manda el registro oficial del modelo y la revisión exactos.

No encontré ninguna fuente primaria que sustituya esta comprobación específica por un límite universal de antigüedad.

Sigue estas rutas:

Hallazgo	Ruta	Motivo
El modelo exacto está en fin de vida o no existe una vía fiable de actualización	Sustituir	Las vulnerabilidades conocidas pueden quedar sin corregir de forma permanente
No se puede confirmar el estado de soporte	Desconocido / consultar a soporte	Suponer que «aún es seguro» convierte silenciosamente una falta de pruebas en un aprobado
Mantiene soporte, pero el firmware oficial está atrasado	Reforzar	Aplica el proceso del fabricante o ISP y verifica después la versión instalada
Está actualizado, mantiene soporte y lo administra el ISP	Continuar la auditoría	El soporte no demuestra que la configuración sea correcta ni que el equipo esté libre de compromiso

Sustituir no significa comprar el router para videojuegos más caro. Antes de elegir, debes poder confirmar el periodo de soporte, el mecanismo de actualización, los valores predeterminados seguros y el procedimiento de recuperación. NIST IR 8425A es un perfil dirigido a fabricantes y productos, no un sello para consumidores. Aun así, sus resultados sirven como lista de compra: configuración autenticada, actualizaciones verificadas, interfaces limitadas, restablecimiento seguro e información verificable sobre el estado de seguridad.

Ejecuta la auditoría de 18 comprobaciones
#

La auditoría clasifica cada resultado como aprobado, fallido o desconocido en las áreas de propiedad, soporte, exposición, configuración, clientes y recuperación. El hallazgo de mayor gravedad determina la respuesta; no inventa una puntuación de seguridad de 87 sobre 100.

Antes de cambiar nada, abre el CSV descargado en una hoja de cálculo o editor de texto local y añade una columna para tu resultado. No incluyas secretos. Escribe «administración remota desactivada», no la contraseña administrativa; anota «coincide con el servidor DNS previsto», no exportes toda la configuración sensible.

1. Verifica el firmware y el control administrativo
#

Comprueba la versión instalada después de actualizar; pulsar el botón no demuestra que la actualización haya terminado. Revisa todas las cuentas administrativas. Sustituye cualquier contraseña administrativa predeterminada o reutilizada por una exclusiva que tu gestor de contraseñas pueda generar y guardar. La contraseña del panel del router y la clave de Wi-Fi son controles distintos: cambiar una no modifica la otra.

Si encuentras una cuenta administrativa que no creaste, deja de tratar la tarea como un simple refuerzo. Fotografía o guarda localmente el nombre de la cuenta, la hora, la versión del firmware y la entrada de registro relacionada antes de borrar o restablecer nada. Conserva esa evidencia: una cuenta desconocida exige investigar, pero no demuestra por sí sola un ataque estatal.

Si estás reorganizando credenciales, aplica el mismo método acotado y verificable que en una migración de gestor de contraseñas: cambia los secretos de mayor impacto desde un dispositivo limpio, no los pegues en servicios de diagnóstico al azar y conserva una vía de recuperación.

2. Cierra las rutas de administración innecesarias
#

Busca ajustes como Remote Management, Remote Administration, Web Access from WAN —WAN significa red de área amplia, el lado expuesto a internet—, Cloud Management, Telnet o el acceso por línea de comandos SSH. El perfil del NIST recomienda desactivar por defecto el acceso remoto desde la WAN y limitar la administración a la red de área local (LAN). Desactiva el panel accesible desde internet salvo que exista una necesidad documentada y un método para restringir quién puede conectarse.

Comprueba también:

WPS (configuración protegida de Wi-Fi): desactívalo, como recomienda la guía básica de la FTC.
UPnP (Universal Plug and Play): desactívalo si ningún equipo necesita crear reenvíos de puertos automáticamente. Anota primero los mapeos actuales; algunas consolas, aplicaciones de llamadas o equipos multimedia pueden necesitar ajustes.
Host DMZ y reenvíos de puertos: una zona desmilitarizada (DMZ) o un reenvío expone un dispositivo o servicio local al tráfico entrante de internet. Cada entrada debe tener un responsable y un propósito vigentes. Un reenvío obsoleto hacia una dirección interna reutilizada no es un mero descuido administrativo.
DNS dinámico (DDNS): asigna un nombre estable a una IP pública cambiante. Verifica tanto el servicio como la cuenta configurada.
VPN y otros perfiles de túnel: verifica cada servicio. Un perfil desconocido justifica conservar la evidencia y consultar al fabricante o ISP antes de actuar.

La guía de la FTC para proteger el Wi-Fi doméstico recomienda desactivar la administración remota, WPS y UPnP. Es un buen punto de partida para una red doméstica, pero las prestaciones disponibles y las necesidades operativas varían. Documenta la excepción en vez de fingir que la función está apagada.

3. Comprueba el cifrado inalámbrico y la segmentación
#

Utiliza WPA3-Personal si todos los equipos necesarios son compatibles, o WPA2-Personal con AES cuando WPA3 no esté disponible. WEP, el WPA original y una red principal abierta exigen cambiar la configuración o el equipo; no son modos de «compatibilidad» aceptables.

Anota todos los SSID —los nombres de red—, incluidas las redes de invitados, IoT y ocultas. Después prueba el aislamiento; no confíes en la etiqueta. Si una red de invitados todavía puede acceder al portátil, al almacenamiento de red, al panel de la impresora o a la consola del router, no está aislada de forma efectiva.

Coloca los dispositivos inteligentes menos fiables en un segmento donde el router aplique una separación real. Esto no vuelve segura una cámara obsoleta; limita los equipos a los que puede llegar. Es el mismo principio de un modelo de amenazas para la era de la IA: reducir el alcance de un incidente cuando la prevención falla.

4. Haz inventario de clientes y del estado de configuración
#

Revisa la lista de clientes conectados, las concesiones del protocolo de configuración dinámica de host (DHCP) —las direcciones que asignó el router— y las direcciones reservadas. Clasifica cada dispositivo actual por propietario y tipo. No trates automáticamente cada identificador desconocido como un intruso: los teléfonos modernos pueden usar una dirección privada o aleatoria de control de acceso al medio (MAC), y un equipo conocido puede aparecer bajo el nombre del fabricante de uno de sus chips.

Compara después estos ajustes con los que esperabas:

servidores DNS de la WAN y la LAN;
estado del cortafuegos para IPv4 e IPv6;
reenvíos de puertos, host DMZ y servicios expuestos;
cuentas administrativas e intentos recientes de inicio de sesión;
zona horaria y sincronización del reloj;
versión del firmware e historial de actualizaciones;
estado de la administración remota y en la nube.

Un servidor DNS inesperado, una cuenta administrativa desconocida o un reenvío de puertos sin explicación permiten actuar con más precisión que una sospecha vaga basada en que el router se calienta. Conserva la evidencia exacta. Luego utiliza un dispositivo limpio y el soporte oficial del fabricante o ISP para averiguar si el cambio era legítimo.

5. Examina las evidencias que ofrece el producto
#

El perfil del NIST indica que un router debería permitir conocer su estado de seguridad, incluidos los intentos de inicio de sesión, los eventos administrativos, el estado del sistema y del cortafuegos, el estado de los componentes y la sincronización horaria. Muchas interfaces de consumo solo muestran una parte.

Si no hay registro, escribe desconocido. No lo marques como aprobado. Cuando sí exista, busca accesos administrativos desde orígenes inesperados, cambios que no realizaste, fallos repetidos de actualización, reinicios sin explicación o un reloj tan incorrecto que las marcas de tiempo no sirvan. No subas los registros a un sitio público: pueden revelar direcciones internas, nombres de equipos, dominios y cuentas.

Por eso diseñé la hoja a partir de evidencias observables. No afirma detectar malware. Permite ver qué conclusiones sobre el soporte y la configuración están respaldadas y cuáles siguen siendo desconocidas.

Elige entre observar, reforzar, reinicializar o sustituir
#

Elige la ruta según el hallazgo más grave, no por el número de resultados aprobados. Un firmware sin soporte pesa más que diez ajustes Wi-Fi impecables. Una sola cuenta administrativa no autorizada pesa más que una contraseña robusta.

En esta guía, reinicializar significa conservar primero la evidencia, seguir el procedimiento oficial de restablecimiento o recuperación específico del modelo y reconstruir la configuración a partir de valores verificados. No significa pulsar Reset por reflejo.

Ruta	Ejemplos que la activan	Acción siguiente
Observar	Mantiene soporte, está actualizado, no hay exposición ni cambio de estado sin explicar y se conoce la recuperación	Guarda la fecha de la comprobación; repite la revisión tras avisos de seguridad y con una periodicidad sostenible
Reforzar	Mantiene soporte, pero el firmware está atrasado; quedan valores predeterminados; WPS, UPnP innecesario o administración WAN están activos	Registra el estado anterior, aplica cambios oficiales de uno en uno y comprueba la conexión y el estado posterior
Reinicializar	Aviso de compromiso creíble; cambio confirmado como no autorizado en cuentas, DNS, túneles o puertos; los ajustes reaparecen; las actualizaciones fallan repetidamente	Conserva primero la evidencia, contacta con el ISP o fabricante y sigue el procedimiento oficial exacto de restablecimiento o reinstalación; reconstruye desde ajustes verificados
Sustituir	Fin de vida o falta de soporte; no existe una vía fiable de firmware; no admite el cifrado seguro necesario; no puede recuperarse un estado fiable	Retira el equipo, configura otro con soporte y credenciales administrativas nuevas, y no importes una copia completa de configuración que no sea de confianza

«Observar» no es un certificado de limpieza. Los registros de un producto de consumo no demuestran que no exista software malicioso persistente y oculto. Solo indica que la auditoría no encontró un fallo conocido y que el router aún puede recibir soporte.

«Reinicializar» es una ruta deliberadamente condicional. Si el router puede contener evidencia relevante para un caso de acoso, intrusión dirigida, pérdida financiera o investigación laboral, el restablecimiento destruye configuración y registros que podrían importar. Desconecta o aísla únicamente en la medida necesaria para la seguridad, fotografía el estado y consulta a profesionales de respuesta a incidentes o a las autoridades antes de borrar. Para anomalías domésticas de menor impacto, el soporte del fabricante o ISP puede indicar la secuencia de recuperación específica.

El reinicio eléctrico, el restablecimiento de fábrica, la reinstalación del firmware y la sustitución no son sinónimos
#

Ningún botón restablece la confianza de forma universal. Un reinicio eléctrico vuelve a arrancar el equipo; un restablecimiento de fábrica recupera ajustes documentados; una reinstalación oficial sustituye el firmware; y un router nuevo inicia otro ciclo de soporte.

Acción	Qué puede hacer	Qué no permite afirmar
Reinicio eléctrico	Reiniciar el estado operativo; completar el arranque que exija un procedimiento oficial de actualización o recuperación	Que las vulnerabilidades estén corregidas, que hayan desaparecido los ajustes no autorizados o que el malware no pueda volver
Restablecimiento de fábrica	Recuperar los ajustes predeterminados documentados y borrar los datos del cliente almacenados, según lo previsto para el producto; retirar muchos cambios de configuración no autorizados	Que el firmware o los componentes de nivel inferior sean auténticos, que las credenciales predeterminadas sean seguras o que corrija las vulnerabilidades de un equipo EOL
Reinstalación o recuperación oficial del firmware	Sustituir el firmware mediante una vía verificada y respaldada por el fabricante en algunos modelos	Una solución universal para compromisos del cargador de arranque, hardware, cadena de suministro o equipos sin soporte
Sustitución	Retirar el dispositivo antiguo y comenzar un nuevo ciclo de soporte y actualizaciones	Que ahora sean seguros los ajustes importados, los secretos reutilizados, los servicios expuestos o los dispositivos locales comprometidos

La alerta del FBI sobre routers EOL de 2025 recomienda una secuencia: sustituir el equipo al final de su vida útil si es posible, instalar las correcciones, desactivar la administración remota, utilizar una contraseña exclusiva y reiniciar después de esos cambios. Citar solo «reinicia el router» elimina los controles que impiden que la exposición siga presente.

Si reinicializas un router con soporte, utiliza las instrucciones exactas del fabricante o ISP. Obtén el firmware oficial y la documentación de recuperación antes de empezar. Anota los ajustes de conexión que exija el ISP sin copiar secretos en la hoja pública. Después del restablecimiento o reinstalación, configura credenciales administrativas nuevas y una administración segura antes de volver a conectar los dispositivos locales que no sean necesarios. Verifica al final la versión del firmware instalada.

No restaures automáticamente una copia completa creada después de los cambios sospechosos. Hazlo solo si el fabricante o un especialista en respuesta a incidentes ha confirmado que es segura. Una copia puede reproducir fielmente el problema que intentabas eliminar.

Qué puede y qué no puede solucionar una VPN
#

Una VPN crea un túnel cifrado entre un cliente y un servidor VPN. Puede reducir lo que el router o el ISP ven del tráfico dentro de ese túnel, pero no repara el router que lo transporta.

NIST SP 800-77 Rev. 1 delimita la protección: una VPN protege el tráfico entre los extremos del túnel. No actualiza el firmware del router que reenvía los paquetes ni autentica su configuración.

Pregunta	VPN de cliente en un portátil o teléfono	VPN ejecutada en el router
¿Puede actualizar el firmware del router?	No	No
¿Puede cerrar la administración remota expuesta?	No	No
¿Puede eliminar malware o cuentas desconocidas del router?	No	No
¿Puede cifrar el tráfico compatible del cliente hasta el servidor VPN?	Sí, si está bien configurada	Sí, pero el propio router es un extremo del túnel
¿Puede impedir que un router comprometido actúe como proxy o ataque la LAN?	No	No
¿Oculta todos los metadatos?	No; el router aún ve el servidor VPN, el horario y el volumen	No; el extremo comprometido procesa el tráfico antes o después del túnel

HTTPS ya cifra gran parte del contenido web entre el navegador y el sitio. Una VPN de cliente añade otro túnel y puede ser útil para la privacidad, pero ninguna de las dos capas cambia el estado de soporte del router. Si el router aloja el cliente VPN, el compromiso del router también compromete el dispositivo que crea y encamina el túnel.

Por eso esta guía no clasifica proveedores de VPN ni recomienda mantenerla siempre activa como defensa del router. Elige herramientas de privacidad de red dentro de una pila de privacidad más amplia, después de comprobar que las actualizaciones y la administración del propio router siguen siendo fiables.

Si encuentras un cambio no autorizado
#

Conserva la evidencia necesaria para explicar el cambio. Después, recupera la confianza desde un dispositivo limpio y actualizado mediante una vía oficial. No cambies todas tus cuentas desde un equipo que también podría estar comprometido.

Anota modelo, revisión de hardware, firmware, hora actual y quién posee o administra el router.
Captura la cuenta, entrada DNS, reenvío, túnel, evento de registro o aviso concretos. Guarda la evidencia localmente y oculta los secretos antes de compartirla con un servicio de soporte legítimo.
Si el ISP administra el router, contacta con su canal de seguridad o soporte. Si lo compraste por tu cuenta, utiliza la vía oficial del fabricante.
Sustituye un dispositivo EOL. No inviertas horas en perfeccionar ajustes de un equipo que ya no puede recibir actualizaciones de seguridad.
En un dispositivo con soporte, sigue la secuencia oficial de restablecimiento, recuperación o reinstalación. Reconstruye los ajustes en vez de importar automáticamente una copia que no sea fiable.
Desde un dispositivo limpio y actualizado, cambia la contraseña administrativa del router y toda credencial que la evidencia indique que pudo quedar expuesta. Activa la autenticación multifactor en las cuentas sensibles cuando esté disponible.
Tras la recuperación, vuelve a comprobar firmware, administración WAN, cuentas, DNS, reenvíos, cortafuegos, clientes y registros.

Si la evidencia apunta a credenciales expuestas fuera del router, aplica un plan de defensa tras una filtración de datos gubernamentales específico para cuentas e identidad. Un solo ajuste incorrecto del router no demuestra que todas tus cuentas estén comprometidas.

En conclusión: recupera una confianza que puedas verificar
#

Una auditoría útil deja constancia del soporte, la configuración y la acción justificada. No produce una puntuación mágica ni promete descartar un compromiso sofisticado.

Empieza por el modelo exacto y su ciclo oficial de soporte. Comprueba después firmware, control administrativo, administración WAN, cifrado inalámbrico, exposición de puertos, DNS, clientes, segmentación y registros disponibles. Marca como desconocida la evidencia que falte. Sustituye el equipo sin soporte, conserva los cambios no autorizados antes de borrarlos y sigue la recuperación oficial específica del modelo.

El riesgo silencioso de 2026 no consiste solo en que alguien lea el tráfico. Un dispositivo doméstico puede convertirse en infraestructura ajena sin dejar de parecer normal a su propietario. La defensa también es discreta: menos interfaces expuestas, software vigente y verificado, una configuración conocida, evidencias que puedas consultar y una vía de recuperación fiable.

Preguntas frecuentes
#

Estas respuestas separan el refuerzo habitual de la respuesta a incidentes, mantienen visibles los datos que siguen sin comprobarse y no prometen detectar malware con un equipo de consumo.

¿Cada cuánto conviene auditar el router doméstico?
#

Comprueba ahora el soporte y toda la configuración; repite la revisión tras un aviso de seguridad específico para el modelo o un cambio inexplicable, y además con una periodicidad que puedas mantener. En equipos que se actualizan manualmente, es razonable confirmar la versión cada mes. Los routers administrados por el ISP o con actualización automática también necesitan una comprobación periódica de que las actualizaciones llegan. Importa más anotar la versión y la fecha que elegir un intervalo perfecto.

¿Reiniciar el router elimina el malware?
#

Un reinicio cambia el estado en ejecución, pero las fuentes gubernamentales citadas no demuestran que elimine AVrecon, TheMoon, Moobot ni ningún otro software malicioso del router. No corrige una vulnerabilidad, no confirma la autenticidad del firmware, no borra todos los cambios persistentes ni evita una nueva infección. Úsalo como paso operativo cuando lo exija el procedimiento oficial de actualización o recuperación, no como prueba de limpieza.

¿Basta un restablecimiento de fábrica después de un compromiso?
#

No en todos los casos. Puede recuperar los ajustes predeterminados documentados y eliminar muchos cambios de configuración, pero también restablece credenciales predeterminadas y borra evidencias útiles. No garantiza la eliminación de firmware modificado ni de mecanismos persistentes en capas inferiores, como el cargador de arranque. Sigue el procedimiento exacto del fabricante o ISP, instala el firmware oficial vigente, reconstruye la configuración con cuidado y sustituye el equipo sin soporte.

¿Debo desactivar UPnP y WPS?
#

La FTC recomienda desactivar ambos. Desactiva WPS. Algunas consolas, aplicaciones de llamadas o equipos multimedia pueden necesitar UPnP, así que anota primero los mapeos y prueba las aplicaciones afectadas después de apagarlo. Si mantienes una excepción, documenta qué dispositivo y aplicación la necesitan; no dejes una exposición automática sin explicar.

¿Puedo comprobar si mi modelo estuvo en la botnet AVrecon?
#

El FLASH del FBI enumera fabricantes y modelos observados y dice que cerca de 1.200 modelos fueron objetivo, pero una coincidencia no demuestra que tu unidad estuviera infectada. Utiliza el modelo para buscar firmware oficial, ciclo de vida, avisos de vulnerabilidad aplicables e indicadores del FBI. No aparecer en la lista tampoco certifica la seguridad. Contacta con el fabricante o ISP si el modelo o el indicador exactos no están claros.

Fuentes
#

Las fuentes activas son documentos gubernamentales y técnicos primarios. Cada enlace archivado reproduce exactamente la página correspondiente y respondió con HTTP 200 durante la verificación independiente del 28 de agosto de 2026.

#	Fuente	URL activa	Copia archivada
1	FBI FLASH 20260312-001 — routers infectados por AVrecon utilizados como proxies residenciales por SocksEscort	https://www.fbi.gov/file-repository/cyber-alerts/avrecon-malware-infected-routers-exploited-as-residential-proxies-by-socksescort.pdf	https://web.archive.org/web/20260402044918/https://www.fbi.gov/file-repository/cyber-alerts/avrecon-malware-infected-routers-exploited-as-residential-proxies-by-socksescort.pdf
2	FBI — cómo impedir que las redes de proxies residenciales conviertan tu dispositivo en una herramienta criminal	https://www.fbi.gov/investigate/cyber/alerts/2026/evading-residential-proxy-networks-protecting-your-devices-from-becoming-a-tool-for-criminals	https://web.archive.org/web/20260808054457/https://www.fbi.gov/investigate/cyber/alerts/2026/evading-residential-proxy-networks-protecting-your-devices-from-becoming-a-tool-for-criminals
3	FBI — servicios de proxy criminales que aprovechan routers al final de su vida útil	https://www.fbi.gov/investigate/cyber/alerts/2025/cybercriminal-proxy-services-exploiting-end-of-life-routers	https://web.archive.org/web/20260822065226/https://www.fbi.gov/investigate/cyber/alerts/2025/cybercriminal-proxy-services-exploiting-end-of-life-routers
4	DOJ — operación contra botnets de IoT responsables de ataques DDoS sin precedentes	https://www.justice.gov/usao-ak/pr/authorities-disrupt-worlds-largest-iot-ddos-botnets-responsible-record-breaking-attacks	https://web.archive.org/web/20260825205257/https://www.justice.gov/usao-ak/pr/authorities-disrupt-worlds-largest-iot-ddos-botnets-responsible-record-breaking-attacks
5	DOJ — operación autorizada por un tribunal contra una botnet controlada por el GRU ruso	https://www.justice.gov/archives/opa/pr/justice-department-conducts-court-authorized-disruption-botnet-controlled-russian	https://web.archive.org/web/20260808070920/https://www.justice.gov/archives/opa/pr/justice-department-conducts-court-authorized-disruption-botnet-controlled-russian
6	NIST IR 8425A — requisitos de ciberseguridad recomendados para routers de consumo	https://doi.org/10.6028/NIST.IR.8425A	https://web.archive.org/web/20260506061206/https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8425A.pdf
7	FTC — cómo proteger una red Wi-Fi doméstica	https://consumer.ftc.gov/articles/how-secure-your-home-wi-fi-network	https://web.archive.org/web/20260821194423/https://consumer.ftc.gov/articles/how-secure-your-home-wi-fi-network
8	NIST — siete consejos para un hogar inteligente más seguro y privado	https://www.nist.gov/blogs/taking-measure/7-tips-keep-your-smart-home-safer-and-more-private-nist-cybersecurity	https://web.archive.org/web/20260816082442/https://www.nist.gov/blogs/taking-measure/7-tips-keep-your-smart-home-safer-and-more-private-nist-cybersecurity
9	NIST SP 800-77 Rev. 1 — guía sobre VPN IPsec	https://doi.org/10.6028/NIST.SP.800-77r1	https://web.archive.org/web/20260816065058/https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-77r1.pdf

Cora Aegis

Cora Aegis escribe en CypherpunkGuide guías de OPSEC con la privacidad como eje. Para este artículo comparó cuatro casos recientes sobre routers publicados por organismos estadounidenses con el perfil del NIST para routers de consumo, probó la consulta en Google AI Mode y otros cuatro sistemas de IA, y convirtió los límites de la evidencia en una auditoría de 18 comprobaciones que no escanea ni modifica la red del lector.

Más sobre Cora Aegis →

Copias cifradas: ¿puedes restaurar tus archivos? (2026)

Thu, 03 Sep 2026 00:00:00 +0000

Una nota sobre la financiación: CypherpunkGuide no incluye publicidad de vigilancia, redes publicitarias, píxeles de rastreo ni contenido patrocinado. Se financia mediante vías transparentes: hoy, donaciones de lectores; más adelante, suscripciones y enlaces de afiliación acordes con la línea editorial. Este artículo no contiene enlaces de afiliación ni recomienda un proveedor de almacenamiento.

Las fotos, la correspondencia y los documentos pueden seguir siendo importantes mucho después de retirar el equipo que los creó. Cifrar su copia ayuda a mantenerlos privados. Para recuperarlos también hacen falta acceso al almacenamiento, un método de desbloqueo válido, la versión adecuada y programas capaces de leerla.

Diseñé un experimento de restauración con 12 archivos artificiales y seis casos de prueba, utilizando restic, un programa de copias cifradas de código abierto. En un caso, la comprobación del repositorio, la lectura completa de los datos y la restauración terminaron sin errores. Sin embargo, solo regresaron 11 de los 12 archivos previstos. En otro, se recuperaron los 12 y todos superaron las pruebas de formato, pero uno contenía una revisión anterior.

La pregunta práctica es si puedes recuperar los documentos que querías conservar, en la versión que necesitas, y utilizarlos. Esta guía une la planificación de las copias con un experimento reproducible y un ensayo seguro. Solo usamos archivos generados para la prueba. No medimos la vida de los discos, la resistencia de copias situadas en otros lugares ni la recuperación de un equipo completo.

Distingue sincronización, copia y conservación a largo plazo
#

La sincronización mantiene alineados los archivos de trabajo; una copia de seguridad permite recuperarlos; la conservación a largo plazo también mantiene su significado y legibilidad cuando cambian los equipos y programas. Un servicio puede ofrecer varias funciones, pero hay que comprobar cada una.

Que un borrado se propague puede ser el comportamiento correcto de un servicio de sincronización. La posibilidad de deshacerlo depende de sus versiones retenidas, sus reglas de eliminación y el acceso a la cuenta. Un disco desconectado, por su parte, puede contener una copia valiosa sin incluir nada de lo escrito desde que se desconectó. Primero define la función que necesitas.

Función	Para qué sirve	Qué falta comprobar
Sincronización	Disponer de los archivos activos en varios dispositivos	Si se conservan versiones borradas o sobrescritas y durante cuánto tiempo
Copia de seguridad	Recuperarse de pérdidas o cambios no deseados	Qué archivos y versiones incluye, qué fallos puede resistir y si se restaura correctamente
Conservación a largo plazo	Mantener utilizables los documentos elegidos durante años	Descripciones, formatos, programas de lectura, renovación de soportes y continuidad del acceso

La Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos, CISA, define el criterio 3-2-1 como tres copias en total, en dos tipos de soporte, con una copia en otro lugar. Su guía contra el ransomware también recomienda copias cifradas y desconectadas, junto con pruebas periódicas de integridad y restauración. Estar en otro lugar describe la ubicación; estar desconectado describe la conectividad. Una cuenta comprometida que pueda borrar una copia remota sigue siendo una dependencia de esa copia. Véanse la guía de copias de CISA y su guía contra el ransomware.

Enumera fallos concretos: robo del portátil, borrado accidental, incendio, bloqueo de la cuenta o pérdida del método de desbloqueo. Después identifica qué copia seguiría disponible en cada caso. Es la misma pregunta que guía un conjunto personal de herramientas de privacidad: ¿qué problema resuelve cada medida?

Conserva una vía de recuperación independiente del sistema averiado
#

El cifrado protege el contenido frente a quien no tiene un método válido para desbloquearlo. No conserva ese método, no mantiene accesible una cuenta ni asegura la disponibilidad de todas las copias. La recuperación debe resolver cada dependencia.

Anota dónde está la copia, qué programa y formato utiliza, cómo se recupera la cuenta si la necesita y cómo obtendrá una persona autorizada la información de desbloqueo. Protege las credenciales. No las publiques en una hoja de control ni las envíes a un chatbot. Indicar dónde están las instrucciones protegidas no exige escribir el secreto en el registro de comprobaciones.

Restic cifra los datos del repositorio, el almacén donde guarda las copias, y permite acceder mediante claves protegidas por contraseña. Un repositorio puede tener varias de esas claves. Olvidar una contraseña no implica perderlo todo si queda otra combinación válida de clave y contraseña. Perder todas las vías utilizables es una situación distinta. La documentación de creación del repositorio explica este diseño.

Evita una dependencia circular: la única copia de la contraseña está dentro de la propia copia cifrada, o las instrucciones para recuperar tu gestor de contraseñas solo existen en el portátil perdido. Las guías de recuperación de passkeys y migración de gestores de contraseñas abordan el mismo problema desde el acceso a las cuentas.

El autoalojamiento cambia quién opera el sistema y te hace responsable de recuperarlo. Si un servicio autoalojado y su única copia están en el mismo equipo, perder ese equipo sigue bastando para perder ambos.

Qué demuestra cada comprobación
#

Cada comprobación responde a una pregunta limitada. La coherencia del repositorio, la lectura de los datos almacenados, la presencia de los archivos previstos, la igualdad de sus bytes y la posibilidad de abrirlos requieren pruebas distintas. Un resultado correcto no sustituye a los demás.

La documentación de restic, consultada el 3 de septiembre de 2026, distingue check de check --read-data. El primero examina la estructura y coherencia del repositorio, pero no lee y verifica todo el contenido de los archivos que agrupan los datos almacenados, llamados packs. La opción --read-data los lee todos, lo que puede consumir tiempo y tráfico de red considerables. Véase Working with repositories.

Comprobación	Qué permite confirmar	Qué no demuestra por sí sola
Comprobación ordinaria del repositorio	Coherencia de las estructuras examinadas	Que se hayan leído y verificado todos los bytes almacenados
Lectura completa de los datos	Que los packs superan las verificaciones de datos del programa	Que se hayan incluido todos los archivos necesarios o elegido la versión adecuada
Comparación con la lista prevista	Que las rutas recuperadas coinciden con una lista independiente	Que coincidan los bytes o que una aplicación pueda utilizarlos
Comparación de hashes	Que los bytes coinciden con los valores de referencia	Que la referencia era correcta, actual o legible
Prueba de formato o aplicación	Que el lector probado interpreta el contenido probado	Que funcionen todas las funciones, los demás archivos o programas futuros

Un manifiesto es una lista de archivos previstos que puede incluir sus tamaños y hashes. Un hash criptográfico, como SHA-256, se calcula a partir de los bytes de un archivo y ayuda a detectar cambios. Conserva una referencia protegida de lo que realmente quieres guardar. Una lista obtenida únicamente de la copia no puede revelar un archivo que nunca entró en ella. Los nombres también pueden divulgar información privada: protege el manifiesto.

La Biblioteca del Congreso de Estados Unidos distingue la conservación de los bits del mantenimiento del acceso futuro en su glosario de colecciones digitales. Consulté la versión archivada de septiembre de 2025 porque la página activa bloqueó el acceso durante esta revisión. Esa distinción orientó el experimento: copiar exactamente los bytes también puede conservar un archivo que ya era ilegible.

Seis casos de restauración con archivos artificiales
#

El experimento separa el éxito de un comando del resultado que necesita la persona. Con restic 0.19.1 en Windows, las tres operaciones —comprobar el repositorio, leer todos sus datos y restaurarlo— terminaron correctamente aunque faltara un archivo previsto o se eligiera una revisión antigua. La referencia independiente permitió detectar ambos problemas.

Preparé el conjunto antes de aplicar exclusiones: 12 archivos de siete grupos de formatos, texto UTF-8, JSON, CSV, XML, ZIP, WAV y TOML. Contiene notas y registros artificiales, un archivo ZIP y un tono generado. Los lectores de la biblioteca estándar de Python comprueban su lectura a nivel de formato. No probamos interfaces de programas de fotos, ofimática o reproducción de audio.

Cada caso utiliza el identificador de una instantánea concreta —una versión guardada de la copia— y una carpeta de destino nueva y vacía. Se registran por separado las tres operaciones de restic, las rutas previstas, los hashes y las pruebas de formato. El código de salida 0 indica que el comando terminó correctamente. Un valor distinto señala un error de esa operación. Estos códigos no puntúan la calidad del conjunto de documentos personales.

Resultados
#

Caso	Comprobación / lectura completa / restauración	Rutas previstas recuperadas	Hashes que coinciden con la versión requerida	Lecturas correctas / archivos probados
S1: archivos válidos sin modificar	0 / 0 / 0	12/12	12/12	12/12
S2: contraseña pública de prueba incorrecta	12 / 12 / 12	0/12	0/12	Sin pruebas; no se recuperaron archivos
S3: un byte alterado en los datos de un repositorio desechable	0 / 1 / 1	11/12	11/12	11/11
S4: exclusión de un archivo necesario	0 / 0 / 0	11/12	11/12	11/11
S5: elección de una instantánea antigua	0 / 0 / 0	12/12	11/12	12/12
S6: JSON mal formado antes de crear la copia	0 / 0 / 0	12/12	12/12	11/12

Las rutas y los hashes se cuentan sobre los 12 archivos previstos. La última columna solo cuenta los archivos recuperados que se pudieron someter a la prueba: no se puede analizar un archivo ausente. En S5, la referencia corresponde a la revisión actual requerida, registrada independientemente, no a la lista de la instantánea antigua. En S6 se registra como referencia la entrada que ya estaba mal formada.

Cómo interpretar los fallos
#

S2 prueba una contraseña incorrecta. Confirma el rechazo de esa contraseña, no la imposibilidad de recuperar el contenido mediante otra clave válida. La contraseña publicada es un dato artificial de prueba; no la uses para proteger una copia real.

S3 modifica los datos almacenados conservando la estructura circundante. La comprobación ordinaria terminó correctamente, pero la lectura completa y la restauración detectaron errores. Esto describe el daño concreto introducido. No implica que la comprobación ordinaria ignore cualquier corrupción ni que un repositorio real dañado pierda exactamente un archivo. Conservé los resultados de cada operación para hacer visible esa diferencia.

S4 es un error al seleccionar qué guardar. El programa respaldó correctamente la selección. Nuestra lista prevista también incluía documents/contacts.csv, excluido a propósito en esta prueba. El programa no puede deducir que una exclusión válida contradice tu intención. Revisa las reglas de selección y exclusión con la documentación de copias de restic.

S5 recupera correctamente una versión que no satisface el objetivo. El antiguo documents/status.json seguía siendo JSON válido. Su hash era distinto del de la revisión actual requerida. Contar los archivos y comprobar que se leen no confirma su actualidad. Una instantánea antigua puede ser la opción correcta para recuperar algo borrado; el problema aparece cuando no es la versión que necesitas.

S6 conserva fielmente una entrada defectuosa. Antes de crear la copia se genera un documents/records.json con sintaxis inválida. Las tres operaciones de restic terminan correctamente y los hashes de los 12 archivos restaurados coinciden con sus referencias. Sin embargo, el lector de JSON rechaza ese archivo antes y después de la copia. El problema ya estaba en el origen; la restauración no lo causó. Los otros 11 archivos superan sus pruebas de formato.

Cómo reproducir el experimento
#

El script descargable solo admite el ZIP oficial de restic 0.19.1 para Windows amd64 fijado en su código. Verifica los hashes del ZIP y del ejecutable, genera los archivos artificiales y crea repositorios desechables. No acepta tus directorios de origen, repositorios existentes ni destinos de restauración. El daño intencionado se limita a una copia creada dentro del experimento.

Puedes consultar el método y sus límites, la tabla de resultados, los resultados detallados, los manifiestos artificiales y el registro de comandos con datos del entorno ocultados. El registro sustituye identificadores y rutas del equipo; no es una transcripción intacta del terminal. Los datos y el código se conservan en su formato original para facilitar la reproducción.

Lee el script y ejecútalo con Python 3.11 o posterior desde una carpeta de trabajo vacía y desechable. Descarga el ZIP correspondiente de la versión oficial 0.19.1 y contrasta su hash con las sumas publicadas. Después ejecuta:

python restore-lab.py --restic-zip restic_0.19.1_windows_amd64.zip

El script deja el directorio de prueba disponible para inspeccionarlo. La ejecución registrada utilizó Python 3.12.10. Demuestra mecanismos con un conjunto pequeño y fallos definidos; no estima tasas de fallo ni compara productos. No prueba permisos, sistemas operativos completos, interrupciones de red, ubicaciones independientes, envejecimiento del hardware ni todas las funciones de una aplicación.

Ensaya la recuperación sin sobrescribir tus originales
#

Restaura en una carpeta nueva y vacía. Antes de cambiar los originales, contrasta la versión, los archivos y el contenido con referencias independientes, y abre una selección en las aplicaciones previstas. Una muestra pequeña solo aporta evidencia sobre lo probado.

La documentación de restauración de restic advierte que, por defecto, se sobrescriben archivos existentes. Otros programas tienen sus propias reglas. Lee las instrucciones de la versión instalada y confirma el destino. No uses tu carpeta de documentos de trabajo para un ensayo.

Define qué quieres recuperar. Por ejemplo, correspondencia y fotos hasta la última copia terminada, o la versión anterior al borrado de ayer. Anota las carpetas y fechas necesarias. Si el origen sigue disponible, prepara la lista independientemente de la selección de la copia y asóciala a la versión prevista. Un archivo modificado después de la copia será distinto: esa diferencia no prueba un daño durante la restauración.
Comprueba acceso y espacio. Localiza la copia y una vía válida de desbloqueo. Usa un equipo de confianza y un destino separado, vacío y con espacio suficiente. Los archivos restaurados pueden quedar sin cifrar: protege la carpeta y evita que se sincronice o comparta por accidente.
Elige una versión guardada concreta. Registra su identificador y fecha relevante. «La más reciente» solo describe un criterio de ordenación; no confirma que incluya los cambios necesarios.
Ejecuta las comprobaciones y la restauración documentadas. Distingue el examen estructural de la lectura completa. Revisa advertencias y errores, también los del trabajo que creó la copia. Que exista una instantánea no demuestra que se hayan leído todos los archivos de origen.
Contrasta el resultado con tu objetivo. Comprueba rutas, contenidos y revisiones representativas, y hashes de confianza cuando los tengas. Abre documentos, revisa fotos, reproduce grabaciones y prueba las funciones necesarias. Anota qué examinaste y qué queda sin comprobar.
Conserva las copias utilizables hasta verificar el resultado. Un ensayo satisfactorio no justifica borrar la única otra copia que funciona. Después, protege o elimina los archivos del ensayo conforme a tus reglas de conservación. No hagas limpieza destructiva mientras investigas diferencias.

Si no tienes tiempo o espacio para restaurarlo todo, empieza con una selección y registra ese límite. Amplía la cobertura con el tiempo. Si el origen ya no existe y no hay una lista independiente, la integridad del conjunto queda sin confirmar: contar los archivos de la copia superviviente no resuelve la duda.

Mantén legibles los documentos a lo largo de los años
#

Conservar archivos a largo plazo exige revisar soportes, conexiones, lectores, formatos y vías de recuperación. La duración anunciada de un material no garantiza que el archivo completo siga siendo recuperable durante ese plazo.

La guía de documentos personales de la Biblioteca del Congreso recomienda comprobar al menos una vez al año que los archivos se leen y crear copias en soportes nuevos cada cinco años o cuando sea necesario. Su nota sobre durabilidad explica la incertidumbre de las estimaciones. Es una pauta de mantenimiento, no una garantía de supervivencia hasta la próxima fecha. Vuelve a comprobar después de migrar, cambiar el método de desbloqueo o sospechar un fallo.

Dependencia	Qué conservar o revisar	Qué registrar
Soporte y conexión	Soportes utilizables, unidades de lectura, cables e interfaces compatibles	Fecha de lectura completa, errores y resultado de la migración
Significado y formato	Originales, descripciones y copias de acceso o exportación cuando correspondan	Qué lector abrió cada archivo y qué funciones se perdieron al convertirlo
Desbloqueo y acceso a cuentas	Información protegida de recuperación y acceso para una persona autorizada	Un ensayo satisfactorio sin escribir secretos en el registro
Selección y versiones	Lista prevista y reglas adecuadas de conservación	Rutas ausentes, revisiones requeridas y alcance de la última verificación

No elijas un disco basándote en una regla universal de años para HDD o SSD. Del mismo modo, la afirmación de longevidad de M-DISC de Verbatim se refiere a un producto óptico; no garantiza que en el futuro tengas un lector compatible, la información de desbloqueo o formatos legibles. Los Archivos Nacionales de Estados Unidos explican por qué es difícil predecir la duración de los soportes de vídeo, incluidos los discos ópticos, y cómo influyen las condiciones de conservación. Esas limitaciones no demuestran que todos los discos ópticos vayan a fallar.

Si un formato o programa se vuelve difícil de usar, crea una copia de acceso documentada y conserva el original. Convertir un documento complejo puede alterar el diseño o eliminar funciones. El hash también cambiará porque la conversión modifica los bytes. Comprueba los aspectos que importan, identifica la copia convertida y establece una nueva referencia para ella. No sobrescribas el original solo para ordenar una carpeta.

Comparé los casos registrando la lista prevista, la versión requerida y las pruebas de lectura junto a cada resultado de comando. Esa separación ayuda a decidir qué corregir: un archivo ausente exige revisar la selección; una revisión antigua, elegir la versión; un origen ilegible, trabajar en su conservación. Otro disco, por sí solo, no resuelve esas preguntas.

Preguntas frecuentes
#

¿La sincronización en la nube es una copia de seguridad?
#

Puede aportar funciones de recuperación si conserva versiones y archivos borrados durante un plazo adecuado. Comprueba esas reglas y cómo recuperarías la cuenta. La sincronización por sí sola no demuestra que puedas deshacer un cambio, un borrado o la pérdida de acceso.

¿Un resultado correcto de restic check significa que todos los archivos están a salvo?
#

No. La comprobación ordinaria no lee todo el contenido de los packs. La lectura completa tampoco confirma que se incluyeran todos los archivos necesarios, que eligieras la versión adecuada o que las aplicaciones puedan leer lo restaurado.

¿Puedo recuperar una copia cifrada si olvido la contraseña?
#

Depende del programa y de las vías de desbloqueo restantes. Restic admite varias claves protegidas por contraseña: otra combinación válida puede seguir funcionando. No supongas que el proveedor puede descifrar la copia ni que un intento fallido demuestra la pérdida de todas las vías de recuperación.

¿Con qué frecuencia debo comprobar mis documentos personales?
#

La Biblioteca del Congreso aconseja comprobar la lectura al menos una vez al año. Adapta el calendario a la frecuencia de los cambios importantes y vuelve a probar tras cambios relevantes de almacenamiento, programas o acceso. Registra si examinaste una muestra o todo el conjunto. Ni una fecha ni una muestra pequeña garantizan la recuperación futura.

¿Qué soporte conserva archivos durante décadas?
#

Ninguno elimina la necesidad de copias independientes, inspecciones y migración. Considera las condiciones de almacenamiento y los lectores compatibles, además del soporte. La disponibilidad también depende de los formatos, programas e información de desbloqueo. Conserva los originales verificados al crear nuevas copias de acceso.

Fuentes y registro de reproducción
#

Las fuentes primarias se consultaron el 3 de septiembre de 2026. Los resultados corresponden al entorno y a los datos artificiales indicados. Las versiones archivadas conservan el historial de las fuentes y pueden ser anteriores a la página activa utilizada para una afirmación.

#	Fuente primaria	Original	Versión archivada
1	CISA — Data Backup Options	PDF	2026-08-05
2	CISA — StopRansomware Guide	Guía	2026-08-30
3	restic — Preparing a New Repository	Documentación	2026-08-19
4	restic — Working With Repositories	Documentación	2026-08-22
5	restic — Restoring From Backup	Documentación	2026-08-22
6	Biblioteca del Congreso — Digital Collections Management Glossary	Glosario; acceso bloqueado en la revisión	2025-09-16
7	Biblioteca del Congreso — Personal Digital Records	Guía	2026-08-28
8	Biblioteca del Congreso — How Long Will Digital Storage Media Last?	PDF	2025-11-07
9	Verbatim — M-DISC Optical Media	Afirmación del fabricante	2026-05-02
10	Archivos Nacionales de EE. UU. — Video Condition Assessment	Guía de conservación	2026-05-15
11	restic — Backing Up	Documentación	2026-08-22
12	restic 0.19.1 — Versión publicada	Publicación oficial	2026-08-18; notas, no copia del ejecutable

Cora Aegis

Cora Aegis escribe sobre privacidad y autonomía digital en CypherpunkGuide. Para esta guía diseñó y revisó un experimento de restauración de copias cifradas con datos artificiales, y contrastó los resultados con documentación oficial de restic y guías de conservación. No utilizó copias de datos personales.

Más sobre Cora Aegis ->

Autoalojamiento y soberanía en 2026: una auditoría de cinco capas

Wed, 01 Jul 2026 00:00:00 +0000

En algún momento de estos últimos años, «autoalójalo» se convirtió en la respuesta refleja a cualquier problema de privacidad. Monta tu propia nube en lugar de alquilar la de Google. Levanta tu propio nodo de Bitcoin en vez de confiar en el de una empresa. Ten tu propio servidor de correo, tu propia VPN, tu propio todo y, según la promesa, no le deberás nada a las grandes tecnológicas. La palabra que se le pega a esto es soberanía, y es una palabra hermosa. También es, casi siempre, una palabra que carga con mucho más peso del que puede sostener el montaje que hay debajo.

Lo incómodo no es que el autoalojamiento sea inútil. Es que resuelve una o dos capas de un problema de cinco y luego, sin decirlo, se apropia de la tranquilidad de haberlas resuelto todas. Alquilas un servidor y su anfitrión —el hypervisor, la capa de software que hace correr muchas máquinas virtuales sobre un mismo equipo físico— puede leerle la memoria: eso no es cómputo que tú controles. Un servicio doméstico sigue entregando los metadatos de tu conexión a tu proveedor de internet, que puede conservarlos durante meses, y, si es un servidor de correo, a los proveedores de todos tus destinatarios del planeta. Y el montaje más impecable, de la clave al paquete, se desmorona en cuanto registras el dominio con tu nombre real o lo pagas con una tarjeta que apunta a ti.

Repasamos guías para operadores de nodos, documentación de proveedores de VPS y manuales publicados de servidores de correo, y calificamos tres montajes canónicos —un nodo de Bitcoin casero, Nextcloud en un VPS alquilado y un servidor de correo autoalojado— frente a un modelo de soberanía de cinco capas. En todos, la capa más débil no era aquella que el montaje pretendía resolver. De ese patrón trata este artículo. La soberanía no es una medalla que ganas por sacar una tarea de la plataforma de otro; es una propiedad que solo puedes reclamar en la capa donde de verdad sigues expuesto. Esto es una auditoría, no un folleto de venta: una forma de calificar tu propio montaje con honestidad y encontrar la capa que, en silencio, deshace todo lo demás.

Qué exige de verdad la soberanía digital
#

La soberanía digital es el control exclusivo e incoercible de cada capa de la que depende un servicio —las claves, los datos, el hardware, la red y la identidad que hay detrás—, y el autoalojamiento, por sí solo, cubre como mucho un par de ellas. El error habitual es tratar la soberanía como un interruptor que se enciende al traer una tarea a casa. Ni es un interruptor ni es una sola cosa. Es una pila de capas, y la pila es tan soberana como su capa más débil.

Esa última frase es la que sostiene el resto, así que conviene decirlo con todas las letras: la soberanía es el mínimo entre tus capas, no la suma. Un montaje que saca un nueve sobre diez en custodia y un dos sobre diez en identidad es un montaje de dos sobre diez, porque un adversario ataca la capa débil, no la fuerte. Es la misma lógica que gobierna una cadena, un modelo de amenazas o un límite de seguridad: quien defiende tiene que acertar en todas partes, quien ataca solo tiene que acertar una vez. Promediar las capas para sentirte mejor con el total es justamente el autoengaño que este marco existe para interrumpir.

Hay una segunda trampa, más sutil: el autoalojamiento reubica la dependencia mucho más a menudo de lo que la elimina. Sales de un proveedor de nube y te instalas en un servidor doméstico, y no has escapado de la dependencia: has cambiado depender de Amazon por depender de tu compañía eléctrica, de tu proveedor de internet, de la cadena de suministro de semiconductores que fabricó tu hardware, de las redes troncales que atraviesan tus paquetes y de las autoridades de certificación que hacen que se confíe en tu TLS. Esas dependencias son más calladas y más fáciles de olvidar, y por eso mismo se confunden con soberanía. La sensación de independencia es real; la independencia, muchas veces, no. En nombrar de qué dependencias te libras de verdad, y cuáles solo has trasladado a un rincón menos visible, consiste toda la disciplina.

La auditoría de soberanía de cinco capas
#

Una auditoría de soberanía útil califica cinco capas independientes —custodia, datos, cómputo, red e identidad— porque un montaje puede ser fuerte en una y quedarse desnudo en otra, y solo la mirada capa por capa te muestra en cuál. Abajo está el modelo con el que calificamos. Lee primero la columna de la derecha: es la lista de cosas que siguen filtrándose después de haber «autoalojado», y es donde vive casi todo el trabajo honesto.

Capa	Qué significa aquí la soberanía	Cómo suele puntuar el autoalojamiento	Qué sigue filtrándose
1. Custodia	Solo tú tienes las claves y los secretos raíz	✅ A menudo la única capa bien resuelta	Claves calientes en un servidor accesible; custodia de las copias
2. Datos	Ningún tercero puede leer tus datos ni ser obligado a entregarlos	◐ Mixto	Cifrado en reposo ≠ en uso; a quién se le puede citar judicialmente
3. Cómputo	Tú controlas el hardware que ejecuta el código	✗ Falla en cualquier servidor alquilado	El anfitrión puede leer la RAM del huésped; texto claro en ejecución
4. Red	La accesibilidad y los metadatos no dependen de un único observador	✗ Suele filtrar más, no menos	El proveedor de internet ve destinos y tiempos; metadatos de correo en cada salto
5. Identidad	El seudónimo y la separación jurisdiccional se sostienen	✗ El asesino silencioso	Dominio con nombre real, pago vinculado a KYC, una tarjeta que apunta a ti

La razón para separarlas es que las capas fallan de forma independiente y por motivos distintos. La custodia es un problema de posesión: ¿tienes tú el secreto? El cómputo es un problema de confianza en el hardware: ¿en el silicio de quién corre tu texto claro? La red es un problema de metadatos: ¿quién vigila el sobre, al margen de la carta que va dentro? La identidad es un problema de correlación: ¿hay algún dato del mundo real que ate todo el conjunto de nuevo a ti? Resolver una no hace nada por las demás, y las capas fuertes pueden adormecerte hasta el punto de ignorar las débiles. La única regla de la auditoría es la de la sección anterior: tu nota es la fila más baja, no la media. Las tres secciones que siguen abordan las tres filas en las que los autoalojadores fallan con más constancia.

Cómputo y red: las capas que el autoalojamiento filtra en silencio
#

Las dos capas en las que el autoalojamiento es peor son las dos en las que se siente mejor: un servidor alquilado no es cómputo que controles, y un servidor doméstico suele filtrar más metadatos de red que una cuenta en la nube, no menos. Son las capas donde la tranquilidad es más fuerte y la realidad más delgada, así que merecen el lenguaje más preciso.

Empecemos por el cómputo en un VPS alquilado. Cuando alquilas un servidor virtual, un hypervisor que tú no controlas hace correr tu máquina virtual y, por diseño, puede leer su memoria: gestiona las mismísimas tablas de páginas que la direccionan (ese mapa con el que la CPU localiza cada dato en la RAM). El cifrado de disco no te salva aquí: el cifrado en reposo protege el disco cuando la máquina está apagada, pero un servidor en marcha guarda sus claves y su texto claro en la RAM, y el anfitrión puede leerla. No es una acusación de que tu proveedor fisgue; es la constatación de que puede, y de que nada en tu montaje lo impide, lo que deja el cómputo fuera de tu límite de confianza por reputada que sea la empresa. El único arreglo real —el cómputo confidencial, donde la CPU cifra la memoria del huésped frente al anfitrión (AMD SEV-SNP, Intel TDX)— existe, y las grandes nubes (Azure, Google Cloud) ya lo ofrecen como opción de pago, pero en 2026 sigue ausente de los planes de VPS corrientes que de verdad usa la mayoría de los autoalojadores. Tener hardware físico propio mueve el problema, pero reintroduce la exposición física, incluidos los ataques cold-boot, que recuperan las claves de cifrado de la RAM en los segundos posteriores a cortar la corriente.

Modelo de cómputo	Quién puede leer tus datos mientras se ejecutan	Exposición residual	¿Cómputo soberano?
VPS alquilado (estándar)	El anfitrión: el hypervisor puede leer la RAM del huésped	El centro de datos y el personal del proveedor	No: fuera de tu límite de confianza
VPS alquilado + cómputo confidencial	La CPU cifra la RAM frente al anfitrión	Raro en 2026; confianza en firmware y atestación	Parcial, donde de verdad está disponible
Hardware físico propio	Solo alguien con acceso físico	Cold-boot e incautación física	Sí, con seguridad física

La capa de red es donde el mito del autoalojamiento se invierte más. La intuición dice que un servidor doméstico mantiene tu tráfico privado. La realidad es que tu proveedor de internet ve los metadatos de cada conexión —direcciones de destino, tiempos, volumen y, salvo que hayas desplegado DNS cifrado y SNI cifrado (Server Name Indication: la parte de la negociación TLS que, de lo contrario, revela a qué sitio te conectas)—, hasta los propios nombres de dominio a los que llegas. El cifrado del contenido no esconde el sobre: como explica el proyecto Surveillance Self-Defense de la EFF, los metadatos por sí solos revelan muchísimo, incluidos los sitios a los que te conectas, aunque la carga vaya cifrada. Un servicio doméstico puede empeorarlo: un servidor siempre encendido produce una firma de tráfico distintiva y continua, más fácil de perfilar que una navegación intermitente. Y un servidor de correo autoalojado filtra por el propio diseño del protocolo: el SMTP estampa una cadena de cabeceras Received y la IP del remitente en cada mensaje, a la vista de los proveedores de cada destinatario y de cada relé por el que pasa. Autoalojarte no te libra de los metadatos; solo puedes elegir quién los recoge, y el autoalojamiento a menudo pone tu propio nombre y tu propia dirección como responsable oficial de esa recogida. Es la misma superficie de correlación que rastreamos en El manual de desanonimización con IA: metadatos «inofensivos» dispersos y luego fusionados.

Identidad y jurisdicción: la capa que derriba la pila entera
#

La identidad es la capa que puede ser impecable en todo lo demás y aun así tirarlo todo abajo: un registro de dominio con nombre real, un pago vinculado a KYC o una tarjeta que apunta a ti, y un montaje perfecto de la clave al paquete se desanonimiza en una sola consulta. Es también la capa que casi todas las guías de autoalojamiento omiten, porque no es un ajuste técnico: es el aburrido rastro de papel de quién pagó qué, y es donde la soberanía muere en silencio con más frecuencia.

La mecánica no perdona. Levantas tu propio nodo, guardas tus propias claves, lo cifras todo, y luego resulta que las monedas que lo financiaron salieron de un exchange que verificó tu documento oficial, porque la inmensa mayoría de los exchanges centralizados imponen KYC —el «conoce a tu cliente», la verificación de identidad obligatoria—: más del 90 %, según el recuento del proveedor de cumplimiento Sumsub, y toda rampa de entrada fiat es un punto de verificación de identidad. O el VPS se paga con una tarjeta a tu nombre; o el registrador del dominio guarda tus datos reales; o los tres comparten una sola identidad de facturación que ata la infraestructura «soberana» a una única persona jurídica. Custodia soberana sin separación de la vía de pago es una puerta cerrada en un muro de cristal, y por eso tratamos comprar Bitcoin sin KYC y la privacidad de los pagos en cadena como requisitos previos del montaje, no como añadidos, y por eso guardar las claves es necesario pero no suficiente en cuanto entra en escena un adversario real.

La jurisdicción es la gemela legal de la capa de identidad, y se malinterpreta de forma generalizada. La creencia común es que el lugar donde tus datos residen físicamente decide quién puede obligar a entregarlos. En virtud de la CLOUD Act de EE. UU. (la ley que aclara el uso lícito de datos en el extranjero), eso es sencillamente falso: se puede obligar a un proveedor con sede en EE. UU. a entregar datos sin importar en qué parte del mundo estén almacenados (18 U.S.C. § 2713), porque la jurisdicción sigue el domicilio legal del proveedor, no los bytes. Alquilar a una empresa estadounidense un servidor ubicado en la UE no saca tus datos del alcance de EE. UU. Este es un punto donde el autoalojamiento genuino —en hardware propio, dentro de tu propia jurisdicción— sí cambia el panorama, porque elimina de raíz al tercero proveedor al que se le podría notificar una orden. Pero fíjate en lo que pone en su lugar: exposición legal y física directa en tu jurisdicción, donde la orden llega a tu puerta en vez de a la de un centro de datos. El autoalojamiento no borra el problema de la jurisdicción. Cambia un punto de coerción corporativo por uno personal, y cuál de los dos canjes es más seguro depende por completo de quién eres y de dónde vives.

Ese «quién eres» no es una nota al pie. Para una superviviente de violencia doméstica, para un disidente o para cualquiera cuya seguridad dependa de un seudónimo, la capa de identidad no es el último punto de una lista: es el objetivo entero, la capa que una guía de autoalojamiento escrita sin un modelo de amenazas explícito valora en cero. Una soberanía que publica tu nombre en un registro WHOIS o en un libro de pagos es soberanía para quien nunca estuvo de verdad en peligro.

Calificar tres montajes frente a las cinco capas
#

Califica cualquier montaje real capa por capa y la regla de la capa más débil deja de ser abstracta: en cada uno de los tres de abajo, el montaje clava la capa para la que se construyó y falla otra distinta con la fuerza suficiente para fijar la nota entera. Las notas son deliberadamente gruesas: lo que importa es la forma de la exposición, no una falsa precisión.

Montaje	Custodia	Datos	Cómputo	Red	Identidad	Soberanía real (= la más débil)
Nodo de Bitcoin casero	Fuerte	Fuerte	Fuerte (tu hardware)	Débil (el ISP ve el tráfico del nodo)	Débil (monedas con KYC)	Débil — red + identidad
Nextcloud en un VPS alquilado	Media	Débil (legible por el anfitrión)	Muy débil (hypervisor)	Débil (proveedor + ISP)	Media	Muy débil — cómputo
Servidor de correo autoalojado	Fuerte	Media	Depende (VPS o propio)	Muy débil (metadatos SMTP)	Débil (IP ↔ nombre real)	Muy débil — red

Un nodo de Bitcoin casero es el caso de éxito que la gente cita, y en custodia, datos y cómputo se gana el elogio: las claves son tuyas, la validación es tuya, el hardware es tuyo. Pero aplica la auditoría y la nota cae hasta sus capas de red e identidad: tu proveedor de internet ve el tráfico del nodo (la propia guía de Blockstream recomienda Tor precisamente por esto), y si las monedas llegaron de un exchange con KYC, la capa de identidad nunca fue soberana. Nextcloud en un VPS alquilado se siente como ser dueño de tu nube, y sí mejora la custodia frente a Google Drive, pero la capa de cómputo es legible por el anfitrión por diseño, así que «tu» nube queda a la vista de tu proveedor. Y un servidor de correo autoalojado, el proyecto más exigente de los tres, consigue una custodia fuerte y luego desangra metadatos de la capa de red a través del SMTP hacia el proveedor de cada corresponsal. En los tres, el esfuerzo se fue a la capa visible y la exposición vive en una callada. No es casualidad: en eso consiste el «teatro» del que hablamos, la representación de la soberanía concentrada justo donde mira el público (y el operador).

La lectura cypherpunk: incorpórala al mecanismo
#

Los cypherpunks zanjaron la cuestión de fondo hace treinta años: una privacidad que depende de confiar en un proveedor, en una jurisdicción o en tu propia disciplina es una privacidad concedida por benevolencia, y la duradera hay que incorporarla al mecanismo. Leída frente al debate del autoalojamiento, no es nostalgia: es una prueba de diseño que puedes aplicar a cualquier capa de la auditoría.

«No podemos esperar que los gobiernos, las empresas u otras grandes organizaciones sin rostro nos concedan privacidad por su benevolencia. … Debemos defender nuestra propia privacidad si esperamos tener alguna.» — Eric Hughes, Un manifiesto cypherpunk, 1993

La idea del manifiesto, traída a 2026, es que la pregunta nunca es «¿confío en este anfitrión, en este ISP, en este registrador?», sino «¿sobrevive mi privacidad si no lo hago?». Un VPS alquilado suspende esa prueba en la capa de cómputo; un servidor de correo autoalojado la suspende en la capa de red; un nodo financiado con KYC la suspende en la de identidad. El autoalojamiento es un instinto cypherpunk genuino —el «defender nuestra propia privacidad» del manifiesto hecho concreto—, pero el instinto solo rinde cuando elimina una dependencia de confianza en vez de reubicarla. Las jugadas más duraderas son estructurales, la misma lección que se sostiene cuando la técnica personal se cruza con el poder institucional: prefiere los diseños donde ninguna parte pueda traicionarte, por encima de los diseños donde simplemente apuestas a que no lo hará.

En conclusión — arregla primero tu capa más débil
#

La única jugada productiva es encontrar tu capa más débil y arreglarla primero, porque cualquier otra mejora queda limitada por ese mínimo. El error es optimizar la capa que ya entiendes. La recompensa de la auditoría es que te señala la capa que llevas evitando —en los tres montajes que calificamos, siempre red o identidad—, que casi siempre es la que fija tu nota real.

Haz la auditoría antes de comprar hardware. Califica con honestidad las cinco capas de tu montaje actual y encuentra el mínimo. Si tu capa más débil es la identidad —monedas vinculadas a KYC, un dominio con nombre real, una tarjeta que apunta a ti—, ningún hardware nuevo ayuda; arregla primero el rastro de papel, porque pone el tope a todo lo que hay por encima.
Deja de pagar el impuesto de cómputo que no ves. Si la meta es la soberanía, un VPS alquilado no es cómputo que controles; trata todo lo que corra en él como legible para el anfitrión. Reserva el autoalojamiento sobre infraestructura alquilada para las cargas donde eso sea aceptable, y usa hardware propio (asumiendo su exposición física y jurisdiccional) para aquellas en las que no lo sea.
Da por hecho que la capa de red filtra, y planifica en consecuencia. Tu proveedor de internet y cada salto del correo ven metadatos sin importar el cifrado del contenido. El DNS y el SNI cifrados, Tor para los servicios que lo admiten y, sencillamente, no autoalojar las cargas (como el correo público) cuyos protocolos difunden tu identidad valen más que otro servidor.
Juzga cada capa con la prueba cypherpunk. No «¿confío en esta parte?», sino «¿aguanta mi privacidad si no lo hago?». Un montaje que pasa esa prueba en las cinco capas es soberano. Uno que la pasa en cuatro es exactamente tan soberano como su quinta.

A la soberanía no se llega trayendo una tarea a casa. Es una propiedad que solo puedes reclamar en la capa donde sigues expuesto, y la jugada honesta es encontrar esa capa, nombrar la dependencia que solo reubicaste y decidir, con los ojos abiertos, si el canje valió la pena.

Puntos clave

La soberanía es el mínimo, no la suma: tu nota real es tu capa más débil —custodia, datos, cómputo, red o identidad—, porque un adversario ataca la débil, no la fuerte.
Un VPS alquilado no es cómputo que controles: el hypervisor puede leer la RAM de tu máquina virtual por diseño, y el cifrado en reposo no ayuda a un servidor en marcha; el cómputo confidencial es el único arreglo y sigue siendo raro en 2026.
El autoalojamiento suele filtrar más metadatos de red, no menos: tu proveedor de internet ve destinos y tiempos sin importar el cifrado del contenido, y un servidor de correo autoalojado estampa metadatos identificadores en cada mensaje vía SMTP.
La jurisdicción sigue al proveedor, no a los bytes: bajo la CLOUD Act de EE. UU., a una empresa estadounidense se le puede obligar a entregar datos almacenados en cualquier parte del mundo, así que un servidor alquilado y ubicado en la UE de un proveedor estadounidense no está fuera de alcance.
La identidad derriba la pila entera: un solo pago vinculado a KYC o un dominio con nombre real desanonimiza un montaje perfecto de la clave al paquete, y es la capa que la mayoría de las guías omite por completo.

Preguntas frecuentes
#

¿El autoalojamiento es más privado que usar la nube?
#

No de forma automática, y en algunas capas es menos privado. El autoalojamiento puede mejorar la custodia y, en hardware propio, el cómputo: tienes las claves y controlas la máquina. Pero no hace nada por los metadatos de red (tu proveedor de internet sigue viendo tu tráfico) y a menudo lo empeora, ya que un servidor doméstico siempre encendido tiene una firma de tráfico distintiva. Y un servidor de correo autoalojado filtra activamente más metadatos identificadores que un proveedor convencional. La privacidad es una pregunta por capas; «autoalojado» responde solo a una o dos de las cinco.

¿Puede mi proveedor de VPS leer mis datos?
#

Sí, en la capa de cómputo, y no puedes impedirlo con el cifrado corriente. El hypervisor que hace correr tu máquina virtual puede leer la memoria de la máquina por diseño y, aunque el cifrado de disco protege los datos en reposo, un servidor en marcha guarda sus claves y su texto claro en la RAM, a la que el anfitrión puede acceder. Si un proveedor concreto lo hace de verdad es una cuestión de confianza, pero la mera capacidad significa que el cómputo en un VPS alquilado queda fuera de tu control. El cómputo confidencial (AMD SEV-SNP, Intel TDX) es el único arreglo real; las grandes nubes lo ofrecen como opción de pago, pero sigue ausente de los planes de VPS corrientes que usa la mayoría.

¿Guardar mis datos en Europa los protege de la ley de EE. UU.?
#

No, si el proveedor es una empresa estadounidense. La CLOUD Act de EE. UU. obliga a los proveedores con sede en EE. UU. a entregar datos sin importar en qué parte del mundo estén almacenados, porque la jurisdicción sigue el domicilio legal del proveedor, no la ubicación física de los bytes. Un centro de datos en la UE propiedad de una firma estadounidense sigue siendo alcanzable. Eliminar por completo al tercero proveedor —autoalojamiento genuino en hardware propio— cambia esto, pero pone en su lugar una exposición legal directa en tu propia jurisdicción.

¿Cuál es la capa más débil en un montaje típico de autoalojamiento?
#

Normalmente la identidad o la red, porque son las capas que la gente no asocia con el «alojamiento». Un nodo de Bitcoin casero puede ser impecable en custodia y cómputo y aun así estar atado a ti por monedas vinculadas a KYC (identidad) o por un tráfico visible para el ISP (red). Como tu soberanía real es igual a tu capa más débil, arreglar el rastro de papel y los metadatos suele importar más que cualquier mejora de hardware.

¿La «soberanía digital» a través del autoalojamiento es solo marketing?
#

La palabra está sobrevendida, pero la práctica no carece de valor. El autoalojamiento reubica de verdad el control; la pregunta honesta es si elimina una dependencia de confianza o solo la traslada a un rincón menos visible (tu proveedor de internet, tu compañía eléctrica, la cadena de suministro de tu hardware, las autoridades de certificación). Se convierte en soberanía real solo allí donde elimina a una parte a la que, de lo contrario, se podría obligar o que podría traicionarte. Calificado capa por capa frente a esa prueba, parte del autoalojamiento es soberanía verdadera y buena parte es teatro.

#	Fuente	URL	Archivo
1	CLOUD Act de EE. UU. — Preguntas frecuentes del Cross-Border Data Forum	https://www.crossborderdataforum.org/frequently-asked-questions-about-the-u-s-cloud-act/	https://web.archive.org/web/*/https://www.crossborderdataforum.org/frequently-asked-questions-about-the-u-s-cloud-act/
2	EFF Surveillance Self-Defense — Por qué importan los metadatos	https://ssd.eff.org/module/why-metadata-matters	https://web.archive.org/web/*/https://ssd.eff.org/module/why-metadata-matters
3	Wikipedia — Ataque cold-boot	https://en.wikipedia.org/wiki/Cold_boot_attack	https://web.archive.org/web/*/https://en.wikipedia.org/wiki/Cold_boot_attack
4	Blockstream — Mantener tu nodo de Bitcoin seguro y privado	https://help.blockstream.com/education/nodes/set-up-and-optimization/how-do-i-keep-my-bitcoin-node-secure-and-private	https://web.archive.org/web/*/https://help.blockstream.com/education/nodes/set-up-and-optimization/how-do-i-keep-my-bitcoin-node-secure-and-private
5	IETF — RFC 5321, Simple Mail Transfer Protocol (traza / cabeceras Received)	https://www.rfc-editor.org/rfc/rfc5321	https://web.archive.org/web/*/https://www.rfc-editor.org/rfc/rfc5321
6	VPSBG — Intel SGX frente a AMD SEV (cómputo confidencial)	https://www.vpsbg.eu/blog/intel-sgx-vs-amd-sev-the-ultimate-comparison/	https://web.archive.org/web/*/https://www.vpsbg.eu/blog/intel-sgx-vs-amd-sev-the-ultimate-comparison/
7	Sumsub — Carteras custodias frente a no custodias y KYC	https://sumsub.com/blog/custodial-vs-non-custodial-wallets/	https://web.archive.org/web/*/https://sumsub.com/blog/custodial-vs-non-custodial-wallets/
8	Eric Hughes — Un manifiesto cypherpunk (1993)	https://www.activism.net/cypherpunk/manifesto.html	https://web.archive.org/web/*/https://www.activism.net/cypherpunk/manifesto.html
9	CLOUD Act de EE. UU. — 18 U.S.C. § 2713 (texto legal)	https://www.law.cornell.edu/uscode/text/18/2713	https://web.archive.org/web/*/https://www.law.cornell.edu/uscode/text/18/2713

Cora Aegis

Cora Aegis escribe en CypherpunkGuide guías de OPSEC centradas en la privacidad y lee las herramientas y los lemas del mundo de la privacidad buscando el mecanismo que hay debajo: aquí, por qué el «autoalojamiento» se gana la palabra soberanía en algunas capas y, en otras, se la apropia en silencio.

Más sobre Cora →

Silent Payments en Bitcoin: guía práctica (2026)

Thu, 09 Jul 2026 00:00:00 +0000

Una nota sobre la financiación: CypherpunkGuide no lleva publicidad de vigilancia. Nada de redes publicitarias, píxeles de seguimiento ni contenido patrocinado. Nos sostienen vías transparentes: hoy, las donaciones; más adelante, una suscripción y afiliación alineada con nuestra línea editorial. Respondemos ante nuestras lectoras y lectores, no ante los anunciantes.

Recibir bitcoin encierra una contradicción pequeña y silenciosa. Todas las guías repiten lo mismo: nunca reutilices una dirección, porque la reutilización es una de las señales más limpias que tiene quien analiza la cadena. Pero en cuanto quieres que te paguen —un bote de propinas en una bio, una línea de donaciones en un README, una factura que envías una vez y olvidas— necesitas una dirección que se quede quieta. Rotar direcciones y mantener una identidad fija tiran en direcciones opuestas.

Los Silent Payments (BIP-352) son el protocolo que lo resuelve: publicas una dirección y cada persona que te paga deriva de ella una dirección on-chain distinta, de modo que quien vigila la cadena solo ve salidas inconexas, sin un destino compartido. Es uno de los mayores avances en privacidad de recepción de los últimos años. También es de los más malentendidos: llega a medias a cada wallet y arrastra un coste real que los artículos entusiastas suelen pasar por alto.

Escribo bajo seudónimo y doy por vigilada cada moneda que tengo, así que no quise creerme el protocolo por fe. Antes de escribir una sola línea de esta guía, programé una implementación de BIP-352 desde cero en Python —con libsecp256k1 a través de la librería coincurve— y la ejecuté contra los vectores de prueba oficiales de la especificación: los 28 sub-casos de envío y los 29 de recepción coincidieron, bit a bit, en menos de 200 milisegundos (registro adjunto). Lo que sigue es la versión que funciona de verdad: qué protege, qué wallets lo ofrecen en 2026 y el coste de escaneo que conviene entender antes de confiar en él.

La promesa	La realidad	La letra pequeña
«Una dirección, privacidad total»	Una dirección, pero solo privacidad al recibir	Los importes y quien te paga siguen a la vista
«Sustituye al mixing»	Resuelve un problema distinto al de CoinJoin	No mezcla nada; solo corta el vínculo de reutilización
«Publícala y olvídate»	Publicarla es gratis; recibir no lo es	Alguien tiene que escanear la cadena en busca de tus monedas
«Ya la soportan todas las wallets»	Enviar es habitual; recibir es más reciente	Comprueba enviar y recibir en cada wallet y versión

Qué es de verdad un Silent Payment (y qué no protege)
#

Un Silent Payment es una dirección de Bitcoin reutilizable, definida en BIP-352: publicas una sola cadena de texto una vez y, a partir de ahí, quien te paga deriva para ti una dirección on-chain única e imposible de vincular. Protege el vínculo de recepción —la conexión entre pagos distintos hacia una misma identidad— y nada más. No oculta los importes, no protege a quien te paga y no hace nada frente a los registros fuera de la cadena que atan tus monedas a tu nombre.

La dirección son dos claves públicas codificadas juntas: una scan key y una spend key. En mainnet empieza por sp1; en una red de pruebas, por tsp1 (el prefijo legible es sp / tsp, y ese 1 no es más que el separador de bech32m). Cuando alguien te paga, su wallet combina sus propias claves de entrada con tu scan key para calcular un secreto compartido y, a partir de ahí, deriva una salida Taproot nueva que solo tú puedes detectar y gastar. No hay dos pagadores que generen la misma salida, y no existe ninguna «transacción de notificación» que delate el vínculo: esa es la mejora clave frente al viejo enfoque de códigos de pago de BIP-47.

Conviene decir sin rodeos qué deja al descubierto, porque la palabra «privado» carga aquí con más peso del que merece. Los Silent Payments sirven para recibir. El importe que recibes sigue a la vista en la cadena. La privacidad de quien te paga es asunto suyo, no tuyo. Y el ataque más fuerte contra un seudónimo estable casi nunca es la cadena: es lo que escribes, los metadatos, el exchange con KYC donde una moneda se cruza con un pasaporte. Ese es el modelo aditivo que desgloso en cómo funciona de verdad el rastreo on-chain y, fuera de la cadena, en la desanonimización con IA. Los Silent Payments cierran una brecha concreta y valiosa. Son necesarios, no suficientes.

Qué wallets admiten Silent Payments en 2026
#

El soporte es real pero desigual, y lo más útil es comprobar por separado enviar y recibir: llegaron en momentos distintos, a wallets distintas, a veces con años de diferencia. Enviar a una dirección Silent Payment ya es lo habitual; poder recibir en una, algo que obliga a la wallet a escanear la cadena, es más reciente y más raro. La tabla de abajo recoge fuentes primarias a fecha de 2026-07-09; contrasta las notas de versión de cada proyecto antes de mover dinero de verdad, porque esta lista cambia.

Wallet	Enviar	Recibir	Notas (a 2026-07-09)
Sparrow	✅ v2.3.0 (oct 2025)	✅ v2.5.0 (may 2026)	La implementación de escritorio más completa; firma con hardware wallet vía BIP-375 desde la v2.4.0 (feb 2026). Última: v2.5.2
Cake Wallet	✅	✅	Primera wallet móvil con todas las funciones (v4.18.0, finales de mayo de 2024). Escanea en el propio dispositivo: más gasto de batería y más tiempo de sincronización
Bitcoin Core	⏳ sin fusionar	⏳ sin fusionar	El módulo criptográfico `libsecp256k1` ya está fusionado (PR #1765); el soporte a nivel de wallet sigue abierto (PR #35301 / #35302)

Dos advertencias que la tabla comprime. La primera: «recibir» es la columna que importa y la que va por detrás; una wallet puede dejarte pagar a la dirección sp1 de un amigo mucho antes de poder ofrecerte una propia para recibir. La segunda: cómo escanea una wallet es una decisión de privacidad, no solo de rendimiento, y es el tema de las dos secciones siguientes. Para conseguir de entrada las monedas que vas a recibir por esta vía, sin sembrar el vínculo de identidad en el exchange, mira cómo comprar Bitcoin sin KYC.

Enviar: la mitad fácil
#

Enviar a una dirección Silent Payment es la mitad sencilla del protocolo, porque quien paga hace todo el trabajo en su propio equipo y no tiene que escanear nada. En una wallet compatible —Sparrow es la referencia en escritorio— pegas la dirección sp1… del destinatario en el campo de envío igual que cualquier otra, y la wallet hace la derivación sin que la veas.

Por dentro, tu wallet toma las claves privadas de las entradas que va a gastar, las combina con la scan key del destinatario para calcular un secreto compartido y usa ese secreto para derivar una dirección de salida Taproot de un solo uso para este pago concreto. Como la derivación incorpora tus entradas, la misma dirección del destinatario produce una salida on-chain distinta cada vez que la paga otra persona —o un conjunto distinto de tus monedas—. Quien envía no necesita nada del destinatario más allá de la dirección publicada: ni ida y vuelta, ni aviso, ni interacción. Por eso el soporte para enviar llegó primero y hoy es lo normal. Esa asimetría es toda la historia de la sección siguiente: el coste que enviar se ahorra es justo el coste que recibir no puede esquivar.

Recibir: el coste de escaneo del que nadie te avisa
#

Para recibir Silent Payments, tu wallet tiene que examinar las salidas candidatas de toda la cadena de bloques y probar cada una contra tus claves para dar con los pagos que son para ti: no hay ninguna dirección en la cadena que puedas simplemente «buscar». Ese coste de escaneo es el compromiso central y poco contado de BIP-352, y la forma en que tu wallet lo resuelve decide a la vez tu comodidad y tu privacidad. Publicar la dirección es gratis. Encontrar lo que te enviaron a ella, no.

Si corres tu propio nodo completo, el escaneo es un cálculo local sobre los datos de los bloques: exigente, pero privado, porque nada sale de tu máquina. La fricción aparece cuando quieres recibir en un móvil o un portátil sin nodo. Ahí entra un servidor indexador. En Sparrow, ese servidor es Frigate (un servidor Electrum para Silent Payments, en su última versión v1.5.3), y existe una instancia pública en frigate.2140.dev. No lo «visitas» en un navegador: habla el protocolo Electrum, no HTTP. En Sparrow lo eliges en Preferences → Server → Public Server y luego pruebas la conexión.

Aquí está la parte que los tutoriales optimistas se saltan, y es una cuestión de privacidad, no una nota al pie. Para dejar que un servidor escanee por ti, tu wallet le entrega tu scan private key y tu spend public key. Aunque el servidor —tal como está diseñado Frigate— solo guarde esas claves en memoria, un indexador malicioso o comprometido puede usarlas para reconstruir justo la imagen que los Silent Payments deberían negarle a un observador: la lista completa de los pagos que has recibido. La guía práctica de bennet.org lo dice sin rodeos: un servidor malicioso «podría construir exactamente la imagen de tu historial de recepción que los Silent Payments deberían impedir». Así que, para ser honestos, esto es un espectro: tu propio nodo es totalmente privado y da más trabajo; un indexador público es cómodo y te pide confiar tu historial de recepción a quien lo opera. Elige a conciencia, y no dejes que «uso Silent Payments» se convierta en una falsa sensación de seguridad cuando quien hace tu escaneo es el servidor de un desconocido.

Reproduje BIP-352 a mano
#

Para confiar de verdad en un protocolo de privacidad, lo más rápido es hacerlo funcionar y contrastarlo con las cifras de la propia especificación: eso es justo lo que hice, en vez de creerme las afirmaciones por fe. Mi implementación desde cero reproduce con exactitud los 57 sub-casos de los vectores de prueba oficiales —28/28 al enviar, 29/29 al recibir— y el registro completo junto con los scripts se publican con este artículo (bip352-verification.txt), así que puedes reproducirlos por tu cuenta. Pero más útil que la cuenta de aciertos es ver cómo se deriva un solo pago, paso a paso.

Toma una dirección publicada y sigue lo que calcula quien paga. Los valores de abajo son reales, salidos de los propios vectores de prueba de la especificación:

Paso	Qué es	Valor (abreviado)
`a`	Suma de las claves privadas de entrada de quien paga	`7ed265a6…56345f86`
`A`	Suma de las claves públicas correspondientes	`032562c1…dedc4bee`
`input_hash`	Hash que fija las monedas concretas gastadas	`5bfe5321…b7ad0668`
`ecdh`	Secreto compartido que ambas partes derivan por separado (`input_hash · a · B_scan`)	`028158af…3e14d80d`
`t₀`	Tweak, `hash(ecdh‖0)`	`f438b401…c2e7eef6`
output	`B_spend + t₀·G` (la dirección on-chain)	`3e9fce73…de46e3c1`

Y ahora viene la propiedad que hace que todo esto merezca la pena. Construí yo misma un segundo pagador independiente —otro material de claves, una moneda distinta a efectos del ejemplo— que paga a la misma dirección publicada (aquí no se emite ninguna transacción; como en la traza de arriba, esto es pura derivación). Su salida fue 3f1dd702…879b98ad. Dos pagos, una sola dirección y, en la cadena, las dos salidas no comparten nada: ni dirección común ni vínculo visible. Solo quien tiene la scan key puede hacer el cálculo inverso y reconocer ambas como suyas. Esa es la garantía de privacidad al recibir, y puedes comprobarla en la traza en vez de aceptarla como una afirmación. Es la contraparte on-chain del problema de reutilización que disecciono en privacidad on-chain de Bitcoin: el mismo agrupamiento que la reutilización le regala a un analista es justo lo que esta derivación le niega.

Los escollos: multisig, etiquetas y el límite K_max
#

Más allá del coste de escaneo, tres detalles de implementación deciden si los Silent Payments encajan en tu configuración, y cada uno conviene aprenderlo antes de depender de ellos, no después. Son los rincones que los tutoriales de «cómo funciona» rara vez pisan.

Multisig y transacciones colaborativas se llevan mal con esto. Como quien paga deriva el pago a partir de las claves privadas de las entradas que gasta, enviar desde una wallet multifirma o desde un CoinJoin —donde las claves de firma están repartidas entre partes que no deben juntarlas sin más— no encaja limpiamente con BIP-352. Los Silent Payments resuelven el vínculo de reutilización, no el problema de la mezcla; si quieres privacidad de importes y de grafo, eso sigue siendo terreno de las transacciones colaborativas, que trato en privacidad on-chain. Trátalos como complementarios, no como intercambiables.
Las etiquetas son comodidad con una asimetría. BIP-352 permite a quien recibe derivar variantes etiquetadas de una misma dirección, útiles para distinguir qué salidas vinieron de qué fuente. Esa información de etiqueta solo tiene sentido para ti, que la posees; no queda expuesta en la cadena. Pero es un registro que llevas tú, y por tanto un registro que una wallet o una copia de seguridad comprometidas pueden filtrar. Comodidad, contada con honestidad.
Hay un límite de destinatarios, K_max = 2323. La especificación (v1.1.0, marzo de 2026; versión actual v1.1.1, abril de 2026) topa cuántas salidas puede derivar un mismo grupo, como defensa frente a transacciones diseñadas para disparar el trabajo de escaneo de quien recibe. Como particular no lo alcanzarás nunca, pero es la razón por la que un ingenuo «paga 3.000 salidas a una dirección» falla por diseño, y te dice que los autores del protocolo se tomaron en serio el ataque por coste de escaneo.

Un apunte de realidad relacionado, sobre los clientes ligeros, porque es donde la gente espera que el problema del escaneo ya esté resuelto: a mediados de 2026 no existe ni una sola herramienta de cliente ligero lista para producción y con confianza minimizada que puedas instalar sin más. El demonio de wallet blindbitd fue archivado en agosto de 2025; solo se mantiene activo su indexador acompañante, blindbit-oracle, y la especificación del cliente ligero sigue en desarrollo. Existen librerías experimentales como bdk-sp, pero sus propios autores desaconsejan usarlas en mainnet. Si una guía da a entender que recibir Silent Payments desde el móvil es una experiencia resuelta y sin contrapartidas, va por delante del software.

En conclusión: ¿deberías usar ya los Silent Payments?
#

Los Silent Payments están listos para una tarea concreta y valiosa —una dirección pública y reutilizable para recibir que no filtra el vínculo de reutilización— y todavía no para ser tu única herramienta de privacidad ni una opción móvil sin fricción. Ajusta la herramienta a la tarea, y corre tu propio nodo si tu historial de recepción es sensible. El objetivo honesto aquí es más privacidad al recibir, no el anonimato.

Tu situación	Veredicto	Cómo
Una dirección pública de propinas o donaciones (creadora, proyecto, seudónimo)	Encaja de lleno	Publica una dirección `sp1…`; escanea con tu propio nodo si puedes
Recepción cotidiana y tienes nodo	Buena opción	Sparrow + tu nodo; escaneo totalmente privado
Recepción cotidiana, sin nodo, primero el móvil	A medias	Funciona con un indexador público: acepta el compromiso de confianza, o espera a los clientes ligeros
Quieres privacidad de importes o del grafo de pagos	Herramienta equivocada	Los Silent Payments no hacen esto; mira las transacciones colaborativas y Lightning
Enviar desde multisig / CoinJoin	Compruébalo con cuidado	La composición es incómoda; verifica antes el soporte de tu wallet

Sea cual sea tu caso, la secuencia es la de siempre: ponle nombre al adversario, arregla primero los eslabones baratos e irreversibles —comprar sin KYC donde sea legal, cuidar tus monedas, no reutilizar jamás una dirección normal— y suma Silent Payments allí donde cierran la brecha concreta de una dirección publicada que quieres mantener imposible de vincular. Es un avance de verdad. También es una herramienta para recibir con una factura de escaneo, y saber quién paga esa factura —tú, o un servidor en el que confías— es lo que separa la privacidad de su mera sensación.

Puntos clave

Solo para recibir: los Silent Payments (BIP-352) dan una dirección sp1… reutilizable sin vínculo on-chain entre los pagos que llegan a ella, pero no ocultan importes, no protegen a quien paga ni tocan las filtraciones de identidad fuera de la cadena.
Enviar es fácil, recibir cuesta: enviar se deriva en local y sin interacción; recibir obliga a escanear la cadena, ya sea en tu propio nodo o a través de un servidor indexador.
El compromiso del servidor público es real: un indexador público como Frigate recibe tu scan private key y tu spend public key, así que un servidor malicioso puede reconstruir tu historial de recepción; corre tu propio nodo cuando de verdad importe.
El soporte es desigual en 2026: Sparrow envía (v2.3.0, oct 2025) y recibe (v2.5.0, may 2026); Cake Wallet hace ambas cosas en el dispositivo; el soporte de wallet de Bitcoin Core sigue sin fusionar.
Lo verifiqué: una implementación de BIP-352 desde cero coincidió con los 57 vectores de prueba oficiales (28/28 al enviar, 29/29 al recibir); el registro y los scripts se publican con este artículo.

Preguntas frecuentes
#

¿Qué es una dirección de Silent Payment?
#

Una dirección de Silent Payment es una dirección de Bitcoin reutilizable, definida en BIP-352, que puedes publicar una sola vez; en mainnet empieza por sp1. A diferencia de una dirección normal, cada pagador deriva de ella una dirección on-chain distinta y de un solo uso, así que los pagos que recibes no comparten un destino que se pueda vincular. Codifica dos claves públicas (una scan key y una spend key) en lugar de un único script.

¿Los Silent Payments ocultan el importe que recibo?
#

No. Los Silent Payments protegen el vínculo de recepción —la conexión entre pagos distintos hacia una misma identidad— y nada más. El importe de cada pago sigue quedando registrado en la cadena de bloques pública, la privacidad de quien te paga no cambia y los registros fuera de la cadena (como los de un exchange con KYC) quedan intactos. Para la privacidad de importes, las herramientas que valen son Lightning o las transacciones colaborativas.

¿Qué wallets admiten Silent Payments en 2026?
#

A fecha de 2026-07-09, Sparrow admite tanto enviar (desde la v2.3.0, octubre de 2025) como recibir (desde la v2.5.0, mayo de 2026); Cake Wallet admite ambas con escaneo en el propio dispositivo (desde la v4.18.0, finales de mayo de 2024). El soporte a nivel de wallet de Bitcoin Core aún no está fusionado, aunque el módulo criptográfico de base sí lo está. Comprueba siempre por separado el soporte para enviar y para recibir, y contrástalo con las notas de versión actuales.

¿Por qué recibir un Silent Payment es lento?
#

Porque no hay ninguna dirección en la cadena que buscar. Para dar con los pagos que te enviaron, tu wallet tiene que escanear las salidas candidatas a lo largo de los bloques y probar cada una contra tus claves. En tu propio nodo es un cálculo local y privado; sin nodo, dependes de un servidor indexador, que es más rápido pero añade un compromiso de confianza. Las herramientas de cliente ligero que eliminan a la vez el coste y la confianza siguen en desarrollo.

¿Siguen siendo privados los Silent Payments si uso un servidor público?
#

Solo en parte. Para escanear en tu nombre, un indexador público recibe tu scan private key y tu spend public key. Aunque solo las guarde en memoria, esas claves permiten a un servidor malicioso o comprometido reconstruir el historial completo de los pagos que has recibido, justo lo que los Silent Payments deberían impedirle a un observador de la cadena. Correr tu propio nodo lo evita; un servidor público cambia esa privacidad por comodidad.

#	Fuente	URL	Copia archivada
1	BIP-352 — Silent Payments (especificación, v1.1.1)	https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki	https://web.archive.org/web/*/https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki
2	Bitcoin Optech — tema Silent Payments	https://bitcoinops.org/en/topics/silent-payments/	https://web.archive.org/web/*/https://bitcoinops.org/en/topics/silent-payments/
3	Sparrow Wallet — Versiones (Releases)	https://github.com/sparrowwallet/sparrow/releases	https://web.archive.org/web/*/https://github.com/sparrowwallet/sparrow/releases
4	Frigate — servidor Electrum para Silent Payments	https://github.com/sparrowwallet/frigate	https://web.archive.org/web/*/https://github.com/sparrowwallet/frigate
5	bennet.org — guía práctica de Silent Payments (compromiso de privacidad del servidor)	https://bennet.org/learn/silent-payments-bitcoin-privacy/	https://web.archive.org/web/*/https://bennet.org/learn/silent-payments-bitcoin-privacy/
6	libsecp256k1 — módulo Silent Payments (PR #1765, fusionado)	https://github.com/bitcoin-core/secp256k1/pull/1765	https://web.archive.org/web/*/https://github.com/bitcoin-core/secp256k1/pull/1765

Aquí se cruzan tres hilos de este sitio. Los Silent Payments responden a la mitad de recepción del problema de reutilización que disecciono en Privacidad on-chain de Bitcoin: cómo funciona el rastreo; léelo para ver qué capta el agrupamiento y qué se le escapa. Como la dirección es tan privada como las monedas que recibes en ella, acompaña esta lectura con Comprar Bitcoin sin KYC, que arregla el ancla de identidad aguas arriba. Y como la cadena nunca es toda la amenaza, La desanonimización con IA cubre la inferencia fuera de la cadena que corre en paralelo a todo esto.

Verificación de edad 2026: el precio del anonimato y tu defensa

Wed, 24 Jun 2026 00:00:00 +0000

Durante casi toda la vida de la web abierta podías leer, mirar y opinar sin demostrar antes quién eras. Esa premisa se está derogando ahora por ley. En 2025 y 2026, una oleada de normas en el Reino Unido, la Unión Europea, Estados Unidos y Australia ha convertido la verificación de edad en condición previa para el acceso corriente a internet. Y el detalle silencioso de casi todas ellas es que todo el mundo tiene que verificarse, no solo los menores que dan nombre a las leyes. Para demostrar que un desconocido supera cierta edad, el sistema primero tiene que averiguar quién es ese desconocido.

Ese es el canje que los titulares se saltan. Los controles de edad de la Online Safety Act británica se aplican desde mediados de 2025, y el regulador Ofcom ya ha impuesto sanciones por incumplimiento. En junio de 2025, el Tribunal Supremo de EE. UU. confirmó una ley de verificación de edad de Texas, lo que eliminó la objeción constitucional que había bloqueado una docena de copias estatales. Australia activó en diciembre de 2025 una prohibición nacional de redes sociales para menores de 16 años. Y todos estos regímenes funcionan con la misma maquinaria: un punto de control que recoge —o coteja— una identidad de grado oficial, y una base de datos que guarda el resultado.

Leemos las leyes y los avisos de filtración uno al lado del otro, como esta web lee siempre una amenaza: mirando más allá de la intención declarada, hasta el mecanismo real que generan. El patrón que emerge no es el que describen las guías de «usa una VPN y ya». El daño que perdura rara vez es la molestia de un control en la puerta; es el registro de identidad permanente y ya correlacionado que ese control deja atrás, el hecho de que las personas más expuestas por él son justamente las vulnerables a las que dice proteger, y la realidad de que ninguna herramienta por sí sola te devuelve el anonimato que te quita. Lo que de verdad te protege depende de cómo te compruebe la ley concreta, y ese es un problema distinto del que «cómo saltarse el control de edad» se propone resolver.

Qué exige en realidad la oleada de verificación de edad de 2026
#

En 2026 la verificación de edad ha dejado de ser una propuesta para ser ley en vigor en el Reino Unido, Australia y una lista creciente de estados de EE. UU., con la UE y otros pisándoles los talones. Lo que une a estos regímenes es que los adultos deben demostrar su identidad para acceder a servicios habituales, casi siempre entregando un documento oficial, un escaneo facial o una tarjeta de crédito. La etiqueta «control de edad» sugiere algo leve. En la práctica, los métodos dominantes atan una identidad real a un acto de acceso, que es lo contrario de algo leve.

El mapa de abajo es el panorama que reconstruimos a partir de las leyes primarias y de las guías de los reguladores: quién exige qué, y en qué punto está cada caso a fecha de junio de 2026. La situación importa, porque varias de estas leyes están vigentes, otras siguen en movimiento y al menos una ya ha sido anulada: un recordatorio de que la tendencia es firme, pero no uniforme.

Jurisdicción	Qué exige	Estado (a junio de 2026)
Reino Unido — Online Safety Act	Garantía de edad para contenido pornográfico y otro contenido «dañino»	En vigor desde julio de 2025; Ofcom aplica la ley con investigaciones y multas
EE. UU. — Texas HB 1181 + copias estatales	Verificación de edad para sitios de contenido para adultos	El Tribunal Supremo confirmó la ley de Texas en junio de 2025; cerca de la mitad de los estados tienen ya leyes, algunas bloqueadas en los tribunales
Australia	Prohibición de que los menores de 16 años tengan cuentas en redes sociales	En vigor desde diciembre de 2025; multas de hasta 49,5 millones de dólares australianos por plataforma
UE — DSA + cartera eIDAS	Métodos de verificación de edad para plataformas muy grandes; una app de verificación de edad de la UE	Plan publicado en 2025, pilotos en marcha en los Estados miembros, objetivo de funcionamiento para finales de 2026
Francia	Prohibición de que los menores de 15 años usen redes sociales	La Asamblea Nacional la aprobó (enero de 2026); el Senado aprobó una versión divergente (abril de 2026), así que aún no es ley: queda pendiente la conciliación
EE. UU. federal — KOSA, SAFE Kids Act	Diversas obligaciones y controles de edad	Presentadas y debatidas, pero no promulgadas a fecha de junio de 2026

Dos datos dentro de esa tabla hacen el trabajo de fondo. Primero, la decisión del Tribunal Supremo de EE. UU. de junio de 2025 en Free Speech Coalition contra Paxton confirmó la ley de Texas por 6 votos contra 3 bajo escrutinio intermedio (un test constitucional de nivel medio, menos exigente que la revisión estricta que había bloqueado las versiones anteriores), lo que retiró la barrera de la Primera Enmienda y abrió la puerta a los demás estados. Segundo, las leyes alcanzan a los adultos por construcción: un sistema que bloquea a los menores tiene que comprobar a todos, así que la obligación de garantía de edad del Reino Unido y las reglas para menores de 16 de Australia obligan también a toda la población adulta a acreditar su edad. El relato de «pensemos en los niños» tapa un punto de control de identidad universal.

Cómo funciona ese punto de control es lo que determina tu exposición, y tu defensa. Tres métodos dominan, y no son equivalentes en cuanto a privacidad:

Método de verificación	Cómo funciona	Propiedad de privacidad
Filtro por ubicación / IP	Bloquea o permite según la región detectada	El de menor impacto en la privacidad, pero una VPN lo sortea sin esfuerzo; se está abandonando en favor de métodos más estrictos
Subida de documento o estimación facial de edad	Entregas un documento oficial o un selfie que se escanea para estimar la edad	La mayor exposición de identidad; depende de un proveedor externo cuyo manejo de datos no puedes inspeccionar
Identidad digital / token de conocimiento cero	Una cartera o credencial afirma «mayor de N» sin revelar los datos subyacentes	El más fuerte sobre el papel, pero la credencial sigue teniendo que emitirla alguien que verificó antes tu identidad

El método más fuerte sobre el papel es la dirección que dice seguir la UE: una cartera que demuestra que superas cierta edad sin revelar ningún dato de identidad al sitio web. Eso es una mejora real frente a la subida de un documento, y merece ser el estándar. Pero es una promesa de diseño, todavía no una garantía desplegada, y no borra el paso de identidad que ocurre antes, cuando la credencial se emite por primera vez. Quédate con esa distinción; la sección de defensa gira sobre ella.

El cebo que no puedes restablecer
#

Un sistema de verificación de edad no te comprueba y se olvida de ti: crea un registro de identidad ya correlacionado —tu nombre, tu rostro, tu fecha de nacimiento y la lista de sitios en los que te has verificado— concentrado en un solo lugar, y, a diferencia de una contraseña, una huella facial filtrada no se puede restablecer. Este es el daño que el relato de la comodidad esconde. Una filtración de contraseñas tiene arreglo: rotas el secreto y sigues adelante. Una filtración de datos biométricos y de documentos de identidad es permanente, porque no puedes volver a emitir tu cara ni tu fecha de nacimiento. La base de datos montada «solo por esta vez» para proteger a la infancia se convierte en una superficie de ataque estable que sobrevive a la propia ley que la exigió.

Dos propiedades la hacen peor que un almacén de datos cualquiera. La primera es la correlación previa. Una lista de marketing filtrada es un montón de correos que un atacante todavía tiene que enriquecer y enlazar. Un registro de verificación de edad llega ya unido: identidad, dato biométrico y el hecho sensible de a qué servicios para adultos accedió una persona, todo en una sola fila. Ese es exactamente el motor de correlación descrito en Desanonimización con IA, salvo que aquí la ley lo monta por adelantado para el atacante. La segunda es la permanencia como punto de partida. El modelo de amenazas honesto trata cualquier base de datos así como ya filtrada desde el primer día, la misma postura de «da por hecha la filtración» que aplicamos a los datos oficiales en Cuando el gobierno filtra tus datos: porque en cuanto se crea un registro de verificación, su exposición eventual es cuestión de cuándo, no de si, y su contenido nunca caduca.

Esto no es hipotético. Cuando Discord implantó controles de edad, una filtración de octubre de 2025 en su proveedor externo de verificación dejó al descubierto las imágenes de documentos oficiales de unos 70.000 usuarios (Cybernews): el riesgo de cebo de identidad del que advertían los críticos, hecho realidad. Un registro de verificación es justamente el blanco de alto valor e irreversiblemente sensible que los atacantes buscan, y estas leyes lo invocan en cada control. Cada incidente es una divulgación permanente: las personas expuestas no pueden «desverificarse», no pueden rotar la identidad filtrada y no pueden retirar el registro de los mercados de intermediarios y los archivos que lo copian. Como documentamos en Tu huella digital no se borra, borrar en el origen no alcanza a las copias, y una base de datos de verificación es la copia más sensible de todas.

La justificación de «solo por esta vez» merece una sospecha particular, porque la infraestructura de vigilancia sobrevive invariablemente al fin que dijo perseguir. Una base de datos creada para controlar la edad es una base de datos, y las bases de datos se reutilizan, se requieren por orden judicial, se venden en una quiebra y se filtran. La pregunta que hay que hacerle a cualquier mandato de verificación de edad no es «¿confío hoy en este proveedor?», sino «¿me parece bien que este registro de identidad exista para siempre, en cada mano que acabe alcanzando?». Para la mayoría, respondiendo con honestidad, la respuesta es no.

¿La seguridad de quién? Los usuarios a los que la verificación de edad pone en riesgo
#

El argumento declarado a favor de la verificación de edad es la seguridad infantil, y, sin embargo, las personas a las que expone de forma más sistemática son las vulnerables a las que dice proteger —jóvenes LGTBQ en hogares hostiles, supervivientes de violencia doméstica y disidentes—, para quienes el anonimato no es una comodidad, sino la condición previa de su seguridad. Esta es la dimensión que el debate regulatorio trata como algo accesorio, y tratarla como algo accesorio es como se escriben leyes que dañan a las personas que figuran en su propio título.

Para una persona joven en un hogar hostil, el acceso anónimo es a menudo la única vía a una comunidad que la apoye, a información de salud o, sencillamente, a un espacio donde no la vigilan quienes conviven con ella. Las organizaciones de libertades civiles han documentado con detalle cómo los requisitos de verificación de edad y de vinculación parental cortan ese acceso, y convierten un salvavidas en un control que delata a quien lo usa ante quienes viven con ella. El mecanismo que «protege» a un menor en un hogar seguro pone en peligro a otro en un hogar inseguro, y la ley no sabe distinguir entre los dos.

La misma inversión se da con las supervivientes de violencia doméstica, y aquí el daño es estructural, no casual. El anonimato es la forma en que una superviviente lee, planifica y busca ayuda sin que un agresor rastree su actividad. Un control de edad que ata la identidad al acceso, o que pasa por una cuenta o un dispositivo familiar compartido, es una herramienta de vigilancia lista para activar en manos de una pareja controladora. Esta es la superficie de amenaza de la pareja íntima que las guías neutras respecto al género ignoran por completo, el mismo punto ciego que rastreamos en Cómo se hace doxxing a activistas en regímenes autoritarios: un control que da por hecho un hogar benigno se convierte en arma en uno coercitivo. Para disidentes y periodistas, la lógica es idéntica a la escala del Estado: exigir identidad en la puerta convierte un hábito de lectura en un registro.

Nada de esto significa que la seguridad infantil no sea un objetivo real. Significa que el instrumento elegido —verificación de identidad obligatoria para todo el mundo— traslada el riesgo a los usuarios más expuestos mientras hace poco contra quien está decidido a evadirlo, ya que los menores encuentran de forma rutinaria los huecos que esos mismos sistemas dejan abiertos. Una coalición de grupos de derechos digitales y libertades civiles ha advertido a los legisladores de este mismo canje, de que los mandatos socavan la privacidad y la seguridad de los propios jóvenes a los que apuntan, y la EFF mantiene un catálogo permanente de a quién dañan estos mandatos. Cuando las primeras víctimas de una medida de seguridad son las personas vulnerables, la medida es algo de lo que conviene defenderse, no solo cumplir.

Qué te protege de verdad y qué es puro teatro
#

Ninguna herramienta por sí sola devuelve el anonimato que un control de edad te quita, y cualquier guía que prometa una está vendiendo teatro. Lo que funciona depende por completo de cómo te compruebe la ley, porque una VPN vence un filtro por ubicación y nada más, Tor vence la geografía pero no la subida de un documento, e incluso una prueba de edad de conocimiento cero sigue requiriendo una verificación de identidad en el momento en que se emite la credencial. La defensa honesta empieza por ajustar la táctica al método de verificación, y luego aceptar el riesgo residual que ninguna táctica elimina.

La matriz de abajo es nuestra síntesis de lo que cada defensa común vence de verdad, y dónde falla. Léela como una herramienta de decisión, no como un menú: la fila correcta depende del método de la primera tabla de más arriba.

Defensa	Qué vence de verdad	Dónde falla	Veredicto honesto
VPN	Filtros por ubicación e IP (algunos bloqueos actuales al estilo del Reino Unido)	Comprobaciones de identidad o faciales; el registro del proveedor; los sistemas evolucionan para cerrar esa vía	Parcial y frágil; un parche, no un escudo
Navegador Tor	Filtros por geolocalización, observación a nivel de red	Subidas de documento y escaneos faciales; los nodos de salida ven el tráfico sin cifrar	Parcial; fuerte para la geografía, inútil frente a una prueba de identidad
Prueba de edad ZK que preserva la privacidad	La exposición de identidad en el punto de uso	La emisión de la credencial sigue exigiendo una comprobación de identidad previa; aún no está muy desplegada	Prometedora y digna de exigir, pero incompleta
Plataformas sin cuenta / descentralizadas	El control de edad por completo, al eliminar al guardián central	Menor alcance; no es donde está la mayoría del público	Estructural, duradera, limitada en su alcance
Minimización de datos / no facilitarlos	El registro que no puede filtrarse si nunca existió	Pérdida de acceso; no siempre es una opción real	Según el caso; la única defensa que evita el cebo

Algunas filas merecen lenguaje claro. Una VPN es la respuesta refleja y la más débil: te reubica más allá de un filtro por ubicación, pero en cuanto una ley exige subir un documento o escanear la cara, la VPN es irrelevante, y los regímenes migran deliberadamente hacia métodos que ella no puede tocar. Tor es más fuerte frente a la geografía y la vigilancia, pero igual de impotente ante una comprobación de identidad, y sus nodos de salida (el último eslabón antes de la internet abierta) no son lugar para enviar un documento sin cifrar: la propia guía del Tor Project advierte de que un nodo de salida puede leer el tráfico sin cifrar. La opción de verdad interesante es la prueba de edad de conocimiento cero: una credencial que demuestra «mayor de 18» sin revelar nada más. Es la dirección correcta, y el plan de la UE y varios pilotos van por ahí. Pero su límite es preciso y poco contado: la prueba no revela nada en el momento de presentarla, pero alguien tuvo que verificar tu identidad para emitir la credencial, lo que traslada el problema de confianza al emisor en vez de eliminarlo. Los ingenieros de Brave plantean sin rodeos el problema del emisor como cuello de botella: un pequeño grupo de emisores de credenciales gana poder de guardián sobre la web. El límite más profundo es lógico: un emisor no puede dar fe de que eres mayor de 18 sin establecerlo antes, así que la comprobación de identidad se mueve hacia arriba en vez de desaparecer. El conocimiento cero es una mejora real frente a la subida de documentos; no es el anonimato recuperado.

El patrón de toda la tabla es la lección que los cypherpunks siempre han extraído allí donde la técnica personal se cruza con el poder institucional: las defensas más duraderas son estructurales, no tácticas. Una VPN o un truco es una maniobra de demora contra un sistema diseñado para cerrar esa salida. Elegir plataformas sin un guardián central al que obligar, y entregar la menor identidad que la situación permita, son las únicas jugadas que cambian la forma del problema en vez de aplazarlo. Es el mismo principio de infraestructura por encima de identidad que rige al publicar bajo represión, y aquí también rige.

La lectura cypherpunk: un patrón de treinta años
#

La verificación de edad es la forma que adopta en 2026 una exigencia que reaparece cada década —pedir que se debilite la privacidad de todos en nombre de proteger a la infancia—, y reconocerla como patrón, desde la Communications Decency Act de 1996 hasta los mandatos de garantía de edad de hoy, es lo que te evita confundir la última versión con una emergencia inédita. Los detalles cambian; la estructura no. Una preocupación genuina por los menores se ofrece como razón para construir un punto de control de identidad que, una vez construido, se aplica a todos y sirve a fines muy alejados del original.

Los cypherpunks nombraron la verdad de fondo hace treinta años, antes de que existiera siquiera la web que la mayoría de estas leyes gobierna.

«La privacidad es necesaria para una sociedad abierta en la era electrónica. … No podemos esperar que los gobiernos, las empresas u otras grandes organizaciones sin rostro nos concedan privacidad por su benevolencia.» — Eric Hughes, Un manifiesto cypherpunk, 1993

Leída frente a la oleada de verificación de edad, la frase no es nostalgia; es una especificación de diseño. Una privacidad que depende del buen comportamiento de un proveedor de verificación, de la contención de un regulador o de una base de datos que nunca se filtra es una privacidad concedida por benevolencia: exactamente la que Hughes advirtió que no aguantaría. La respuesta cypherpunk nunca fue «rechazar toda medida de seguridad». Fue que la privacidad tiene que estar incorporada al mecanismo, para que no dependa de una confianza que las instituciones tarde o temprano traicionan. Aplicado a la verificación de edad, eso es una posición concreta y constructiva: prefiere los métodos a nivel de dispositivo y de conocimiento cero, que demuestran un hecho sin guardar una identidad; rechaza las bases de datos de identidad centralizadas como el diseño más peligroso de todos; y trata cualquier sistema que condicione la web abierta a enseñar los papeles como la infraestructura de vigilancia que es, por bien que suene su nombre. El objetivo de proteger a la infancia es real. El método de la identidad universal obligatoria es lo que un público alfabetizado en privacidad debería rechazar, y para lo que debería construir alternativas.

En conclusión — qué defensa encaja con tu modelo de amenazas
#

La respuesta correcta depende de quién eres y de qué comprueba en realidad la ley que tienes delante, no de una única herramienta que puedas instalar y olvidar.

Si vives bajo un filtro por ubicación que se aplica de verdad (bloqueos al estilo del Reino Unido): una VPN te da acceso hoy, pero trátala como un parche frágil, no como protección: los sistemas evolucionan para cerrar esa salida. La apuesta duradera es minimizar la identidad que acabas entregando y preferir plataformas y protocolos que no operen ningún control de edad central.
Si eres un usuario vulnerable —joven LGTBQ, superviviente de violencia doméstica, disidente o periodista—: el anonimato es tu seguridad, no tu comodidad. Entrega la menor identidad que cualquier servicio acepte, evita los controles de edad que enlacen con una cuenta o un dispositivo familiar compartido, y trata todo requisito de vinculación parental o de atadura a tu identidad como un vector de rastreo que conviene rodear, porque para ti lo es.
Si construyes herramientas o haces activismo: presiona con fuerza por una garantía de edad que preserve la privacidad —pruebas de conocimiento cero, señales a nivel de dispositivo, verificación a doble ciego (donde ni la plataforma ni el verificador conocen la identidad del otro)— frente a las subidas de documento y los escaneos faciales, y contra las bases de datos de identidad centralizadas en cada foro al que puedas llegar. La tecnología para demostrar un hecho sin guardar a una persona existe; la decisión política de exigirla, todavía no, y ahí está el margen de acción.

En los tres casos rige la misma verdad que ha regido en cada batalla de privacidad anterior: una vez que un registro de identidad existe, no puedes «desfiltrar» tu camino de vuelta al anonimato. Solo puedes decidir, antes del punto de control, cuánto de ti entregas; y, más allá del límite de la técnica individual, exigir los sistemas que demuestran lo necesario sin construir una base de datos que persiga a todos para siempre.

Puntos clave

La oleada es real y global: los controles de edad del Reino Unido se aplican desde julio de 2025, el Tribunal Supremo de EE. UU. confirmó la ley de Texas en junio de 2025 y la prohibición australiana para menores de 16 entró en vigor en diciembre de 2025, y cada uno comprueba a todos los adultos, no solo a los menores.
El daño que perdura es el cebo, no la molestia: un registro de verificación de edad es una identidad ya correlacionada (nombre, rostro, fecha de nacimiento, sitios a los que accediste) que, a diferencia de una contraseña, no se puede restablecer una vez filtrada, y las filtraciones ya han ocurrido.
Las personas vulnerables pagan primero: jóvenes LGTBQ en hogares hostiles, supervivientes de violencia doméstica y disidentes pierden el anonimato que es su seguridad, mientras los menores decididos encuentran los huecos de todos modos.
Ninguna herramienta devuelve el anonimato: una VPN vence solo los filtros por ubicación, Tor solo la geografía, y una prueba de conocimiento cero sigue requiriendo una verificación de identidad en la emisión: ajusta la táctica al método y acepta el riesgo residual.
Lo estructural vence a lo táctico: las defensas duraderas son elegir plataformas sin guardián y minimizar la identidad que acabas entregando, porque eso cambia el problema en vez de aplazarlo.

Preguntas frecuentes
#

¿La verificación de edad comprueba mi edad o mi identidad?
#

En la mayoría de los sistemas actuales, las dos cosas a la vez. Para confirmar que superas cierta edad, la subida de un documento o la estimación facial primero establece quién eres y luego deduce la edad a partir de ahí. Solo los métodos emergentes de conocimiento cero y a nivel de dispositivo buscan demostrar la edad sin retener la identidad, y aun esos dependen de una comprobación de identidad previa, cuando se emite por primera vez la credencial de edad. Trata cualquier sistema de subida de documento o de escaneo facial como verificación de identidad, porque es lo que es.

¿Puede una VPN saltarse la verificación de edad?
#

Solo frente a los filtros por ubicación, y solo por ahora. Una VPN cambia la región que un sitio detecta, así que puede sortear un bloqueo que funciona puramente por geografía. No hace nada contra una ley que te exige subir un documento o escanear tu cara, porque esas comprueban la identidad, no la ubicación, y varios regímenes migran deliberadamente hacia métodos basados en identidad precisamente para cerrar la vía de la VPN. Útil como parche a corto plazo; no como escudo fiable.

¿Por qué a una base de datos de verificación de edad se la llama «cebo»?
#

Porque concentra los datos personales más sensibles —documento oficial, datos biométricos, fecha de nacimiento y los servicios a los que accedió una persona— en un solo lugar, ya correlacionados e irresistibles para los atacantes. A diferencia de una contraseña filtrada, una huella facial o un documento filtrados no se pueden restablecer, así que cualquier filtración es permanente. Los investigadores de seguridad y las filtraciones de sistemas reales de control de edad ya han mostrado esta dinámica, y por eso quienes defienden la privacidad tratan cualquier base de datos así como un pasivo que, para empezar, no debería crearse.

¿Quién está más en riesgo por las leyes de verificación de edad?
#

Los usuarios vulnerables a los que las leyes dicen proteger. Los jóvenes LGTBQ en hogares hostiles pierden el acceso anónimo a una comunidad que los apoye; las supervivientes de violencia doméstica pierden el acceso sin vigilancia que necesitan para buscar ayuda; a disidentes y periodistas se les convierte un hábito de lectura en un registro. Para todos ellos, el anonimato es un mecanismo de seguridad, y los controles de edad atados a la identidad se lo quitan, mientras los menores decididos evaden esos mismos sistemas.

¿Hay una forma de demostrar mi edad que preserve la privacidad?
#

En parte. Las pruebas de edad de conocimiento cero y las señales de edad a nivel de dispositivo pueden afirmar «mayor de 18» sin revelar al sitio web tu nombre, tu documento ni tu fecha de nacimiento, y el plan de la UE apunta en esa dirección. Son una mejora real frente a la subida de documentos y el estándar que conviene exigir. El límite es que alguien sigue verificando tu identidad para emitir la credencial, así que el problema de confianza se mueve hacia arriba en vez de desaparecer. Es mejor, no resuelto, y muchísimo mejor que una base de datos centralizada de documentos y rostros.

#	Fuente	URL	Archivo
1	Gobierno del Reino Unido — Colección sobre la Online Safety Act	https://www.gov.uk/government/collections/online-safety-act	https://web.archive.org/web/*/https://www.gov.uk/government/collections/online-safety-act
2	Tribunal Supremo de EE. UU. — Free Speech Coalition contra Paxton (23-1122)	https://www.supremecourt.gov/opinions/24pdf/23-1122_3e04.pdf	https://web.archive.org/web/*/https://www.supremecourt.gov/opinions/24pdf/23-1122_3e04.pdf
3	Comisionada australiana de eSafety — Restricciones de edad en redes sociales	https://www.esafety.gov.au/about-us/industry-regulation/social-media-age-restrictions	https://web.archive.org/web/*/https://www.esafety.gov.au/about-us/industry-regulation/social-media-age-restrictions
4	Comisión Europea — Verificación de edad de la UE	https://digital-strategy.ec.europa.eu/en/policies/eu-age-verification	https://web.archive.org/web/*/https://digital-strategy.ec.europa.eu/en/policies/eu-age-verification
5	EFF — 10 peligros (no tan) ocultos de la verificación de edad	https://www.eff.org/deeplinks/2025/12/10-not-so-hidden-dangers-age-verification	https://web.archive.org/web/*/https://www.eff.org/deeplinks/2025/12/10-not-so-hidden-dangers-age-verification
6	EFF — El costo humano de la verificación de edad en línea	https://www.eff.org/deeplinks/2026/01/effecting-change-human-cost-online-age-verification	https://web.archive.org/web/*/https://www.eff.org/deeplinks/2026/01/effecting-change-human-cost-online-age-verification
7	Cybernews — Una filtración de Discord expone ~70.000 documentos oficiales de la verificación de edad	https://cybernews.com/news/discord-70000-gov-ids-exposed-zendesk-third-party-breach-scattered-spider/	https://web.archive.org/web/*/https://cybernews.com/news/discord-70000-gov-ids-exposed-zendesk-third-party-breach-scattered-spider/
8	Brave — Los límites de las pruebas de conocimiento cero para la verificación de edad	https://brave.com/blog/zkp-age-verification-limits/	https://web.archive.org/web/*/https://brave.com/blog/zkp-age-verification-limits/
9	Eric Hughes — Un manifiesto cypherpunk (1993)	https://www.activism.net/cypherpunk/manifesto.html	https://web.archive.org/web/*/https://www.activism.net/cypherpunk/manifesto.html
10	Tor Project — Texto plano sobre Tor sigue siendo texto plano	https://blog.torproject.org/plaintext-over-tor-still-plaintext/	https://web.archive.org/web/*/https://blog.torproject.org/plaintext-over-tor-still-plaintext/
11	EFF — A quién dañan los mandatos de verificación de edad	https://www.eff.org/pages/whos-harmed-age-verification-mandates	https://web.archive.org/web/*/https://www.eff.org/pages/whos-harmed-age-verification-mandates

Cora Aegis

Cora Aegis escribe en CypherpunkGuide guías de OPSEC centradas en la privacidad y lee las nuevas leyes de vigilancia buscando el mecanismo que la información periodística se salta: aquí, cómo un control de edad en la puerta se convierte en un registro de identidad permanente, y qué defensas aguantan de verdad.

Más sobre Cora →

OPSEC en la era de la IA: rehaz tu modelo de amenazas (2026)

Sun, 14 Jun 2026 00:00:00 +0000

Desde que existe la seguridad operacional —el OPSEC, la disciplina de proteger información pensando como piensa quien la quiere— ha descansado en una sola imagen del adversario: una persona. Un investigador con presupuesto. Un acosador con paciencia. Un reclutador, un agente de frontera, una expareja. Aprendiste a construir un modelo de amenazas —un mapa breve y honesto de qué proteges, quién lo quiere, qué puede hacer de verdad y cuánto te cuesta detenerlo— y luego pusiste tu esfuerzo donde ese mapa decía que importaba. Durante dos décadas de vida digital, ese mapa bastó.

Hoy se equivoca en cuatro puntos concretos, porque el adversario ya no es una persona, sino, cada vez más, una máquina. Una máquina no se cansa, no olvida, no necesita una orden judicial para leer lo que ya es público y no trabaja a escala humana. El cambio no es hipotético: en un resumen de Pew Research de marzo de 2026, el 50 % de los adultos estadounidenses dijo sentirse más preocupado que entusiasmado ante la expansión de la IA —frente al 37 % de 2021—, y una encuesta anterior de Pew a personas familiarizadas con la IA halló que el 81 % esperaba que su información personal se usara de maneras que les resultarían incómodas. La preocupación es razonable. En esta misma web vigilamos nuestros registros de servidor en busca de la docena larga de rastreadores de IA que se identifican como tales —GPTBot, ClaudeBot, PerplexityBot, Google-Extended y compañía— y llegan sin pausa, a su ritmo, no al nuestro.

Construimos el marco de cuatro premisas que sigue después de repasar la orientación sobre privacidad que ya existe, y descubrir que casi toda asegura sistemas de IA empresariales o se queda en una lista de herramientas de consumo, dejando sin escribir el modelo de amenazas del propio individuo.

¿Cómo rehaces, entonces, un modelo de amenazas cuando el adversario es una máquina? No buscando un botón de borrado: ninguno llega a los pesos entrenados de un modelo. Lo rehaces como reharías tu casa al descubrir que la cerradura ya no encaja en la puerta: premisa por premisa. Estas son las cuatro que la IA rompe, qué cambia cada una y dónde tu esfuerzo restante mueve de verdad tu exposición, en lugar de limitarse a tranquilizarte.

Las cuatro premisas — el OPSEC clásico suponía un adversario humano; el adversario-máquina las rompe las cuatro a la vez (correlación, inferencia, permanencia, identidad sintética); cada una tiene una palanca que aún funciona.

El OPSEC clásico suponía…	En cambio, el adversario-máquina…	Tu palanca real
Enlazar datos dispersos es lento y manual	Correlaciona millones de fragmentos al instante y casi gratis	Reduce lo vinculable entre contextos
Solo expones lo que eliges publicar	Infiere lo que no publicaste a partir de patrones	Gestiona la señal, no solo el enunciado
Borrar en la fuente elimina el dato	Ya absorbió copias en los pesos del modelo	Prevén al publicar; borrar es parcial
Falsificar tu identidad exige tu participación	Sintetiza tu voz, tu rostro y tu escritura	Acuerda confianza por adelantado; minimiza muestras

Premisa 1: la correlación ya no es lenta
#

La correlación a escala es la primera premisa que la IA rompe. Una máquina puede unir datos que por separado son inofensivos —un nombre de usuario reutilizado, la ubicación incrustada en una foto, el ritmo con que publicas— en un único perfil, más rápido y mucho más barato de lo que jamás pudo cualquier investigador humano. La protección de antes era la fricción: enlazar tus cuentas le tomaba horas a una persona, así que casi ningún adversario se molestaba. Esa fricción desapareció.

Correlación significa aquí conectar piezas sueltas de información hasta formar una sola imagen. El peligro nunca fue una publicación aislada; fue la unión. Tu cuenta profesional y la anónima comparten un giro de frase. Una foto de paisaje lleva coordenadas GPS en sus metadatos —los datos invisibles adheridos a un archivo, que registran dónde y cuándo se creó—. Una reseña de un envío, el resultado de una carrera, una lista pública de deseos: cada cosa es trivial por sí sola y, juntas, son un dosier. Las máquinas existen precisamente para encontrar esas uniones entre millones de registros a la vez.

Esto reformula una regla clásica. «No publiques nada sensible» siempre fue una verdad a medias, porque lo sensible suele ser emergente: aparece solo cuando los fragmentos se combinan. La disciplina que la reemplaza es la compartimentación (compartmentation): impedir a propósito que tus contextos compartan rasgos vinculables. Cada identidad lleva su propio nombre de usuario, su propio registro de escritura, sus propios dispositivos y redes donde haga falta; los metadatos se eliminan antes de que algo salga de tus manos. Cuando es el propio Estado el que te obliga a entregar los datos que luego se correlacionan, ese es un riesgo emparentado con su propio manual: Cuando el gobierno filtra tus datos.

Premisa 2: expones más de lo que publicas
#

La inferencia es la segunda premisa rota: un modelo puede deducir datos que nunca revelaste —tu ubicación probable, tu empleador, tu estado de salud, tus relaciones o tu orientación sexual— a partir de patrones en lo que sí publicaste. El modelo mental de antes era un libro de cuentas: tu exposición equivalía a la suma de lo que escribías. La inferencia convierte ese libro en una superficie, donde también habla el espacio en blanco.

El mecanismo es aprendizaje automático corriente. Con suficientes ejemplos, un modelo aprende que quienes escriben de cierta manera, siguen ciertas cuentas y publican a ciertas horas tienden a compartir rasgos, y te aplica ese patrón. No dijiste tu ciudad; los fondos de tus fotos, la hora de tus «buenos días» y la jerga local que repites la delatan. Por eso borrar con saña puede sentirse productivo y cambiar poco: quitar una publicación rara vez quita el patrón que sostiene la inferencia.

La palanca es gestionar la señal, no solo el enunciado. Varía o difumina los patrones que un adversario explotaría —horarios de publicación, fondos que revelan ubicación, la huella lingüística que ata dos identidades— y trata cualquier dato que revele relaciones y ubicación como el objetivo de mayor valor, porque son los que la inferencia agrava más rápido. Para casi todo el mundo, la meta realista no es derrotar a la inferencia, sino elevar su tasa de error lo suficiente para dejar de ser el perfil más barato de construir. Una disección más completa de cómo discurren estas cadenas de inferencia de principio a fin llega en otra entrega de esta serie.

Premisa 3: borrar ya no alcanza al dato
#

La permanencia es la tercera premisa que la IA rompe. Una vez que tu texto o tu imagen pública quedó absorbido en los datos de entrenamiento de un modelo, borrar el original no elimina lo que el modelo ya aprendió: no existe un «borrar» que llegue al interior de los pesos entrenados. La promesa de antes era la reversibilidad: un error podía despublicarse. Frente a un modelo, publicar se parece más a una puerta de un solo sentido.

Las publicaciones, descripciones e imágenes en abierto se recopilan en grandes conjuntos de datos a escala de la web —Common Crawl, el archivo de la internet pública con el que entrena la mayoría de los grandes laboratorios, es el más conocido— y sirven para entrenar modelos de lenguaje y de imagen. El campo de investigación del desaprendizaje automático (machine unlearning), que intenta hacer que un modelo entrenado olvide datos concretos, trata el problema como algo genuinamente difícil y sin resolver a escala; el único remedio confiable es reentrenar sin esos datos, algo que los dueños casi nunca hacen por una sola persona. Y la ingestión no es un borrón inofensivo: investigadores en seguridad ya demostraron que se pueden extraer fragmentos de los datos de entrenamiento desde los grandes modelos.

Esta es la dimensión donde la era de la IA se cruza de la forma más directa con el viejo problema de la web permanente, así que, en lugar de repetirlo, aquí está el relevo: el manual de auditoría completo de lo que sobrevive al borrado —respaldos, brokers, archivos web y los corpus de entrenamiento— vive en Tu huella digital no se borra. La consecuencia para tu modelo de amenazas es contundente: el momento de publicar pesa más que la limpieza. Como la ingestión es continua, el único control plenamente eficaz es no publicar lo sensible desde el principio. Toda defensa posterior es parcial, y ese solo hecho debería reordenar tus prioridades: menos herramientas de borrado y más atención a qué llegas a publicar.

Premisa 4: tu voz y tu rostro son ahora credenciales
#

La identidad sintética es la cuarta premisa rota: con una pequeña muestra de tu voz, tu rostro o tu escritura, un modelo genera falsificaciones convincentes, y los mismos rasgos biométricos que tomas como prueba de que «eres tú» se vuelven materia prima para suplantarte. La premisa de antes era que falsificar tu identidad exigía tu participación o tus secretos. Ahora solo exige los medios que ya publicaste.

Unos segundos de audio nítido bastan para clonar una voz; un puñado de fotos basta para una imagen sintética; un corpus de tus publicaciones basta para imitar tu escritura. Esto derriba una protección silenciosa en la que casi todos confiábamos sin notarlo: que una voz o un rostro conocidos se autenticaban solos. Y el riesgo no se reparte por igual. La suplantación, las imágenes íntimas fabricadas y el fraude por voz recaen de forma desproporcionada sobre las mujeres y sobre cualquiera con un acosador motivado, lo que convierte esta dimensión en una cuestión de soberanía sobre el propio cuerpo y la propia reputación, no en simple higiene de datos.

Aquí valen dos palancas. La primera es la minimización: limita el volumen y la nitidez de las muestras biométricas en bruto que publicas —menos clips de voz de alta fidelidad, menos fotos de rostro atadas a tu nombre legal—, asumiendo que esto mitiga, no cura. La segunda es la confianza acordada por adelantado: pacta de antemano y por un canal aparte —uno que un atacante no pueda interceptar— un paso de verificación con la gente que importa: una palabra compartida, un número al que devolver la llamada, un segundo canal, de modo que una voz clonada al teléfono no pueda fabricar urgencia. Un tratamiento dedicado de la voz y el rostro como credencial, con el protocolo de verificación familiar al completo, llega en esta serie.

Rehacer el modelo: una lista de cuatro dimensiones
#

Rehacer tu modelo de amenazas para la era de la IA consiste en volver a plantear las cuatro preguntas clásicas del OPSEC frente a un adversario-máquina y, luego, volver a decidir dónde tu esfuerzo cambia la exposición real. No tienes que defender cada dimensión por igual; tienes que hallar cuál es tu eslabón más débil y empezar por ahí. Al recorrer nosotros mismos este marco, la dimensión que más vemos subestimada es la inferencia: la gente cuida lo que dice y olvida que los patrones a su alrededor hablan igual de fuerte.

Pasa tu propia situación por las cuatro dimensiones, en orden aproximado de prioridad para alguien sin un adversario concreto:

Dimensión	Qué hace la máquina	Tu palanca	Por dónde empezar
Permanencia	Retiene lo que publicas dentro de los pesos del modelo	Publica menos; trata la versión pública como imborrable	Primero: es irreversible
Identidad sintética	Falsifica voz y rostro a partir de muestras pequeñas	Minimiza las muestras; acuerda verificación por canal aparte	Primero: alto daño personal
Correlación	Une fragmentos dispersos en un perfil, barato	Compartimenta: nombres de usuario, dispositivos y metadatos separados	Después
Inferencia	Deduce lo que no publicaste a partir de tus patrones	Gestiona la señal: difumina ubicación, rutina y vínculos	Continuo

Ordénalas contra tu propia vida, no contra esta tabla: la idea es hallar tu eslabón más débil y actuar ahí primero, no defender las cuatro por igual.

Una nota sobre dónde no conviene invertir de más: la regulación. La AI Act de la UE empieza a aplicar la mayoría de sus disposiciones el 2 de agosto de 2026, pero sus obligaciones más exigentes para los sistemas de alto riesgo se aplazaron —bajo el acuerdo «Digital Omnibus» de mayo de 2026— hasta diciembre de 2027 y agosto de 2028. Los reguladores de protección de datos se están implicando en serio; el Dictamen 28/2024 del Comité Europeo de Protección de Datos (EDPB), adoptado el 18 de diciembre de 2024, fijó cómo se aplican los principios del GDPR a los modelos de IA, incluido cuándo un modelo puede considerarse anónimo y qué arriesgan los modelos entrenados de forma ilícita. Es una frontera viva que vale la pena seguir, y una mala cosa en la que apoyarse. Tu modelo de amenazas tiene que aguantar en los años que faltan para que la ley llegue, y por eso mismo tiene que ser tuyo.

«La privacidad es necesaria para una sociedad abierta en la era electrónica. … No podemos esperar que los gobiernos, las empresas u otras organizaciones grandes y sin rostro nos concedan privacidad por su benevolencia.» — Eric Hughes, Un manifiesto cypherpunk, 1993

Esa frase se escribió sobre la criptografía y el correo electrónico. Hoy se lee como una descripción del adversario-máquina: cambiaron las herramientas, no el principio. Construyes el modelo porque nadie lo construye por ti. Después pones tu esfuerzo donde mueve tu exposición real, y mantienes cerca el resto del pilar de Privacidad, porque cada dimensión de aquí tiene su propio mapa más a fondo.

Conclusión: ¿cuál es tu eslabón más débil?
#

El nivel correcto de OPSEC para la era de la IA es el que encaja con tu modelo de amenazas, y cuál es tu eslabón más débil depende por entero de quién te protege.

Si eres un usuario general sin un adversario concreto: las jugadas de mayor palanca son la permanencia y la identidad sintética: adopta una pausa antes de publicar y recorta tus muestras de voz y rostro más identificables. Deja el resto hasta que tengas un motivo.
Si mantienes identidades separadas —una creadora seudónima, un activista, cualquiera cuyos contextos no deban conectarse—: la correlación es tu primera línea. Compartimenta sin concesiones; un solo nombre de usuario reutilizado puede deshacer todo lo demás.
Si cargas con un riesgo asimétrico —mujeres que enfrentan acoso, sobrevivientes, profesionales de cara al público—: prioriza la identidad sintética y la inferencia, y trata el protocolo de verificación por canal aparte como innegociable.

En las cuatro dimensiones rige la misma verdad que regía en la era del adversario humano: después del hecho, ningún borrado te devuelve la seguridad de forma confiable. Solo puedes modelar al adversario que de verdad tienes, decidir con intención y publicar menos de aquello que no querrías que una máquina conservara.

Puntos clave

El OPSEC de la era de la IA es modelar amenazas frente a un adversario-máquina —uno que correlaciona, infiere, recuerda y sintetiza—, no solo frente a uno humano.
Correlación: una máquina une fragmentos inofensivos por separado (un alias reutilizado, los metadatos GPS de una foto, el ritmo al publicar) en un único perfil; la palanca es la compartimentación, no el silencio.
Inferencia: los modelos deducen lo que no publicaste —ubicación, relaciones, empleador— a partir de patrones, así que borrar una publicación rara vez quita el patrón que te expone.
Permanencia: una vez absorbido en los datos de entrenamiento, el contenido sobrevive en los pesos del modelo; el machine unlearning sigue sin resolverse a escala, así que el momento de publicar pesa más que la limpieza.
Identidad sintética: segundos de voz o unas pocas fotos bastan para falsificaciones convincentes —un riesgo con sesgo de género—, así que minimiza las muestras en bruto y acuerda verificación por canal aparte.
No esperes a la ley: las obligaciones de alto riesgo de la AI Act de la UE se aplazaron a 2027-2028; tu modelo de amenazas tiene que aguantar mientras tanto.

Preguntas frecuentes
#

¿Qué es el OPSEC de la era de la IA? Es la seguridad operacional rehecha para un adversario-máquina. El OPSEC clásico modelaba a un investigador humano con tiempo finito; el de la era de la IA modela un sistema que correlaciona datos a escala, infiere lo que nunca publicaste, retiene lo que publicas dentro de los pesos del modelo y puede sintetizar tu voz y tu rostro. En la práctica significa volver a plantear las preguntas estándar del modelo de amenazas —qué proteges, quién lo quiere, qué puede hacer— frente a esas cuatro capacidades.

¿De verdad la IA puede desanonimizarme a partir de datos «anónimos»? A menudo, sí. El anonimato por omisión —dejar tu nombre fuera de una publicación— es débil ante la inferencia y la correlación, porque un modelo puede reidentificarte a partir de patrones y de uniones entre conjuntos de datos separados. La verdadera imposibilidad de vincularte viene de la compartimentación (nombres de usuario, dispositivos y redes separados, y metadatos eliminados), no de callar tu nombre.

¿Sirve de algo excluirme del entrenamiento de IA? En parte, y sobre todo de cara al futuro. Las exclusiones y las señales de «no entrenar» pueden reducir la ingestión futura allí donde las plataformas las respetan, pero no alcanzan los datos ya absorbidos en modelos entrenados, y el machine unlearning sigue sin resolverse a escala. Trata la exclusión como un control de prevención más entre varios, no como un botón de borrado.

¿Me protegerá la AI Act de la UE como individuo? No pronto, y no como sustituto de tu propio modelo de amenazas. La mayoría de las disposiciones de la ley se aplican desde agosto de 2026, pero sus obligaciones de alto riesgo más estrictas se aplazaron a diciembre de 2027 y agosto de 2028 bajo el acuerdo Digital Omnibus de mayo de 2026. La regulación es un respaldo lento y desigual; los controles de este artículo son lo que sostienes mientras tanto.

Referencias
#

#	Fuente	URL	Copia archivada
1	Pew Research Center — «What the data says about Americans’ views of AI» (mar 2026)	https://www.pewresearch.org/short-reads/2026/03/12/key-findings-about-how-americans-view-artificial-intelligence/	https://web.archive.org/web/*/https://www.pewresearch.org/short-reads/2026/03/12/key-findings-about-how-americans-view-artificial-intelligence/
2	Pew Research Center — «How Americans View Data Privacy» (oct 2023)	https://www.pewresearch.org/internet/2023/10/18/how-americans-view-data-privacy/	https://web.archive.org/web/*/https://www.pewresearch.org/internet/2023/10/18/how-americans-view-data-privacy/
3	AI Act de la UE — Calendario de aplicación	https://artificialintelligenceact.eu/implementation-timeline/	https://web.archive.org/web/*/https://artificialintelligenceact.eu/implementation-timeline/
4	EDPB — Dictamen 28/2024 sobre modelos de IA y el GDPR (18 dic 2024)	https://www.edpb.europa.eu/news/news/2024/edpb-opinion-ai-models-gdpr-principles-support-responsible-ai_en	https://web.archive.org/web/*/https://www.edpb.europa.eu/news/news/2024/edpb-opinion-ai-models-gdpr-principles-support-responsible-ai_en
5	Carlini et al. — «Extracting Training Data from Large Language Models» (USENIX Security 2021)	https://arxiv.org/abs/2012.07805	https://web.archive.org/web/*/https://arxiv.org/abs/2012.07805

Claude (Anthropic) — hechos de identidad y tratamiento de datos

Tue, 14 Jul 2026 00:00:00 +0000

Divulgaciones: naturaleza de esta página · afiliaciones · correcciones

Esta página es un registro factual — no es consejo, ni recomendación, ni invitación, ni aval. La inclusión no es aprobación. Las políticas cambian; consulta los documentos primarios del proveedor antes de apoyarte en cualquier valor.
Actualmente no tenemos ninguna relación de afiliación con los servicios listados. Si eso cambiara, lo divulgaríamos en el propio texto, no afectaría a qué se lista ni en qué orden, y el cambio quedaría registrado aquí.
¿Eres un proveedor listado y crees que un valor es erróneo? Si nuestra revisión confirma el error, lo corregimos y publicamos la corrección — escribe a editor@cypherpunkguide.com
Cómo se recogen y comprueban estos datos (metodología)

Estado del registro piloto

Nombres: Claude · Claude.ai
Proveedor: Anthropic (proveedor de chat directo)
Dimensiones con registros: 8 de 17 dimensiones tienen al menos un registro con ámbito definido
Origen de las afirmaciones: 8 declaradas por el proveedor · 0 observadas en la interfaz

Sin registro vigente con ámbito definido en este piloto:

Identificadores de registro
Pago e identidad de facturación
Envío de consultas a proveedores posteriores
Revisión humana de chats
Retención
Controles de privacidad opcionales
Jurisdicción del responsable del tratamiento
Analítica de terceros en el sitio
Metadatos recopilados (IP, etc.)

Cuenta obligatoria

condicional

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: obligatoria
Método de verificación de la cuenta: confirmación por correo
Condición de activación: pasar a un plan de pago
Vinculación: tu cuenta
Receptor: Anthropic (Claude)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/API
Primera incorporación a KYC Drift: 2026-07-13

To access our Services, we may ask you to create an Account.

— copia archivada · capturado 2026-07-13

you must sign up for a subscription with us (a “ Subscription ”), first by creating an Account

— copia archivada · capturado 2026-07-13

Métodos de acceso (SSO/cartera)

inicio de sesión único de Google (SSO) o enlace de acceso por correo

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Vinculación: tu cuenta · tercero
Receptor: Anthropic (Claude) · Google
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/escritorio/móvil
Fecha del documento: 2026-05-19 (el documento indica la última actualización)
Primera incorporación a KYC Drift: 2026-07-13

you will see two different options for logging in to your Claude account. Continue with Google ... Continue with email

— copia archivada · capturado 2026-07-10

Teléfono al registrarse

obligatorio

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: obligatoria
Método de verificación de la cuenta: código único por SMS
Restricciones: números VoIP rechazados · Google Voice rechazado · números generados por apps rechazados · líneas fijas rechazadas · solo ubicaciones admitidas · una cuenta por número
Vinculación: tu cuenta
Receptor: Anthropic (Claude)
Se aplica a: Región: ubicaciones admitidas · Plan: gratuito/de pago · Plataforma: web/escritorio/móvil · Vía de registro: Google SSO/correo
Fecha del documento: 2026-05-19 (el documento indica la última actualización)
Primera incorporación a KYC Drift: 2026-07-13

We require phone verification for all new users, and there isn't a way to skip this step.

— copia archivada · capturado 2026-07-13

you'll be asked to enter your phone number from a supported location to receive a verification code via text message

— copia archivada · capturado 2026-07-13

you cannot use VoIP numbers, Google Voice, phone numbers created using apps, landlines, or other numbers that can't receive texts to verify your account.

— copia archivada · capturado 2026-07-13

Correo al registrarse

condicional

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: puede recoger (redacción de la política)
Condición de activación: elegir la vía de registro por correo (la alternativa es Google SSO)
Vinculación: tu cuenta
Receptor: Anthropic (Claude)
Se aplica a: Región: ubicaciones admitidas · Plan: gratuito/de pago · Plataforma: web/API
Primera incorporación a KYC Drift: 2026-07-13

Anthropic collects identifiers, including your name, email address, and phone number when you sign up for an Anthropic account

— copia archivada · capturado 2026-07-13

Edad mínima

18+

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Vinculación: tu cuenta
Receptor: Anthropic (Claude)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/API
Primera incorporación a KYC Drift: 2026-07-13

You must be at least 18 years old or the minimum age required to consent to use the Services in your location, whichever is higher.

— copia archivada · capturado 2026-07-13

Uso continuado

Verificación posterior de identidad o teléfono

condicional

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: puede recoger (redacción de la política)
Método de verificación de la cuenta: documento oficial o prueba de edad
Condición de activación: a discreción del proveedor ('en determinadas circunstancias')
Vinculación: tu cuenta
Receptor: Anthropic (Claude)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/API
Primera incorporación a KYC Drift: 2026-07-13

Verification Data: In certain circumstances, we may ask you to verify your age or identity.

— copia archivada · capturado 2026-07-13

Uso de entradas para entrenar

activado por defecto; opción de exclusión disponible

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: obligatoria
Vinculación: tu cuenta
Receptor: Anthropic (Claude)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-13

We may use your Inputs and Outputs to train and improve Anthropic AI models, unless you opt out through your account settings.

— copia archivada · capturado 2026-07-13

Eliminación

Eliminación y reutilización de identificadores

disponible

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Vinculación: tu cuenta
Receptor: Anthropic (Claude)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-13

You also are able to delete individual conversations, which will be removed immediately from your conversation history and automatically deleted from our back-end within 30 days.

— copia archivada · capturado 2026-07-13

Evidencia

La tabla distingue la captura que sustentó inicialmente la afirmación de la revisión más reciente del mismo historial inmutable de evidencias. El SHA-256 del documento identifica el texto conservado; la huella de una ejecución controlada de la interfaz identifica una prueba revisada y sin datos sensibles. Estas huellas permiten detectar cambios, pero no demuestran por sí solas cuándo se obtuvieron los datos.

Función de la evidencia	Fuente	Archivo o resultado	Captura u observación	registro / comprobación	sha256
captura inicial · última revisión	https://www.anthropic.com/legal/consumer-terms	copia archivada	2026-07-13	2026-07-13	`731724432cfff0c19f2b8a2da4610f0107442a100d35c405a2d88ff4bcff1070`
captura inicial · última revisión	https://support.claude.com/en/articles/13189465-log-in-to-your-claude-account	copia archivada	2026-07-10	2026-07-13	`2493243a906bbc42a13cb20a5767449b03f2a9462cdeb5eecb8532269f8059cb`
captura inicial · última revisión	https://support.claude.com/en/articles/8287232-verify-your-phone-number	copia archivada	2026-07-13	2026-07-13	`c789de708f21e72e768e9eda79de4bd3374e6dca0690b6ccf91148f93f48177c`
captura inicial · última revisión	https://www.anthropic.com/legal/privacy	copia archivada	2026-07-13	2026-07-13	`a2fdc63d6bb693e172a803a2da85dbad2619d4022265cdb2cb0f2f2afb476168`

DeepSeek — hechos de identidad y tratamiento de datos

Tue, 14 Jul 2026 00:00:00 +0000

Divulgaciones: naturaleza de esta página · afiliaciones · correcciones

Esta página es un registro factual — no es consejo, ni recomendación, ni invitación, ni aval. La inclusión no es aprobación. Las políticas cambian; consulta los documentos primarios del proveedor antes de apoyarte en cualquier valor.
Actualmente no tenemos ninguna relación de afiliación con los servicios listados. Si eso cambiara, lo divulgaríamos en el propio texto, no afectaría a qué se lista ni en qué orden, y el cambio quedaría registrado aquí.
¿Eres un proveedor listado y crees que un valor es erróneo? Si nuestra revisión confirma el error, lo corregimos y publicamos la corrección — escribe a editor@cypherpunkguide.com
Cómo se recogen y comprueban estos datos (metodología)

Estado del registro piloto

Nombres: DeepSeek · DeepSeek Chat
Proveedor: DeepSeek (proveedor de chat directo)
Dimensiones con registros: 6 de 17 dimensiones tienen al menos un registro con ámbito definido
Origen de las afirmaciones: 4 declaradas por el proveedor · 0 observadas en la interfaz

Sin registro vigente con ámbito definido en este piloto:

Cuenta obligatoria
Métodos de acceso (SSO/cartera)
Edad mínima
Verificación posterior de identidad o teléfono
Pago e identidad de facturación
Envío de consultas a proveedores posteriores
Revisión humana de chats
Retención
Controles de privacidad opcionales
Analítica de terceros en el sitio
Metadatos recopilados (IP, etc.)

Identificadores de registro

correo o teléfono

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: obligatoria
Método de verificación de la cuenta: varía según la vía
Vinculación: tu cuenta
Receptor: DeepSeek (China)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-14

We collect Personal Data that you provide when you set up an account, such as your date of birth (where applicable), username (where applicable), email address and/or telephone number, and password.

— copia archivada · capturado 2026-07-14

Uso continuado

Jurisdicción del responsable del tratamiento

China (CN)

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Vinculación: tu cuenta · perfil de la empresa matriz
Receptor: DeepSeek (China)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-14

The Services are provided and controlled by Hangzhou DeepSeek Artificial Intelligence Co., Ltd., with its registered address in China (“we” or “us”).

— copia archivada · capturado 2026-07-14

Uso de entradas para entrenar

activado por defecto; no se declara una opción de exclusión

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: obligatoria
Vinculación: tu cuenta
Receptor: DeepSeek (China)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-14

To improve and develop the Services and to train and improve our technology, such as our machine learning models and algorithms.

— copia archivada · capturado 2026-07-14

Eliminación

Eliminación y reutilización de identificadores

disponible

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Vinculación: tu cuenta
Receptor: DeepSeek (China)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-14

you may also copy or delete your chat history via your settings.

— copia archivada · capturado 2026-07-14

Evidencia

Función de la evidencia	Fuente	Archivo o resultado	Captura u observación	registro / comprobación	sha256
captura inicial · última revisión	https://cdn.deepseek.com/policies/en-US/deepseek-privacy-policy.html	copia archivada	2026-07-14	2026-07-14	`339984e36a795843ee2b5b917797072ec249f3c0e9ff7cbbfe754c01caa4f069`

Gemini (Google) — hechos de identidad y tratamiento de datos

Tue, 14 Jul 2026 00:00:00 +0000

Divulgaciones: naturaleza de esta página · afiliaciones · correcciones

Esta página es un registro factual — no es consejo, ni recomendación, ni invitación, ni aval. La inclusión no es aprobación. Las políticas cambian; consulta los documentos primarios del proveedor antes de apoyarte en cualquier valor.
Actualmente no tenemos ninguna relación de afiliación con los servicios listados. Si eso cambiara, lo divulgaríamos en el propio texto, no afectaría a qué se lista ni en qué orden, y el cambio quedaría registrado aquí.
¿Eres un proveedor listado y crees que un valor es erróneo? Si nuestra revisión confirma el error, lo corregimos y publicamos la corrección — escribe a editor@cypherpunkguide.com
Cómo se recogen y comprueban estos datos (metodología)

Estado del registro piloto

Nombres: Gemini · Google Gemini
Proveedor: Google (proveedor de chat directo)
Dimensiones con registros: 6 de 17 dimensiones tienen al menos un registro con ámbito definido
Origen de las afirmaciones: 6 declaradas por el proveedor · 0 observadas en la interfaz

Sin registro vigente con ámbito definido en este piloto:

Teléfono al registrarse
Correo al registrarse
Métodos de acceso (SSO/cartera)
Edad mínima
Verificación posterior de identidad o teléfono
Pago e identidad de facturación
Envío de consultas a proveedores posteriores
Uso de entradas para entrenar
Eliminación y reutilización de identificadores
Jurisdicción del responsable del tratamiento
Analítica de terceros en el sitio

Cuenta obligatoria

condicional

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: obligatoria
Método de verificación de la cuenta: contraseña
Condición de activación: uso con sesión iniciada
Vinculación: tu cuenta · perfil de la empresa matriz
Receptor: Google
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/aplicación
Fecha del documento: 2026-06-29 (el documento indica la última actualización)
Primera incorporación a KYC Drift: 2026-07-13

When you're signed in, we also collect information that we store with your Google Account, which we treat as personal information.

— copia archivada · capturado 2026-07-13

When you use Gemini Apps while signed out, Google processes your data (like your IP address and browser type) per the Google Privacy Policy .

— copia archivada · capturado 2026-07-13

Identificadores de registro

obligatorio

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: obligatoria
Vinculación: tu cuenta · perfil de la empresa matriz
Receptor: Google
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/aplicación
Primera incorporación a KYC Drift: 2026-07-13

When you create a Google Account, you provide us with personal information that includes your name and a password.

— copia archivada · capturado 2026-07-13

Uso continuado

Revisión humana de chats

sí

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: obligatoria
Vinculación: tu cuenta · tercero
Receptor: Google · proveedores de servicios
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/aplicación
Fecha del documento: 2026-06-29 (el documento indica la última actualización)
Primera incorporación a KYC Drift: 2026-07-13

Human reviewers (including trained reviewers from our service providers) review some of the data we collect for these purposes.

— copia archivada · capturado 2026-07-13

Controles de privacidad opcionales

disponible

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Vinculación: tu cuenta
Receptor: Google
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/aplicación
Fecha del documento: 2026-06-29 (el documento indica la última actualización)
Primera incorporación a KYC Drift: 2026-07-13

You can also use temporary chats, which are not used to improve Google AI with help from human reviewers.

— copia archivada · capturado 2026-07-13

Metadatos recopilados (IP, etc.)

se recoge

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: recogida automática
Vinculación: tu cuenta · dispositivo
Receptor: Google
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/aplicación
Fecha del documento: 2026-06-29 (el documento indica la última actualización)
Primera incorporación a KYC Drift: 2026-07-13

Location information: the general area from your device, IP address, or Home or Work addresses in your Google Account.

— copia archivada · capturado 2026-07-13

Eliminación

Retención

hasta 3 años

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Condición de activación: conversación seleccionada para revisión humana
Vinculación: tu cuenta
Receptor: Google
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/aplicación
Fecha del documento: 2026-06-29 (el documento indica la última actualización)
Primera incorporación a KYC Drift: 2026-07-13

Instead, they are retained for up to three years.

— copia archivada · capturado 2026-07-13

Evidencia

Función de la evidencia	Fuente	Archivo o resultado	Captura u observación	registro / comprobación	sha256
captura inicial · última revisión	https://policies.google.com/privacy	copia archivada	2026-07-13	2026-07-13	`35a5f8416bb2ab8ddfe15523696989dc57cb1763050e00d3df2cb4c822da262f`
captura inicial · última revisión	https://support.google.com/gemini/answer/13594961	copia archivada	2026-07-13	2026-07-13	`df5172a0969cda86258428f0bc7b82af2ba267ca1b895225185a03616e592b9a`

Le Chat (Mistral AI) — hechos de identidad y tratamiento de datos

Tue, 14 Jul 2026 00:00:00 +0000

Divulgaciones: naturaleza de esta página · afiliaciones · correcciones

Esta página es un registro factual — no es consejo, ni recomendación, ni invitación, ni aval. La inclusión no es aprobación. Las políticas cambian; consulta los documentos primarios del proveedor antes de apoyarte en cualquier valor.
Actualmente no tenemos ninguna relación de afiliación con los servicios listados. Si eso cambiara, lo divulgaríamos en el propio texto, no afectaría a qué se lista ni en qué orden, y el cambio quedaría registrado aquí.
¿Eres un proveedor listado y crees que un valor es erróneo? Si nuestra revisión confirma el error, lo corregimos y publicamos la corrección — escribe a editor@cypherpunkguide.com
Cómo se recogen y comprueban estos datos (metodología)

Estado del registro piloto

Nombres: Le Chat · Mistral
Proveedor: Mistral AI (proveedor de chat directo)
Dimensiones con registros: 9 de 17 dimensiones tienen al menos un registro con ámbito definido
Origen de las afirmaciones: 9 declaradas por el proveedor · 0 observadas en la interfaz

Sin registro vigente con ámbito definido en este piloto:

Identificadores de registro
Métodos de acceso (SSO/cartera)
Verificación posterior de identidad o teléfono
Pago e identidad de facturación
Envío de consultas a proveedores posteriores
Revisión humana de chats
Analítica de terceros en el sitio
Metadatos recopilados (IP, etc.)

Cuenta obligatoria

condicional

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: obligatoria
Condición de activación: según el producto (algunos productos requieren cuenta)
Vinculación: tu cuenta
Receptor: Mistral AI (Francia)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/aplicación
Fecha de efecto: 2026-05-28 (el documento indica la entrada en vigor)
Primera incorporación a KYC Drift: 2026-07-14

Some Mistral AI Products require a Mistral AI account.

— copia archivada · capturado 2026-07-14

Correo al registrarse

se recoge

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: se recoge
Vinculación: tu cuenta
Receptor: Mistral AI (Francia)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/aplicación
Fecha de efecto: 2026-04-08 (el documento indica la entrada en vigor)
Primera incorporación a KYC Drift: 2026-07-14

Contact Data, such as your email address.

— copia archivada · capturado 2026-07-14

When you create your Mistral AI Account and subscribe to a Mistral AI Product.

— copia archivada · capturado 2026-07-14

Teléfono al registrarse

se recoge si lo aportas

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: puede recoger (redacción de la política)
Vinculación: tu cuenta
Receptor: Mistral AI (Francia)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/aplicación
Fecha de efecto: 2026-04-08 (el documento indica la entrada en vigor)
Primera incorporación a KYC Drift: 2026-07-14

Account Data (such as the phone number or email address you provided to verify or change your account password, etc.):

— copia archivada · capturado 2026-07-14

Edad mínima

13+

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Vinculación: tu cuenta
Receptor: Mistral AI (Francia)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/aplicación
Fecha de efecto: 2026-05-28 (el documento indica la entrada en vigor)
Primera incorporación a KYC Drift: 2026-07-14

You must be at least thirteen (13) years old to use the Mistral AI Products

— copia archivada · capturado 2026-07-14

Uso continuado

Jurisdicción del responsable del tratamiento

Francia (FR)

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Vinculación: tu cuenta · perfil de la empresa matriz
Receptor: Mistral AI (Francia)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/aplicación
Fecha de efecto: 2026-04-08 (el documento indica la entrada en vigor)
Primera incorporación a KYC Drift: 2026-07-14

Mistral AI is a French company incorporated in Paris, under number 952 418 325, having its registered offices at 15 rue des Halles, 75001 Paris

— copia archivada · capturado 2026-07-14

Mistral AI is the data controller.

— copia archivada · capturado 2026-07-14

Uso de entradas para entrenar

activado por defecto; opción de exclusión disponible

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: obligatoria
Vinculación: tu cuenta
Receptor: Mistral AI (Francia)
Se aplica a: Región: global por defecto · Plan: gratuito · Plataforma: web/aplicación
Fecha de efecto: 2026-05-28 (el documento indica la entrada en vigor)
Primera incorporación a KYC Drift: 2026-07-14

We do not use Your Data to train our artificial intelligence models except (a) when you (i) use Mistral AI Products under a free subscription, or are subscribed to Vibe Pro or Vibe Student, and (ii) you have not opted-out of training,

— copia archivada · capturado 2026-07-14

We’ve introduced a user control which allows you to object to the use of your input and output data for model training directly from your account.

— copia archivada · capturado 2026-07-14

Please note that we do not use your Input and Output to train our artificial intelligence models when you use Le Chat Enterprise or the paid version of our APIs.

— copia archivada · capturado 2026-07-14

Retención

hasta que lo borres

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Vinculación: tu cuenta
Receptor: Mistral AI (Francia)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/aplicación
Fecha de efecto: 2026-04-08 (el documento indica la entrada en vigor)
Primera incorporación a KYC Drift: 2026-07-14

we keep your Input and Output until you delete your account or until you delete the conversation from Le Chat.

— copia archivada · capturado 2026-07-14

Controles de privacidad opcionales

disponible

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Vinculación: tu cuenta
Receptor: Mistral AI (Francia)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/aplicación
Fecha de efecto: 2026-04-08 (el documento indica la entrada en vigor)
Primera incorporación a KYC Drift: 2026-07-14

Turn off Memories at all times through your settings.

— copia archivada · capturado 2026-07-14

Eliminación

Eliminación y reutilización de identificadores

disponible

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Vinculación: tu cuenta
Receptor: Mistral AI (Francia)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/aplicación
Fecha de efecto: 2026-04-08 (el documento indica la entrada en vigor)
Primera incorporación a KYC Drift: 2026-07-14

for 1 year after you delete your account.

— copia archivada · capturado 2026-07-14

Your Civil Identity Data (your first and last name, etc.): for 5 years after the termination of your Mistral AI account.

— copia archivada · capturado 2026-07-14

Evidencia

Función de la evidencia	Fuente	Archivo o resultado	Captura u observación	registro / comprobación	sha256
captura inicial · última revisión	https://legal.mistral.ai/terms/privacy-policy	copia archivada	2026-07-14	2026-07-14	`a8406676deefa30f582c624c559d97645502eca7f1d9b4ac6d0db755510a55ab`
captura inicial · última revisión	https://legal.mistral.ai/terms/eu-consumers-terms-of-service	copia archivada	2026-07-14	2026-07-14	`b01bd5bb70e7199f54dc6f6f9365b3bef8c26b55f4e1d2355e1de1dc87d336a9`

ChatGPT (OpenAI) — hechos de identidad y tratamiento de datos

Tue, 14 Jul 2026 00:00:00 +0000

Divulgaciones: naturaleza de esta página · afiliaciones · correcciones

Esta página es un registro factual — no es consejo, ni recomendación, ni invitación, ni aval. La inclusión no es aprobación. Las políticas cambian; consulta los documentos primarios del proveedor antes de apoyarte en cualquier valor.
Actualmente no tenemos ninguna relación de afiliación con los servicios listados. Si eso cambiara, lo divulgaríamos en el propio texto, no afectaría a qué se lista ni en qué orden, y el cambio quedaría registrado aquí.
¿Eres un proveedor listado y crees que un valor es erróneo? Si nuestra revisión confirma el error, lo corregimos y publicamos la corrección — escribe a editor@cypherpunkguide.com
Cómo se recogen y comprueban estos datos (metodología)

Estado del registro piloto

Nombres: ChatGPT
Proveedor: OpenAI (proveedor de chat directo)
Dimensiones con registros: 3 de 17 dimensiones tienen al menos un registro con ámbito definido
Origen de las afirmaciones: 4 declaradas por el proveedor · 0 observadas en la interfaz

Sin registro vigente con ámbito definido en este piloto:

Cuenta obligatoria
Identificadores de registro
Teléfono al registrarse
Correo al registrarse
Métodos de acceso (SSO/cartera)
Edad mínima
Verificación posterior de identidad o teléfono
Envío de consultas a proveedores posteriores
Revisión humana de chats
Retención
Controles de privacidad opcionales
Jurisdicción del responsable del tratamiento
Analítica de terceros en el sitio
Metadatos recopilados (IP, etc.)

Uso continuado

Uso de entradas para entrenar

activado por defecto; opción de exclusión disponible

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: obligatoria
Vinculación: tu cuenta
Receptor: OpenAI (ChatGPT)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-13

we may use Content you provide us to improve our Services, for example to train the models that power ChatGPT.

— copia archivada · capturado 2026-07-11

Read our instructions on how you can opt out of our use of your Content to train our models.

— copia archivada · capturado 2026-07-11

Pago

Pago e identidad de facturación

obligatorio

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: obligatoria
Método de verificación de la cuenta: confirmación por correo
Condición de activación: pasar a un plan de pago
Vinculación: tu cuenta · identidad de facturación
Receptor: OpenAI (ChatGPT)
Se aplica a: Región: global por defecto · Plan: de pago · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-13

To upgrade to Plus/Pro/Teams, a user will still be required to verify an email.

— copia archivada · capturado 2026-07-13

Eliminación

Eliminación y reutilización de identificadores

reutilizable tras el borrado

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Vinculación: tu cuenta
Receptor: OpenAI (ChatGPT)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-13

With some exceptions, we do allow consumers who have deleted their ChatGPT account to re-register using the same phone number.

— copia archivada · capturado 2026-07-13

Eliminación y reutilización de identificadores

disponible

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Vinculación: tu cuenta
Receptor: OpenAI (ChatGPT)
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-13

Once you choose to delete Personal Data, we will remove it from our systems within 30 days

— copia archivada · capturado 2026-07-11

Evidencia

Función de la evidencia	Fuente	Archivo o resultado	Captura u observación	registro / comprobación	sha256
captura inicial · última revisión	https://help.openai.com/en/articles/10388702-phone-only-signups	copia archivada	2026-07-13	2026-07-13	`cd6eac339eb7e485a952b5c50c5c63209b6f440c12ff0ed24e1cb48b24862ceb`
captura inicial · última revisión	https://openai.com/policies/row-privacy-policy/	copia archivada	2026-07-11	2026-07-13	`8f30b38251d856ce871031eb507aaa551f632c47ee1579c773a1ca50505721ca`

OpenRouter — hechos de identidad y tratamiento de datos

Tue, 14 Jul 2026 00:00:00 +0000

Divulgaciones: naturaleza de esta página · afiliaciones · correcciones

Esta página es un registro factual — no es consejo, ni recomendación, ni invitación, ni aval. La inclusión no es aprobación. Las políticas cambian; consulta los documentos primarios del proveedor antes de apoyarte en cualquier valor.
Actualmente no tenemos ninguna relación de afiliación con los servicios listados. Si eso cambiara, lo divulgaríamos en el propio texto, no afectaría a qué se lista ni en qué orden, y el cambio quedaría registrado aquí.
¿Eres un proveedor listado y crees que un valor es erróneo? Si nuestra revisión confirma el error, lo corregimos y publicamos la corrección — escribe a editor@cypherpunkguide.com
Cómo se recogen y comprueban estos datos (metodología)

Estado del registro piloto

Nombres: OpenRouter
Proveedor: OpenRouter (router / agregador)
Dimensiones con registros: 6 de 17 dimensiones tienen al menos un registro con ámbito definido
Origen de las afirmaciones: 6 declaradas por el proveedor · 0 observadas en la interfaz

Sin registro vigente con ámbito definido en este piloto:

Identificadores de registro
Teléfono al registrarse
Métodos de acceso (SSO/cartera)
Edad mínima
Verificación posterior de identidad o teléfono
Revisión humana de chats
Retención
Eliminación y reutilización de identificadores
Controles de privacidad opcionales
Jurisdicción del responsable del tratamiento
Metadatos recopilados (IP, etc.)

Cuenta obligatoria

obligatorio

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: obligatoria
Método de verificación de la cuenta: contraseña
Vinculación: tu cuenta · plataforma de autenticación de terceros
Receptor: OpenRouter · plataforma de autenticación
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/API
Primera incorporación a KYC Drift: 2026-07-13

To access most features of the Service, you must register for an account.

— copia archivada · capturado 2026-07-13

Correo al registrarse

condicional

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: puede recoger (redacción de la política)
Vinculación: tu cuenta · plataforma de autenticación de terceros
Receptor: OpenRouter · plataforma de autenticación
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/API
Primera incorporación a KYC Drift: 2026-07-13

you may be required to provide us or our authentication platform with some information about yourself, such as your email address or other contact information.

— copia archivada · capturado 2026-07-13

Uso continuado

Envío de consultas a proveedores posteriores

enviado a un proveedor de modelos posterior

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: obligatoria
Vinculación: proveedor de modelos posterior
Receptor: proveedor de modelos seleccionado
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/API
Primera incorporación a KYC Drift: 2026-07-13

When you submit Inputs through the Service, those Inputs are transmitted to the Model Provider you select, or that is selected through automatic routing, as applicable.

— copia archivada · capturado 2026-07-13

Analítica de terceros en el sitio

presente

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: recogida automática
Vinculación: tercero
Receptor: Google Analytics
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-13

Presently, we use Google Analytics.

— copia archivada · capturado 2026-07-13

Uso de entradas para entrenar

varía según el proveedor posterior; puedes elegirlo

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Vinculación: proveedor de modelos posterior
Receptor: proveedor de modelos seleccionado
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web/API
Primera incorporación a KYC Drift: 2026-07-14

Different Model Providers have different data practices, including with respect to whether they retain or use your Inputs and Outputs to train, fine-tune, evaluate, or improve their Models.

— copia archivada · capturado 2026-07-13

If you do not want your Inputs used for model training, select a Model or Model Provider that commits to not using your data for that purpose.

— copia archivada · capturado 2026-07-13

Pago

Pago e identidad de facturación

acepta criptomonedas

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-13 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Vinculación: identidad de facturación
Receptor: OpenRouter
Se aplica a: Región: global por defecto · Plan: de pago · Plataforma: web/API
Primera incorporación a KYC Drift: 2026-07-13

Cryptocurrency payments are never refundable.

— copia archivada · capturado 2026-07-13

Evidencia

Función de la evidencia	Fuente	Archivo o resultado	Captura u observación	registro / comprobación	sha256
captura inicial · última revisión	https://openrouter.ai/terms	copia archivada	2026-07-13	2026-07-13	`d264e051a102a9671dab6759d6235011403a199d9a33f494e5d4592698756dd8`
captura inicial · última revisión	https://openrouter.ai/privacy	copia archivada	2026-07-13	2026-07-13	`2b67c33c413db66aa2b4fc37b1cf13d021496acc0716cc3a89bd397163b17d67`

Perplexity — hechos de identidad y tratamiento de datos

Tue, 14 Jul 2026 00:00:00 +0000

Divulgaciones: naturaleza de esta página · afiliaciones · correcciones

Esta página es un registro factual — no es consejo, ni recomendación, ni invitación, ni aval. La inclusión no es aprobación. Las políticas cambian; consulta los documentos primarios del proveedor antes de apoyarte en cualquier valor.
Actualmente no tenemos ninguna relación de afiliación con los servicios listados. Si eso cambiara, lo divulgaríamos en el propio texto, no afectaría a qué se lista ni en qué orden, y el cambio quedaría registrado aquí.
¿Eres un proveedor listado y crees que un valor es erróneo? Si nuestra revisión confirma el error, lo corregimos y publicamos la corrección — escribe a editor@cypherpunkguide.com
Cómo se recogen y comprueban estos datos (metodología)

Estado del registro piloto

Nombres: Perplexity · Perplexity AI
Proveedor: Perplexity (IA de búsqueda)
Dimensiones con registros: 2 de 17 dimensiones tienen al menos un registro con ámbito definido
Origen de las afirmaciones: 2 declaradas por el proveedor · 0 observadas en la interfaz

Sin registro vigente con ámbito definido en este piloto:

Cuenta obligatoria
Teléfono al registrarse
Correo al registrarse
Métodos de acceso (SSO/cartera)
Edad mínima
Verificación posterior de identidad o teléfono
Pago e identidad de facturación
Envío de consultas a proveedores posteriores
Revisión humana de chats
Retención
Eliminación y reutilización de identificadores
Controles de privacidad opcionales
Jurisdicción del responsable del tratamiento
Analítica de terceros en el sitio
Metadatos recopilados (IP, etc.)

Identificadores de registro

obligatorio

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: obligatoria
Vinculación: tu cuenta · dispositivo
Receptor: Perplexity
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-14

Account Registration When you make an account, we collect your name, contact information, username and password, and, in some instances, device and network identifiers

— copia archivada · capturado 2026-07-06

Uso continuado

Uso de entradas para entrenar

contenido de correos excluido

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Vinculación: tu cuenta
Receptor: Perplexity
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-14

We do not use the content of emails to create, train, improve, or fine-tune AI models.

— copia archivada · capturado 2026-07-06

Evidencia

Función de la evidencia	Fuente	Archivo o resultado	Captura u observación	registro / comprobación	sha256
captura inicial · última revisión	https://www.perplexity.ai/hub/legal/privacy-policy	copia archivada	2026-07-06	2026-07-14	`3a3038bcfab1f5536754352156df2ae1dadf135b276afa31995003c573b241ee`

Venice — hechos de identidad y tratamiento de datos

Tue, 14 Jul 2026 00:00:00 +0000

Divulgaciones: naturaleza de esta página · afiliaciones · correcciones

Esta página es un registro factual — no es consejo, ni recomendación, ni invitación, ni aval. La inclusión no es aprobación. Las políticas cambian; consulta los documentos primarios del proveedor antes de apoyarte en cualquier valor.
Actualmente no tenemos ninguna relación de afiliación con los servicios listados. Si eso cambiara, lo divulgaríamos en el propio texto, no afectaría a qué se lista ni en qué orden, y el cambio quedaría registrado aquí.
¿Eres un proveedor listado y crees que un valor es erróneo? Si nuestra revisión confirma el error, lo corregimos y publicamos la corrección — escribe a editor@cypherpunkguide.com
Cómo se recogen y comprueban estos datos (metodología)

Estado del registro piloto

Nombres: Venice · Venice.ai
Proveedor: Venice (router / agregador)
Dimensiones con registros: 5 de 17 dimensiones tienen al menos un registro con ámbito definido
Origen de las afirmaciones: 5 declaradas por el proveedor · 0 observadas en la interfaz

Sin registro vigente con ámbito definido en este piloto:

Identificadores de registro
Teléfono al registrarse
Correo al registrarse
Edad mínima
Verificación posterior de identidad o teléfono
Pago e identidad de facturación
Uso de entradas para entrenar
Revisión humana de chats
Eliminación y reutilización de identificadores
Controles de privacidad opcionales
Jurisdicción del responsable del tratamiento
Analítica de terceros en el sitio

Cuenta obligatoria

opcional

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: no se recoge
Vinculación: solo la sesión
Receptor: Venice
Se aplica a: Región: global por defecto · Plan: demo · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-14

The Venice.ai Website features a chat demonstration interface which is accessible to anyone without an account.

— copia archivada · capturado 2026-07-14

Métodos de acceso (SSO/cartera)

correo, acceso mediante red social o cartera Web3

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: obligatoria
Método de verificación de la cuenta: varía según la vía
Condición de activación: crear una cuenta (la demo no la necesita)
Vinculación: tu cuenta
Receptor: Venice
Se aplica a: Región: global por defecto · Plan: gratuito/de pago · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-14

registering for an Account using a social login feature such as Google, Facebook, Apple, Discord, Coinbase, or a Web3 wallet

— copia archivada · capturado 2026-07-14

You must provide an email address to register for an account (“Account”) (either Free or Pro, as further described below) to use our Services.

— copia archivada · capturado 2026-07-14

Uso continuado

Envío de consultas a proveedores posteriores

retención cero de datos (exigida a proveedores posteriores)

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Vinculación: proveedor de modelos posterior
Receptor: proveedores de modelos
Se aplica a: Región: global por defecto · Plan: gratuito/de pago/demo · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-14

We operate a zero data retention policy with our model providers in which our model providers are prohibited from storing, retaining, or using any of your Prompts or Outputs beyond the time strictly necessary to process and return a response.

— copia archivada · capturado 2026-07-14

Metadatos recopilados (IP, etc.)

se recoge

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: recogida automática
Vinculación: solo la sesión · dispositivo
Receptor: Venice
Se aplica a: Región: global por defecto · Plan: demo · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-14

Without an account, we collect basic metadata on you, such as time zone, browser type, and IP address.

— copia archivada · capturado 2026-07-14

Retención

no se retiene

Origen de la afirmación: declarado por el proveedor
Integridad del archivo: archivado y contenido comprobado
Aplicación real: sin probar — una política publicada no demuestra el comportamiento del sistema
afirmación comprobada hasta: 2026-07-14 · objetivo de revisión mensual; el sistema de seguimiento aún no está operativo
Conflicto entre fuentes: no se registra ningún conflicto en el conjunto actual de evidencias
Recogida: no se recoge
Vinculación: solo la sesión
Receptor: Venice
Se aplica a: Región: global por defecto · Plan: gratuito/de pago/demo · Plataforma: web
Primera incorporación a KYC Drift: 2026-07-14

We do not collect or retain your Prompts or Outputs (other than as described in the Prompts and Outputs section above).

— copia archivada · capturado 2026-07-14

Evidencia

Función de la evidencia	Fuente	Archivo o resultado	Captura u observación	registro / comprobación	sha256
captura inicial · última revisión	https://venice.ai/legal/tos	copia archivada	2026-07-14	2026-07-14	`a23fcfd349c1e26ce53bd2f017eb6f8fcbb6f65bbbd5d88ffcd5d54426df7e98`
captura inicial · última revisión	https://venice.ai/legal/privacy-policy	copia archivada	2026-07-14	2026-07-14	`b4ee97bcc08f31b872ef5ac40dec1eef70f83cc34ea12827728f3771f8a33b90`

Hal Finney: PGP, RPOW y los inicios de Bitcoin (2026)

Tue, 18 Aug 2026 00:00:00 +0000

La historia de Hal Finney suele quedar reducida a dos frases: recibió la primera transacción de Bitcoin y quizá fue Satoshi Nakamoto. Ninguna explica bien su aportación. La primera exige aclarar de qué clase de transacción hablamos; la segunda pertenece a la especulación sobre identidades, no al registro de su trabajo.

Pretty Good Privacy (PGP) era un programa de cifrado para proteger mensajes. Un remailer anónimo era un servicio de reenvío pensado para ocultar quién enviaba un mensaje o hacia dónde se dirigía. Reusable Proofs of Work (RPOW) fue el experimento de Finney, basado en un servidor, para transferir fichas respaldadas por trabajo computacional.

Revisé y clasifiqué 12 documentos primarios decisivos, fechados entre 1992 y 2013: un manual de PGP 2.0, mensajes de los cypherpunks, documentación de RPOW, debates previos al lanzamiento de Bitcoin, una declaración pública de ejecución, el bloque 170 y la retrospectiva de Finney. El mapa de evidencias vinculado a las fuentes pasa la validación de esquema de un comprobador determinista; las Referencias añaden otros cuatro documentos de contexto.

El resultado no es una hagiografía ni una cacería de Satoshi. Es una historia más concreta: la de un programador que convertía problemas abstractos de privacidad en sistemas que funcionaban y que, al mismo tiempo, dejaba visible la confianza que cada sistema todavía exigía.

Qué construyó realmente Hal Finney antes de Bitcoin
#

Antes de Bitcoin, Finney ayudó a programar PGP 2.0, operó remailers anónimos y creó RPOW, un sistema de prueba de trabajo con un servidor central dotado de atestación remota. En 2008 y 2009 fue uno de los primeros revisores y probadores de Bitcoin.

La prueba de trabajo es un coste computacional que otras personas pueden verificar con poco esfuerzo. La atestación remota usa un informe de hardware firmado para demostrar qué software ejecuta un servidor. Los documentos permiten seguir una misma práctica desde el cifrado de mensajes y la comunicación anónima hasta los pagos privados, el trabajo reutilizable y un historial descentralizado de transacciones.

Los matices importan. Finney no creó PGP: su creador fue Philip Zimmermann, y la guía de usuario de PGP 2.6.2 reconoce a Finney entre varios colaboradores del trabajo sobre PGP 2.0. RPOW tampoco alcanzó el consenso descentralizado de Bitcoin; dependía de un servidor dedicado y de hardware de IBM. Y Finney no afirmó con certeza que fuera la primera persona después de Satoshi en ejecutar Bitcoin. Cuatro años más tarde escribió: «Creo que fui yo».

Las fuentes muestran a un desarrollador que ponía a prueba la frontera entre confianza y verificación. No sostienen el mito de un inventor solitario.

Una escala de evidencias: qué puede probar cada documento
#

El registro de Finney es más sólido al separar documentos fechados, notas operativas, datos de la cadena y testimonios posteriores. Una fuente puede acreditar un hecho sin probar todas las identidades o causas que luego se le atribuyeron.

No traté todos los enlaces como si tuvieran el mismo peso. Los ordené en cuatro niveles:

Documento contemporáneo: manual, mensaje de una lista de correo, anuncio de lanzamiento o declaración pública creado cerca del hecho.
Documentación operativa: código y notas de seguridad que explican cómo debía funcionar un sistema y cómo podía fallar.
Registro de un sistema público: datos de la cadena que cualquiera puede volver a leer, sin confundir una clave pública con el nombre de una persona.
Retrospectiva en primera persona: el relato posterior de Finney, valioso, pero no equivalente a un registro generado en el momento.

Documento	Qué prueba	Qué no puede probar
Manual de PGP 2.0	Finney figura como programador reconocido	Que creara PGP o lo escribiera solo
Mensaje sobre remailers de 1992	Participó pronto y describió una capa práctica de privacidad	Que fundara el movimiento cypherpunk o que ese mensaje marque el inicio de su operación
Anuncio y código de RPOW	Funcionó un experimento transferible de prueba de trabajo	Consenso descentralizado o influencia directa sobre Bitcoin
Respuestas sobre Bitcoin de 2008	Examinó el diseño antes del lanzamiento	Coautoría de Bitcoin
«Running bitcoin»	Declaró públicamente que ejecutaba el cliente	Un censo completo que demuestre que solo había dos nodos
Bloque 170	El primer gasto no coinbase (fuera de la recompensa de minería) registrado produjo salidas de 10 BTC y 40 BTC	La identidad humana de los propietarios a partir de la cadena por sí sola
Bitcoin and Me	Su relato directo de la transferencia de prueba y de los errores que reportó	Certeza contemporánea de que fue la primera persona, aparte de Satoshi, en ejecutarlo

La biografía convencional convierte las siete filas en un relato continuo. Las fuentes primarias conservan algo más útil: el distinto valor de cada prueba y la incertidumbre que queda entre ellas.

PGP 2.0: colaborador, no creador
#

Finney fue uno de los programadores reconocidos por su trabajo en PGP 2.0 y más tarde trabajó en PGP Corporation. Philip Zimmermann siguió siendo el creador de PGP; los documentos conservados no permiten presentar a Finney como su único autor.

Llamarlo «el creador de PGP» borra tanto a Zimmermann como el carácter colectivo de la implementación.

En su página personal archivada, Finney se describió como uno de los programadores originales de PGP 2.0, trabajando directamente con Zimmermann. La guía de usuario de la época reconoce a un equipo más amplio. Ninguna fuente asigna porcentajes precisos del código, así que no los inventé.

Sí muestran un patrón que volvería a repetirse: Finney entraba en una propuesta criptográfica ambiciosa desde la implementación. PGP convirtió la criptografía de clave pública en un programa utilizable por personas corrientes. Su mensaje posterior sobre los malentendidos de la red de confianza de PGP enseña la otra mitad, menos vistosa, de publicar software criptográfico: corregir lo que los usuarios creen que garantiza el modelo de confianza.

La diferencia sigue siendo importante. Una herramienta de privacidad no se define solo por su componente criptográfico, sino también por la distribución de claves, las interfaces, los modos de fallo y las conclusiones equivocadas de sus usuarios. Nuestra guía del Manifiesto cypherpunk sitúa ahí la distancia entre una promesa y un mecanismo. Finney trabajó una y otra vez dentro de esa distancia.

Los remailers incorporaron los metadatos al problema de la privacidad
#

Los textos de Finney sobre remailers ampliaron el objetivo de la privacidad: además del contenido, había que ocultar la relación entre quienes se comunicaban. El cifrado protegía lo dicho; los remailers trataban de ocultar quién hablaba con quién.

En su mensaje de noviembre de 1992 Why Remailers I, Finney presentó la comunicación privada y anónima como la base de futuras credenciales y transacciones. En 1993, Protecting Privacy with Electronic Cash ordenó el proyecto en tres capas: cifrado de clave pública, mensajería anónima y dinero electrónico privado.

Esta secuencia dice más que la etiqueta vaga de «pionero de la privacidad», porque separa cada registro protegido del problema que queda abierto:

Capa	Registro que protege	Problema que deja abierto
PGP	Contenido del mensaje	Relación entre remitente y destinatario, y datos de los dispositivos finales
Remailers	Ruta de comunicación y vínculo con una identidad	Fiabilidad, resistencia al abuso, análisis de tráfico y dispositivos comprometidos
Dinero electrónico	Relación de pago e historial de transacciones	Doble gasto, emisión, aceptación y presión institucional

Finney escribió más tarde que había operado el primer remailer anónimo basado en criptografía. Es un testimonio propio, no un censo completo de todos los servicios de la época. La conclusión sólida no depende de ese superlativo: en 1992 describía una infraestructura concebida para funcionar y, años después, dejó por escrito que había administrado remailers.

RPOW funcionó, pero mantenía un servidor en el centro
#

RPOW reutilizaba fichas de prueba de trabajo mediante un servidor dedicado en un IBM 4758. El código y la atestación remota reducían la confianza en el operador, pero no eliminaban el servidor ni descentralizaban la prevención del doble gasto.

Finney ya había explicado el problema del doble gasto en 1993. Su anuncio de RPOW de agosto de 2004 describió después un experimento en marcha: el cliente enviaba un sello Hashcash contra el abuso y el servidor devolvía una ficha firmada con criptografía de clave pública. Quien la recibía podía cambiarla por otra nueva. Así, el trabajo se volvía transferible y cada ficha concreta se aceptaba una sola vez.

El servidor era quien impedía el doble gasto. La atestación remota —una comprobación firmada del software cargado— debía revelar si había sido modificado, mientras el módulo de IBM protegía las claves de firma frente al dueño de la máquina. El modelo de seguridad de RPOW trata al propietario, al operador y al desarrollador como posibles adversarios, y confía en el programa atestado. Eso reduce la confianza necesaria; no la hace desaparecer.

Pregunta	RPOW	Bitcoin v0.1
¿Quién rechaza un segundo gasto?	Un servidor dedicado con estado persistente	Los nodos que validan un historial compartido de prueba de trabajo
¿Qué puede verificar el usuario?	El código publicado y la atestación del IBM 4758	Las reglas públicas, las transacciones y el trabajo acumulado de la cadena
Dependencia central	Disponibilidad del servidor, hardware y cadena de atestación	No hay casa de moneda ni servidor central; persisten riesgos de red y software
Advertencia inicial de fallo	Reiniciar el servidor beta podía invalidar las fichas	El estado alfa podía necesitar un reinicio; el consenso seguía siendo experimental
Función de la prueba de trabajo	Crear una entrada escasa que se canjea por fichas firmadas	Ordenar y proteger el historial de transacciones mientras se emiten monedas

Marqué esta diferencia porque muchas historias llaman a RPOW «Bitcoin antes de Bitcoin». El libro blanco de Bitcoin no cita a Finney ni a RPOW, y el registro conservado no prueba una línea directa de herencia. RPOW pertenece a la historia de la prueba de trabajo anterior a Bitcoin. Afirmar que Bitcoin se construyó a partir de RPOW excede la evidencia.

Finney no creía que el código hiciera desaparecer la política
#

Finney rechazó la doctrina de «escribe código e ignora la política». En 1994 sostuvo que las protecciones técnicas de la privacidad también dependían de victorias políticas, la persuasión pública y el entorno jurídico de uso.

Es la mayor omisión del relato habitual sobre Finney como desarrollador. En Politics vs Technology, respondió a la idea de que los avances tecnológicos eran permanentes y las protestas, secundarias. Lo dijo sin rodeos:

«No hay atajos. Refugiarse en la tecnología es como taparse la cabeza con las mantas». — Hal Finney, 1994; traducción propia

Señaló los controles sobre el cifrado, la investigación de las exportaciones de PGP y la necesidad de protección jurídica frente a la entrega forzosa de claves. No decía que el código fuera inútil. Decía que el software se despliega dentro de instituciones, leyes y aceptación pública.

Por eso su trabajo sigue teniendo valor en los debates actuales sobre privacidad. Un protocolo puede reducir el número de actores en los que hay que confiar, pero una ley puede prohibir su uso, un dispositivo final puede filtrar datos y una plataforma puede cerrar el acceso. La misma tensión aparece en el cercamiento actual de la web abierta: la arquitectura y la política se limitan mutuamente.

Antes del lanzamiento, Finney ya hacía las preguntas difíciles
#

En noviembre de 2008, Finney calificó Bitcoin de prometedor y preguntó por la propagación de transacciones, las cadenas rivales y la detección del doble gasto. En enero de 2009 pasó de revisar públicamente el diseño a probar el cliente publicado.

Su respuesta del 7 de noviembre al documento de Bitcoin elogió la idea y pasó de inmediato a analizar sus posibles fallos. La mezcla de optimismo y examen crítico coincide con su práctica anterior: entender el mecanismo, localizar el límite de confianza y ponerlo en marcha.

Cuando Satoshi anunció Bitcoin v0.1 en enero de 2009, describió el software como alfa y experimental. La respuesta pública de Finney dijo que esperaba probarlo. El 11 de enero, su siguiente paso quedó resumido en dos palabras: «Running bitcoin».

Cuatro años después, Finney escribió que creía haber sido la primera persona, aparte de Satoshi, en ejecutar Bitcoin; también contó que había minado un bloque a una altura entre 70 y 79 y que Satoshi corrigió errores que él reportó. Mantengo el verbo «creía» porque no existe un registro público de todas las personas que abrieron el cliente durante unos minutos. Las fuentes permiten decir «una de las primeras personas conocidas que ejecutaron Bitcoin después de Satoshi»; no permiten afirmar «el segundo nodo» como un hecho.

Finney publicó esa retrospectiva cuando la esclerosis lateral amiotrófica (ELA) ya lo había dejado casi completamente paralizado y usaba una interfaz controlada con la mirada. Explicó que seguía escribiendo código. La enfermedad da contexto a la forma en que produjo su relato; no vuelve más creíble ninguna afirmación técnica ni debe emplearse para embellecer la discapacidad con una historia de superación.

El bloque 170 prueba un gasto, no un nombre
#

El bloque 170 contiene la primera transacción no coinbase registrada: 50 BTC se gastaron en salidas de 10 BTC y 40 BTC. La cadena prueba los importes y el momento; Finney explicó después que recibió de Satoshi los 10 BTC como transferencia de prueba.

El registro de la transacción se puede consultar de forma independiente: txid f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16, altura 170, 12 de enero de 2009 a las 03:30:25 UTC, y salidas de 10 BTC y 40 BTC. Los bloques anteriores ya incluían transacciones coinbase, que crean la recompensa de minería. Por eso es técnicamente incorrecto llamarla «la primera transacción de Bitcoin» sin ningún calificativo.

La cadena no etiqueta como «Hal Finney» la clave pública que recibió 10 BTC. La identidad procede del mensaje de 2013 Bitcoin and Me, donde Finney dijo que Satoshi le había enviado diez monedas como prueba. La afirmación histórica tiene, por tanto, dos partes:

Hecho en la cadena (on-chain): el bloque 170 contiene la primera transacción no coinbase registrada y una salida de 10 BTC.
Atribución externa (off-chain): Finney se identificó como receptor y describió al remitente como Satoshi.

Esta separación también es necesaria al analizar cadenas actuales. Un grafo muestra transacciones y reglas de gasto; asociar una identidad humana exige pruebas externas y puede resultar equivocado. Nuestra guía sobre la privacidad de Bitcoin en cadena explica por qué la agrupación de direcciones es una inferencia, no un hecho demostrado.

Qué significa el «puente» de Finney y qué no significa
#

La carrera de Finney recorre PGP 2.0, remailers, dinero electrónico, RPOW y la primera prueba pública de Bitcoin. «Puente» describe esa trayectoria, pero no prueba autoría individual, herencia técnica directa ni la identidad de Satoshi.

El vínculo está en el método:

Convertir una promesa de privacidad en un mecanismo. PGP protegía el contenido; los remailers trataban los metadatos de comunicación.
Nombrar la confianza que todavía queda. RPOW publicaba el código y permitía verificar el servidor mediante atestación, sin dejar de depender de él.
Probar antes de fabricar un mito. Finney preguntó cómo podía fallar Bitcoin, ejecutó el alfa, reportó errores y matizó su propio recuerdo.
Mantener la política dentro del modelo de amenazas. Nunca fingió que la criptografía eliminara el poder jurídico o institucional.

Por eso, la pregunta sobre Satoshi distrae en este contexto. Ninguna fuente primaria de esta auditoría demuestra que Finney creara Bitcoin, y el libro blanco no lo cita a él ni a RPOW. La especulación sobre la autoría sustituye una contribución documentada por un juego de identidades que las fuentes no pueden resolver.

Su legado más duradero es una norma de trabajo: construir el sistema mínimo que permita poner a prueba una afirmación, publicar lo suficiente para que otros examinen el límite de confianza y declarar la incertidumbre cuando el registro no alcanza una conclusión. Esa práctica conecta PGP, RPOW y las primeras pruebas de Bitcoin mejor que cualquier relato heroico.

En resumen
#

Hal Finney conecta la práctica cypherpunk con Bitcoin sin probar una cadena de invención. Ayudó con PGP 2.0, operó remailers, construyó RPOW con un servidor, probó Bitcoin y recibió la primera transferencia de prueba conocida entre dos personas.

Conviene mantener visibles los niveles de prueba. PGP tuvo varios colaboradores. RPOW tenía un servidor. El bloque 170 contiene salidas públicas, pero ningún nombre. Bitcoin and Me es un testimonio directo escrito cuatro años después. Cada límite permite saber con precisión qué sigue estando demostrado.

Puntos clave

PGP y remailers: Finney fue un programador reconocido por su trabajo en PGP 2.0, no su creador, y trató los metadatos de las relaciones como un problema distinto del cifrado del contenido.
RPOW: el sistema hacía transferible la prueba de trabajo mediante un servidor IBM 4758 atestado; fue software operativo, no un Bitcoin descentralizado.
Política: Finney rechazó de forma explícita que escribir código permitiera ignorar la ley y la persuasión pública.
Bitcoin: fue uno de sus primeros revisores y una de las primeras personas que lo ejecutaron, pero «el segundo nodo» sigue siendo un recuerdo matizado, no el resultado de un censo demostrable.
Bloque 170: la cadena prueba la primera transacción no coinbase registrada; el testimonio posterior de Finney aporta la atribución humana.

Preguntas frecuentes
#

Cada afirmación sobre Hal Finney depende de la prueba que la respalda. Mensajes fechados acreditan actividad pública; la cadena acredita un gasto sin nombrar personas; el testimonio posterior aporta una atribución directa con incertidumbre explícita.

¿Fue Hal Finney la primera persona, aparte de Satoshi, en ejecutar Bitcoin?
#

Es posible, pero el registro no demuestra que fuera el único. En 2013, Finney escribió: «Creo que fui la primera persona, aparte de Satoshi, en ejecutar Bitcoin». Su mensaje público «Running bitcoin» confirma un uso muy temprano, no un censo completo. La fórmula compatible con la evidencia es «una de las primeras personas conocidas que ejecutaron Bitcoin después de Satoshi».

¿Por qué se llama al bloque 170 la primera transacción de Bitcoin?
#

Porque contiene la primera transacción no coinbase registrada: 50 BTC minados previamente se gastaron en salidas de 10 BTC y 40 BTC. Los bloques anteriores ya contenían transacciones coinbase que crean las recompensas de minería. Sabemos que los 10 BTC fueron una transferencia de prueba a Finney por su propio testimonio posterior, no porque la cadena muestre su nombre.

¿Inventó Hal Finney Bitcoin o actuó como Satoshi Nakamoto?
#

Las fuentes primarias revisadas no demuestran ninguna de las dos afirmaciones. Muestran a Finney examinando el diseño, ejecutando el software publicado, reportando errores y recibiendo una transferencia de prueba de la persona a la que describió como Satoshi. Es evidencia de colaboración y ensayo técnico, no de una identidad compartida ni de autoría.

¿Fue RPOW una versión temprana de Bitcoin?
#

Fue un experimento operativo de fichas de prueba de trabajo anterior a Bitcoin, pero su arquitectura era distinta. RPOW usaba un servidor dedicado y la atestación del IBM 4758 para impedir la emisión no autorizada y el doble gasto. Bitcoin empleó una cadena de prueba de trabajo entre pares para prescindir de una casa de moneda o servidor central. El libro blanco no documenta una influencia directa de RPOW sobre Bitcoin.

¿Qué aportó Finney a PGP 2.0?
#

El manual de la época y el relato de Finney lo identifican como uno de los programadores que trabajaron en PGP 2.0 con Philip Zimmermann. Los documentos disponibles no permiten asignarle un porcentaje preciso del código y tampoco lo convierten en creador o único autor de PGP.

Referencias
#

El mapa de evidencias reúne 12 documentos y se complementa aquí con otros cuatro de contexto. Cada fuente disponible se acompaña de una reproducción exacta de Wayback elegida en el registro CDX del archivo, no de una fecha de captura inventada.

Cora Aegis

Cora Aegis escribe guías de OPSEC con la privacidad como eje en CypherpunkGuide. Para este artículo auditó 12 documentos primarios de 1992 a 2013, separó las pruebas directas de las atribuciones retrospectivas y preparó el mapa de evidencias y su validador determinista.

Más sobre Cora Aegis ->

Lectores de matrículas: qué defensa funciona de verdad (2026)

Fri, 10 Jul 2026 00:00:00 +0000

La matrícula es el único identificador que el Estado te obliga a exhibir en público, atornillar al coche y hacer desfilar ante cada cámara de cada carretera que usas. Durante casi toda su historia, las cámaras automáticas que la fotografiaban fueron una herramienta policial de nicho —los lectores automáticos de matrículas, o ALPR: cámaras de carretera y de coche patrulla que fotografían cada matrícula que pasa, le estampan una hora y un lugar, y la guardan en una base de datos que se consulta en segundos—. Hoy son una red que registra todos los coches que pasan, no solo los de quienes están bajo sospecha. Flock Safety, el proveedor de más rápido crecimiento, superó las 100.000 cámaras en 2026; superpuesta a la vieja red Vigilant de Motorola y a miles de sistemas locales, deja un país donde —allí donde hay un lector instalado— los movimientos de tu coche quedan grabados, fechados y guardados por defecto, y donde la mayoría de los estados aún no tienen ninguna ley que regule expresamente nada de esto.

El abuso no es hipotético, y no es raro. A los agentes los detienen una y otra vez por usar estos sistemas para dar caza a personas con las que salieron. Un agente de Pensilvania rastreó a su esposa, de la que estaba separado, más de 250 veces. Un jefe de policía de Kansas, según la auditoría del departamento que lo destapó, pasó por las cámaras a una exnovia y a la nueva pareja de ella 228 veces. Un agente de Milwaukee registró 179 búsquedas sobre una novia y el ex de ella. El propio director jurídico de Flock, preguntado por el mal uso, declaró al medio especializado en el sector de la vigilancia IPVM que usar el sistema para «averiguar dónde está una exnovia» era «en realidad lo más común». La empresa que vende esta red sabe exactamente qué aspecto tiene su abuso más frecuente.

Entonces, ¿qué puede hacer una sola persona frente a una cámara que no es suya, en una carretera que no controla? Casi todas las respuestas que encontrarás son peor que inútiles. Las fundas para la matrícula, los sprays reflectantes y los soportes inclinables son ilegales en buena parte del país y, según las pruebas independientes, no hacen prácticamente nada contra un lector moderno. Reunimos las declaraciones juradas, los escritos de acusación y las notas de prensa de las fiscalías que hay detrás de más de una docena de estos casos, y contrastamos cada uno con una búsqueda en sentido contrario, tratando de refutarlo. Así descartamos dos historias muy citadas como «casos ALPR» que resultaron ser otra cosa: un rastreador GPS oculto y una cámara que leyó mal la matrícula de una conductora inocente, nada que ver con el abuso de los lectores. Lo que muestra el registro ya verificado es que las defensas que de verdad reducen tu riesgo son casi lo contrario de lo que las guías de instrucciones colocan en primer lugar.

La tabla de abajo es una síntesis propia: no son los argumentarios de ningún proveedor ni el refrito de un único recuento de una organización, sino los casos que pudimos anclar a registros judiciales de primera mano, leídos buscando el patrón que la cobertura periodística se salta.

Agente / lugar	Qué muestran los registros	Situación
McSherry — Frazer Township, Pensilvania	Rastreó a su esposa, de la que estaba separado, más de 250 veces con equipo policial de lectura de matrículas	Se declaró culpable; encarcelado (2021)
Heiar — Kechi, Kansas	Siguió a su esposa, de la que estaba separado, a través de Flock y luego le mandaba mensajes contándole dónde había estado	Se declaró culpable de un delito informático y de acoso (2023)
Nygaard — Sedgwick, Kansas	228 búsquedas en Flock sobre una exnovia y su nueva pareja, registradas con pretextos falsos	Dimitió; inhabilitado como policía (2023)
Josett — Costa Mesa, California	Pasó a su esposa, a una amante y a un rival sentimental por bases de datos policiales	Se declaró culpable de tres cargos (2026)
Ayala — Milwaukee, Wisconsin	179 búsquedas en Flock sobre una novia y el ex de ella; la víctima declaró tener miedo	Se declaró culpable; dimitió (2026)

Léelos en conjunto y las defensas se reordenan solas. A ninguna de estas mujeres la localizaron porque le fallara un disfraz ingenioso. La localizaron porque quien vigilaba tenía una placa policial, una base de datos y a nadie que revisara el registro de consultas; y ese es un problema distinto del que se propone resolver la pregunta «¿cómo escondo mi matrícula?».

Qué es en realidad una red ALPR
#

Una red ALPR no es una cámara: es un historial consultable de por dónde ha pasado tu coche. Cada aparato es un sensor pasivo: lee todas las matrículas que ve, haya o no alguien sospechoso de algo, y escribe una fila —matrícula, hora, coordenada GPS y, a menudo, una foto del vehículo y de su entorno— en una base de datos que se puede consultar en segundos. Encadena las suficientes y una sola consulta te devuelve un mapa de tus trayectos: la ruta que hiciste, a qué hora saliste y volviste, la iglesia, la clínica, el local sindical o la casa del amante ante la que aparcaste. El resumen técnico de la Electronic Frontier Foundation lo dice sin rodeos: los ALPR recogen datos de todo el mundo, no solo de las personas bajo investigación.

Dos rasgos separan esto del policía de barrio que se fija en tu coche. El primero es la retención: las lecturas se guardan, así que la vigilancia es retroactiva. Una consulta lanzada hoy puede reconstruir dónde estabas el mes pasado. Los límites de retención, donde existen, van de los tres minutos de Nuevo Hampshire a los 21 días de Washington o los 60 días o más de otros sitios; y en la mayoría de los estados no hay tope alguno. El segundo es la interconexión: las cámaras de un pueblo son consultables de forma rutinaria por agencias de otros estados. En 2025, la EFF y la ACLU documentaron que la policía de San Francisco había lanzado más de 1,6 millones de búsquedas compartidas fuera del estado, algunas ligadas al control migratorio, consultas que ni la propia política del departamento autorizaba. El servicio de estudios del Congreso ha catalogado los vacíos legales resultantes; en resumen, la tecnología le sacó a la ley cosa de una década de ventaja.

La retención es donde ese vacío se abre más, y vale la pena ver qué poca parte del país le pone algún tope:

Estado	Límite de retención de datos ALPR
Nuevo Hampshire	~3 minutos salvo que haya una alerta: el más estricto de EE. UU.
Washington	21 días (Driver Privacy Act de 2026)
California	60 días (SB 34)
La mayoría de los estados	Sin límite específico para ALPR: se guardan de forma indefinida

El abuso es el patrón, no la excepción
#

El dato más importante sobre la vigilancia de matrículas es que su mal uso documentado más común no consiste en atrapar delincuentes, sino en agentes que rastrean a mujeres. No es el enfoque de ningún activista: es el del propio proveedor. Cuando ponemos los registros judiciales uno al lado del otro, la misma historia se repite de un estado a otro: un agente, en activo o retirado, usa un sistema pensado para la seguridad pública para seguir a una pareja, a una ex o a una mujer con la que se ha obsesionado.

La fiscalía sostiene que Ayala hizo 179 búsquedas en Flock sobre una mujer con la que había salido y sobre la expareja de ella. El abuso solo salió a la luz porque la víctima empezó a sospechar y pidió al departamento que comprobara quién había estado consultando su matrícula; y la revisión interna que vino después dejó al descubierto a un segundo detective de Milwaukee —uno de los investigadores asignados al propio caso de Ayala—, acusado de hacer lo mismo con otra mujer. El registro de auditoría no atrapó a ninguno de los dos. Lo hizo una víctima asustada.

— Milwaukee, Wisconsin — el agente Josue Ayala, se declaró culpable en 2026

Ese detalle —no lo atrapó el registro, lo atrapó la víctima— se repite casi en todas partes. En Georgia, una cadena de departamentos solo destapó el mal uso después de adoptar las herramientas de auditoría de Flock y ponerse de verdad a mirar: Braselton en noviembre de 2025, y luego el condado de Coffee, el de Cherokee y Albany para julio de 2026; cuatro agencias en ocho meses, en cuanto alguien se puso por fin a revisar los registros. No todos estos casos eran rastreo de una expareja; el rasgo común es que los pilló una auditoría, no el sistema en sí. La lección no es «los registros de auditoría te mantienen a salvo». Es la contraria: un registro que nadie lee es la prueba del delito, no una defensa frente a él. Quien te diga que el sistema es seguro porque está «totalmente auditado» te está describiendo un detector de humo al que le han quitado la pila.

La magnitud real es incierta, porque el recuento no deja de subir. El Plate Privacy Project del Institute for Justice lleva años registrando estos casos de acecho policial, y la cifra no ha hecho más que crecer a medida que más departamentos auditan y más víctimas preguntan. Nuestro propio recuento mínimo —los agentes que pudimos vincular a declaraciones de culpabilidad, condenas o cargos penales en curso— llega a una docena, repartidos por siete estados; y es solo eso, un mínimo: durante todo 2026 salieron casos nuevos casi cada mes. Toma cada número concreto como una foto fija que ya estará desactualizada cuando la leas, y el patrón como algo permanente.

Una advertencia en sentido contrario, porque la credibilidad lo exige: no todo relato dramático de «lector de matrículas» lo es de verdad. Un caso de acecho de California muy difundido implicaba un rastreador GPS oculto, no lectores de matrículas; otro incidente viral atribuido a «Flock» fue en realidad el sistema leyendo mal la matrícula de una mujer inocente, a la que casi le imputan un delito por error: un daño real, pero de otra clase. Aquí la precisión no es pedantería. Si te defiendes del mecanismo equivocado, gastas el esfuerzo en el lugar equivocado, el mismo error que te vende la vigilancia cuando te promete que una funda para la matrícula va a servir de algo. Sobre cómo, de entrada, esos datos dispersos acaban fundiéndose en un único perfil, mira nuestra guía sobre la desanonimización a escala de IA.

La dimensión de género: cuando quien vigila sabe dónde duerme ella
#

Una red de matrículas no se vive igual para todo el mundo, porque ser localizable no es igual de peligroso para todos. Para una mujer que deja a un maltratador, para quien busca atención reproductiva en un estado hostil o para una activista que a un gobierno le incomoda, un sistema que convierte una matrícula en una ubicación no es una preocupación abstracta de privacidad: es exactamente la capacidad que su modelo de amenazas trata de anular. Y el registro muestra rastreadas justamente a estas personas.

El caso de la atención reproductiva está ya documentado con detalle. En 2025, la EFF reveló que un sheriff de Texas rastreó más de 83.000 cámaras por todo el país para dar con una mujer que se había practicado un aborto autogestionado, con el pretexto de una «persona desaparecida». La respuesta de Washington fue escribir el daño directamente en la ley: la Driver Privacy Act de 2026 del estado (SB 6002) prohíbe usar datos ALPR para el control migratorio y para rastrear a quienes buscan atención de salud reproductiva. Cuando un parlamento tiene que prohibir de forma expresa el uso de las cámaras de matrículas para dar caza a pacientes de aborto y a inmigrantes, te está diciendo para qué se venían usando ya esas cámaras.

Por eso los casos de pareja son el centro de esta historia, y no un morboso apunte al margen. Los agentes que rastrearon a sus ex no explotaban un fallo oscuro ni escribían código a medida: usaban la función de búsqueda corriente del sistema —sin ningún exploit técnico— para el mismo mal uso que su propio proveedor califica de más habitual. Para una superviviente, el dato relevante es de una sencillez brutal: si tu agresor tiene una placa, o un amigo que la tenga, la red ya conoce tu nuevo trayecto al trabajo. Ninguna funda para la matrícula cambia eso. Lo que sí lo cambia es cortar el vínculo entre el coche y tú, y poner en marcha la maquinaria legal que te permite averiguar quién ha estado consultando tu matrícula; las dos cosas están en la sección de defensa de más abajo, y las dos son aburridas, que es justo por lo que casi nadie te las vende.

Lo que de verdad funciona: una matriz de defensas por eficacia
#

La clasificación honesta de las defensas individuales es casi la inversa de la que publican la mayoría de las guías. Las medidas que se llevan todo el protagonismo —los artilugios físicos que «bloquean» la cámara— son las menos eficaces y las que más papeletas tienen de ser ilegales. Las que de verdad mueven tu riesgo son legales, estructurales y colectivas, y son lo bastante aburridas como para que las listas escritas para cobrar comisiones las pasen por alto. Esta es la clasificación que sostiene la evidencia, de peor a mejor:

Defensa	¿Funciona?	¿Es legal?	Ideal para
Fundas para la matrícula / sprays reflectantes / película infrarroja	No: las pruebas independientes no muestran casi ningún efecto sobre los lectores modernos	Ilegal en California, Nueva York, Florida y muchos estados (en California la infracción ronda los 2.000 dólares con los recargos)	Nadie: evítalo
Variar rutas y horarios	No: una red pasiva que funciona a todas horas te registra vayas donde vayas	Legal	Solo tranquilidad mental; no es una defensa real
Mapas colaborativos de cámaras (DeFlock)	Marginal: sirve para saber dónde estás y planear rutas allí donde la cobertura es escasa	Legal	Entender tu exposición y organizarte a nivel local
Derechos legales sobre los datos (solicitudes de registros públicos y de borrado)	Parcial: puedes averiguar quién te consultó y pedir el borrado, pero los proveedores escurren el bulto	Legal	Supervivientes; cualquiera que sospeche que es un objetivo
Estructural: no atar un coche a tu nombre (coche compartido, alquiler)	Alta: una matrícula que no es la tuya vence el rastreo por matrícula	Legal	Trayectos de alto riesgo, destinos sensibles
Política: contratos locales y leyes estatales	La más alta: retira las cámaras o limita su uso para todo el mundo	Legal	Todo el mundo; el único arreglo duradero

Empieza por abajo, porque ahí es donde está la palanca. La acción política no es el premio de consolación: es la defensa que más rinde. Hay comunidades cancelando contratos ALPR en números que cuentan: para mediados de 2026, decenas de ciudades habían dejado a Flock por compartir datos sin autorización con el gobierno federal y con otros estados, muchas después de que sus vecinos se presentaran en una sesión del ayuntamiento con las auditorías en la mano. El kit de herramientas «Get the Flock Out» de la ACLU existe precisamente porque esta es la intervención que escala: un solo ayuntamiento convencido protege a cada conductor del municipio como ningún artilugio personal puede hacerlo, aunque nunca del todo para siempre. Un ayuntamiento posterior puede volver a encender las cámaras, como hizo Richmond en 2026 tras una pausa, y por eso una cancelación es una batalla que ganas y luego tienes que seguir defendiendo.

Luego están tus derechos legales, que son reales pero piden ajustar las expectativas. En California y en una lista creciente de estados puedes presentar una solicitud de registros públicos para pedir la política ALPR de un departamento y sus auditorías de uso y, allí donde la ley lo prevé, pedir que borren los datos sobre ti. La trampa, documentada en pleitos aún abiertos, es que Flock a menudo se presenta como un simple «proveedor de servicios» y reenvía las solicitudes individuales de vuelta al ayuntamiento, que puede actuar o no. Ejerce el derecho, pero no des por hecho que se cumple solo. El fiscal general de California ha demandado al menos a una ciudad por compartir datos de forma ilegal, un recordatorio de que la aplicación de la ley, cuando llega, tiende a venir de las autoridades y los tribunales antes que de las bajas individuales.

El único movimiento estructural que una persona controla del todo es la defensa personal más eficaz de la lista: romper el vínculo entre el coche y tu identidad en los trayectos que importan. Un coche compartido, uno de alquiler o un viaje en un coche que no es tuyo dan una matrícula que lleva a otra parte, no a ti. No esconderá tu ida y vuelta diaria al trabajo, pero para el trayecto sensible —la clínica, el refugio, la reunión— marca la diferencia entre una matrícula que te nombra y otra que no. Es la versión sobre ruedas del mismo principio que recorre todo el pilar de Soberanía: cambia la infraestructura, no solo la conducta.

Queda la fila por la que todo el mundo empieza y con la que debería terminar: la ocultación física no funciona y encima puede costarte una multa. El análisis independiente de RadarTest sobre los productos reflectantes para matrículas no halló ningún efecto medible frente a los lectores modernos, que combinan captura por infrarrojos y por luz visible con exposición automática; y, a la vez, las fundas y los sprays son ilegales de forma expresa en California, Nueva York, Florida y otros sitios. Estarías pagando por infringir la ley a cambio de nada.

Los límites de la defensa individual
#

Frente a una red pasiva, interconectada y retroactiva, la técnica individual es a la vez necesaria e insuficiente. Este es el límite que las guías escritas para cobrar comisiones nunca dicen con claridad, y decirlo es el sentido entero de este artículo. Puedes alquilar un coche para ir a la clínica y presentar tus solicitudes de borrado, y deberías hacerlo. Lo que no puedes, tú solo, es desconectar cien mil cámaras entre sí, revocar el acceso de otro estado a los datos de tu ciudad ni hacer que un sistema que ya registró tus movimientos del mes pasado los olvide. Al lector que fotografió tu matrícula esta mañana le dio igual quién eres, y ninguna astucia personal alcanza hacia atrás para deshacer ese registro.

Los casos lo dicen, cuando los lees como un conjunto. A las víctimas rastreadas no se les escapó ningún detalle de OPSEC: alguien con acceso autorizado sencillamente apuntó el sistema hacia ellas. Lo que de verdad cambió esas situaciones no fue un artilugio, sino la auditoría que alguien leyó, la periodista que lo publicó, el ayuntamiento que canceló el contrato, el parlamento que fijó un límite de retención; la palanca que los cypherpunks siempre han señalado, ahí donde la defensa personal se topa con el poder institucional y le pasa el resto a la acción colectiva. El Tribunal Supremo ha empezado a insinuar que el rastreo de ubicación agregado y a largo plazo plantea preguntas constitucionales que a los operadores de esta red les convendría esquivar; y esa presión se construye con demandas y con leyes, no torciendo tu matrícula. Es la misma conclusión a la que llegó, desde el otro lado, nuestro estudio sobre los sistemas de identidad impuestos por el Estado: el arreglo duradero está aguas arriba, en las reglas, no aguas abajo, en la caja de herramientas del individuo.

«La privacidad es el poder de revelarse selectivamente al mundo.» — Eric Hughes, A Cypherpunk’s Manifesto, 1993

Una matrícula es el reverso exacto de ese poder: un identificador que estás obligado a mostrar a cada cámara, consientas o no. Defiende el trayecto concreto donde puedas y, después, presiona sobre las condiciones, porque el proveedor que reconoce que el acecho es su uso «más común» no va a limitar por pura benevolencia su propia retención de datos.

En conclusión — qué defensa encaja con tu riesgo
#

No hay una única respuesta, porque la defensa correcta depende por completo de quién podría apuntar el sistema hacia ti y de cuánto te costaría si lo hiciera.

Si eres un conductor normal al que le molesta que lo rastreen: olvídate por completo de los artilugios y dedica esa misma energía a lo único que escala: una solicitud de registros públicos para ver la política ALPR de tu departamento local y un mensaje a tu ayuntamiento. Tu palanca es política, no técnica, y de paso protege también a tus vecinos.
Si estás dejando a una pareja maltratadora, sobre todo si tiene acceso policial: da por hecho que la red ya conoce tu rutina y defiende los trayectos sensibles no conduciendo un coche matriculado a tu nombre. En paralelo, usa los derechos de acceso a los datos de tu estado para averiguar quién ha estado consultando tu matrícula; en los casos documentados, esa solicitud es justo lo que dejó al descubierto al agente.
Si eres activista, periodista u organizador: trata tu vehículo como una baliza que te delata y planifica en consecuencia: coche compartido para las reuniones sensibles, y combínalo con la disciplina de identidad e infraestructura de nuestra guía sobre defensa frente al doxxing de activistas, porque la matrícula es solo una de las señales que te sitúan.
Si buscas atención reproductiva o sensible desde el punto de vista migratorio en un estado hostil: la amenaza está documentada y es concreta. No vayas a la cita en tu propio coche, conoce las reglas de retención y de intercambio de datos de tu estado antes de salir, y apoya las leyes —como la de Washington— que prohíben de plano estas búsquedas.

En los cuatro casos rige la misma verdad que rigió en cada fracaso de vigilancia anterior: no hay artilugio que le gane a una red así. Puedes reducir tu exposición en los trayectos que importan, ejercer los derechos legales que obligan al sistema a salir a la luz y, más allá del límite de lo que una sola persona puede hacer, actuar junto a otros para retirar las cámaras.

Puntos clave

El abuso más común es el acecho, y lo admite el propio proveedor: el director jurídico de Flock calificó usar el sistema para localizar a «una exnovia» como el mal uso «más común», un patrón confirmado por una docena de agentes, en siete estados, ligados a declaraciones de culpabilidad, condenas o cargos penales.
Los bloqueadores físicos son la peor opción: las fundas, los sprays y la película infrarroja no muestran casi ningún efecto frente a los lectores modernos en las pruebas independientes, y son ilegales en California, Nueva York, Florida y más estados, donde la infracción ronda los 2.000 dólares.
Los registros de auditoría no te protegen; los registros que alguien revisa, sí: en los casos documentados, el abuso lo destaparon víctimas y compañeros que sospecharon, no el sistema; un registro que nadie lee es prueba, no defensa.
El movimiento personal eficaz es estructural: para los trayectos sensibles, un coche que no esté matriculado a tu nombre vence el rastreo por matrícula como no puede hacerlo ningún accesorio.
El arreglo duradero es político: decenas de ciudades cancelaron contratos ALPR para mediados de 2026, y estados como Washington limitaron la retención a 21 días y prohibieron las búsquedas ligadas al aborto y a la inmigración, una palanca que ningún artilugio individual iguala.

Preguntas frecuentes
#

¿Cómo me defiendo de los lectores de matrículas?
#

No con artilugios. Las fundas para la matrícula, los sprays reflectantes y los soportes inclinables son ilegales en muchos estados y no hacen prácticamente nada contra los lectores modernos. Las defensas que sí funcionan, por orden de eficacia, son la política (presiona a tu municipio para que cancele o limite su contrato ALPR), la legal (presenta solicitudes de registros públicos y de borrado de datos al amparo de la ley de tu estado) y la estructural (para los trayectos sensibles, conduce un coche que no esté matriculado a tu nombre, como uno compartido o de alquiler). Frente a una red pasiva y siempre encendida, reducir tu exposición en los trayectos que importan y cambiar las reglas mediante la acción colectiva le ganan a cualquier dispositivo personal.

¿Son legales las fundas o los sprays reflectantes para la matrícula, y funcionan?
#

En general, no a las dos cosas. Los productos que se venden para «bloquear» las cámaras ALPR —fundas, sprays reflectantes como PhotoBlocker, película infrarroja— son ilegales de forma expresa en California, Nueva York, Florida y otros estados, donde una infracción puede llegar a unos 2.000 dólares una vez sumados los recargos estatales. Las pruebas independientes, como las de RadarTest, no hallaron ningún efecto medible frente a los lectores modernos, que combinan captura por infrarrojos y por luz visible con exposición automática. Estarías pagando por infringir la ley a cambio de ninguna protección real.

¿Puedo borrar los datos de mi matrícula o averiguar quién la consultó?
#

A veces, según tu estado. En California y en un número creciente de estados puedes presentar una solicitud de registros públicos para pedir la política ALPR de un departamento y sus auditorías de uso y, donde la ley lo permite, pedir el borrado de los datos sobre ti. En varios casos de acecho documentados, la solicitud de una víctima para ver quién había consultado su matrícula es justo lo que dejó al descubierto al agente. El límite es que proveedores como Flock a menudo se llaman a sí mismos «proveedor de servicios» y reenvían las solicitudes individuales de vuelta al ayuntamiento, que puede no actuar; así que trata el derecho como real, pero no como algo que se cumpla solo.

¿Cuánto tiempo guarda la policía los datos de los lectores de matrículas?
#

Varía muchísimo y, por lo general, no tiene tope. Entre los estados con límites, la retención va de los tres minutos de Nuevo Hampshire a los 21 días de Washington o los 60 días o más de otros sitios, pero la mayoría de los estados no tienen ninguna ley de retención específica para ALPR, lo que significa que los datos pueden guardarse y consultarse de forma retroactiva durante meses o años. Como los registros se conservan y se interconectan entre jurisdicciones, una consulta lanzada hoy puede reconstruir dónde estuvo un coche hace semanas: la propiedad que convierte esta tecnología en una herramienta de vigilancia, y no en una alerta en tiempo real.

¿Es legal Flock Safety?
#

Operar cámaras ALPR es legal en la mayor parte de Estados Unidos, pero usos concretos y ciertos acuerdos de intercambio de datos se están impugnando cada vez más por ilegales. Para mediados de 2026, Flock afrontaba demandas colectivas, la demanda de un fiscal general estatal por compartir datos de forma ilegal con otros estados, el escrutinio del Congreso y decenas de contratos municipales cancelados después de que las auditorías revelaran búsquedas no autorizadas a nivel federal y entre estados. «Legal de instalar» y «legal por el uso que se le da en realidad» han resultado ser preguntas muy distintas.

Cora Aegis

Cora Aegis escribe en CypherpunkGuide guías de OPSEC centradas en la privacidad, y lee los registros de primera mano buscando el mecanismo que la mayoría de la cobertura se salta: aquí, cómo una matrícula que estás obligado a exhibir se convierte en un mapa consultable de tu vida, y qué defensas frente a ella son reales.

Más sobre Cora →

Cómo el monitoreo de Slack te hace perder el empleo (2026)

Tue, 16 Jun 2026 00:00:00 +0000

Parte de lo que ya está zanjado, porque no tiene sentido fingir lo contrario: tu empresa puede leer tu Slack, incluidos los mensajes marcados como privados, y puede exportar el historial completo desde un panel de administración que nunca verás. Si te llevas una sola cosa de la búsqueda que te trajo hasta aquí —¿mi empresa puede leer mi Slack?—, que sea esta: da por hecho que no es privado, y para ahí. Esa respuesta ya está en todas partes, incluido el resumen que la IA seguramente te mostró de camino a esta página, y no vamos a gastar un artículo entero en reconfirmarla.

La pregunta que esa página no responde es la que de verdad decide si conservas tu empleo: ¿qué se marca y qué provoca el despido? No es lo mismo que ¿se puede leer?, y en la distancia entre ambas se pierden las carreras. Construimos este caso de estudio porque la orientación existente se queda en la higiene —usa un dispositivo personal, evita los mensajes directos— y deja sin escribir el mecanismo: cómo un registro de chat se convierte en un despido, quién lo decide y qué cambió en 2024, cuando el lector dejó de ser un administrador humano y pasó a ser un algoritmo que puntúa tu tono en tiempo real. Vigilamos los rastreadores de IA que indexan esta web: llegan a su propio ritmo, sin nadie humano de por medio. Ese mismo giro ha entrado ya en tu lugar de trabajo.

Así que esto es un modelo de amenazas para la ventana de chat en la que estás escribiendo ahora mismo. Abajo hay tres casos documentados —todos reportados, todos históricos, con nombres solo donde nombrarlos ya es público— y, a partir de ellos, la parte que las listas de higiene se saltan: la taxonomía de lo que hace despedir a la gente, el paso de 2024 a la puntuación automatizada que vuelve inútil esquivar palabras clave, y un relato honesto de dónde termina la defensa individual y dónde empieza la acción colectiva.

La tabla de abajo es nuestra propia síntesis: tres casos reportados, ordenados según un eje que las listas de higiene omiten —el método de monitoreo, qué marca y qué acaba de verdad con el empleo—.

Método de monitoreo	Qué marca	Qué provoca de verdad el despido	Tu palanca real
Exportación y búsqueda por administrador (revisión humana)	Palabras clave, personas nombradas, historial de mensajes a petición	Crítica pública o registrada a la dirección; un mensaje que alguien captura y eleva	Saca la conversación sensible de la plataforma de la empresa
Auditoría dirigida o con pretexto	Actividad en torno a un organizador o a una investigación por filtración	Organización y reclamos de equidad salarial, reencuadrados como falta de política	Documenta la cronología; conoce tus protecciones de actividad concertada
Puntuación automatizada de sentimiento o toxicidad (IA, en tiempo real)	El tono y los patrones en todos los mensajes: no hace falta palabra clave	Una puntuación de «sentimiento» o de riesgo baja, que nunca ves, entregada a la empresa	Asume que el tono se puntúa; no hay frase que lo evite con fiabilidad

Cómo funciona de verdad el monitoreo corporativo de Slack
#

El monitoreo corporativo de Slack viene integrado en los planes empresariales del producto, no añadido por fuera: los administradores de los planes de pago pueden exportar, buscar y retener el historial de mensajes —incluidos los mensajes directos y los canales que crees privados—, y la distinción que la plataforma te invita a pasar por alto es que privado es un ajuste de visibilidad, no un muro legal ni técnico. En un espacio de trabajo administrado por la empresa, quien opera el sistema alcanza lo que el sistema guarda. Ese es el piso.

Lo que importa para tu modelo de amenazas es el tipo de lectura, porque los tipos difieren en lo que capturan. El más antiguo y común es la exportación y búsqueda por administrador: una persona con el rol adecuado extrae el historial —a menudo durante una investigación, un conflicto o una salida— y lo lee o lo busca por palabras clave. Es reactiva y se dispara por un evento; casi siempre necesita un motivo para fijarse en ti en particular. Un segundo tipo es la auditoría dirigida, en la que se examina la actividad de una persona concreta porque ha llamado la atención: como organizadora, como presunta filtradora, como alguien a punto de irse. El tercer tipo es nuevo, y es la razón de ser de este artículo: la puntuación automatizada y continua mediante herramientas de IA de terceros que leen cada mensaje a medida que se envía y le asignan una señal de tono, sentimiento o riesgo, sin nadie humano de por medio hasta que algo se marca. Los dos primeros preguntan qué dijo esta persona; el tercero pregunta cuál es el patrón en todo lo que dice todo el mundo, todo el tiempo.

El marco legal, en Estados Unidos y en muchas jurisdicciones comparables, es implacable: en los sistemas propiedad de la empresa, en las cuentas corporativas, las comunicaciones suelen ser de la empresa para monitorearlas, y «lo marqué como privado» pesa poco frente a quien opera el sistema. Hay límites reales —categorías de expresión protegidas, que vemos más abajo—, pero la situación por defecto es la exposición. Nada de esto está oculto; está en la documentación del plan. El error que comete casi todo el mundo no es ignorar si puede ser leído. Es calcular mal cuál de las lecturas le afecta, y defenderse de la que no es.

Tres casos: de lo que se vigilaba a quién fue despedido
#

La forma más rápida de ver la distancia entre se puede leer y te hace perder el empleo es poner tres casos reportados uno al lado del otro y trazar el mismo recorrido en cada uno: qué se monitoreó, qué disparó el despido y qué —si algo— habría cambiado el desenlace. Son episodios cerrados y documentados, tomados por entero de la cobertura de su momento; el contenido de los mensajes se atribuye a esos reportes, no se reconstruye aquí.

El mecanismo: corregir en público a la dirección. A los pocos días de que Elon Musk adquiriera Twitter, la empresa despidió a una oleada de empleados que habían criticado a la nueva propiedad en canales internos de Slack y en público. Entre los reportados como despedidos estaba el ingeniero Eric Frohnhoefer, quien, según NBC News, había contradicho públicamente las afirmaciones técnicas de Musk sobre el rendimiento de la plataforma y fue despedido poco después.

La lección no está en el contenido de ningún mensaje. Está en que criticar a la dirección en un canal registrado y controlado por la empresa —o en público bajo tu identidad laboral— es el camino más fiable que existe de monitoreado a despedido, y no requiere ninguna herramienta sofisticada.

— Twitter, despidos tras la adquisición, noviembre de 2022

El mecanismo: organizarse, con el pretexto de una política de dispositivos. Apple despidió a Janneke Parrish, gerenta de programa y coorganizadora del movimiento #AppleToo, que recogía testimonios de empleados sobre desigualdad salarial y trato en el trabajo. El motivo declarado fue el borrado de archivos de un dispositivo de trabajo durante una investigación por filtraciones. Parrish y quienes la apoyaban describieron el despido como una represalia por su labor de organización.

En enero de 2023, según informó TechCrunch, una oficina regional de la NLRB halló fundamento en las denuncias de que Apple había vulnerado los derechos de los trabajadores. Fue un paso preliminar, no un fallo definitivo, y el hilo regulatorio no aguantó: en septiembre de 2025, según informó Reuters, los fiscales del organismo laboral retiraron ese conjunto de acusaciones —incluida la del despido de Parrish— en medio de un cambio en la dirección de la junta, sin que hubiera una resolución definitiva de que Apple infringiera la ley. El patrón que conviene retener no depende del veredicto: la labor de organización casi nunca se cita como el motivo; lo que se cita es una falta de política con apariencia defendible, y el remedio regulatorio, aun cuando arranca, puede tardar años y luego esfumarse.

— Apple, organización de #AppleToo, octubre de 2021

El mecanismo: ningún despido con nombre, y ahí está el punto. Aware, una empresa que vende monitoreo con IA del chat laboral en Slack, Microsoft Teams y herramientas similares, puntúa los mensajes por sentimiento y «toxicidad» a gran escala. Según informó CNBC en 2024, sus sistemas habían analizado del orden de 20.000 millones de interacciones de más de 3 millones de empleados, y entre sus clientes nombrados figuraban Walmart, Delta, T-Mobile, Chevron y Starbucks.

No hay ningún despido público atado a una sola puntuación de Aware, y no hace falta que lo haya. Aware marca; la empresa cliente decide qué hacer con la marca. La amenaza es estructural, no anecdótica, que es justo por lo que no produce un despido de portada como los dos primeros casos, y por lo que es la más difícil de combatir.

— Aware, monitoreo laboral con IA, reportado en 2024

Lee los tres como un conjunto y la síntesis es más nítida que cualquier caso suelto. El episodio de Twitter muestra que el método de monitoreo más antiguo —una persona leyendo una crítica registrada— sigue produciendo los despidos más rápidos. El de Apple muestra que el monitoreo suele ser la prueba del pretexto, no la causa declarada: el despido se viste de falta de política mientras el verdadero detonante es una actividad protegida. Y Aware señala la trayectoria: lejos de una persona que decide qué dice un mensaje, hacia una máquina que puntúa qué implica un patrón. Los dos primeros tratan de un contenido que puedes elegir. El tercero trata de un tono que no controlas del todo, y esa distinción es la actualización entera que 2024 trajo a este modelo de amenazas.

El modelo de amenazas: qué provoca de verdad el despido
#

Los despidos que nacen del monitoreo del chat laboral se agrupan en un puñado de detonantes, y no entrañan el mismo riesgo: la crítica a la dirección y la actividad de organización suman la mayoría de los casos reportados, las marcas de sentimiento son el tercero emergente, y la protección legal que debería cubrir la categoría intermedia es real, pero se aplica con lentitud y de forma despareja. Conocer la taxonomía te permite defenderte del riesgo concreto que cargas, en lugar de diluir tu cautela en todo.

Cuatro detonantes hacen casi todo el trabajo, y no entrañan el mismo riesgo:

Detonante del despido	Caso de referencia	Cómo suele aparecer	Riesgo relativo
Crítica a la dirección en canales registrados o públicos	Twitter, 2022	Citada directamente, o una captura reenviada hacia arriba: no hace falta herramienta especial	El más frecuente
Organización y reclamos de equidad salarial	Apple, 2021	Casi nunca se atribuye a la organización; se viste de un problema de política simultáneo (un archivo borrado, una regla de dispositivo)	Alto, casi siempre disfrazado
Marcas de sentimiento y de riesgo	Aware, 2024	Una puntuación opaca sin un solo mensaje como causa: nada concreto que señalar ni que apelar	Emergente, difícil de rebatir
Investigaciones por filtración y confidencialidad	Vehículo de los demás	El motivo declarado que habilita una auditoría dirigida contra alguien incómodo por otra razón	Amplifica a los otros tres

Leída de arriba abajo, la tabla también ordena tu exposición: los dos primeros detonantes suman la mayoría de los despidos documentados, el tercero es el que asciende, y el cuarto es la forma habitual de ejecutar los demás.

Este es el matiz legal que las listas de higiene aplanan, y pesa lo suficiente como para enunciarlo con precisión. En Estados Unidos, la National Labor Relations Act protege la actividad concertada —empleados que actúan juntos en torno a salarios, horarios y condiciones de trabajo, lo que abarca buena parte de la organización y de la discusión sobre equidad salarial, y que aplica a la mayoría de los trabajadores del sector privado, haya o no sindicato—. Esa protección es genuina. También es una protección que no opera en el momento: se aplica a posteriori, mediante una denuncia ante la National Labor Relations Board o un litigio, con la carga sobre el empleado de demostrar que la actividad protegida fue el verdadero motivo de una medida adversa. Los desenlaces varían, los plazos se cuentan en meses o años, y la cobertura difiere según la jurisdicción y la categoría de trabajador. El asunto de Apple es ilustrativo de las dos caras a la vez: los organizadores tenían un reclamo de actividad protegida, y el hallazgo preliminar de fundamento de la NLRB llegó más de un año después del despido, solo para ser retirado en 2025 sin un fallo definitivo. Trata la NLRA como una razón para documentar con cuidado y actuar de forma colectiva, no como una inmunidad en tiempo real. Esto es información general extraída de la cobertura pública y de la ley, no asesoría legal; para tu situación, consulta a un abogado laboralista.

El giro de 2024: cuando el lector se volvió un algoritmo
#

La actualización más importante de este modelo de amenazas es que el lector de tu chat laboral ya no es, de forma fiable, un administrador humano que necesita un motivo para fijarse en ti: es, cada vez más, un sistema de IA siempre activo que puntúa cada mensaje por sentimiento y riesgo, y ese solo cambio vuelve casi inútil el consejo estándar de evitar ciertas palabras. La cobertura de Aware marca el punto de inflexión: monitoreo a la escala de miles de millones de interacciones, aplicado de forma continua, a todo el mundo, sin una investigación como condición previa.

Entiende por qué esto derrota al manual antiguo. El monitoreo por palabras clave —la exportación humana, la búsqueda de un término concreto— se evita no usando el término. Puedes evitar nombrar al directivo, evitar la palabra sindicato, rodear el detonante. La puntuación de sentimiento no tiene palabra clave que evitar. Lee el tono, la frustración, la trayectoria de tu ánimo a lo largo de semanas; construye un patrón a partir de cómo escribes, no solo de qué escribes. No hay manera de redactar que un modelo que no puedes inspeccionar lea de forma fiable como «neutral», ajustado a umbrales que nunca te muestran, por un proveedor cuya lógica de puntuación es un secreto comercial. La conversación no necesita contener una palabra prohibida para que la marquen como un problema.

Tres consecuencias reordenan la defensa. Primera, el colchón del juicio humano se adelgaza. Un revisor humano aporta contexto —el sarcasmo, una mala semana, una broma interna— que una puntuación automatizada descarta por diseño; la marca llega despojada del mismo matiz que habría disculpado el mensaje. Segunda, no hay nada concreto que apelar. Un despido que se rastrea hasta una palabra clave te da un mensaje específico que rebatir; un despido aguas abajo de una «puntuación de riesgo» agregada te da un número sin ninguna frase pegada. Tercera, y la más útil, borra la distinción entre canales. Si el tono se puntúa en todas partes, todo el tiempo, entonces la disciplina de canal es tu único control real: no la elección de palabras dentro de la plataforma de la empresa, sino sacar de esa plataforma, por completo, las conversaciones que cargan el verdadero riesgo. Que es justo el manual.

El manual defensivo
#

Defenderse del monitoreo del chat laboral consiste en ajustar tu control al detonante concreto que cargas, y los controles caen en tres niveles: separa tus cuentas y tus dispositivos para que la vigilancia laboral no alcance tu vida personal, practica la disciplina de canal dentro del trabajo y —si haces algo cercano a la organización— saca la conversación de alto riesgo de la plataforma de la empresa antes de que empiece. No necesitas todo. Necesitas la capa que encaja con tu amenaza.

Separa las superficies. Mantén el trabajo y lo personal en dispositivos distintos y cuentas distintas, sin solapamiento: ningún inicio de sesión personal en el portátil del trabajo, ningún chat de trabajo en tu teléfono personal más allá de lo estrictamente necesario. Esta es la base que los resúmenes de IA ya te dan, y es correcta: impide que el monitoreo de un contexto alcance al otro, y es el control más barato de adoptar. También es necesaria pero insuficiente, porque no hace nada respecto a lo que dices dentro de la superficie de trabajo.

Practica la disciplina de canal. En cualquier espacio administrado por la empresa, escribe cada mensaje —incluidos los mensajes directos, incluidos los canales marcados como privados— como si fuera a exportarse y a leerlo alguien sin simpatía hacia ti, porque quien opera el sistema puede hacer exactamente eso. No se trata de autocensurar tu competencia hasta el silencio; se trata de no poner nunca la frase que acaba con tu carrera en un sistema que controla su destinatario.

Saca la conversación de alto riesgo de la plataforma, pronto. Si te organizas, planteas equidad salarial o preparas cualquier cosa que una empresa tendría incentivos para vigilar, la jugada de mayor palanca es sostener esa conversación en un lugar donde tu empresa no opere, antes de que esté en marcha y no después de que la descubran. En un dispositivo personal, en tu propio tiempo, un canal cifrado de extremo a extremo como Signal o SimpleX mantiene el contenido fuera de la exportación por completo; lo relevante es el diseño de estas herramientas, que minimiza los metadatos, no una función suelta. Este es el arreglo estructural que señala el caso de Apple: la conversación de organización que vive en la plataforma de la empresa es prueba; la que nunca la tocó, no lo es. Acompaña esto con el principio más amplio de que lo que publicas es difícil de despublicar: la permanencia de tu huella digital rige dentro de un registro laboral tanto como en las redes sociales.

Conoce tus protecciones de actividad concertada, y documenta. Si tu actividad es concertada —acción colectiva sobre salarios, horarios o condiciones de trabajo—, es probable que entre en la protección de la NLRA, lo que conviene saber con precisión justamente porque moldea lo que registras. Lleva una cronología fechada y contemporánea de la actividad protegida y de cualquier trato adverso que la siga, guardada en un dispositivo personal. No estás construyendo inmunidad; estás construyendo el registro probatorio que una denuncia posterior o un abogado laboralista necesitarán, dado que la carga de demostrar el verdadero motivo recaerá sobre ti.

Por qué la defensa individual no basta
#

Este es el límite honesto, y un caso de estudio sobre fallos de OPSEC que lo ocultara estaría haciendo lo mismo que las listas de higiene. La disciplina de canal y la separación de dispositivos protegen al individuo; no cambian las condiciones que produjeron la vigilancia, y frente a una puntuación automatizada y opaca aplicada a todos a la vez, la técnica individual se agota. Puedes mantener la frase que provoca el despido fuera de la plataforma de la empresa. No puedes, en solitario, salirte de una puntuación de sentimiento que corre sobre todo el espacio de trabajo, ni restaurar el colchón de juicio humano que el monitoreo automatizado elimina, ni desplazar una carga de la prueba que la ley pone sobre ti.

Los casos lo dicen cuando los lees como un conjunto. Los despidos de Twitter fueron una asimetría de poder, no un problema de redacción. Los organizadores de Apple necesitaron peso colectivo y la atención de un regulador —la NLRB, no un mejor OPSEC— para siquiera dejar el reclamo en acta, y aun así el hallazgo fue preliminar, llegó mucho después de que los empleos se hubieran perdido y luego se retiró sin un fallo definitivo. El modelo de Aware es estructural por construcción: se vende como monitoreo de todos, que es precisamente lo que ningún individuo puede rodear. La palanca que de verdad mueve estas condiciones es la que los cypherpunks siempre nombraron cuando la criptografía individual se topa con el poder institucional: la acción colectiva y el cambio de reglas. Una aplicación más firme de las protecciones de actividad concertada, requisitos de transparencia para la puntuación laboral automatizada, una organización con los números suficientes para volver costosa la represalia. La defensa individual te compra seguridad y tiempo; no arregla, por sí sola, la asimetría.

Ese es el hilo conductor de todo el trabajo de Privacidad de esta web. La vigilancia que enfrentas de tu empresa tiene la misma forma que la que enfrentas de una base de datos del gobierno que se filtra: no puedes borrarte de un sistema en el que estás obligado a participar, así que la defensa vive en las capas que controlas y, más allá de ellas, en la presión colectiva. Y el motor más profundo bajo todo esto es el que cartografiamos en OPSEC en la era de la IA: una vez que el lector es una máquina que puntúa el tono de forma continua, la vieja regla de evitar la palabra equivocada deja de funcionar, y el modelo de amenazas hay que reconstruirlo en torno al patrón, no al enunciado. Mantén cerca el resto del pilar de Privacidad: el monitoreo laboral es una cara de un solo problema.

«La privacidad es necesaria para una sociedad abierta en la era electrónica. … No podemos esperar que los gobiernos, las empresas u otras organizaciones grandes y sin rostro nos concedan privacidad por su benevolencia.» — Eric Hughes, Un manifiesto cypherpunk, 1993

La empresa es aquí la organización sin rostro, y el registro de chat es la era electrónica. Defiende el caso individual y, después, presiona sobre las condiciones, porque ningún proveedor de vigilancia, ni ninguna empresa que compre uno, te concederá privacidad por su benevolencia.

Conclusión: ¿qué defensa encaja con tu situación?
#

El nivel correcto de cautela depende por entero de qué haces en esa ventana de chat y de quién tiene motivos para vigilarte.

Si eres un empleado general sin una exposición concreta: trata el espacio de trabajo como exportable por defecto, separa tus dispositivos y cuentas de trabajo de los personales, y mantén la frase que arruina carreras fuera de cualquier sistema controlado por la empresa. Así resuelves la mayor parte de tu riesgo a bajo costo.
Si te organizas, planteas equidad salarial o haces cualquier cosa que una empresa quiera vigilar: tu primera línea está fuera de la plataforma. Lleva la conversación sustantiva a un dispositivo personal por un canal cifrado antes de que esté en marcha, documenta una cronología fechada de la actividad protegida y de cualquier represalia, y aprende tus protecciones de actividad concertada como algo que moldea la prueba, no como una inmunidad en tiempo real.
Si diriges un equipo de privacidad o seguridad: el giro de 2024 es tu insumo de planificación. Asume que los empleados están sujetos a una puntuación de sentimiento automatizada cuya lógica no puedes ver, diseña la política partiendo de que el tono ya se monitorea y no existe un conjunto de palabras seguro, y sopesa el costo estructural de concentrar la vigilancia del chat bajo un proveedor externo frente a la eficiencia que te venden.

En los tres casos rige la misma verdad que regía en cada fallo de OPSEC anterior: no puedes des-enviar tu camino a la seguridad después de que un mensaje queda registrado. Solo puedes decidir, antes de escribir, a qué sistema le permites guardar la frase y, pasado el límite de lo que una persona puede hacer, actuar con otros para cambiar las condiciones que pusieron al sistema a vigilarte en primer lugar.

Puntos clave

Que tu empresa pueda leer tu Slack está zanjado —sí, incluidos los mensajes directos «privados»—. La pregunta decisiva es qué te hace perder el empleo, y ese es un modelo de amenazas distinto que las listas de higiene se saltan.
Monitoreo y despido — Twitter, 2022: criticar a la dirección en canales registrados o públicos es el camino documentado más rápido de monitoreado a despedido, y no requiere herramienta especial.
Monitoreo y despido — Apple, 2021: la organización rara vez es el motivo declarado; el pretexto es una falta de política simultánea (un archivo borrado, una regla de dispositivo). Una oficina regional de la NLRB halló fundamento en el reclamo de derechos de los trabajadores más de un año después: un paso preliminar que el organismo retiró en 2025 sin un fallo definitivo.
El giro de 2024 — Aware: la puntuación de sentimiento automatizada y continua de miles de millones de mensajes significa que no hay palabra clave que evitar; se puntúa el tono mismo, de modo que esquivar palabras ya no sirve y la disciplina de canal es el único control real.
Realidad legal — la NLRA: protege la actividad concertada sobre salarios y condiciones, pero la aplica a posteriori con la carga sobre ti; trátala como una razón para documentar y organizarte, no como una inmunidad en tiempo real.
El límite: la defensa individual compra seguridad y tiempo, pero no te saca de una puntuación que abarca todo el espacio de trabajo ni arregla la asimetría de poder; eso lo hacen la acción colectiva y el cambio de reglas.

Preguntas frecuentes
#

¿Puede mi empresa leer mis mensajes directos de Slack?
#

En un espacio de trabajo de Slack administrado por la empresa, en general sí. Los administradores de los planes de pago pueden exportar y buscar el historial de mensajes, incluidos los mensajes directos y los canales marcados como privados. Privado es un ajuste de visibilidad entre usuarios, no una barrera frente a quien opera el sistema. Trata cualquier mensaje en un espacio controlado por la empresa —los mensajes directos incluidos— como legible y exportable por la empresa.

¿Es legal el monitoreo del chat laboral?
#

En Estados Unidos y en muchas jurisdicciones comparables, monitorear las comunicaciones en sistemas propiedad de la empresa y en cuentas corporativas suele estar permitido, y la situación por defecto en un espacio de trabajo es que tus mensajes son de la empresa para monitorearlos. Las reglas concretas varían según la jurisdicción y según lo que se monitoree, y hay categorías de actividad protegidas (mira la NLRA más abajo). Esto es información general, no asesoría legal: consulta a un abogado laboralista para tu situación.

¿Me protege la NLRA si critico a mi empresa en Slack?
#

En parte, y bajo condiciones. La National Labor Relations Act protege la actividad concertada —empleados que actúan juntos en torno a salarios, horarios y condiciones de trabajo, lo que cubre buena parte de la organización y de la discusión sobre equidad salarial para la mayoría de los trabajadores del sector privado—. Pero se aplica a posteriori, mediante una denuncia ante la NLRB o un litigio, con la carga sobre ti de demostrar que la actividad protegida fue el verdadero motivo de una medida adversa; los desenlaces y los plazos varían. El desahogo individual que no es colectivo ni trata de las condiciones de trabajo, en general, no está cubierto.

¿Puedo evitar que la IA me marque por el monitoreo de sentimiento?
#

No de forma fiable cambiando tus palabras. Herramientas como las reportadas en 2024 puntúan el tono y los patrones en todos tus mensajes en lugar de buscar palabras clave concretas, así que no hay frase que un modelo que no puedes inspeccionar lea de forma fiable como neutral. El control realista no es la redacción dentro de la plataforma de la empresa: es mantener las conversaciones de alto riesgo fuera de esa plataforma por completo.

¿Qué herramientas ayudan de verdad contra el monitoreo laboral?
#

Para las conversaciones que cargan el verdadero riesgo —organización, equidad salarial, cualquier cosa que una empresa quiera vigilar—, llevarlas fuera de la plataforma de la empresa, a un dispositivo personal, por un canal cifrado de extremo a extremo y que minimice los metadatos, como Signal o SimpleX, mantiene el contenido fuera de cualquier exportación. Dentro del trabajo, los controles son separar dispositivos y cuentas de trabajo y personales, y un uso disciplinado de los canales. Ninguna herramienta dentro de un espacio administrado por la empresa vuelve tus mensajes ilegibles para su administrador.

#	Fuente	URL	Copia archivada
1	NBC News — Despidos en Twitter tras la adquisición y Eric Frohnhoefer (nov 2022)	https://www.nbcnews.com/news/amp/rcna57250	https://web.archive.org/web/*/https://www.nbcnews.com/news/amp/rcna57250
2	CNN Business — Apple despide a la organizadora de #AppleToo Janneke Parrish (oct 2021)	https://www.cnn.com/2021/10/15/tech/apple-appletoo-organizer-janneke-parish/index.html	https://web.archive.org/web/*/https://www.cnn.com/2021/10/15/tech/apple-appletoo-organizer-janneke-parish/index.html
3	TechCrunch — La NLRB halló que directivos de Apple vulneraron los derechos de los trabajadores (ene 2023)	https://techcrunch.com/2023/01/30/labor-officials-found-that-apple-execs-infringed-on-workers-rights/	https://web.archive.org/web/*/https://techcrunch.com/2023/01/30/labor-officials-found-that-apple-execs-infringed-on-workers-rights/
4	CNBC — La IA podría estar leyendo tus mensajes de Slack y Teams, vía Aware (feb 2024)	https://www.cnbc.com/2024/02/09/ai-might-be-reading-your-slack-teams-messages-using-tech-from-aware.html	https://web.archive.org/web/*/https://www.cnbc.com/2024/02/09/ai-might-be-reading-your-slack-teams-messages-using-tech-from-aware.html
5	National Labor Relations Board — Actividad concertada (derechos de la Sección 7)	https://www.nlrb.gov/about-nlrb/rights-we-protect/the-law/employees/concerted-activity	https://web.archive.org/web/*/https://www.nlrb.gov/about-nlrb/rights-we-protect/the-law/employees/concerted-activity
6	Reuters — El organismo laboral de EE. UU. retira las acusaciones de que el CEO de Apple violó derechos de los empleados (sep 2025)	https://www.reuters.com/sustainability/sustainable-finance-reporting/us-labor-board-withdraws-claims-apple-ceo-violated-employee-rights-bloomberg-2025-09-26/	https://web.archive.org/web/*/https://www.reuters.com/sustainability/sustainable-finance-reporting/us-labor-board-withdraws-claims-apple-ceo-violated-employee-rights-bloomberg-2025-09-26/

Cora Aegis

Cora Aegis escribe orientación de OPSEC con la privacidad por delante en CypherpunkGuide, leyendo casos cerrados de vigilancia para hallar el mecanismo que casi toda la cobertura se salta: aquí, cómo un registro de chat laboral se convierte en un despido.

Más sobre Cora →

Privacidad del número de teléfono: lo que aún funciona en 2026

Tue, 14 Jul 2026 00:00:00 +0000

Todos los formularios de alta lo piden. Tu banco, tu dentista, la tarjeta de puntos del supermercado y —lo comprobé este mes al recopilar los requisitos de registro de seis grandes servicios de IA— hasta tu chatbot. Un usuario de r/privacy lo resumió mejor que la mayoría de las empresas de seguridad: el número de teléfono es el nuevo SSN («the phone number is the new SSN» en el original), el número de la seguridad social estadounidense. Es el identificador que casi nadie cambia en toda su vida, el que te sigue de servicio en servicio y el que sueltas decenas de veces al año. Eso lo convierte en la llave de cruce más barata que pueden desear un adversario o un data broker (un comerciante de datos).

La complicación es que 2026 está cerrando las salidas por los dos extremos a la vez. Desde arriba, la FCC —el regulador de las telecomunicaciones de EE. UU.— propone que cada operadora recoja de todo cliente, nuevo o en renovación, «el nombre, la dirección física, el número de un documento de identidad oficial y un número de teléfono alternativo» (en el original: “the name, physical address, government issued identification number, and an alternate telephone number”) — el modelo que 157 países ya aplicaban de alguna forma según el recuento global de Privacy International de 2021. Desde abajo, los servicios rechazan en silencio el atajo que toda guía recomienda primero: los números VoIP, los números de teléfono por internet que reparten apps como Google Voice o Hushed y que no dependen de ninguna tarjeta SIM. El centro de ayuda de Anthropic ya avisa de que para abrir una cuenta de Claude no puedes usar «números VoIP, Google Voice, números de teléfono creados con apps, líneas fijas» (“VoIP numbers, Google Voice, phone numbers created using apps, landlines” en el original), y el propio Google Voice empezó a exigir un documento de identidad oficial a los usuarios nuevos en enero de 2026. Mientras tanto, el número que ya tienes sigue goteando: el FBI registró 982 denuncias de SIM swap —el secuestro de la SIM— y 26 millones de dólares en pérdidas en 2024, y una empresa de vigilancia fue sorprendida explotando SS7 —la red de señalización entre operadoras, diseñada en los años setenta— para localizar teléfonos por su número durante 2024 y 2025.

Así que la pregunta honesta no es «cómo escondo mi número de teléfono». No puedes esconderlo del todo, y fingir lo contrario es la manera de que alguien acabe herido. La pregunta es qué número hace qué trabajo. Este artículo traza lo que revela un número, documenta la tenaza con fuentes primarias y una tabla país por país, muestra —con mis propias pruebas de alta— qué servicios rechazan de verdad los números alternativos, y despliega después la estrategia de cuatro números que aún funciona, ajustada a cuatro modelos de amenaza concretos.

Tu número de teléfono ya es un documento de identidad
#

Atar la identidad al número de teléfono significa usar tu número como prueba de quién eres, no solo como una vía para localizarte. Ese es el cambio. Un dato de contacto se sustituye; un ancla de identidad es lo que las cuentas, los comerciantes de datos y los gobiernos usan para unir todo lo demás. Tres mecanismos hacen que el número sea especialmente peligroso en ese papel.

Abre cuentas que nunca debiste poder perder. Un SIM swap —el secuestro de la SIM— es un ataque en el que alguien convence a tu operadora para pasar tu número a su propia tarjeta; a partir de ese momento, cada SMS —códigos de acceso incluidos— le llega al atacante. No es nada exótico. Cuando investigadores de Princeton pusieron a prueba a cinco grandes operadoras estadounidenses de prepago en 2020, sus intentos de secuestro triunfaron en 39 de 50 casos (78 %); y de las más de 140 webs populares que auditaron, en 17 se podía tomar el control con solo el número de teléfono, sin contraseña alguna. El IC3 —el centro de denuncias de ciberdelitos del FBI— registró 982 denuncias de SIM swap con 25,98 millones de dólares perdidos en 2024; menos que los 72,7 millones de 2022, aunque parte de las pérdidas puede estar contabilizada hoy en categorías de fraude vecinas.

Difunde tu ubicación a cualquiera que pueda alquilar el acceso. SS7, la red de señalización que las operadoras usan para encaminar llamadas entre sí, permite a quien logra entrar preguntar «¿dónde está este número ahora mismo?». En 2025, investigadores de la firma de seguridad de telecomunicaciones Enea documentaron a una empresa de vigilancia que usaba un comando malformado para saltarse las defensas de las operadoras y extraer ubicaciones de teléfonos a demanda — una clase de ataque que Enea sigue viendo en uso activo desde finales de 2024. No hace falta que pulses nada. Basta con que alguien sepa tu número.

Acaba en tu nombre. En Estados Unidos, CNAM —la base de datos de las operadoras que asocia cada número al nombre de quien llama— convierte números en nombres registrados, y los buscadores comerciales de personas cruzan números con datos de filtraciones, censos electorales y registros de propiedad para devolver un nombre y un domicilio por unos pocos dólares. Un número «privado» que alguna vez estuvo ligado a tu identidad es una entrada de índice, para siempre. Es la misma permanencia que documenté con el historial de redes sociales: borrar la copia visible no borra la llave de cruce.

La tenaza: identificación desde arriba, rechazo desde abajo
#

Este es el giro estructural al que la mayoría de las guías aún no ha llegado: las dos salidas de siempre —comprar una SIM de prepago en efectivo o usar un número de internet— se están cerrando a la vez desde extremos opuestos. Entender las dos mordazas de la tenaza es lo que hace que la estrategia de las siguientes secciones sea realista y no nostálgica.

Desde arriba: los registros obligatorios. Según la revisión global de Privacy International de 2021, 157 países exigían registrar la identidad para comprar una SIM; solo 34 no lo hacían; y 14 pedían datos biométricos, como el escaneo facial. La lista sin registro no deja de encoger: la Suprema Corte de México anuló un padrón biométrico de SIM en 2022 y, aun así, en enero de 2026 llegó la obligación de registrar la línea con la CURP —la clave de identidad nacional mexicana—, con suspensión de las líneas no registradas desde julio de 2026. Estados Unidos venía siendo la gran excepción —sin mandato federal de registro—, y eso es exactamente lo que acabaría la propuesta de la FCC de abril de 2026 (expediente CG 17-59, publicado en el Federal Register el 26 de mayo): una obligación de verificación de identidad (KYC, «conoce a tu cliente») con nombre, domicilio, número de documento oficial y un teléfono alternativo, todo conservado durante cuatro años después de que dejes de ser cliente. Es una propuesta, no una ley —el plazo de réplicas corre hasta el 27 de julio de 2026—, pero la deriva es inequívoca. Japón se movió en la misma dirección un mes antes: una reforma de mayo de 2026 de su ley contra el uso fraudulento de móviles extiende la verificación de identidad a las SIM de solo datos, el último rincón sin identificación de aquel mercado, con plazo de aplicación hasta mayo de 2027.

No son los delincuentes a quienes aprieta primero esta tenaza. La National Network to End Domestic Violence —la red nacional de EE. UU. contra la violencia doméstica— dijo a la FCC que las conductas «sospechosas» que persigue la propuesta —pagar en efectivo, usar un apartado de correos o una dirección de reenvío— «son, para las supervivientes, prácticas de seguridad asentadas y, a menudo, las que les salvan la vida» (en el original: “are, for survivors, well-established and often life-preserving safety practices”). Una mujer que huye de su maltratador puede no tener una dirección segura que dar ni documentos que pueda recuperar. Los periodistas y sus fuentes cargan con el mismo problema, con otras cosas en juego. Es el patrón al que vuelvo una y otra vez en este sitio: los controles de identidad diseñados contra el fraude golpean con más dureza a quienes más tienen que perder.

La situación de tu país. Construí esta tabla a partir de fuentes legales primarias y del estudio de Privacy International; cada fila lleva su propia fuente y su fecha de comprobación. Es una instantánea de regímenes representativos, no una lista completa.

País	¿Identificación obligatoria para la SIM de prepago?	Qué se comprueba	SIM de solo datos	Fuente
Estados Unidos	Sin obligación legal — Propuesta de la FCC pendiente (2026): añadiría la recogida de identificación	—	—	fuente · 2026-07-14
Reino Unido	Sin obligación legal	—	—	fuente · 2026-07-14
Portugal	Sin obligación legal	—	—	fuente · 2026-07-14
Alemania	Obligatoria por ley (2017)	Documento de identidad oficial	Misma regla	fuente · 2026-07-14
España	Obligatoria por ley (2007)	Documento de identidad oficial	Misma regla	fuente · 2026-07-14
México	Obligatoria por ley (2026) — Registro biométrico anulado en 2022; registro con CURP en vigor desde enero de 2026	Documento de identidad oficial	Misma regla	fuente · 2026-07-14
Brasil	Obligatoria por ley	Documento de identidad oficial	Misma regla	fuente · 2026-07-14
Japón	Obligatoria por ley (2006) — La reforma de 2026 extiende la verificación de identidad a las SIM de solo datos, con plazo hasta mayo de 2027	Documento de identidad oficial	Exenta hoy	fuente · 2026-07-14
China	Obligatoria por ley (2019)	Documento oficial + escaneo facial	Misma regla	fuente · 2026-07-14

Instantánea de regímenes representativos, no una lista completa — las normas cambian; cada fila lleva su fuente y su fecha de última comprobación. «Sin obligación legal» no significa que la operadora no recoja nada: siguen existiendo los registros de pago, las cámaras de las tiendas y las políticas de cada operadora.

Antes de aplicar nada de lo que sigue, busca en la tabla de arriba la fila del país donde vives. Si lees desde España, tu fila quedó decidida hace tiempo: el registro es obligatorio desde 2007 (Ley 25/2007), la capa de prepago queda ligada a tu identidad en el mismo mostrador, y las otras tres capas tienen que sostener la separación. Si lees desde México, la historia es más reciente: la Suprema Corte tumbó el registro biométrico en 2022, pero desde enero de 2026 rige el registro con CURP y las líneas no registradas se suspenden desde julio de 2026 — cuenta con que el prepago anónimo deja de existir ahí también. Desde cualquier otro país: localiza tu fila y abre la fuente que la acompaña antes de dar nada por hecho.

Desde abajo: los propios servicios. Incluso donde la ley calla, las plataformas rechazan cada vez más los números que no cuelgan de un contrato con una operadora — y saben distinguirlos. La API Line Type Intelligence de Twilio, una de varias consultas comerciales, clasifica cualquier número en doce tipos — mobile, landline, fixedVoip, nonFixedVoip, etcétera — y Twilio vende abiertamente a los equipos antifraude la posibilidad de filtrar los números «nonFixedVoip» de sus flujos de verificación. Google Voice, que durante años fue la recomendación de privacidad por defecto, exige desde el 30 de enero de 2026 verificación con documento oficial para estrenar número. El ecosistema de atajos se está quedando sin sitio: lo que antes era gratis ahora exige documentos, permiso o las dos cosas.

Comprobé qué servicios de IA rechazan los números alternativos
#

Una advertencia abstracta sirve menos que una lista contrastada. En julio de 2026 revisé los requisitos de alta vigentes de seis grandes servicios de IA en sus propios centros de ayuda, condiciones y políticas de privacidad, archivando cada fuente como parte de un conjunto de datos de requisitos más amplio que estoy construyendo — trata la tabla como una instantánea con fecha y verifica las páginas actuales de cada proveedor antes de apoyarte en ella. Los asistentes de IA son un buen banco de pruebas: son la categoría de cuentas que más crece y, como mostré en la auditoría de asistentes de IA, lo que les cuentas queda registrado.

Servicio	Teléfono en el alta (a fecha de julio de 2026)	Vía sin número	El detalle que importa
Claude (Anthropic)	Obligatorio — todas las cuentas nuevas, solo SMS	Ninguna	Rechaza VoIP, Google Voice, números de apps y fijos; una cuenta por número
ChatGPT (OpenAI)	No exigido vía email o cuenta externa	Email o inicio de sesión con Google/Microsoft/Apple (SSO)	El alta solo con teléfono existe, pero está limitada a 13 regiones listadas
Gemini (Google)	Sigue las reglas de la cuenta de Google	Cuenta de Google	El vínculo es con toda tu identidad de Google, no solo con un número
DeepSeek	Email o teléfono	Vía email	En el registro vale cualquiera de los dos identificadores
OpenRouter	No exigido	Email/SSO	Es un enrutador: la exposición de tu identidad se traslada al proveedor que sirva cada modelo
Venice	No exigido	Email, cuenta social o monedero cripto	La demo funciona sin cuenta alguna — la vía con menos ataduras que encontramos

La fila de Claude merece la cita literal, porque es la declaración más nítida de la nueva normalidad que haya publicado un servicio grande: «Exigimos la verificación telefónica a todos los usuarios nuevos y no hay forma de saltarse este paso… no puedes usar números VoIP, Google Voice, números de teléfono creados con apps, líneas fijas ni otros números que no puedan recibir SMS para verificar tu cuenta» (en el original: “We require phone verification for all new users, and there isn’t a way to skip this step… you cannot use VoIP numbers, Google Voice, phone numbers created using apps, landlines, or other numbers that can’t receive texts to verify your account”). Un número móvil real, una cuenta. La horquilla de esa tabla es la lección práctica: la misma categoría de producto va desde «teléfono verificado por la operadora, sin excepciones» hasta «no hace falta ni cuenta». Qué número merece cada servicio —si es que merece alguno— sigue siendo decisión tuya, pero solo si lo compruebas antes de teclear el de verdad.

La estrategia de cuatro números que aún funciona
#

La vulnerabilidad es que un único número hace todos los trabajos. El arreglo duradero es separar funciones — la misma lógica de compartimentación que recorre el modelo de amenazas en la era de la IA — aplicada al identificador que todo el mundo olvida compartimentar. Los números son baratos; lo caro es que una sola llave de cruce basta para encontrarte. Cuatro capas, de la más protegida a la más desechable:

Capa	El número	Dáselo a	No lo uses jamás para
1 — Caja fuerte	Tu número real de operadora	Tu operadora, los bancos que te obligan al SMS, la administración pública	Altas en webs, apps de mensajería, directorios
2 — Identidad	Mensajería segura detrás de un nombre de usuario	Las personas con las que hablas de verdad	Publicar en abierto; dejar activado que te encuentren por el número
3 — Cuentas	Uno o dos números VoIP	Tiendas, boletines, apps que acepten VoIP	Cualquier cosa que pueda mover dinero
4 — Frontera	SIM de prepago (donde sea legal) o ningún número	Verificaciones puntuales, anuncios clasificados, viajes	Entrar en cuentas de las capas 1 y 2

Montarlo, por orden:

Blinda la caja fuerte antes que nada. Llama a tu operadora y activa un PIN de portabilidad o un bloqueo del número — los resultados de Princeton muestran por qué la autenticación de las operadoras es el muro más débil. Después retira tu número real de toda cuenta que permita sustituirlo por una app de códigos o una llave de acceso (passkey); el SMS debería ser tu segundo factor solo donde no ofrezcan nada más.
Convierte tu número de mensajería en un nombre de usuario. Signal permite ocultar el número detrás de un nombre de usuario desde febrero de 2024: registrarse sigue exigiendo un número, pero con «¿Quién puede encontrarme por mi número?» en Nadie, tus contactos ven cora.01, no dígitos. La capa 2 existe porque poder localizarte y saber quién eres nunca fueron lo mismo.
Compra la capa de cuentas. Un servicio VoIP —telefonía por internet, números sin SIM detrás— como MySudo o Hushed te da números compartimentados por unos dólares al mes; JMP.chat funciona sobre XMPP —un protocolo abierto de mensajería— y es popular en las comunidades de privacidad. Espera exactamente lo que enseñó la tabla de arriba: algunos servicios rechazarán estos números, y ese rechazo es en sí mismo información sobre cuánta identidad exige ese servicio.
Mantén una capa frontera donde tu fila lo permita. En los países sin registro obligatorio, una SIM de prepago pagada en efectivo sigue siendo legal y sigue siendo el verificador puntual más limpio — la propuesta de la FCC no se ha aprobado. En los países con registro, la versión honesta de esta capa es ningún número: prefiere la vía del email, la del monedero o marcharte. Lo que no recomiendo es mentir a una operadora ni esquivar una obligación legal de identificación — en los países con registro eso puede ser un delito en sí mismo, y este sitio no juega a la ruleta con los riesgos legales.

Dos apuntes de pago, brevemente: paga las capas VoIP con una tarjeta enmascarada o de prepago cuando puedas, porque un número privado facturado a tu tarjeta real es un rodeo burocrático, no un muro; y si ya guardas bitcoin sin KYC por una cuestión de principios, JMP.chat es de los pocos servicios de números que lo acepta.

Encaja los números en tu modelo de amenazas
#

Una estrategia solo significa algo frente a un adversario con nombre. Estos cuatro cubren a la mayoría de los lectores — elige el tuyo y la tabla de arriba se reduce a dos o tres movimientos concretos.

Amenaza	Qué explota	Tus movimientos
Comerciantes de datos / marketing	El número como llave de cruce entre servicios	Capa 3 en todas partes; el número de la caja fuerte, jamás en un formulario
Atacantes de filtraciones y credenciales	Códigos por SMS, identificadores reutilizados	App de códigos o passkeys en las cuentas de la caja fuerte; PIN en la operadora
Una persona — acosador, ex, hostigador	Buscadores de personas, CNAM, historia compartida	Capa 2 nueva con el número oculto; bajas en los comerciantes de datos; capa 1 que casi nadie conoce
Adversario con recursos / nivel estatal	Localización por SS7, registros de operadora, datos del registro de SIM	Ningún número que lleves encima está a salvo de la localización; dispositivos separados — mira el protocolo de publicación segura para activistas

La fila del acosador es para la que escribo. El expediente de la FCC dice en voz alta la parte que suele callarse: la red de supervivientes describe los teléfonos pagados en efectivo y las direcciones confidenciales como prácticas de seguridad «que salvan vidas» (“life-preserving safety practices” en el original), y esas son exactamente las conductas que un régimen KYC marca como sospechosas. Si tu amenaza es una persona que conoce tu nombre, el número de la caja fuerte que ya tiene es el riesgo — un número que nunca ha visto, en una mensajería que no lo confirmará, vale más que cualquier cantidad de bloqueos.

Lo que no funciona
#

Desmontar mitos es una capa de defensa por derecho propio; estos cuatro fallos cuestan dinero real y seguridad real.

«Una app de números desechables (una burner app) me hace anónima». Un número VoIP oculta tu número de operadora a la persona que llamas — no te oculta ante la app, que conoce tu método de pago, tu dirección IP y muchas veces tu agenda, y queda retratado como VoIP en cuanto un servicio consulta el tipo de línea. Compartimento útil, no capa de invisibilidad.
«Pues me cambio de número». El número viejo se queda en cada base de datos de comerciantes de datos, cada volcado de filtraciones y cada registro CNAM que tocaste, y el nuevo empieza a acumular historial en cuanto lo repartes de la misma manera. Rotar sin separar funciones no pone nada a cero.
«El prepago es anónimo». En 157 países queda registrado con tu documento en el mostrador. Incluso en los países sin registro, la compra deja rastros de pago y cámaras de tienda, y la FCC propone cerrar ese hueco del todo. Trata el prepago en efectivo como sin vínculo en la compra, no como imposible de rastrear en el uso — los hallazgos sobre SS7 de arriba valen para todas las SIM por igual.
«El doble factor por SMS es mejor que nada». Cierto, y también es el mecanismo por el que en 17 de las más de 140 webs auditadas bastaba el número para tomar el control. Donde exista una app de códigos o una llave de acceso, el SMS no es tu respaldo: es tu superficie de ataque, la puerta que dejas abierta.

En conclusión: ¿qué configuración es la tuya?
#

Si hoy haces una sola cosa: activa el PIN de portabilidad con tu operadora y retira tu número real de toda cuenta que acepte una app de códigos en su lugar. Esa única hora cierra la vía del SIM swap que produjo 26 millones de dólares en pérdidas declaradas en EE. UU. el año pasado.

Si montas el sistema completo: número de caja fuerte para la banca y la administración pública, nombre de usuario de Signal para las personas, un número VoIP para las cuentas y — donde la fila de tu país lo permita — un prepago en efectivo para la frontera. Comprueba el servicio antes de gastar el número: la diferencia entre Claude (teléfono verificado por la operadora, sin excepciones) y un servicio con acceso por monedero como Venice es la diferencia entre un vínculo de identidad permanente y ninguno, dentro de la misma categoría de producto.

Y no pierdas de vista el calendario: el plazo de réplicas de la FCC se cierra el 27 de julio de 2026, la norma japonesa de las SIM de solo datos llega como muy tarde en mayo de 2027, y cada fila de la tabla de arriba lleva su fecha de comprobación. En 2026, la privacidad del número de teléfono no es una compra; es una estructura que se mantiene.

Puntos clave

El número es un ancla de identidad: 982 denuncias de SIM swap y 25,98 millones de dólares en pérdidas (FBI IC3, 2024); Princeton logró el secuestro en el 78 % de los intentos (39 de 50) y halló que en 17 de más de 140 webs se podía tomar el control con solo el número (2020).
La tenaza es real y aprieta por los dos lados: 157 países obligan a registrar la SIM, 14 con biometría (Privacy International, 2021); la propuesta de la FCC de 2026 (CG 17-59) añadiría un KYC estadounidense con retención de 4 años, mientras Claude rechaza de plano los números VoIP y Google Voice exige documento oficial desde enero de 2026.
Cuatro números, cuatro trabajos: caja fuerte (operadora + PIN de portabilidad), identidad (nombre de usuario de Signal, número oculto desde febrero de 2024), cuentas (VoIP: MySudo/Hushed/JMP.chat), frontera (prepago en efectivo donde sea legal — o ningún número).
Primero tu fila, después el servicio: la ley de SIM varía por país (mira la tabla, con fuente por fila); los servicios van del teléfono obligatorio (Claude) al acceso por monedero (Venice) dentro de la misma categoría — verifica antes de entregar tus dígitos.
Lo que falla: el «anonimato» de las apps desechables, rotar de número sin separar funciones, el «prepago = irrastreable» (SS7 rastrea todas las SIM) y el doble factor por SMS allí donde exista una llave de acceso.

Preguntas frecuentes
#

¿Basta un número VoIP para proteger mi identidad?
#

Compartimenta — no anonimiza. Un número VoIP evita que tiendas y apps conozcan tu número de operadora, pero el proveedor VoIP conoce tu método de pago y tu dirección IP, y los servicios pueden detectar el tipo de línea con consultas como la de Twilio y rechazarlo, como hace Claude. Usa el VoIP para la capa de cuentas, nunca como tu único muro.

¿Son ilegales los teléfonos desechables en 2026?
#

En Estados Unidos, no: hoy no existe una obligación federal de identificarse para comprar una SIM de prepago, aunque la propuesta de la FCC de 2026 (réplicas hasta el 27 de julio de 2026) lo cambiaría. En los 157 países con registro obligatorio, el prepago es legal pero queda ligado a tu identidad en la compra; adquirirlo con una identidad falsa puede ser un delito. Comprueba la fila de tu país en la tabla de arriba y su fuente.

¿Signal sigue exigiendo mi número de teléfono?
#

Sí: registrarse exige un número, sin cambios desde el lanzamiento de los nombres de usuario en febrero de 2024. Lo que cambió es la exposición: con un nombre de usuario y «¿Quién puede encontrarme por mi número?» en Nadie, los demás usuarios nunca ven el número. Regístrate una vez con tu número de caja fuerte o VoIP y reparte después solo el nombre de usuario.

¿Qué pasa si la propuesta de la FCC se convierte en ley?
#

Todas las operadoras de EE. UU. —el prepago incluido— recogerían tu nombre, tu domicilio, el número de tu documento oficial y un teléfono alternativo, y guardarían esos registros cuatro años después de que te vayas. Las organizaciones contra la violencia doméstica dijeron a la FCC que eso convierte las prácticas de seguridad de las supervivientes en señales de alarma. Si sale adelante, Estados Unidos abandona el club menguante de países sin registro —34 en 2021, menos México desde enero de 2026— y la capa frontera de la estrategia se desplaza del prepago a las vías sin número.

¿Y si simplemente estreno número y empiezo de cero?
#

Solo como parte de una separación de funciones, y solo si tu amenaza es una persona concreta que tiene el viejo. El número antiguo permanece para siempre en las bases de los comerciantes de datos y en los volcados de filtraciones, y un número nuevo usado a la vieja manera — uno para todo — reconstruye el mismo perfil en cuestión de meses. La estructura vence a la rotación.

Fuentes
#

#	Fuente	URL	Archivo
1	FCC — «Enhancing Know-Your-Customer Requirements», propuesta FNPRM, expediente CG 17-59 (Federal Register, 2026-05-26)	https://www.federalregister.gov/documents/2026/05/26/2026-10407/enhancing-know-your-customer-requirements	https://web.archive.org/web/*/https://www.federalregister.gov/documents/2026/05/26/2026-10407/enhancing-know-your-customer-requirements
2	Ars Technica — la FCC planea una obligación de identificación que podría acabar con los prepagos anónimos (citas del escrito de la NNEDV, 2026-06-24)	https://arstechnica.com/tech-policy/2026/06/fcc-plans-id-mandate-that-could-block-anonymous-use-of-prepaid-burner-phones/	https://web.archive.org/web/*/https://arstechnica.com/tech-policy/2026/06/fcc-plans-id-mandate-that-could-block-anonymous-use-of-prepaid-burner-phones/
3	Privacy International — cronología de las leyes de registro de tarjetas SIM (estudio de 2021)	https://privacyinternational.org/long-read/3018/timeline-sim-card-registration-laws	https://web.archive.org/web/*/https://privacyinternational.org/long-read/3018/timeline-sim-card-registration-laws
4	FBI IC3 — informe de ciberdelincuencia de 2024 (SIM swap: 982 denuncias, 25.983.946 dólares)	https://www.ic3.gov/AnnualReport/Reports/2024_IC3Report.pdf	https://web.archive.org/web/*/https://www.ic3.gov/AnnualReport/Reports/2024_IC3Report.pdf
5	Lee et al., Princeton — estudio empírico de la autenticación de las operadoras ante el SIM swap (2020)	https://collaborate.princeton.edu/en/publications/an-empirical-study-of-wireless-carrier-authentication-for-sim-swa	https://web.archive.org/web/*/https://collaborate.princeton.edu/en/publications/an-empirical-study-of-wireless-carrier-authentication-for-sim-swa
6	Signal — mantén tu número en privado con los nombres de usuario (2024-02-20)	https://signal.org/blog/phone-number-privacy-usernames/	https://web.archive.org/web/*/https://signal.org/blog/phone-number-privacy-usernames/
7	Anthropic — cómo verificar tu número de teléfono (centro de ayuda, comprobado en julio de 2026)	https://support.claude.com/en/articles/8287232-verify-your-phone-number	https://web.archive.org/web/*/https://support.claude.com/en/articles/8287232-verify-your-phone-number
8	Google Voice — verificación de identidad obligatoria para reclamar un número (en vigor desde 2026-01-30)	https://support.google.com/voice/community-guide/405972015/identity-verification-now-required-before-you-can-claim-a-google-voice-number	https://web.archive.org/web/*/https://support.google.com/voice/community-guide/405972015/identity-verification-now-required-before-you-can-claim-a-google-voice-number
9	Twilio — Lookup v2: Line Type Intelligence (los 12 tipos de línea)	https://www.twilio.com/docs/lookup/v2-api/line-type-intelligence	https://web.archive.org/web/*/https://www.twilio.com/docs/lookup/v2-api/line-type-intelligence
10	TechCrunch — una empresa de vigilancia, sorprendida explotando un nuevo ataque SS7 para localizar teléfonos (2025-07-18)	https://techcrunch.com/2025/07/18/a-surveillance-vendor-was-caught-exploiting-a-new-ss7-attack-to-track-peoples-phone-locations/	https://web.archive.org/web/*/https://techcrunch.com/2025/07/18/a-surveillance-vendor-was-caught-exploiting-a-new-ss7-attack-to-track-peoples-phone-locations/
11	Bundesnetzagentur — requisitos de identificación para SIM de prepago (TKG, la ley alemana de telecomunicaciones; desde 2017)	https://www.bundesnetzagentur.de/DE/Fachthemen/Telekommunikation/OeffentlicheSicherheit/IdentverfahrenPrepaid/start.html	https://web.archive.org/web/*/https://www.bundesnetzagentur.de/DE/Fachthemen/Telekommunikation/OeffentlicheSicherheit/IdentverfahrenPrepaid/start.html
12	BOE — Ley 25/2007, de conservación de datos (España, registro de SIM)	https://www.boe.es/buscar/act.php?id=BOE-A-2007-18243	https://web.archive.org/web/*/https://www.boe.es/buscar/act.php?id=BOE-A-2007-18243
13	e-Gov — 携帯電話不正利用防止法, la ley japonesa contra el uso fraudulento de móviles (contexto de la reforma de 2026)	https://elaws.e-gov.go.jp/document?lawid=417AC0000000031	https://web.archive.org/web/*/https://elaws.e-gov.go.jp/document?lawid=417AC0000000031
14	Infobae — registro de celular con CURP: plazos y suspensión de líneas (México, 2026-06)	https://www.infobae.com/mexico/2026/06/15/registro-de-celular-con-curp-gobierno-aclara-que-no-existe-padron-nacional-de-telefonia-movil/	https://web.archive.org/web/*/https://www.infobae.com/mexico/2026/06/15/registro-de-celular-con-curp-gobierno-aclara-que-no-existe-padron-nacional-de-telefonia-movil/

Cora Aegis escribe sobre privacidad en Bitcoin, autocustodia y soberanía digital bajo seudónimo — una elección que este artículo debería explicar por sí sola. Las fuentes de cada estadística están listadas arriba; la tabla de países lleva su fuente y su fecha de comprobación en cada fila. Correcciones: cora@cypherpunkguide.com.

Recuperar claves de acceso en 2026: comparativa de 4 plataformas

Sat, 01 Aug 2026 00:00:00 +0000

Las claves de acceso ya superan la prueba del inicio de sesión cotidiano. El Passkey Index 2025 de FIDO Alliance registró una tasa de éxito del 93 %, frente al 63 % de otros métodos, y un tiempo medio de 8,5 segundos en lugar de 31,2. También resisten el phishing: una web falsa no puede pedirte que escribas un secreto reutilizable porque no existe ningún secreto de ese tipo que puedas teclear.

La dificultad aparece al recuperar el acceso. Una credencial excelente para entrar a diario puede seguir dependiendo del número de teléfono, la cuenta de correo, el proveedor en la nube, un dispositivo de confianza o un código en papel que la respaldan. El 1 de agosto de 2026 revisé 25 documentos oficiales o fuentes primarias de Google, Apple, Microsoft, GitHub, FIDO y NIST. Después apliqué el mismo fallo a cada ecosistema: has perdido el teléfono y la computadora que usas a diario, además de la llave física que llevas contigo; solo quedan los recursos de recuperación guardados en otro lugar. No encontré un único proceso de «recuperación de passkeys», sino una cadena de dos o tres recuperaciones con distintos puntos de bloqueo definitivo.

Por eso no basta con preguntar si una clave de acceso es más segura que el doble factor por SMS (2FA, una segunda prueba que se pide después de la contraseña). Contra el phishing, lo es. La pregunta decisiva es otra: si pierdes los dispositivos cotidianos, ¿puedes recuperar tanto la cuenta del proveedor que guarda la clave como la cuenta de destino que la aceptó, sin volver a depender del mismo dispositivo perdido? Esta guía traza esas dependencias, corrige una confusión entre cuentas personales de Microsoft y cuentas empresariales de Entra que ya aparece en buscadores, y propone una migración que prepara la recuperación antes de retirar nada. No elimines tu último método de acceso operativo mientras lees.

Recuperar una clave de acceso exige resolver dos problemas distintos
#

Puedes recuperar la credencial desde el proveedor que la guarda o recuperar la cuenta de destino y registrar una clave nueva. Son operaciones controladas por empresas diferentes: completar una no garantiza la otra.

Una clave de acceso (passkey) es una credencial criptográfica para una web o una aplicación concreta. El servicio conserva la clave pública; el dispositivo o el gestor de credenciales conserva la privada. WebAuthn, el estándar web que usan las claves de acceso, vincula esa clave al dominio auténtico del servicio. Por eso NIST SP 800-63B-4 considera que WebAuthn bien configurado resiste el phishing, mientras que un código de un solo uso introducido a mano no lo hace.

Detrás de ese acceso sencillo intervienen dos actores:

El proveedor de credenciales guarda o sincroniza la clave de acceso. Cumplen esa función la aplicación Contraseñas de Apple con el Llavero de iCloud, Google Password Manager, Microsoft Password Manager, un gestor de contraseñas independiente, Windows Hello o una llave física de seguridad.
El servicio de destino —la relying party en WebAuthn— es la web que acepta la clave. GitHub ocupa ese papel. Google y Microsoft pueden ser a la vez proveedor y servicio de destino cuando guardan la clave que abre una cuenta propia.

La primera conclusión de la auditoría nace de esa diferencia. Muchas comparativas colocan Apple, Google, Microsoft y GitHub en cuatro columnas equivalentes. No lo son: en este análisis Apple actúa sobre todo como proveedor de credenciales; GitHub, como servicio de destino. La diferencia importa especialmente después de una pérdida.

Credencial o vía	Dónde se guarda el secreto	¿Resiste la pérdida de un dispositivo?	Si pierdes todos los dispositivos cotidianos	Riesgo principal
Clave de acceso sincronizada	Gestor de credenciales cifrado de extremo a extremo	Por lo general sí, si ya hay otro dispositivo con sesión iniciada	Recuperar la cuenta del proveedor y superar su control para restaurar las claves cifradas	La recuperación pasa a depender de la cuenta del proveedor
Clave vinculada al dispositivo	Un teléfono, una computadora o una llave física	No; esa clave se pierde. La cuenta puede seguir accesible con otro autenticador	Recuperar la cuenta de destino por otra vía y registrar una clave nueva	Pérdida permanente de esa credencial
Código de recuperación	Papel o almacenamiento seguro fuera de línea	Sí	Introducir el código largo o de un solo uso	Robo, pérdida o guardarlo junto al dispositivo
Recuperación por correo o teléfono	Otra cuenta o la operadora	A veces	Recuperar primero ese canal	Phishing, SIM swap o un fallo común que elimine ambos accesos

El documento de FIDO sobre el despliegue de claves sincronizadas delimita bien la promesa. Sincronizar aumenta las probabilidades de sobrevivir a la pérdida de un dispositivo, pero aún puedes perder la cuenta del proveedor o no superar su proceso de restauración. «Sincronizada» significa que existe una copia protegida; no significa que el proveedor siempre pueda devolvértela.

Qué ocurre si pierdes todos los dispositivos cotidianos
#

Una clave sincronizada solo regresa a través de su proveedor de credenciales; una clave vinculada al dispositivo se pierde junto con él. Solo podrás volver a entrar en la cuenta de destino si queda operativo un método de recuperación guardado en otro lugar.

Apliqué exactamente ese escenario a cuatro ecosistemas y dejé las pruebas en la auditoría descargable de recuperación de claves de acceso. Es una auditoría documental, no un experimento en el que provoqué bloqueos: no retiré autenticadores de cuentas activas. Tampoco deberías hacerlo solo para reproducirla.

La matriz se limita a cuentas personales que controla su propio titular. Las cuentas administradas por una organización o por un proveedor de identidad —Google Workspace, Managed Apple Accounts, GitHub Enterprise Managed Users y las identidades de Microsoft Entra— obedecen políticas propias y quedan fuera. Las fechas de Entra aparecen más adelante únicamente para corregir la confusión entre el calendario empresarial y el de las cuentas personales.

Ecosistema	Función en esta auditoría	Cómo vuelve la clave sincronizada	Controles documentados para recuperar el acceso al proveedor o a la cuenta	Sobrevive a la pérdida de los dispositivos cotidianos si…	Límite de fallo o bloqueo definitivo
Cuenta personal de Google	Proveedor y servicio de destino	Google Password Manager mediante la cuenta de Google y su PIN, o un dispositivo usado antes que cumpla los requisitos	Proveedor / cuenta de Google: datos de recuperación; algunas cuentas elegibles pueden añadir un contacto de recuperación	Sigue accesible al menos un canal o contacto independiente del equipo perdido	No se puede recuperar el PIN y se restablecen todas las claves de la colección de Password Manager; después hay que recuperar por separado cada servicio de destino
Cuenta personal de Apple	Principalmente proveedor	Recuperación segura del Llavero de iCloud mediante los controles de la Cuenta de Apple	Proveedor / Cuenta de Apple: recuperación estándar, un contacto de recuperación aceptado o la vía opcional de la clave de recuperación	Se puede recuperar el número de confianza, o queda fuera de los dispositivos perdidos un contacto registrado o la clave de 28 caracteres	La clave de recuperación está activa, pero no queda ningún dispositivo de confianza ni la clave de 28 caracteres ni —cuando la Protección de Datos Avanzada permite ambas opciones— un contacto de recuperación configurado por separado y aún utilizable
Cuenta personal de Microsoft	Proveedor y servicio de destino	Un gestor sincronizado vuelve al iniciar sesión en su proveedor; Windows Hello o una llave física pueden quedar vinculados a un dispositivo	Proveedor / cuenta Microsoft: información de seguridad alternativa o un código de recuperación de 25 dígitos	Sigue accesible un canal alternativo o se guardó fuera de línea el código de 25 dígitos	El doble factor está activo y no hay ningún método alternativo; Microsoft afirma que el soporte técnico no puede saltarse ese control
Cuenta personal de GitHub	Principalmente servicio de destino	El proveedor restaura la credencial sincronizada; GitHub no conserva esa clave privada	Cuenta personal de destino: 16 códigos de un solo uso, otra clave de acceso o llave de seguridad, una clave SSH, un token de acceso personal (PAT) o un dispositivo verificado	Sobrevive un código fuera de línea o un autenticador guardado aparte; SSH, PAT y dispositivos verificados solo cuentan si siguen disponibles y GitHub los acepta para recuperar	No queda ninguna clave de acceso ni método de recuperación aceptado; GitHub Support no puede devolver el acceso

La tabla revela otro problema: decir «uso una clave de acceso» no aclara dónde está guardada. Un aviso de Windows puede almacenar una credencial en Windows Hello de una sola computadora y otra en un gestor sincronizado. Un proceso con código QR puede usar el teléfono solo durante esa sesión o guardar allí la clave. Antes de diseñar la recuperación, abre la lista de claves en la web y la lista de credenciales en el proveedor. Anota el proveedor y el dispositivo, no solo el nombre del servicio.

Cuatro plataformas, cuatro rutas de recuperación
#

Los cuatro ecosistemas permiten usar claves de acceso con seguridad, pero no recuperan igual. El lugar de almacenamiento, la recuperación de la cuenta del proveedor y una copia fuera del dispositivo deciden si la pérdida termina en bloqueo.

Cuentas personales de Google: el PIN de Password Manager importa
#

Google Password Manager sincroniza claves de acceso entre Android, Chrome, iPhone y iPad. Al crear por primera vez una clave en una computadora, un iPhone o un iPad, Google puede generar un PIN específico de Password Manager. La documentación del PIN explica que sirve para desbloquear las claves en un dispositivo nuevo y mantener los datos cifrados fuera del alcance de Google.

Añadir una clave de acceso a una cuenta personal de Google no elimina automáticamente la contraseña, los datos de recuperación ni los demás factores. La guía de claves de acceso de la cuenta añade que la propia clave puede satisfacer el segundo paso al iniciar sesión. Ambos hechos son compatibles: una clave puede sustituir a contraseña más código en el uso diario, mientras los factores anteriores siguen disponibles para recuperar, salvo que los retires deliberadamente.

El límite aparece cuando olvidas el PIN. Google permite restablecerlo desde un dispositivo que no sea Android donde ya hayas usado claves de Google Password Manager. Si pruebas todos los dispositivos aptos y aun así no puedes recuperarlo, la salida documentada es Restablecer tus claves de acceso. Esa acción borra todas las claves guardadas en Google Password Manager; no vuelve a emitirlas en cada web. Tendrás que recuperar cada cuenta de destino y crear credenciales nuevas.

Aquí conviene separar dos procesos que muchos resúmenes mezclan. El procedimiento de recuperación de Google puede devolverte el acceso a Gmail y a la propia cuenta. Recuperar Password Manager significa volver a abrir la colección cifrada de claves. Lo primero no demuestra por sí solo que puedas descifrar lo segundo. En algunos bloqueos con verificación en dos pasos, la guía de incidencias advierte que la revisión puede tardar de tres a cinco días laborables. Google presentó Recovery Contacts para cuentas personales elegibles en 2025, pero la disponibilidad y el despliegue varían: trátalo como una opción adicional, no como una promesa universal.

Cuentas personales de Apple: recuperar el Llavero de iCloud tiene condiciones
#

Apple diseñó el Llavero de iCloud para sincronizar contraseñas y claves de acceso con cifrado de extremo a extremo. Sus servidores transfieren registros cifrados sin conservar copias legibles. La guía de seguridad de la plataforma indica expresamente que el sistema está concebido para recuperar el llavero incluso cuando todos los dispositivos del usuario están inaccesibles. Es una afirmación más precisa que «tus claves están en iCloud».

También es una ruta condicionada. La página de Apple sobre seguridad de las claves de acceso explica que, si todos los dispositivos están fuera de alcance, la recuperación puede pedir la contraseña de la Cuenta de Apple, un SMS al número registrado y el código del dispositivo. El servicio que custodia los datos cifrados para la recuperación permite 10 intentos de autenticación; el décimo fallo destruye el registro depositado. El sistema contempla una ruta para el caso en que pierdes todos los dispositivos, pero no ofrece una garantía ilimitada.

El proceso sigue apoyándose en la Cuenta de Apple. La recuperación estándar puede combinar las credenciales de la cuenta, un número de confianza, códigos de dispositivos y, en algunos casos, un periodo de espera. Un contacto de recuperación puede entregar un código de seis dígitos, y Apple permite registrar hasta cinco contactos. Esa persona no puede ver el contenido de la cuenta; solo ayuda a confirmar la identidad.

Apple también advierte que la recuperación completa puede tardar varios días o más y que el soporte técnico no puede acortar la espera. Es una vía de último recurso, no acceso de emergencia para el mismo día.

La clave de recuperación opcional exige una advertencia clara. La documentación de Apple señala que la clave de 28 caracteres desactiva la recuperación estándar de la cuenta. Con la Protección de Datos Avanzada, una clave y un contacto de recuperación pueden coexistir, y cualquiera de los dos puede servir para volver a entrar. Sin la contraseña de la cuenta, un dispositivo de confianza, la clave de 28 caracteres ni un contacto configurado que aún funcione, el bloqueo puede ser permanente. Esa clave solo te da más control si la guardas fuera de la cuenta que protege. Guardarla en Notas de Apple, iCloud Drive o la aplicación Contraseñas crea una dependencia circular; Apple desaconseja expresamente esos lugares.

Las llaves físicas de seguridad de la Cuenta de Apple son otra función, distinta de las claves sincronizadas del Llavero de iCloud. Apple exige al menos dos llaves físicas y admite hasta seis. Su guía de llaves de seguridad avisa de que perder todos los dispositivos de confianza y todas las llaves registradas puede bloquear la cuenta para siempre. Una llave de repuesto solo ayuda si ya está registrada, comprobada y guardada lejos de los dispositivos cotidianos.

Microsoft: las cuentas personales no siguen el calendario de Entra
#

Microsoft admite claves sincronizadas y claves vinculadas al dispositivo. Su guía para consumidores define la primera como una credencial que vuelve mediante un gestor, y la segunda como una credencial que se pierde con el dispositivo si no existe otro método. Microsoft Password Manager se está desplegando en perfiles personales de Edge; Windows Hello y las llaves físicas pueden permanecer locales.

Comprobé el titular «Microsoft retira el SMS en septiembre de 2026» contra la fuente original porque altera la recomendación práctica. El cambio del 1 de septiembre de 2026 afecta a entornos de Entra ID administrados por una organización: a las personas que ya tienen habilitado SMS o voz se les habilita automáticamente la opción de registrar claves de acceso y se les invita a hacerlo. Los administradores del entorno pueden excluirlo temporalmente hasta el 1 de febrero de 2027, cuando Microsoft retira su propio servicio de SMS y voz para Entra. Por separado, Microsoft dice que retirará gradualmente los códigos SMS de las cuentas personales, pero esa página no fija septiembre de 2026 como fecha universal. Mezclar ambos ámbitos empujaría a titulares de cuentas personales a eliminar un método por un plazo que no existe.

La recuperación personal tiene su propio límite. Si la verificación en dos pasos está activa y no puedes usar ninguno de los métodos alternativos, el formulario normal y el soporte técnico no pueden devolverte el acceso, según la página del formulario de recuperación. Microsoft ofrece por separado un código de recuperación de 25 dígitos. Su guía del código advierte que cambiar datos de seguridad con la verificación en dos pasos puede tardar 30 días. Genera y guarda el código antes de una crisis, no cuando ya hayas perdido el dispositivo con la clave.

Cuentas personales de GitHub: varias opciones, ninguna excepción del soporte técnico
#

Este análisis cubre a quienes administran sus propias credenciales en una cuenta personal; la documentación de GitHub no extiende este modelo a cuentas empresariales administradas. En una cuenta personal, una clave de acceso satisface tanto la contraseña como el 2FA al entrar desde el navegador. Recuperar una clave sincronizada corresponde a Apple, Google, Microsoft o al proveedor que guardó la clave privada. La página de gestión de claves de GitHub remite a ese proveedor. Una llave de seguridad vinculada a un dispositivo no se vuelve recuperable solo porque GitHub aún la muestre en la lista.

GitHub sí detalla el otro lado de la recuperación. Según su documentación de métodos, GitHub genera 16 códigos de un solo uso y contempla como posibles pruebas las claves SSH —claves criptográficas usadas para Git o acceso remoto—, los tokens de acceso personal (PAT, credenciales para API y Git) y los dispositivos verificados. Haber usado antes una opción no garantiza que siga siendo apta; una clave SSH inactiva, por ejemplo, puede quedar excluida. Una solicitud con un dispositivo verificado o una clave SSH que GitHub acepte puede tardar hasta tres días laborables.

El último límite es inequívoco: si desaparecen todas las credenciales y todos los métodos aceptados, GitHub Support no restaura una cuenta personal con 2FA. La guía para credenciales perdidas considera permanente esa pérdida. Guarda los códigos fuera de línea y registra más de un método antes de convertir la clave de acceso en tu forma cotidiana de entrar.

La paradoja de la recuperación: acceso fuerte, respaldo más débil
#

La paradoja aparece cuando un acceso resistente al phishing depende de un método de recuperación más débil. El atacante puede dirigirse al correo, el teléfono, el proceso de soporte o la cuenta en la nube que permiten sustituir la clave.

Eso no convierte las claves de acceso en una mala idea. Significa que la recuperación forma parte de la autenticación y no es un trámite posterior. La guía de recuperación de NIST trata la recuperación de cuentas como un evento de gestión de autenticadores y exige mecanismos adecuados al nivel de garantía. Un código de un solo uso resulta útil porque puede ser independiente, pero deja de resistir el phishing si lo escribes en una web falsa.

Vía de recuperación	¿Independiente de los dispositivos perdidos?	¿Resiste el phishing?	Uso más adecuado	Cómo reforzarla
Código de recuperación fuera de línea	Sí, si se guarda fuera del dispositivo	No	Acceso de emergencia	Papel o copia cifrada fuera de línea; nunca solo en la nube
Segunda llave física	Sí, si se guarda en otro lugar	Sí	Cuentas de alto valor	Registra dos, prueba ambas y guarda una en un lugar distinto
Clave sincronizada en el mismo proveedor	En parte	Sí para iniciar sesión	Comodidad diaria y pérdida de un solo dispositivo	Refuerza la recuperación del proveedor y conserva una opción externa
Correo de recuperación	Solo si pertenece a otra cuenta	No por sí solo	Recuperación general de cuentas	Otro proveedor, una clave de acceso y recuperación independiente
Teléfono de recuperación / SMS	Solo si el servicio telefónico sigue disponible	No	Compatibilidad de último recurso	Configura un PIN con la operadora y reduce la exposición con un modelo de amenazas para tu número
Contacto de recuperación	Sí, si la persona y su dispositivo siguen disponibles	No por sí solo	Recuperar Apple o una cuenta de Google elegible	Elige con cuidado y ensaya el contacto y las comprobaciones de identidad

La portabilidad mejora, pero no diseñes tu recuperación sobre una promesa futura. FIDO publicó en marzo de 2026 el Credential Exchange Format como estándar propuesto para importar y exportar credenciales con seguridad. Que exista el estándar no demuestra que los proveedores que usas permitan hoy transferir todas tus claves. Verifica las funciones de exportación e importación de ambos productos antes de depender de una migración entre proveedores.

La contrapartida para la privacidad también está clara. La sincronización protege frente a la pérdida de un dispositivo, pero concentra la recuperación en una cuenta en la nube. Las claves vinculadas al dispositivo reducen esa dependencia a costa de hacer más grave la pérdida física. Es la misma diferencia entre administrar algo directamente y limitarse a trasladar la confianza a un panel de administración, distinción que aplico en la auditoría de soberanía en cinco capas. Decide en función de un adversario y un fallo concretos, no de un eslogan.

Migra empezando por la recuperación
#

Una migración segura empieza por preparar la recuperación, no por eliminar métodos. Haz inventario del almacenamiento, añade un método fuera del proveedor, compruébalo sin borrar nada y solo entonces relega el SMS o la contraseña.

Anota por separado la cuenta y el proveedor. Escribe GitHub — Google Password Manager, no solo GitHub — clave de acceso. Marca cada clave como sincronizada, vinculada al dispositivo o desconocida. Si no lo sabes, todavía no retires nada.
Protege primero la cuenta del proveedor. Para recuperar una clave sincronizada, primero debes recuperar la cuenta de Apple, Google, Microsoft o del gestor independiente y superar los controles que protegen el cifrado. Actualiza el correo de recuperación, el teléfono de confianza, el contacto de recuperación y un autenticador independiente. Empieza también por identificar al adversario, como en el modelo de amenazas en la era de la IA.
Crea una vía de recuperación fuera del proveedor. Según el servicio, usa códigos impresos, una segunda llave física guardada en otro lugar o una clave SSH cuya clave privada —o una copia ya probada— esté en otro dispositivo y que el servicio todavía acepte para recuperar. No dejes la única copia dentro de la misma cuenta en la nube.
Haz una prueba sin borrar nada. Abre una ventana privada o un perfil distinto del navegador y comprueba que el método de reserva aparece entre las opciones de acceso. Usa una comprobación de estado que no cambie nada cuando exista. Si la prueba consume un código de un solo uso, márcalo como usado y sustitúyelo de inmediato, o genera y guarda un juego nuevo. No inicies una recuperación completa, ni elimines la clave principal, ni borres un dispositivo, ni cierres todas las sesiones de confianza solo como ensayo.
Documenta las instrucciones fuera de línea. Incluye el nombre del proveedor, la cuenta de destino, el lugar donde guardas la reserva y la URL oficial de recuperación. La disciplina se parece al primer ensayo de recuperación de autocustodia de bitcoin: si nunca probaste una copia, solo supones que funcionará; todavía no es una salvaguarda comprobada.
Relega el método anterior de una cuenta cada vez. Prefiere la clave de acceso para el uso diario. Retira el SMS solo después de que funcione la vía independiente y únicamente si el servicio no exige el número para recuperar. Vuelve a comprobar después de cambiar de teléfono, gestor de contraseñas, cuenta de Apple, Google o Microsoft, o llaves de seguridad.

El orden es una medida de seguridad. Si eliminas primero el SMS y dejas la reserva para después, habrá un intervalo en el que una caída que dañe el teléfono, una pantalla rota, una llave perdida o un proveedor mal elegido pueden cerrar la cuenta para siempre. El trabajo de seguridad debe reducir los fallos simultáneos, no crear otros nuevos.

Conclusión: ¿deberías sustituir ya el SMS?
#

Usa claves de acceso para entrar a diario, pero no relegues el SMS hasta comprobar con éxito otra vía desde un navegador sin una sesión iniciada. Combina un acceso resistente al phishing con recuperación independiente de un solo dispositivo o cuenta en la nube.

Las pruebas sobre el inicio de sesión normal son sólidas. Los datos de FIDO citados arriba y el informe de Google de 2024 —más de 1.000 millones de autenticaciones en 400 millones de cuentas y accesos un 50 % más rápidos— miden el uso cotidiano, no la recuperación después de perder dispositivos.

La recuperación después de una pérdida tampoco depende de una sola función. Google Password Manager puede pedir su PIN; Apple puede depender de la recuperación de cuenta, un contacto o una clave de recuperación; las cuentas personales de Microsoft tienen información alternativa y un código de 25 dígitos; GitHub depende de sus códigos o de otra prueba ya registrada. «Está respaldado en la nube» oculta todas esas condiciones.

Empieza por la cuenta cuya pérdida causaría más daño. Relaciona proveedor y servicio de destino, guarda un método de recuperación fuera de ambos, pruébalo y pasa después a la siguiente cuenta. Tarda más que pulsar «usar una clave de acceso» en todas partes durante una tarde. A cambio, obtienes protección contra el phishing sin que perder una bolsa te deje fuera de todas tus cuentas importantes.

Puntos clave

Recuperar una clave exige dos procesos distintos: restaurar la credencial desde el proveedor y recuperar la cuenta de destino para registrar una nueva clave no son la misma operación.
El acceso normal mejora: FIDO Alliance registró un 93 % de éxito con claves de acceso frente al 63 % de otros métodos, y 8,5 segundos de media frente a 31,2 en 2025.
La sincronización tiene condiciones: solo resiste la pérdida si puedes recuperar la cuenta del proveedor y superar el control de las claves cifradas; una clave vinculada al dispositivo necesita una reserva separada.
Cada plataforma tiene un límite distinto: Google puede borrar todas las claves de la colección de Password Manager al restablecerla; la clave de recuperación de Apple de 28 caracteres desactiva el proceso estándar, aunque la Protección de Datos Avanzada puede conservar un contacto configurado; Microsoft no permite que el soporte técnico omita el 2FA; GitHub entrega 16 códigos de un solo uso.
El orden de migración reduce el riesgo: haz inventario, refuerza el proveedor, crea una vía externa, pruébala, documéntala y solo entonces relega el SMS, cuenta por cuenta.

Preguntas frecuentes
#

¿Son las claves de acceso más seguras que el doble factor por SMS?
#

Contra el phishing, sí. Una clave WebAuthn está vinculada al dominio real, de modo que una web falsa no puede recoger un secreto reutilizable. En cambio, puedes introducir un código SMS en una web falsa, o un atacante puede interceptarlo después de un SIM swap (secuestro de la SIM). La recuperación sigue siendo otra capa: si el servicio acepta SMS para sustituir una clave perdida, esa vía conserva el riesgo del SMS.

¿Qué ocurre con mis claves de acceso si pierdo el teléfono?
#

Las claves sincronizadas pueden volver cuando recuperas y desbloqueas su gestor en otro dispositivo. Una clave vinculada únicamente al teléfono se pierde. En ambos casos, un segundo autenticador o el método de recuperación del servicio determinan si puedes volver a entrar sin ese teléfono.

¿Pueden Apple, Google o Microsoft leer mis claves sincronizadas?
#

La documentación de sus plataformas describe colecciones cifradas de extremo a extremo o protegidas para que el proveedor no reciba la clave privada en forma legible. Eso no elimina la dependencia: el proveedor sigue operando la cuenta, el servicio de sincronización, las reglas de recuperación y el software que controla el acceso a la colección cifrada.

¿Debo borrar la contraseña y el número usado para SMS después de añadir una clave de acceso?
#

No de inmediato. Añade primero un método independiente y pruébalo desde un navegador sin una sesión iniciada, sin eliminar nada. Después retira o relega los métodos más débiles, una cuenta cada vez, si el servicio lo permite y la recuperación no depende del mismo dispositivo o proveedor.

¿Puede el soporte técnico recuperar mi cuenta si pierdo todas las claves y códigos?
#

No lo des por hecho. GitHub afirma que su equipo de soporte no puede recuperar una cuenta con 2FA cuando no queda un método aceptado. Microsoft indica que el formulario para cuentas personales tampoco sirve si la verificación en dos pasos está activa y no puedes usar ninguna alternativa. Prepara el factor independiente antes de la pérdida.

Fuentes
#

Cora Aegis

Cora Aegis escribe en CypherpunkGuide guías de OPSEC con la privacidad como eje. Para este artículo aplicó a cuatro ecosistemas el mismo escenario —se pierden los dispositivos cotidianos, pero se conservan los recursos de recuperación guardados en otro lugar—, contrastó 25 documentos oficiales y fuentes primarias, y convirtió las dependencias resultantes en una matriz descargable.

Más sobre Cora Aegis →

Migrar de gestor de contraseñas: Bitwarden vs. KeePassXC (2026)

Mon, 03 Aug 2026 00:00:00 +0000

Guardar contraseñas en el navegador no es inseguro por definición. NIST SP 800-63B-4 indica que los verificadores conformes deben permitir gestores de contraseñas y autorrelleno, pues ayudan a usar claves distintas y más robustas. La decisión de salir del navegador depende de tu modelo de amenazas: qué proteges, frente a quién y qué fallo podría dejarte sin acceso. Quizá necesites una bóveda independiente de una sola cuenta del navegador, compatible con varios navegadores, con otro sistema de recuperación o bajo tu control directo.

El riesgo más inmediato está en el traslado. El 3 de agosto de 2026 revisé los 5 primeros resultados de Google, cuatro páginas competidoras legibles con una media de 2.512 palabras y la documentación oficial sobre migración, autenticación e intercambio de credenciales de Chrome, Edge, Firefox, Bitwarden, KeePassXC, NIST y FIDO. Google AI Mode ya ofrecía una respuesta de tres pasos que parecía completa: exportar un CSV —un archivo tabular de texto—, importarlo, comparar el número de filas y borrar el archivo. Ahí falta el fallo decisivo.

Probé dos exportaciones sintéticas de 12 registros con nuestra herramienta de auditoría, que oculta las contraseñas. Ambos archivos contenían 12 filas, pero solo coincidieron 11 credenciales: faltaba una del origen y otra estaba duplicada. El resultado fue una cobertura del 91,7 % y la decisión HOLD, sin mostrar URL, nombre de usuario, contraseña ni huella derivada de un secreto. A partir de esa prueba, esta guía propone una migración en siete pasos. Aprende con datos falsos, conserva intacta la bóveda de origen durante el cambio y nunca subas una exportación real a un convertidor web ni a un asistente de IA.

El gestor del navegador no es el verdadero problema
#

Un gestor de contraseñas guarda tus credenciales y completa los campos de acceso. La comparación útil no es «navegador inseguro, aplicación dedicada segura», sino qué combinación de confianza, sincronización, recuperación y bloqueo encaja con los fallos que de verdad te preocupan.

Los gestores del navegador protegen las contraseñas mediante controles documentados del dispositivo y de la cuenta; la recuperación y el acceso local cambian según el navegador. Un gestor dedicado modifica quién opera la sincronización, cómo recuperas la bóveda, cuántos navegadores y plataformas comparten los datos y si administras personalmente el archivo cifrado. No vuelve inocuo un equipo comprometido y desbloqueado: cualquier gestor debe descifrar una credencial para poder usarla al iniciar sesión.

Migra solo si puedes nombrar el motivo:

Independencia del navegador: usas varios navegadores o quieres poder cambiar de navegador sin volver a trasladar las credenciales.
Recuperación separada: no quieres que la misma cuenta de Google, Microsoft o Mozilla controle los datos de navegación y la recuperación de contraseñas.
Custodia local: quieres decidir dónde están el archivo cifrado, las copias de seguridad y la sincronización.
Uso familiar o en equipo: necesitas compartir de forma administrada, sin copiar contraseñas por chat o correo.
Capacidad de auditoría: buscas un inventario más claro, un informe de estado o una exportación que permita probar la recuperación.

No migres solo por un titular que diga que las contraseñas del navegador están en «RAM sin cifrar». Para iniciar una sesión, un equipo o teléfono desbloqueado tiene que descifrar la contraseña en algún momento. Cambiar de marca no elimina el malware, las capturas de pantalla, las extensiones maliciosas ni el acceso físico. La migración debe reducir una dependencia concreta, no prometer inmunidad.

También por eso las claves de acceso necesitan un inventario separado. Una clave de acceso (passkey) es una credencial criptográfica ligada a un sitio, no otra fila de contraseña. Antes de cambiar de gestor, usa el ensayo de recuperación de claves de acceso para anotar cuáles están sincronizadas, cuáles pertenecen a un solo dispositivo y cuáles puedes recuperar desde la web.

Bitwarden frente a KeePassXC: elige según el tipo de fallo
#

Bitwarden prioriza la sincronización automática entre dispositivos y ofrece clientes móviles oficiales. KeePassXC guarda los datos en un archivo cifrado KDBX bajo tu control, pero te deja a cargo de la sincronización, las copias, los conflictos y la recuperación.

Bitwarden puede importar datos del navegador desde la aplicación web, la extensión, la aplicación de escritorio, la aplicación móvil o la línea de comandos. Su guía para Chrome y Edge explica que cifra los datos localmente antes de enviarlos al servidor. Así, los datos de la importación no llegan al servidor como texto legible, pero la cuenta de Bitwarden, tus dispositivos, la contraseña maestra, el segundo factor (2FA, una prueba adicional después de la contraseña) y la disponibilidad del servicio siguen formando parte de la cadena de recuperación.

Las instalaciones de escritorio compatibles permiten importar directamente desde ciertos navegadores basados en Chromium sin crear manualmente un CSV. La función está disponible en las aplicaciones para Windows y macOS descargadas de la web oficial y en AppImage para Linux; no funciona en las versiones de las tiendas de aplicaciones. En Windows, el auxiliar bitwarden_chromium_import_helper.exe puede activar avisos del Control de cuentas de usuario (UAC, la confirmación del sistema operativo) o de una herramienta EDR (detección y respuesta en los equipos). Verifica primero el instalador y la firma, inicia la importación por tu cuenta y cancela cualquier aviso inesperado: el nombre del proceso, por sí solo, no demuestra que sea legítimo.

KeePassXC almacena las credenciales en una base de datos cifrada con formato KDBX y no incorpora un servicio propio de sincronización en la nube. La documentación oficial permite guardar el archivo en local o colocarlo en el sistema de sincronización que elijas. Para importar un CSV debes asignar sus columnas de forma explícita; el archivo de transferencia sigue sin cifrar aunque el destino sea un KDBX cifrado. Así evitas depender de una cuenta obligatoria del proveedor, pero debes resolver los conflictos entre copias, mantener respaldos fuera del dispositivo y conservar todo lo necesario para abrir la base.

Decisión	Bitwarden	KeePassXC	Fallo que debes prever
Modelo de sincronización	Sincronización cifrada administrada	Archivo KDBX gestionado por ti, con sincronización externa opcional	Recuperar el servicio o la cuenta frente a perder el archivo o sufrir un conflicto
Encaja mejor si…	Usas varios dispositivos, necesitas móvil o compartir y quieres poco mantenimiento	Trabajas sobre todo en escritorio, buscas control local y diseñas tus propias copias	Elegir comodidad o custodia sin asumir las tareas que conllevan
Importación	CSV específico del navegador; vías directas en plataformas compatibles	Asistente CSV con vista previa y asignación de columnas	Crear duplicados frente a colocar datos en columnas incorrectas
Base de la recuperación	Credenciales de la cuenta, segundo factor y plan de recuperación	Archivo KDBX, clave maestra, posible archivo de clave o desafío físico y copias	Guardar todos los componentes en un único dispositivo
Claves de acceso y códigos temporales de un solo uso (TOTP)	Revisa por separado el soporte y los límites del plan; un CSV del navegador no demuestra su traslado	Revisa por separado el soporte y la compatibilidad del sitio; un CSV del navegador no demuestra su traslado	Dar por hecho que las filas de contraseña prueban la transferencia de otras credenciales
Carga operativa	El proveedor mantiene la infraestructura de sincronización	Tú administras almacenamiento, sincronización, copias y conflictos	Confundir «local» con «respaldado automáticamente»

Antes de diseñar la auditoría descargué la versión portátil oficial de KeePassXC 2.7.12, publicada el 10 de marzo de 2026. El ZIP coincidió con la suma criptográfica SHA-256 publicada por el proyecto, 86718f7f47d7ca7f287de0260c567644c846e2a3e51ad2f93a76605178be9850, y la validación de la firma de código Authenticode en Windows identificó a DroidMonkey Apps, LLC como firmante válido del archivo KeePassXC.exe extraído. Esto verifica únicamente los archivos que examiné; no certifica otros espejos, versiones futuras ni configuraciones. Las notas de la versión 2.7.12 también advierten que la corrección de un indicador de las claves de acceso puede hacer que un sitio rechace algunas claves ya existentes. Si tu bóveda contiene claves de acceso, pruébalas una por una mientras siga disponible la vía de acceso original.

Antes del cambio definitivo todavía puedes volver atrás. Instala el destino desde la fuente oficial, crea solo una entrada ficticia, practica el bloqueo y la recuperación y comprueba el comportamiento de los demás dispositivos. No borres credenciales del navegador solo para que la prueba parezca más drástica.

Qué contiene un CSV del navegador y qué no puede demostrar
#

Un CSV de contraseñas del navegador es un archivo de transferencia sin cifrar y legible como texto. Puede contener los campos de inicio de sesión, pero no demuestra por sí solo que se hayan trasladado claves de acceso, semillas TOTP, adjuntos, tarjetas, identidades, campos personalizados, historial ni material de recuperación.

Google documenta url, username y password como los campos mínimos del CSV de Chrome y advierte que cualquiera que conserve el archivo sin borrar puede leer las contraseñas. Son campos de una fila de contraseña, no una garantía sobre las claves de acceso ni sobre cómo importará otro gestor. Microsoft publica la misma advertencia para las exportaciones de Edge, y Mozilla indica que la exportación de Firefox no debe subirse, enviarse por correo ni compartirse.

No confundas los límites del archivo de transporte con los del gestor de destino. El esquema CSV propio de Bitwarden admite el campo login_totp, pero su documentación de importación personalizada limita el CSV a inicios de sesión y notas seguras; las identidades y tarjetas requieren JSON —un formato de datos estructurados—, y los adjuntos se gestionan aparte. KeePassXC avisa de que sus exportaciones CSV no representan adjuntos, atributos avanzados, opciones de automatización Auto-Type ni iconos personalizados. Ningún gestor puede importar desde un CSV datos que el navegador nunca incluyó.

Tipo que debes inventariar	Lo que puede demostrar el CSV de contraseñas	Lo que debes comprobar aparte	Evidencia segura
Inicios de sesión con contraseña	URL, usuario, contraseña y, a veces, nombre o nota	duplicados, valores vacíos, URL modificadas y campos propios del origen	comparación de contenido que no revele secretos
Claves de acceso	Las filas de contraseña no permiten deducir cobertura	proveedor, sitio, estado sincronizado o ligado al dispositivo y portabilidad	listas de credenciales del proveedor y del sitio
Semillas TOTP	Solo si el formato de origen las exporta y el destino las asigna	generación del código tras importar, reloj y códigos de recuperación	prueba no destructiva con una cuenta de bajo riesgo
Adjuntos y campos personalizados	Suelen faltar o tener limitaciones	cantidad, tipo y transferencia manual	inspección del elemento en el destino
Tarjetas, identidades y notas seguras	La exportación del navegador puede omitirlas	JSON propio del producto o transferencia directa	recuento separado por tipo
Material de recuperación	No debes suponer que forma parte de la bóveda	segundo factor, código de recuperación, acceso de emergencia y copia de la base	comprobación desde un navegador nuevo, con el origen intacto

El Protocolo de Intercambio de Credenciales (CXP, por sus siglas en inglés) puede evitar el archivo en texto legible cuando los dos productos lo admiten. La guía actual de Bitwarden documenta vías basadas en FIDO CXP en plataformas móviles compatibles, incluida la transferencia de contraseñas y claves de acceso entre aplicaciones compatibles. Es una mejora importante, no una instrucción universal para Chrome, Edge, Firefox, Bitwarden y KeePassXC en escritorio. Comprueba el origen, el destino y la plataforma que realmente estás usando.

Aunque CXP esté disponible, haz el inventario por tipo. Evitar el CSV elimina un periodo de exposición, pero no demuestra que hayan llegado todas las clases de credenciales ni todas las vías de recuperación.

La trampa de las 12 filas frente a 12 filas
#

Dos bóvedas pueden tener el mismo número de filas y distinto contenido. Si en el destino falta una credencial y aparece otra duplicada, el total sigue coincidiendo; por eso la verificación debe comparar el contenido y los tipos, no limitarse a contar.

El experimento incluido usa únicamente dominios reservados y contraseñas obviamente falsas. El origen sintético del navegador contiene 12 inicios de sesión únicos. El destino sintético con el formato de Bitwarden también tiene 12 filas, pero omite deliberadamente la credencial de administración y duplica otra.

Ejecuté migration-audit.py con ambos archivos. El programa normaliza los encabezados CSV compatibles de navegadores, Bitwarden y KeePassXC. Después compara cada combinación de URL, usuario y contraseña mediante huellas SHA-256 mantenidas en memoria; no escribe ni muestra esas huellas. Tampoco ofrece borrado seguro de la memoria: el sistema recupera la memoria del proceso cuando termina. El resultado publicado solo contiene cifras agregadas.

Para esta herramienta, PASS significa únicamente que coinciden las combinaciones de URL, usuario y contraseña. No certifica que hayan migrado notas, carpetas, campos personalizados, claves de acceso, TOTP, adjuntos, identidades, tarjetas ni material de recuperación.

Comprobación	Resultado	Lo que concluiría un simple recuento
Filas en el origen	12	parece completo
Filas en el destino	12	parece completo
Credenciales que coinciden exactamente	11/12 (91,7 %)	no lo detecta
Credenciales del origen ausentes	1	no lo detecta
Credenciales inesperadas en el destino	1	no lo detecta
Duplicados exactos en el destino	1	no lo detecta
Decisión de la auditoría	HOLD	falso PASS

La prueba no pretende reproducir todos los importadores del mercado. Demuestra un fallo lógico en el método de verificación: un total idéntico es compatible con la pérdida de datos. El riesgo de duplicación es especialmente pertinente en Bitwarden, porque sus preguntas frecuentes oficiales sobre importación explican que cada importación crea registros nuevos aunque ya existan elementos iguales.

Ejecuta el programa únicamente en local. Un CSV real contiene las llaves de tus cuentas. No lo adjuntes a una solicitud de soporte, no lo pegues en un chat de IA, no lo guardes en este repositorio y no uses un «comprobador de migraciones» en la web. Si no confías tus secretos a un programa de comparación, revisa manualmente pequeñas muestras en el dispositivo sin conexión y conserva el origen durante más tiempo.

Migrar un gestor de contraseñas en siete pasos
#

Una migración segura es un cambio controlado: inventaría por tipo, prepara la recuperación, verifica el programa de destino, transfiere una sola vez, compara el contenido, prueba el uso habitual y la recuperación y, al final, elimina el texto legible y retira el gestor anterior.

Haz el inventario por tipo, no con un total único. Anota por separado los inicios de sesión con contraseña, las claves de acceso, las entradas TOTP, las notas seguras, los adjuntos, las identidades, las tarjetas y los códigos de recuperación. Empieza por las cuentas cuya pérdida tendría consecuencias graves: correo principal, gestor de contraseñas, operadora móvil, finanzas, registrador de dominios y almacenamiento en la nube. Aplica la misma separación de identidades que en la auditoría personal de redes sociales.
Determina de qué depende la recuperación antes de elegir producto. Para Bitwarden, documenta el correo de la cuenta, la contraseña maestra, un segundo factor que funcione y el código de recuperación del acceso en dos pasos. Ese código solo desactiva el segundo factor: incluso después de usarlo, todavía necesitas la contraseña maestra. La guía de Bitwarden para una contraseña maestra olvidada indica que su equipo no puede recuperar una bóveda individual si no queda una alternativa configurada previamente; prueba cualquier acceso alternativo documentado antes de depender de él. Para KeePassXC, anota la ubicación del KDBX, la clave maestra, cualquier segundo componente opcional, al menos una copia fuera del dispositivo y el procedimiento para resolver conflictos. No guardes todo en el equipo que llevas contigo.
Verifica el instalador y ensaya con datos falsos. Descarga el programa desde el dominio oficial o desde una publicación firmada, comprueba la suma o la firma que proporcione el proyecto y crea una bóveda sintética. Prueba el bloqueo, el desbloqueo, la integración con el navegador y la restauración de una copia antes de exportar datos reales.
Usa la transferencia documentada que menos exponga los datos. Prefiere la importación directa verificada o CXP solo cuando el origen, el destino, el canal del instalador, el tipo de credencial y la plataforma activa sean compatibles. La importación directa de Bitwarden en escritorio evita crear manualmente un CSV del navegador, pero no demuestra que haya trasladado las claves de acceso ni todos los demás tipos. Si necesitas un archivo, créalo una sola vez en un dispositivo de confianza y guárdalo en un espacio local cifrado que no se sincronice de forma automática. Cierra chats, unidades en la nube, copias de seguridad, indexadores y editores que puedan copiarlo. Anota la ruta exacta. Nunca introduzcas secretos reales en el navegador de Cora, en una consulta a una IA ni en un convertidor en línea.
Transfiere una vez e inspecciona el resultado. Selecciona el origen exacto o la opción correcta de importación directa. En KeePassXC, revisa la vista previa y la asignación de columnas CSV antes de confirmar. En Bitwarden, ni la importación directa ni la de archivo comprueban si ya hay duplicados. Si aparece un error, detente; no repitas la importación para ver si «esta vez funciona».
Demuestra que llegaron el contenido y los tipos. Compara credenciales sin imprimirlas, revisa manualmente cada cuenta crítica y cuenta aparte las claves de acceso, TOTP y adjuntos. La igualdad de filas es solo una señal. La decisión debe ser HOLD si falta alguna credencial de origen, aparece un duplicado inesperado o cualquier tipo de credencial que no sea una contraseña carece de una vía de transferencia documentada.
Prueba, observa y solo después retira el origen. Inicia sesión en varias cuentas de bajo riesgo y en todas las críticas desde un perfil nuevo del navegador. Ejecuta cada paso de recuperación que pueda repetirse sin borrar el origen. Si el código es de un solo uso, comprueba que tienes acceso tanto a la copia guardada como al procedimiento oficial; solo puedes considerarlo probado si decides consumirlo y después guardas el código regenerado o su sustituto. Mantén la bóveda anterior en modo de solo lectura durante un breve periodo de observación. Cuando todo haya funcionado, desactiva el guardado del navegador, elimina los registros de origen y, si usaste un archivo, borra todas las copias en texto legible que puedas localizar.

El orden protege el acceso. Si la importación sale mal, el origen permite volver atrás. Si falla la recuperación, las sesiones abiertas aún pueden servir para reparar la cuenta. Si el CSV terminó en una carpeta sincronizada, lo descubrirás antes de dar por completa la eliminación de una sola copia local.

No cambies sin necesidad los números de recuperación durante esta misma migración. Un número puede seguir siendo imprescindible para recuperar una cuenta aunque ya no intervenga en el inicio de sesión diario; dibuja esa dependencia con el modelo de privacidad del número de teléfono.

Cómo borrar el CSV sin prometer una eliminación imposible
#

Borrar un CSV en texto legible reduce la exposición, pero ninguna orden de borrado demuestra que hayan desaparecido todas las copias físicas, sincronizadas, indexadas, incluidas en respaldos o generadas como vista previa. La defensa más eficaz consiste en impedir copias adicionales antes de exportar y acortar al máximo la vida del archivo.

Google, Microsoft, Mozilla, Bitwarden y KeePassXC advierten que las exportaciones de contraseñas son legibles. Microsoft recomienda expresamente usar Mayús + Supr después de migrar desde Edge. En Windows, esa combinación evita la Papelera de reciclaje; no garantiza una eliminación forense en unidades de estado sólido, historiales de sincronización, respaldos ni sistemas de almacenamiento que no controlas.

Usa esta lista de limpieza:

Lugar	Qué comprobar	Acción
Ruta de exportación elegida	nombre exacto del archivo y hora de modificación	borrar después de la auditoría y de probar la recuperación
Descargas, Escritorio y Documentos	una segunda exportación accidental	eliminar solo las copias confirmadas
Carpeta sincronizada y su historial de versiones	si la ruta llegó a sincronizarse	eliminar las versiones remotas mediante los controles documentados del proveedor
Papelera de reciclaje	si usaste el borrado normal	vaciar el elemento confirmado; no suponer que esto borra el medio físico
Editores, hojas de cálculo y vistas previas	lista de archivos recientes, guardado automático y copia temporal	cerrar antes de exportar; eliminar solo los archivos temporales confirmados
Copias de seguridad e instantáneas	si el archivo existía durante una ventana de respaldo	respetar la política de conservación; cambiar las contraseñas expuestas si no puedes confirmar su eliminación

Si el CSV real pudo llegar al correo, un chat, un servicio de IA, un repositorio público o un convertidor no confiable, considera expuestas las contraseñas. Conserva las pruebas, cambia primero las credenciales críticas, revoca sesiones cuando proceda y continúa siguiendo el inventario. La bóveda de destino no puede devolver la privacidad a un secreto que alguien ya copió. La auditoría de privacidad de asistentes de IA explica por qué un cuadro de chat deja un registro y no debe usarse como canal de transferencia seguro.

En conclusión: qué vía de migración te conviene
#

Elige Bitwarden si las ventajas de la sincronización administrada y el menor mantenimiento cotidiano compensan la dependencia de una cuenta del servicio. Elige KeePassXC si prefieres la custodia local y aceptas ocuparte de las copias y la sincronización. En ambos casos, comprueba el contenido y la recuperación.

Tu prioridad	Mejor punto de partida	Medida imprescindible
Uso automático en varios dispositivos	Bitwarden	plan para la contraseña maestra, código separado de recuperación del 2FA y acceso probado
Base de datos cifrada en local	KeePassXC	copia KDBX fuera del dispositivo y restauración probada
Exposición mínima durante el traslado	Importación directa documentada o CXP	verificar origen, destino, canal del instalador, plataforma y tipos incluidos
Sencillez dentro del navegador	Conservar el gestor del navegador	proteger bien el dispositivo y la cuenta y probar la recuperación; migrar no es obligatorio
Bóveda compleja o de alto riesgo	Migración por etapas	lote pequeño, revisión manual de lo más valioso y periodo más largo con el origen en solo lectura

No basta con «exportar y confiar». Haz inventario, entiende lo que el archivo no puede representar, importa una sola vez, compara sin revelar secretos, prueba la recuperación y solo entonces retira la vía anterior. La elección del producto importa. El procedimiento de cambio importa aún más.

Puntos clave

La elección depende de tus riesgos: Bitwarden gestiona la sincronización cifrada; KeePassXC te entrega un archivo KDBX que administras tú, junto con la responsabilidad de respaldarlo.
Evita el archivo cuando exista soporte explícito; contrólalo cuando sea inevitable: una importación directa documentada o CXP puede evitar el CSV manual, pero no demuestra que hayan migrado todos los tipos de credenciales. Si necesitas un CSV, trátalo como texto legible hasta borrar todas las copias que identifiques.
Los totales engañan: en nuestra prueba sintética de 12 filas frente a 12, solo coincidieron 11 credenciales; el resultado fue una cobertura del 91,7 %, una ausencia y un duplicado.
Las credenciales no son todas iguales: contar filas de contraseñas no demuestra que hayan migrado claves de acceso, TOTP, adjuntos, tarjetas, identidades ni material de recuperación.
El orden protege tu acceso: inventaría, prepara la recuperación, verifica el programa, transfiere una vez, compara, prueba y solo entonces desactiva el gestor anterior y elimina las copias en texto legible.

Preguntas frecuentes
#

Estas respuestas aclaran los límites que suelen pasarse por alto: la elección del producto, el recuento de filas, las claves de acceso, la limpieza del texto legible y lo que realmente significa borrar un CSV en un sistema moderno.

¿Es Bitwarden más seguro que el gestor de contraseñas de Chrome?
#

No de forma categórica. Bitwarden separa la bóveda del ecosistema del navegador y ofrece varios clientes y formas de compartir, de modo que cambia el modelo de confianza y recuperación. Chrome puede ser más sencillo si toda tu actividad gira en torno a una sola cuenta de Google. Compara el riesgo de un dispositivo desbloqueado, la recuperación de la cuenta, la dependencia de la sincronización y el coste de una migración fallida; el nombre del producto no es una puntuación de seguridad.

¿KeePassXC es más seguro que Bitwarden por funcionar sin conexión?
#

KeePassXC elimina la obligación de tener una cuenta de sincronización en la nube, pero su modelo de archivo local te hace responsable del KDBX, los respaldos, la sincronización, los conflictos y la recuperación. Una sola copia local no es soberanía, sino un único punto de fallo. La sincronización administrada de Bitwarden introduce otro riesgo, no necesariamente uno mayor.

¿Puedo borrar el CSV en cuanto coincida el número de registros?
#

No. Un total idéntico puede ocultar una credencial ausente y otra duplicada. Compara el contenido, inspecciona las cuentas críticas, cuenta por separado las claves de acceso y TOTP y prueba el inicio de sesión normal y la recuperación antes de borrar el archivo de transferencia o la bóveda de origen.

¿El CSV de contraseñas de Chrome incluye mis claves de acceso?
#

No uses el número de filas de contraseñas como prueba. El mínimo documentado por Google para el CSV contiene URL, usuario y contraseña; las claves de acceso obedecen reglas propias del proveedor y de portabilidad. Inventaríalas por separado y usa CXP únicamente cuando el origen y el destino confirmen la transferencia en tu plataforma.

¿Debo sobrescribir de forma segura un CSV de contraseñas en una unidad de estado sólido (SSD)?
#

No prometas que una orden de sobrescritura o borrado elimina todas las copias de una unidad SSD, un sistema de sincronización, un respaldo o una vista previa. Evita que se creen copias mediante almacenamiento local cifrado y controlado, conserva el archivo el menor tiempo posible, borra las instancias confirmadas, revisa el historial de sincronización y cambia las credenciales si no puedes descartar una exposición.

Fuentes
#

Estas doce fuentes primarias y oficiales respaldan las afirmaciones sobre la migración a fecha del 3 de agosto de 2026. Once cuentan con una copia archivada exacta e independiente; la página activa de Edge no tenía una captura exacta en esa fecha, y señalamos la ausencia en lugar de ocultarla tras un comodín.

#	Fuente	URL	Copia archivada
1	NIST — SP 800-63B-4	https://pages.nist.gov/800-63-4/sp800-63b.html	https://web.archive.org/web/20260802091116/https://pages.nist.gov/800-63-4/sp800-63b.html
2	Ayuda de Google Chrome — importar o exportar contraseñas y claves de acceso	https://support.google.com/chrome/answer/13068232?hl=en-GB	https://web.archive.org/web/20250409111740/https://support.google.com/chrome/answer/13068232?hl=en-GB
3	Soporte de Microsoft — exportar contraseñas en Edge	https://support.microsoft.com/en-us/edge/export-passwords-in-microsoft-edge	No se encontró una captura exacta (comprobado el 3 de agosto de 2026)
4	Soporte de Mozilla — exportar datos de inicio de sesión desde Firefox	https://support.mozilla.org/en-US/kb/export-login-data-firefox	https://web.archive.org/web/20260621011944/https://support.mozilla.org/en-US/kb/export-login-data-firefox
5	Bitwarden — importar desde Chrome, Edge y navegadores Chromium	https://bitwarden.com/help/import-from-chrome/	https://web.archive.org/web/20260713195219/https://bitwarden.com/help/import-from-chrome/
6	Bitwarden — preguntas frecuentes sobre importación y exportación	https://bitwarden.com/help/import-faqs/	https://web.archive.org/web/20260622160725/https://bitwarden.com/help/import-faqs/
7	Bitwarden — importar desde un archivo personalizado	https://bitwarden.com/help/condition-bitwarden-import/	https://web.archive.org/web/20260708232651/https://bitwarden.com/help/condition-bitwarden-import/
8	KeePassXC — guía del usuario	https://keepassxc.org/docs/KeePassXC_UserGuide	https://web.archive.org/web/20260728213815/https://keepassxc.org/docs/KeePassXC_UserGuide
9	KeePassXC — versión 2.7.12	https://github.com/keepassxreboot/keepassxc/releases/tag/2.7.12	https://web.archive.org/web/20260728142825/https://github.com/keepassxreboot/keepassxc/releases/tag/2.7.12
10	FIDO Alliance — especificaciones para el intercambio de credenciales	https://fidoalliance.org/specifications-credential-exchange-specifications/	https://web.archive.org/web/20260711082529/https://fidoalliance.org/specifications-credential-exchange-specifications/
11	Bitwarden — código de recuperación del acceso en dos pasos	https://bitwarden.com/help/two-step-recovery-code/	https://web.archive.org/web/20260515192732/https://bitwarden.com/help/two-step-recovery-code/
12	Bitwarden — contraseña maestra olvidada	https://bitwarden.com/help/forgot-master-password/	https://web.archive.org/web/20260729154628/https://bitwarden.com/help/forgot-master-password/

Cora Aegis

Cora Aegis escribe en CypherpunkGuide guías de OPSEC con la privacidad como eje. Para este artículo revisó cinco resultados competidores de Google y siete familias de documentación primaria, verificó una versión firmada de KeePassXC y construyó una auditoría de migración de 12 registros que no revela las contraseñas.

Más sobre Cora Aegis →

Modelo de IA de Chrome: auditarlo, eliminarlo o conservarlo (2026)

Thu, 06 Aug 2026 00:00:00 +0000

La afirmación de que «Chrome instaló a escondidas un modelo de IA de 4 GB» plantea una preocupación legítima, pero presenta como constante una cifra variable. Chrome puede descargar un modelo en el dispositivo: archivos con patrones numéricos aprendidos por una IA para generar resultados en tu equipo, no en un servidor remoto. Google documenta variantes de 2 y 4 mil millones de parámetros, entre otras. El número de parámetros no mide el tamaño del archivo, que además cambia con las actualizaciones.

El 6 de agosto de 2026 revisé los cinco primeros resultados de Google para remove Chrome on-device AI model 2026, además de Google AI Overview y AI Mode. Las respuestas generadas mezclaban el ajuste oficial, el borrado manual, las funciones experimentales, las políticas administradas y un acceso directo para iniciar Chrome sin distinguir qué controla cada opción.

Organicé siete controles en tres capas: procesamiento y almacenamiento locales, IA en la nube o híbrida y confianza en el proveedor. También probé una herramienta de auditoría de solo lectura con cuatro estados sintéticos. Obtuvo los 4/4 resultados esperados sin leer el modelo, buscar perfiles, mostrar la ruta indicada, borrar archivos ni modificar políticas. Puedes consultar la matriz de controles y los resultados.

No pretendo convencerte de usar o abandonar Chrome, sino ayudarte a elegir la medida más específica para tu problema.

Qué es en realidad el «modelo de IA de 4 GB» de Chrome
#

El modelo fundacional local de Chrome —un modelo base de IA de uso general— es un componente administrado aparte. «4 GB» se ha observado en algunos casos; no es un tamaño permanente, una descarga universal ni una regla fiable para detectarlo.

La documentación sobre el ciclo de vida separa el navegador del componente del modelo. Chrome puede elegir una variante, descargarla en segundo plano o cuando la solicite una función compatible, actualizarla aparte y retirarla por falta de espacio o por una política. Las etiquetas 2B y 4B describen parámetros, no «2 GB» o «4 GB».

La documentación para desarrolladores exige actualmente al menos 22 GB libres en la unidad del perfil, una red sin límite de consumo y una GPU (procesador gráfico) con más de 4 GB de memoria de video, o bien una CPU (procesador principal) con 16 GB de RAM y cuatro núcleos como mínimo. Estos requisitos corresponden a las API de IA integradas —interfaces que permiten a una web solicitar funciones al navegador—; no demuestran que todo equipo compatible descargue de inmediato el mismo archivo.

Hay varios desencadenantes: una función destinada al usuario puede iniciar la descarga en segundo plano, una API web integrada puede solicitar el modelo y, bajo una condición documentada para detectar estafas, una comprobación de disponibilidad también puede descargarlo. No es fiable afirmar que llega con toda instalación ni que solo se descarga tras una petición expresa.

Afirmación habitual	Comportamiento comprobado a fecha del 6 de agosto de 2026	Consecuencia práctica
Todas las instalaciones de Chrome reciben un modelo de 4 GB	Varían los requisitos, el desencadenante, la variante y el tamaño	Comprueba tu instalación; no busques una cifra única
Un modelo 4B ocupa 4 GB	«4B» indica el número de parámetros, no la cantidad de bytes	Mide los archivos; no conviertas el nombre en almacenamiento
El modelo solo se descarga tras una solicitud explícita de IA	Las funciones habilitadas y las API pueden iniciar la descarga	Usa los ajustes y las políticas como controles duraderos
Borrar los archivos impide que regrese	Un componente administrado puede volver a descargarse mientras siga permitido	Cambia el ajuste o la política específica y después verifica
El modelo local no envía nada a Google	El procesamiento local puede permanecer en el dispositivo, pero una función puede incluir etapas en la nube o híbridas	Audita la función completa, no solo el lugar donde está el modelo

Esta distinción afecta a la privacidad y a la seguridad. Chrome 137 añadió Gemini Nano como señal local para algunas posibles estafas de soporte técnico. Según la explicación de Google, con Enhanced Protection (Protección mejorada) esa señal se envía a Safe Browsing para el veredicto final. Quienes usan Standard Protection (Protección estándar) pueden beneficiarse después cuando una amenaza confirmada entra en las listas de bloqueo. El modelo se ejecuta en local; el proceso de Enhanced Protection es híbrido.

Audita el modelo antes de cambiar nada
#

La auditoría debe aclarar tres cosas: si existe el componente local, qué versión o función te preocupa y si hay rutas de IA en la nube o híbridas activas. Una carpeta solo responde la primera.

Abre chrome://on-device-internals y anota la versión de Chrome, el estado del modelo y el tamaño o los datos del componente que aparezcan. No publiques el diagnóstico ni lo pegues en un chat de IA: puede revelar datos innecesarios de tu entorno.

Como segunda medición de solo lectura, indica a la herramienta una raíz de datos de usuario que elijas expresamente: la carpeta superior de Chrome que contiene los perfiles.

python chrome-ai-model-audit.py "C:\Path\To\Chrome User Data"

El programa solo busca el directorio OptGuideOnDeviceModel. Omite enlaces, cuenta archivos normales y bytes, comprueba si existe weights.bin y sustituye tu ruta por una etiqueta fija. No demuestra que una función haya usado el modelo ni evalúa la IA en la nube.

Puedes reproducir la prueba sintética sin señalar ninguna carpeta de Chrome:

python chrome-ai-model-audit.py --self-test

Estado sintético	Clasificación esperada	Resultado observado
No existe el directorio del componente	`absent`	PASS
El directorio existe, pero está vacío	`present-empty`	PASS
Hay metadatos, pero no pesos	`present-without-weights`	PASS
Hay metadatos y pesos sintéticos	`present-with-weights`	PASS

El programa no enumera perfiles ni muestra usuarios de Windows; tampoco calcula huellas criptográficas del modelo ni abre bases de datos de los perfiles. Esta auditoría no lo necesita.

Define primero el problema. Para el uso de disco o procesamiento local, revisa On-device AI. Para saber si una página envía datos, audita cada función en la nube. La cuenta, las búsquedas y la sincronización tienen controles propios. Si rechazas que Google controle el código y las actualizaciones, necesitas migrar de navegador. Borrar una carpeta no resuelve de forma duradera ninguno de estos problemas.

Elimínalo con el control oficial
#

En un Chrome personal, usa On-device AI. En uno administrado por una organización, aplica la política específica del modelo local. El borrado manual, el bloqueo global de componentes y las opciones experimentales no son equivalentes.

Google sitúa hoy el control en Settings > System > On-device AI. Un cambio de Chromium de julio de 2026 lo traslada hacia Settings > AI en versiones posteriores; si no aparece, busca “On-device AI” en los ajustes. Apagarlo impide usar el modelo local y elimina el instalado; volver a encenderlo permite otra descarga. Google no promete que cada byte desaparezca al instante: deja que Chrome aplique el cambio y verifica después.

Sigue este orden:

Actualiza Chrome. Mantén activadas las actualizaciones de seguridad y anota la versión probada.
Inspecciona antes de eliminar. Abre chrome://on-device-internals y, si lo necesitas, ejecuta la auditoría de solo lectura sobre la carpeta que elegiste.
Usa el interruptor personal. Busca On-device AI en los ajustes —System hoy; AI en versiones futuras— y apágalo.
Usa la política solo en navegadores administrados. GenAILocalFoundationalModelSettings=1 impide la descarga y borra el modelo existente. Sin valor o con 0, Chrome puede administrarlo automáticamente en equipos compatibles. Es una política del navegador, no de la cuenta en la nube.
Reinicia y verifica. Consulta otra vez la página interna y el inventario. Si el estado tarda en cambiar, espera; no borres datos del perfil al azar.
Audita aparte la IA en la nube. Revisa AI Mode, Gemini en Chrome, la asistencia de escritura, las extensiones, las búsquedas, la sincronización y las políticas de la organización.

Control	Objetivo real	Elimina el modelo local	Detiene la IA en la nube	Efecto colateral	Uso
Ajuste On-device AI	modelo fundacional local	Sí	No	inhabilita las funciones que dependen del modelo	control oficial para uso personal
`GenAILocalFoundationalModelSettings=1`	modelo fundacional local	Sí	No	inhabilita las funciones que dependen del modelo	control administrado
Borrado manual de la carpeta	archivos presentes	No de forma fiable	No	puede dañar el perfil si eliges mal la ruta	evitar; no es un control documentado
`ComponentUpdatesEnabled=false`	numerosos componentes	No está garantizado	No	Alto	evitar para un solo modelo
Funciones experimentales relacionadas con IA	experimentos temporales	No está garantizado	No está garantizado	Impredecible	solo para pruebas
`AIModeSettings=1`	entradas de AI Mode en Chrome	No	No; solo oculta ciertas entradas	Bajo	integración en perfiles administrados
Cambiar de navegador	proveedor y servicios	No corresponde	Depende	Alto	si desconfías de Google

No desactives todas las actualizaciones para bloquear un modelo. ComponentUpdatesEnabled abarca muchos componentes, aunque algunos componentes críticos de seguridad basados en datos siguen actualizándose. Tampoco controla las actualizaciones del propio Chrome. Es una política demasiado amplia para esta tarea.

Tampoco dependas de una lista de chrome://flags. Chromium las define como experimentos, y Chrome advierte que pueden provocar pérdida de datos o dañar la seguridad y la privacidad. Pueden desaparecer; los ajustes oficiales tienen un alcance definido.

Qué sigue activo después de eliminarlo
#

Apagar On-device AI controla el modelo local. No desactiva la escritura en la nube, Gemini, las extensiones, los flujos de Safe Browsing, la sincronización, las búsquedas ni la cuenta de Google.

Que una tarea «se ejecute en local» solo indica dónde se procesa. La función aún puede enviar a la nube una señal de riesgo derivada; otra puede enviar texto, contexto o una URL a un modelo remoto; y una extensión puede usar otro proveedor.

Capa	Ejemplos	Pregunta sobre los datos o el control	Control correcto
Local	modelo base, resumen o clasificación local	¿Aceptas guardar el modelo y procesar datos aquí?	On-device AI o política específica
Híbrida	clasificación local de estafas y veredicto de Safe Browsing	¿Qué señal derivada sale y bajo qué modo de protección?	revisar la función y Safe Browsing; no deducirlo de la ubicación del modelo
Nube	Help me write, Gemini en Chrome, AI Mode	¿Envía instrucciones, contexto, URL o datos de la cuenta?	controles de cada función o del perfil administrado
Extensión	asistente de un tercero	¿Qué lee y adónde lo envía?	retirar la extensión o sus permisos y revisar su política
Proveedor	actualizaciones, valores predeterminados, sincronización, servicios	¿Confías en quien opera el navegador?	elegir navegador y configurar cuenta y servicios

La documentación de Help me write indica que el texto introducido, el contenido cercano y la URL se envían a Google. La política de AI Mode solo cubre ciertas entradas de la barra de direcciones y la página Nueva pestaña; no cubre la web de AI Mode ni todas las integraciones de Google. Eliminar el modelo local no cambia nada de ello.

La auditoría de privacidad de asistentes de IA permite comprobar la conservación, las cuentas y los flujos de datos. El modelo de amenazas en la era de la IA distingue el modelo de quienes pueden actuar a partir de sus resultados.

¿Conservarlo, eliminarlo o cambiar de navegador?
#

Conserva el modelo si sus funciones locales encajan con tus riesgos. Elimínalo si rechazas su almacenamiento o procesamiento. Cambia de navegador si no aceptas el papel de Google.

La contrapartida es real. Un modelo local puede reducir la exposición a la nube y ayudar a detectar estafas, pero ocupa disco, consume recursos, añade complejidad y depende de las decisiones del proveedor. Eliminarlo puede ser razonable; tener menos código no implica automáticamente más seguridad.

Tu caso	Primer paso razonable	Lo que no demuestra
Valoro las funciones locales y acepto su coste	Mantén On-device AI y revisa cada función	que todo el flujo sea local
No acepto guardar ni ejecutar el modelo local	Apaga On-device AI y verifica	que la IA de Chrome en la nube esté desactivada
Acepto Chrome, pero rechazo ciertas funciones en la nube	Desactívalas por separado; usa políticas cuando corresponda	que cubra extensiones o servicios de la cuenta
No acepto a Google como operador	Planifica una migración	que el sustituto carezca de IA, informes de uso, servicios en la nube o costes de seguridad

Firefox ofrece un contraste, no un ganador automático. Según AI Controls, Firefox 148 y posteriores permiten bloquear en un panel las funciones generativas integradas actuales y futuras, además de eliminar los modelos locales. El control no abarca extensiones independientes: es una preferencia unificada, no una garantía de ausencia total de IA.

Revisa cada navegador basado en Chromium. Puede omitir un asistente y conservar otros componentes, o usar otra nube. «Privado» o «sin IA» no sustituye comprobar actualizaciones, valores predeterminados, extensiones y políticas.

Si cambias de navegador, traslada las credenciales antes de borrar el perfil. El protocolo para migrar un gestor de contraseñas explica por qué dos totales iguales no prueban que se hayan conservado contraseñas, claves de acceso, códigos de un solo uso y vías de recuperación.

Reduce la dependencia de Google sin debilitar la seguridad del navegador
#

Define qué dependencia de Google quieres eliminar. Sustituye por separado las búsquedas, la sincronización, la IA, la cuenta y el navegador, sin perder las actualizaciones ni una vía de regreso probada.

Sigue este orden:

Define el objetivo. Elige entre búsquedas, cuenta, IA en la nube, sincronización, IA local o navegador. Un interruptor no elimina las seis dependencias.
Haz inventario y traslada los datos. Anota marcadores, extensiones, claves de acceso, contraseñas, segundos factores de autenticación y códigos de recuperación. Usa un proceso documentado y conserva el perfil anterior.
Prueba el sustituto. Descárgalo del sitio oficial; comprueba actualizaciones, buscador, informes de uso y controles de IA; prueba inicios de sesión, llamadas, banca, accesibilidad y llaves físicas.
Retira una dependencia cada vez. Elimina datos o cierra la sesión solo cuando el sustituto funcione. Conserva las actualizaciones: bloquear componentes no elimina la IA en la nube.

En conclusión: elige el control según el problema
#

El procedimiento documentado para el modelo local es sencillo: inspecciona, apaga On-device AI, reinicia y verifica. La privacidad exige revisar por separado lo local, lo híbrido, la nube, las extensiones, la cuenta y el proveedor.

No decidas por «4 GB» ni confundas borrar con establecer una política. Si te preocupan el disco o el procesamiento, apaga el modelo. Si te preocupa la nube, audita cada función. Si rechazas a Google, migra de navegador y sustituye las dependencias de la cuenta sin debilitar las actualizaciones ni perder credenciales.

Preguntas frecuentes
#

El tamaño y los menús cambian; la nube, el borrado y otros navegadores requieren controles propios.

¿Todas las instalaciones de Chrome descargan un modelo de IA de 4 GB?
#

No. Influyen los requisitos, los desencadenantes, el hardware, el espacio libre, la variante y la versión. Google cita modelos de 2B y 4B parámetros y tamaños instalados variables. Inspecciona tu navegador.

¿Dónde está el ajuste On-device AI si no aparece en System?
#

Busca On-device AI en los ajustes de Chrome. A fecha del 6 de agosto de 2026, la ayuda de Google lo situaba en Settings > System, mientras Chromium lo estaba trasladando hacia Settings > AI. La ubicación depende del canal y de la versión.

¿Apagar On-device AI desactiva toda la IA de Chrome?
#

No. Controla el modelo local. AI Mode, Gemini, la escritura en la nube, las extensiones, Safe Browsing, las búsquedas, la sincronización y la cuenta se administran por separado.

¿Debo borrar manualmente `weights.bin` o la carpeta del modelo?
#

No. El borrado manual no es un control documentado y no fija una preferencia duradera, de modo que los archivos permitidos pueden regresar. Usa el ajuste oficial o la política específica y después verifica.

¿Firefox u otro navegador privado es más seguro automáticamente?
#

No. Firefox 148+ ofrece un control unificado para la IA generativa integrada, pero no abarca las extensiones ni los servicios web. Los demás navegadores difieren en asistentes, informes de uso, actualizaciones, dependencias y costes de compatibilidad. Comprueba la versión actual del producto.

Fuentes
#

Las diez fuentes oficiales que pueden cambiar llevan su copia exacta en Wayback. La fuente sobre el traslado del ajuste en Chromium es un commit inmutable, así que no inventamos una fecha de archivo.

#	Fuente	URL	Copia archivada o evidencia inmutable
1	Ayuda de Google Chrome — administrar modelos de IA generativa en el dispositivo en Chrome	https://support.google.com/chrome/answer/16961953?hl=en	https://web.archive.org/web/20260801170205/https://support.google.com/chrome/answer/16961953?hl=en
2	Chrome for Developers — comprender la administración de modelos integrados	https://developer.chrome.com/docs/ai/understand-built-in-model-management	https://web.archive.org/web/20260709211120/https://developer.chrome.com/docs/ai/understand-built-in-model-management
3	Chrome for Developers — primeros pasos con la IA integrada	https://developer.chrome.com/docs/ai/get-started	https://web.archive.org/web/20260629120921/https://developer.chrome.com/docs/ai/get-started
4	Chrome Enterprise — ajustes del modelo fundacional local de IA generativa	https://chromeenterprise.google/policies/gen-ai-local-foundational-model-settings/	https://web.archive.org/web/20260308023006/https://chromeenterprise.google/policies/gen-ai-local-foundational-model-settings/
5	Chrome Enterprise — actualizaciones de componentes habilitadas	https://chromeenterprise.google/policies/component-updates-enabled/	https://web.archive.org/web/20260208072812/https://chromeenterprise.google/policies/component-updates-enabled/
6	Chrome Enterprise — ajustes de AI Mode	https://chromeenterprise.google/policies/ai-mode-settings/	https://web.archive.org/web/20260526191101/https://chromeenterprise.google/policies/ai-mode-settings/
7	Chromium — experimentos y `chrome://flags`	https://www.chromium.org/developers/design-documents/experiments/	https://web.archive.org/web/20260804174840/https://www.chromium.org/developers/design-documents/experiments/
8	Google Security Blog — IA en el dispositivo para detectar estafas de soporte técnico	https://security.googleblog.com/2025/05/using-ai-to-stop-tech-support-scams-in.html	https://web.archive.org/web/20260430082954/https://security.googleblog.com/2025/05/using-ai-to-stop-tech-support-scams-in.html
9	Ayuda de Google Chrome — escribir con IA en Chrome	https://support.google.com/chrome/answer/14582048	https://web.archive.org/web/20260725211037/https://support.google.com/chrome/answer/14582048
10	Soporte de Mozilla — AI Controls de Firefox	https://support.mozilla.org/en-US/kb/firefox-ai-controls	https://web.archive.org/web/20260613231843/https://support.mozilla.org/en-US/kb/firefox-ai-controls
11	Chromium — trasladar los ajustes de On-device AI a la página de IA	https://chromium.googlesource.com/chromium/src/+/a4d2410c1ca703aa6c2ed0ec83ff95d0f4205a72	URL de commit inmutable

Cora Aegis

Cora Aegis escribe en CypherpunkGuide guías de OPSEC con la privacidad como eje. Para este artículo auditó cinco resultados de Google y dos modos de respuesta generada, verificó diez páginas oficiales archivadas y un commit inmutable de Chromium, organizó siete controles de Chrome y creó una auditoría de solo lectura con cuatro estados del modelo local.

Más sobre Cora Aegis →

Privacidad por capas: Monero, SimpleX y Cryptomator (2026)

Thu, 13 Aug 2026 00:00:00 +0000

Un pago privado, una conversación cifrada y una carpeta cifrada en la nube parecen tres problemas resueltos. Cada una de estas herramientas protege algo valioso. El error consiste en creer que, al usarlas juntas, forman por sí solas un sistema anónimo.

Para comprobarlo, clasifiqué 18 datos observables: seis de Monero, seis de SimpleX y seis de Cryptomator. El CSV vinculado a sus fuentes identifica quién puede ver cada dato, qué ocurre con la configuración predeterminada, qué cambia al reforzarla y dónde termina la protección. Un validador con reglas fijas rechaza las filas sin observador, fuente o fecha; el resumen generado conserva cuatro estados sin convertirlos en una puntuación.

La fecha de corte es el 13 de agosto de 2026. La auditoría detectó seis puntos compartidos que pueden relacionar los tres ámbitos: alias, dispositivo, ruta de internet, contraparte, patrón de tiempo y tamaño, y material de recuperación. Por eso, las protecciones documentadas se analizan junto con los rastros que todavía quedan.

Tres herramientas de privacidad protegen ámbitos distintos
#

Monero actúa sobre los datos del pago, SimpleX sobre la entrega de mensajes y Cryptomator sobre los archivos sincronizados. Son tres controles con alcances diferentes; juntos no ofrecen una garantía general de anonimato.

Conviene empezar por el registro que quieres proteger, no por el nombre del producto. Quien analiza una cadena pública, tu proveedor de internet, un servidor intermediario de mensajería, el servicio de nube, la persona con la que tratas y un programa malicioso instalado en tu equipo ven datos distintos. Una misma información puede quedar oculta para uno y expuesta para otro.

Ámbito	Qué protege la herramienta	Qué queda fuera
Pago — Monero	dificulta identificar la entrada real, oculta la dirección del destinatario y el importe	IP de la cartera, datos del comercio, identidad que revelaste, claves y texto legible en el dispositivo
Mensajería — SimpleX	contenido en tránsito, ausencia de un identificador global de perfil, separación entre la IP de origen y el relé de destino mediante reenvío	identificadores de cola entre pares, horarios, algunos metadatos de red y relé, lo que sabe el contacto, historial del dispositivo
Almacenamiento — Cryptomator	contenido y nombres antes de la sincronización; estructura de carpetas ofuscada	fechas, cantidad y tamaño de objetos, formato reconocible de la bóveda, identidad de la cuenta de nube, texto legible en el dispositivo cuando la bóveda está abierta

En este artículo, protected significa que el dato está protegido frente al observador nombrado y dentro del alcance que documenta el proyecto. No significa que el destinatario no pueda verlo ni que un equipo infectado sea seguro. partial indica que una medida reduce la información disponible, pero no elimina ese dato ni todas las formas de relacionarlo. exposed señala una exposición descrita por la fuente. unknown significa que la documentación no demuestra ni protección ni exposición: no es una prueba en ningún sentido.

Esta es también la disciplina básica de un modelo de amenazas: antes de elegir una herramienta, nombra al observador, el dato que quieres proteger y el hecho que podría registrar. Si cambias al observador, puede cambiar la respuesta.

Monero oculta el grafo de transacciones, no todo el pago
#

Monero impide distinguir con certeza la entrada real del emisor entre los señuelos, lo que permite una negación plausible; crea direcciones de un solo uso para el destinatario y oculta los importes con RingCT. Estas propiedades pertenecen al protocolo; no protegen por sí solas la red, la contraparte ni el dispositivo.

Las especificaciones técnicas de Monero indican un anillo de 16 entradas: una corresponde al gasto real y 15 son señuelos. El observador de la cadena no puede atribuir con certeza cuál es la real; esa capacidad de negar de forma creíble una atribución se llama negación plausible. No permite afirmar que alguien tenga exactamente una probabilidad de 1 entre 16 de acertar. La investigación oficial OSPEAD analiza cómo una selección no uniforme y el momento de los gastos pueden alterar las inferencias. El tamaño del anillo no equivale a una probabilidad personal de anonimato.

El destinatario y el importe se protegen con mecanismos distintos. Una dirección sigilosa es una dirección de un solo uso que impide que la cadena pública muestre la dirección reutilizable del destinatario. RingCT, sigla de Ring Confidential Transactions o transacciones confidenciales en anillo, oculta el importe. Por eso «privacidad de Monero» reúne tres afirmaciones diferentes: emisor, destinatario e importe.

Observador	Qué cambia Monero	Qué puede seguir sabiendo
Analista de la cadena pública	dificulta atribuir la entrada real y oculta el vínculo con el destinatario y el importe	existencia y momento del evento en el protocolo; inferencias probabilísticas
Operador de un nodo remoto	no obtiene de la cadena una dirección de destino o un importe legibles	conexión de la cartera e IP de origen si no proteges la ruta de red aparte
Proveedor de internet o VPN	las protecciones del grafo de transacciones no cambian	ruta de conexión, horarios y patrón de destinos
Contraparte o casa de cambio	la cadena pública no revela a otros esos campos privados	identidad, pedido, dirección de entrega, cuenta, importe o conversación que le proporcionaste
Dispositivo comprometido	la privacidad del protocolo sigue protegiendo frente a observadores públicos	claves, destino, importe, pantalla, portapapeles y contraseña introducida

Las preguntas frecuentes oficiales descartan el anonimato garantizado y advierten sobre equipos comprometidos, claves expuestas, contraseñas débiles y datos identificativos entregados a otra persona. Una subdirección distinta para cada pagador o finalidad reduce la reutilización visible para las contrapartes. No borra del sistema de un comercio la dirección donde debe entregar un pedido.

La red exige otra decisión. Según la documentación, una cartera que se conecta a un nodo remoto no oculta su IP de forma predeterminada. Tor o I2P pueden proteger esa ruta si se configuran y comprueban por separado. El mecanismo de propagación Dandelion++ modifica cómo se difunde una transacción, pero no oculta la conexión de un nodo completo frente al proveedor de internet, la VPN o el primer par. Si la IP forma parte de tu riesgo, verifica la ruta real de la cartera.

La guía de privacidad de Bitcoin en cadena parte de otro protocolo, pero llega a una regla operativa compatible: proteger la cadena no elimina los datos comerciales ni las pruebas que quedan en el dispositivo.

SimpleX no usa un identificador global, pero deja metadatos
#

SimpleX no usa un identificador global de perfil para entregar mensajes. Sí usa identificadores de cola distintos para cada relación y genera metadatos operativos que distintos observadores pueden ver. Relés, redes, contactos, notificaciones y dispositivos acceden a datos diferentes.

Un relé es un servidor intermediario que recibe y reenvía datos. La política de privacidad de SimpleX señala que los perfiles y el historial ya entregado permanecen en los dispositivos; los relés no conservan ese historial. Sin embargo, un mensaje cifrado que todavía no se ha entregado puede quedar en los relés predeterminados hasta su entrega o durante un máximo de 21 días. Los relés de archivos predeterminados conservan archivos cifrados durante 48 horas. Por tanto, «los servidores no guardan nada» sería incorrecto, aunque no almacenen el texto legible del mensaje.

Los mensajes se rellenan hasta 16 KiB y los archivos se dividen en bloques de tamaño fijo. Esto reduce la precisión con la que se deduce el tamaño original; no oculta que hubo tráfico. En iOS, las notificaciones instantáneas también pueden revelar al servidor de notificaciones cuántas colas las tienen habilitadas y un volumen aproximado de mensajes.

Dato o control	Comportamiento predeterminado	Configuración más estricta	Exposición que permanece
Identidad del perfil	no hay ID global; cada relación usa sus propios datos	perfiles de incógnito cuando necesitas separar contextos	el contacto conoce el perfil con el que habla; rasgos repetidos pueden relacionarlo con otros
Ruta por relés	un relé de reenvío configurado precede al relé de destino; si hay varios operadores predeterminados, la aplicación prefiere uno distinto	Tor u otra red adicional que hayas evaluado cuando el relé elegido no debe ver la IP de origen	los dos relés podrían pertenecer al mismo operador; un observador local sigue viendo tráfico
Conexión compartida	un perfil comparte una conexión TCP	aislamiento de transporte por contacto, después de comprobar que la función sigue marcada como BETA	el tiempo y el volumen aún pueden coincidir
Identidad del contacto	un enlace de invitación establece la conexión	comparar el código de seguridad por un canal independiente	ese segundo canal también debe pertenecer a la persona correcta
Historial en el dispositivo	los mensajes entregados se guardan localmente	contraseña para la base de datos y una conservación adecuada	el dispositivo desbloqueado, el destinatario, una captura o un programa malicioso pueden conservar texto legible

La guía de privacidad y seguridad advierte que alguien puede sustituir un enlace de invitación durante el envío. Antes de tratar un contacto sensible como auténtico, compara el código de seguridad de la aplicación por un canal realmente independiente. Repetirlo mediante la misma cuenta que aún no has verificado no sirve como segunda comprobación.

El modelo de amenazas del protocolo también precisa qué quiere decir «sin identificadores». Otra persona puede probar si dos perfiles que no están en modo incógnito contienen los mismos datos; los recibos y las respuestas automáticas pueden delatar si alguien está activo y cuándo. Además, una llamada no expone lo mismo que un mensaje. La guía de llamadas explica que un servidor TURN —un relé que transporta el audio o vídeo cuando no hay conexión directa— conoce la duración. En una llamada directa, el contacto ve la IP. Audita las llamadas por separado.

SimpleX protege el transporte de los mensajes, no convierte en seguro todo lo que escribes. La guía sobre privacidad del número de teléfono explica la ventaja de no depender de un número de teléfono; el comportamiento del contacto y la seguridad del dispositivo siguen necesitando controles aparte.

Cryptomator cifra los archivos, no su patrón de actividad
#

Cryptomator cifra el contenido y los nombres antes de sincronizar, y ofusca la estructura de las carpetas. No oculta fechas, cantidades, tamaños almacenados ni el formato reconocible de la bóveda.

El objetivo de seguridad de Cryptomator delimita el producto con especial claridad. El proveedor de nube no debe recibir nombres ni contenido legibles, pero puede observar cuándo cambian los objetos, cuántos hay y cuánto ocupan. Las extensiones .c9r y .c9s, junto con los archivos de configuración, pueden revelar que existe una bóveda de Cryptomator. Es cifrado, no un intento de ocultar que hay datos cifrados.

Cuando abres la bóveda, el dispositivo se convierte en el riesgo más directo. Los archivos se descifran y quedan como texto legible en el dispositivo desbloqueado: una aplicación autorizada puede leerlos y también podrían hacerlo un programa malicioso, quien administre el equipo o una herramienta de captura. Los archivos temporales, el portapapeles y las copias que otra aplicación guarde fuera de la bóveda quedan fuera de Cryptomator.

Tampoco sustituye la sincronización ni las copias de seguridad. Las buenas prácticas oficiales recomiendan copias periódicas de la bóveda cifrada, mientras que la guía sobre conflictos trata la sincronización como un sistema separado que puede producir versiones incompatibles. No guardes las credenciales y el material de recuperación en la misma cuenta de nube ni en el mismo equipo que permiten recuperar o desbloquear. La recuperación de la bóveda no restaura archivos cifrados que ya se borraron.

Nuestra auditoría de 18 datos observables
#

La auditoría compara seis datos por herramienta, siempre frente a un observador concreto. Cada fila contiene fuente oficial, fecha y limitación. Sirve para localizar fallos al combinar herramientas; no puntúa productos ni establece un ranking.

Construí el registro de 18 filas con las fuentes oficiales citadas aquí. Después ejecuté el validador: confirmó las 18 filas, seis por herramienta, campos únicos, dominios autorizados, fechas ISO y limitaciones no vacías. El resumen muestra los cuatro estados y advierte que no deben compararse sus totales.

El método aplica cinco reglas:

Cada dato se evalúa frente a un observador. La «IP de origen» se comprueba frente al relé o al observador de red, no frente a un atacante indefinido.
La configuración predeterminada y la reforzada aparecen por separado. hardened solo recoge una opción documentada o un control adicional indicado expresamente. No afirma que Cora haya probado la ruta ni convierte una posibilidad con Tor en valor predeterminado.
Toda fila dice qué queda fuera de la protección. Un mensaje cifrado durante el transporte puede ser texto legible en los dos dispositivos.
La falta de pruebas queda como unknown. El objetivo de seguridad de Cryptomator no promete anonimato de red para la sincronización. Por eso, la fila se clasifica como unknown en vez de recibir una respuesta inventada.
Los recuentos no se suman. Seis datos, observadores y consecuencias distintos no producen una medida válida de «privacidad total».

Dejar un dato como unknown fue una decisión metodológica, no una carencia que debiera rellenarse con la reputación del producto. También asigné un observador a cada fila antes de clasificarla. Esa disciplina reduce el riesgo de endurecer el componente equivocado porque una tabla parecía completa.

Seis datos compartidos que pueden vincular los registros a una identidad
#

Lo que sigue es una inferencia de Cora a partir de las pruebas de cada componente. Ningún proveedor afirma haber medido el flujo completo de Monero, SimpleX y Cryptomator. El glosario de NIST llama disociabilidad a la capacidad de procesar datos o hechos sin relacionarlos con una persona o dispositivo más de lo necesario para operar. Esa propiedad se debilita cuando los tres ámbitos comparten un dato estable que permite relacionarlos.

Dato compartido entre ámbitos	Ejemplo	Quién podría relacionarlo	Medida de separación
Alias o cuenta	el mismo nombre aparece en el perfil de SimpleX, el registro de una casa de cambio y la cuenta de nube	contraparte, proveedor de la cuenta, empresa que recopila y comercializa datos personales	identidades distintas por propósito; sin correo de recuperación compartido
Dispositivo	un portátil infectado ve la cartera, el chat y los documentos de la bóveda abierta	programa malicioso, administrador, análisis forense	dispositivos distintos o sistemas fuertemente aislados cuando el riesgo lo justifica; una cuenta ordinaria del sistema no detiene a quien tiene privilegios de administrador
Ruta de internet	cartera, relé y nube se conectan mediante la misma IP doméstica estable	proveedor de internet o VPN, relé, proveedor de nube con datos auxiliares	diseña la ruta de cada actividad sensible; cifrar el protocolo o el archivo no oculta la IP
Contraparte	la misma persona recibe el mensaje, el pago y el enlace al archivo	destinatario o comercio	entrega solo los datos necesarios; usa subdirecciones y enlaces específicos para cada propósito
Tiempo y tamaño	mensaje, pago y subida ocurren con segundos de diferencia	observador capaz de consultar varios registros	agrupa o retrasa cuando sea viable; no describas en tiempo real el importe o el nombre exacto del archivo
Recuperación	un correo, gestor de contraseñas o copia de fotos permite recuperar los tres sistemas	atacante que toma la cuenta, proveedor de nube, quien pueda obligarte a entregar el material	canales de recuperación separados y material sin conexión; prueba cada procedimiento por su cuenta

La coincidencia temporal debe interpretarse con cautela. Dos hechos simultáneos son una pista, no una demostración de que pertenezcan a la misma persona. Repetir muchas veces la secuencia mensaje–pago–subida sí puede producir un patrón más útil. Introducir retrasos al azar no crea anonimato: primero elimina vínculos más fuertes, como compartir identidad y dispositivo; después reduce la precisión temporal innecesaria.

El análisis sobre desanonimización mediante IA muestra el mismo problema desde otro ángulo: relacionar muchas señales débiles requiere menos esfuerzo cuando comparten un identificador. Aquí no hablamos del estilo de escritura, sino de hechos que los sistemas pueden registrar.

Configura las tres herramientas sin usar un identificador para todo
#

Empieza por tu modelo de amenazas: separa propósitos, verifica programas y contactos, protege solo las rutas de red necesarias, cifra antes de sincronizar y ensaya la recuperación. Un fallo de cuenta o dispositivo no debería exponerlo todo.

Practica este orden con datos de prueba sin información sensible antes de mover fondos reales o documentos sensibles:

Define tres observadores y qué debes ocultarles. Por ejemplo: «la cadena pública no debe mostrar destinatario ni importe», «el relé no debe conservar el texto del mensaje» y «el proveedor de nube no debe leer nombres ni contenido». Añade red y dispositivo solo si tu riesgo justifica el coste.
Separa las identidades por propósito. Decide si la contraparte puede relacionar el pago, la conversación y el archivo. Si no, evita compartir alias, correo de recuperación, imagen de perfil, cuenta de nube o comentarios que relacionen los tres hechos.
Descarga desde la fuente oficial y verifica el programa. Comprueba firmas o instrucciones sobre compilaciones reproducibles cuando el proyecto las publique. Ensaya Monero en stagenet —su red de pruebas, sin dinero real— y usa datos falsos en SimpleX y Cryptomator. Si no verificas el programa, las demás medidas no compensan ese origen incierto.
Configura el pago. Usa una subdirección distinta por pagador o finalidad. Si el nodo remoto no debe conocer la IP de la cartera, protege y comprueba esa conexión aparte. Anota qué información conserva la contraparte.
Autentica el contacto. Crea la conexión en SimpleX, compara el código de seguridad por otro canal, revisa el modo incógnito y el aislamiento de transporte, y decide si las notificaciones o llamadas encajan con tu modelo de amenazas.
Prepara el almacenamiento. Crea la bóveda en local, asigna una contraseña fuerte y exclusiva, separa el material de recuperación y solo entonces sincroniza los archivos cifrados. Comprueba que exportaciones temporales y copias de otras aplicaciones no dejan texto legible fuera.
Ensaya un fallo sin usar secretos reales. Restaura una bóveda de prueba, recupera o migra un perfil de chat de prueba sin información sensible según la documentación vigente y usa una cartera vacía o un entorno de prueba aislado. Nunca introduzcas la semilla de fondos reales en una web, nube, dispositivo sin verificar o herramienta desconocida; tampoco sobrescribas la cartera existente durante el ensayo. Descubre ahora si los tres procedimientos dependen del mismo teléfono.
Revisa los datos compartidos entre ámbitos. Compara alias, dispositivo, red, contraparte, tiempo, tamaño y recuperación. Retira los puntos compartidos que no aporten nada y documenta los que aceptas.

Separar tiene costes: más material de recuperación, tareas más lentas, notificaciones que no llegan, fallos de red y más ocasiones para equivocarte. La meta no es dividir por dividir, sino aplicar la separación mínima que impida al observador concreto de tu modelo relacionar los registros que quieres mantener separados. La guía sobre soberanía y servidores propios aplica la misma regla a la infraestructura: trasladar un servicio cambia quién administra el riesgo, pero no elimina la administración ni la recuperación.

En conclusión: protege el dato que realmente importa
#

Usa Monero cuando necesites privacidad del grafo de transacciones, SimpleX para mensajes sin un identificador global de perfil y Cryptomator para cifrar archivos de nube. Después revisa identidad, dispositivo, red, tiempo y material de recuperación compartido.

Si solo quieres impedir que la nube lea nombres de archivo, Cryptomator puede resolver todo tu problema. Si un comercio ya conoce tu nombre legal y dirección de entrega, Monero no borra ese registro comercial. Si no has verificado a un contacto, SimpleX puede cifrar la comunicación con la persona equivocada. Añadir herramientas no corrige un modelo de amenazas mal planteado.

Tu configuración tiene una base defendible cuando cada afirmación nombra a su observador y has comprobado cada vía de recuperación. Conserva un unknown honesto cuando falten pruebas. Es más seguro que una tabla impecable en apariencia que promete algo que ninguna fuente establece.

Puntos clave

Tres alcances: Monero, SimpleX y Cryptomator protegen registros distintos; ninguna combinación crea por sí sola anonimato para pagos, mensajes y almacenamiento.
En la cadena: el anillo de Monero tiene 16 entradas —una real y 15 señuelos—, pero ese número no representa una probabilidad personal de «1 entre 16».
En los mensajes: SimpleX elimina el identificador global de perfil, pero siguen existiendo identificadores de cola entre pares, horarios, historial local y ciertos metadatos de notificación.
En la nube: Cryptomator cifra contenido y nombres, pero deja visibles fechas, cantidades, tamaños almacenados y el formato de la bóveda.
En la auditoría: el registro validado contiene 18 datos —tres herramientas por seis campos— y no produce una puntuación ni un ranking.

Preguntas frecuentes
#

Estas herramientas protegen campos concretos del protocolo o del almacenamiento; no ocultan todos los registros de identidad, red, dispositivo y recuperación que los rodean. Nombra primero al observador y elige solo los controles que cambien lo que puede ver.

¿Monero, SimpleX y Cryptomator me vuelven anónimo si los uso juntos?
#

No. Cada uno protege un registro diferente. La contraparte, un dispositivo infectado, una IP estable, una secuencia temporal repetida o un único canal de recuperación pueden relacionarlos. El anonimato depende de tu modelo de amenazas; no aparece por reunir tres productos.

¿Monero oculta mi IP al nodo remoto?
#

No de forma predeterminada. La documentación separa la privacidad en cadena de la privacidad de red y propone Tor o I2P para esa conexión. Comprueba por dónde sale realmente la cartera; no deduzcas la protección de IP a partir de que Monero oculte emisor, destinatario e importe en la cadena.

¿SimpleX funciona sin identificadores ni metadatos?
#

No utiliza un identificador global de perfil para entregar mensajes, pero sí identificadores de cola distintos para cada relación y los metadatos operativos documentados. Relés, contactos, sistemas de notificación, observadores de red y dispositivos acceden a campos diferentes.

¿Mi proveedor de nube puede saber que uso Cryptomator?
#

Sí. Cryptomator oculta el contenido y los nombres, pero no pretende ocultar el formato de la bóveda. Pueden seguir visibles sus extensiones reconocibles, archivos de configuración, fechas, cantidades y tamaños almacenados.

¿Conviene guardar todo el material de recuperación en un gestor de contraseñas?
#

Solo si tu modelo acepta que ese gestor y su propia recuperación se conviertan en un punto común para los tres sistemas. En situaciones de mayor riesgo, separa los materiales cuya pérdida o captura expondría todo y prueba cada procedimiento para que la separación no termine bloqueándote a ti.

Fuentes
#

Cada fuente original que puede cambiar aparece junto a una captura exacta de Wayback. Las afirmaciones se apoyan en la página oficial activa; la copia archivada mantiene una segunda ruta de verificación.

#	Fuente	URL	Copia archivada
1	Monero Docs — especificaciones técnicas	https://docs.getmonero.org/technical-specs/	https://web.archive.org/web/20260808191457/https://docs.getmonero.org/technical-specs/
2	Monero — preguntas frecuentes	https://www.getmonero.org/get-started/faq/	https://web.archive.org/web/20260730231338/https://www.getmonero.org/get-started/faq/
3	Monero Docs — subdirecciones	https://docs.getmonero.org/public-address/subaddress/	https://web.archive.org/web/20260804004416/https://docs.getmonero.org/public-address/subaddress/
4	Monero Research Lab — OSPEAD	https://www.getmonero.org/2025/04/05/ospead-optimal-ring-signature-research.html	https://web.archive.org/web/20260423131819/https://www.getmonero.org/2025/04/05/ospead-optimal-ring-signature-research.html
5	SimpleX Chat — política de privacidad y detalles técnicos	https://simplex.chat/privacy/	https://web.archive.org/web/20260725150448/https://simplex.chat/privacy/
6	SimpleX Chat — privacidad y seguridad	https://simplex.chat/docs/guide/privacy-security.html	https://web.archive.org/web/20260804190527/https://simplex.chat/docs/guide/privacy-security.html
7	Protocolo SimpleX Chat — modelo de amenazas	https://simplex.chat/docs/protocol/simplex-chat.html	https://web.archive.org/web/20260731210120/https://simplex.chat/docs/protocol/simplex-chat.html
8	SimpleX Chat — llamadas de audio y vídeo	https://simplex.chat/docs/guide/audio-video-calls.html	https://web.archive.org/web/20260729214320/https://simplex.chat/docs/guide/audio-video-calls.html
9	Cryptomator Docs — objetivo de seguridad	https://docs.cryptomator.org/security/security-target/	https://web.archive.org/web/20260512122357/https://docs.cryptomator.org/security/security-target/
10	Cryptomator Docs — buenas prácticas	https://docs.cryptomator.org/security/best-practices/	https://web.archive.org/web/20260722112824/https://docs.cryptomator.org/security/best-practices/
11	Cryptomator Docs — recuperación de la bóveda	https://docs.cryptomator.org/desktop/vault-recovery/	https://web.archive.org/web/20260310220344/https://docs.cryptomator.org/desktop/vault-recovery/
12	Cryptomator Docs — conflictos de sincronización	https://docs.cryptomator.org/desktop/sync-conflicts/	https://web.archive.org/web/20260706002907/https://docs.cryptomator.org/desktop/sync-conflicts/
13	NIST CSRC — disociabilidad	https://csrc.nist.gov/glossary/term/disassociability	https://web.archive.org/web/20260622190616/https://csrc.nist.gov/glossary/term/disassociability

Cora Aegis

Cora Aegis escribe en CypherpunkGuide guías de OPSEC con la privacidad como eje. Para este artículo clasificó 18 datos observables de Monero, SimpleX y Cryptomator, respaldó cada fila con documentación oficial y preparó el conjunto de datos y el validador sin puntuaciones.

Más sobre Cora Aegis →

Cómo se hace doxxing a los streamers: 5 casos y la defensa (2026)

Sun, 21 Jun 2026 00:00:00 +0000

Toda guía de privacidad para streamers se lee como una lista de comprobación previa al despegue. Usa una VPN. Ten un correo aparte. Activa la verificación en dos pasos. Borra los metadatos de tus fotos. Vigila lo que se ve detrás de ti. El consejo no es malo, y quien lo cumple entero está de verdad más a salvo que quien no. (A lo largo de este artículo: doxxing es publicar los datos privados de alguien —su nombre, su dirección, su identidad— sin su consentimiento para facilitar el acoso; swatting es hacer una denuncia falsa de emergencia para que la policía armada se presente en el domicilio del blanco.) Pero lee los casos reales —los streamers a los que de verdad localizaron, hicieron swatting, acosaron u obligaron a mudarse— y aparece otra imagen. Casi a ninguno lo atraparon por saltarse la lista entera. Lo atraparon en un punto concreto, y ese mismo puñado de puntos se repite.

Eso importa porque una lista trata todos sus puntos como igual de decisivos, y no lo son. Un estudio de la UNESCO de 2021 sobre mujeres periodistas encontró que el 73 % de las encuestadas había sufrido violencia en línea, y que el abuso pasaba con frecuencia de las palabras a la publicación de datos personales (UNESCO, 2021). Para las creadoras mujeres y para las personas LGBTQ+ en particular, el doxxing rara vez es el final: es el paso anterior al acosador, a la llamada de swatting y a la amenaza sexual. Las guías indiferentes al género no tienen nada de esto en cuenta.

Como siempre hace esta serie, leemos cinco casos documentados de doxxing a streamers no por el espectáculo, sino por el mecanismo. La tabla siguiente es síntesis propia: cada caso queda asociado, no a lo que la víctima debería haber ocultado, sino al único punto de fallo que convirtió una identidad pública en un blanco localizable.

Caso	El punto de fallo	Cómo se ejecutó en la práctica	El control que aísla
Keffals (Clara Sorrenti), 2022	Un detalle visible en una foto publicada	Swatting, luego una ubicación deducida de una imagen, luego una mudanza forzada	Audita lo que se ve detrás, no solo los metadatos
Valkyrae, Cinna y Emiru, 2025	La ubicación en tiempo real, emitida en directo	Un acosador presencial usó la transmisión en la calle como faro de rastreo	Una transmisión desde la calle es una señal de ubicación
Dream, 2022	Un rostro oculto del que dependía toda la marca	Años de intentos colectivos por asociar fotos filtradas a un nombre	Trata el único atributo oculto como una credencial
Nadia Amine, 2022	Una dirección que ya estaba en circulación	Una llamada de swatting que no necesitó ningún error nuevo de ella	La privacidad del domicilio está en el origen de todo
Jacksfilms y SSSniperWolf, 2023	Un domicilio al alcance de una creadora hostil	Una rival que sacó a la luz su ubicación durante una pelea pública	Tu modelo de amenazas incluye a tu propio sector

Lee los cinco en conjunto y la defensa se reordena. El trabajo no es ocultar más cosas. Es saber qué punto de fallo se aplica a tu formato, a tu rostro y a tu audiencia, y cerrar ese primero.

Qué significa de verdad «que te hagan doxxing» siendo streamer
#

El doxxing es la conversión de una persona pública en una persona física a la que se puede alcanzar, y para un streamer la materia prima no es una base de datos filtrada, sino la propia transmisión. La definición clásica —publicar los datos privados de alguien contra su voluntad— se queda corta para entender cómo funciona contra los creadores. Un streamer entrega, por diseño, una enorme cantidad de señal: horas de voz, un rostro o uno ocultado a propósito, una habitación, una rutina, una presencia en tiempo real. El trabajo de quien hace doxxing rara vez es vulnerar un servidor. Es correlacionar lo que ya se mostró —la vista de una ventana, el timbre de un repartidor, un reflejo, el desliz del nombre de una calle— hasta dar con una ubicación y un nombre legal.

Por eso el modelo de amenazas de un streamer se separa del genérico. Los motores de inferencia a escala de IA que funden señales dispersas e «inofensivas» en una identidad apuntan a un caudal excepcionalmente rico cuando el blanco transmite en directo. Y el activo más valioso que tiene un creador seudónimo —un rostro oculto, como en el caso de Dream— es justo el tipo de credencial biométrica que rastreamos en Tu voz y tu rostro ya son contraseñas. La exposición no es una filtración puntual que se parchea. Es una emisión continua que hay que gestionar.

Hay una segunda divergencia que las guías mayoritarias omiten, y es la razón de ser de este artículo: la amenaza no afecta por igual según el género. Para las streamers mujeres y las personas LGBTQ+, el doxxing escala de forma predecible hacia el acoso y la amenaza sexual, y lo hace con más frecuencia y más crudeza que contra los blancos masculinos. Esa asimetría es estructural, cambia qué dato «inofensivo» es en realidad de alto riesgo, y tiene su propia sección más abajo, porque ninguna guía rival le dedica una.

Cinco casos, cinco puntos de fallo
#

La forma más rápida de ver cómo una transmisión se convierte en una ubicación es poner cinco casos documentados uno junto a otro y seguir la misma pregunta en cada uno: qué se mostró, cómo se llevó a la práctica y qué único control habría roto la cadena. Son episodios ya conocidos, tomados de la información periodística de la época; los detalles se atribuyen a esas fuentes, no se reconstruyen aquí.

El punto de fallo: un detalle en una foto, no un agujero en una base de datos. Clara Sorrenti, streamer y activista canadiense conocida como Keffals, sufrió un swatting en agosto de 2022 —la policía armada irrumpió en su casa de London, Ontario, por un correo falso enviado en su nombre— después de que el foro Kiwi Farms (un foro dedicado a organizar acoso) recopilara y difundiera sus datos. Huyó, pero el acoso la siguió: la información periodística describe a usuarios del foro escudriñando las fotos y publicaciones que ella compartía y cotejando los detalles para averiguar adónde se había ido, lo que la obligó a mudarse una y otra vez, en un momento incluso fuera del país (NBC News; Vice). Cloudflare acabó cortándole el servicio al foro, alegando una amenaza para la vida humana (Fortune). La lección: el dato que te expone suele estar escondido al fondo de algo que tú elegiste publicar —una ventana, una colcha, una línea de tejados—, no en un registro que se te olvidó cerrar.

— Keffals (Clara Sorrenti) — Kiwi Farms, agosto de 2022

El punto de fallo: la ubicación en tiempo real, emitida por diseño. En marzo de 2025, las streamers Valkyrae, Cinna y Emiru terminaron antes de tiempo un maratón de transmisión desde la calle (transmisión en vivo desde un lugar real, no desde el estudio) después de que un hombre que las había localizado amenazara al grupo ante la cámara, en directo (Rolling Stone). No fue un swatting ni una filtración de base de datos. Fue un acosador presencial que usó la propia transmisión en directo como faro de rastreo: el directo respondía continuamente y en público a la única pregunta que él necesitaba, dónde están ahora mismo. La lección: una transmisión desde la calle es una señal de ubicación continua, y el punto de fallo no es algo que la streamer olvidara ocultar, sino la presencia en tiempo real que el formato está hecho para transmitir.

— Valkyrae, Cinna y Emiru — transmisión desde la calle, marzo de 2025

El punto de fallo: un único atributo oculto del que depende toda la marca. Dream, uno de los creadores de Minecraft con más seguidores del mundo, se forjó una audiencia inmensa manteniendo su rostro en privado, lo que convirtió ese mismo rostro en el premio de una campaña sostenida de desanonimización. Durante años hubo intentos colectivos de asociar fotos filtradas o supuestas a un nombre real, antes de que él decidiera hacer una revelación controlada de su rostro en octubre de 2022 (Wikipedia). Lo importante no es la revelación, sino la presión que la precedió. La lección: cuando todo el valor de un seudónimo descansa sobre un solo atributo oculto —un rostro, un nombre real, una ciudad—, ese atributo se vuelve una credencial muy valiosa, y una multitud motivada es paciente. Protégelo como protegerías una contraseña, porque funcionalmente lo es.

— Dream — el valor de un rostro oculto, 2022

El punto de fallo: una dirección que ya circulaba. La streamer Nadia Amine sufrió un swatting en 2022, dentro de una oleada más amplia de swattings contra creadores aquel año (Sportskeeda). El fallo decisivo es anterior a cualquier transmisión concreta: una vez que un domicilio se ha filtrado al ecosistema de los data broker (empresas que compran y venden datos personales) y los foros, una falsa llamada de emergencia para enviar policía armada no necesita ningún error más de la víctima. La lección: la privacidad del domicilio está en el origen de todo lo demás —eliminar tus datos de los data broker y mantener el domicilio desvinculado de la persona pública son los controles que importan, porque no puedes deshacer la filtración de una dirección en mitad de una transmisión.

— Nadia Amine — swatting, 2022

El punto de fallo: un par hostil que ya tiene tu ubicación. Durante una pelea pública en octubre de 2023, el youtuber Jacksfilms acusó a la también creadora SSSniperWolf de sacar a la luz su domicilio —ella publicó desde fuera de lo que se dijo que era su casa, en directo por Instagram—, y YouTube respondió desmonetizando temporalmente uno de los vídeos de ella por una conducta fuera de la plataforma que, según dijo, ponía en riesgo la seguridad de alguien (Tubefilter). La lección es la que los creadores menos quieren oír: tu modelo de amenazas incluye a tu propio sector. El control es idéntico al del acosador y al del swatter —mantén tu domicilio imposible de encontrar y desvinculado de tu identidad pública—, porque no puedes cimentar una defensa en la contención de una rival.

— Jacksfilms y SSSniperWolf — octubre de 2023

Leídos como un conjunto, los cinco no son cinco desgracias sin relación. Son cinco puertas de entrada distintas al mismo desenlace —un nombre y un lugar—, y cada una aísla un control que las demás no. Keffals enseña el fondo de la foto; Valkyrae, la señal en tiempo real; Dream, el único secreto que lo sostiene todo; Nadia, la dirección que se filtró hace tiempo; Jacksfilms, el adversario que además es colega. Una defensa construida a partir del patrón, y no de una lista sin jerarquía, sabe dónde concentrar su esfuerzo: justo donde está la puerta de entrada.

La tipología de los patrones de fallo
#

Cada caso de doxxing a un streamer del registro anterior se reduce a uno de cinco modos de fallo, y nombrar el modo te dice qué control es decisivo para ti, en vez de pedirte que los hagas todos por igual. Esta tipología es nuestra síntesis de los casos; es el marco que las listas indiferenciadas nunca llegan a montar, porque enumeran defensas sin asociarlas a la forma concreta en que ocurre la exposición.

Modo de fallo	Qué se filtró en realidad	El control que lo rompe
Exposición visual / por metadatos	Una ubicación incrustada en el fondo de una foto, en un reflejo o en los datos EXIF (metadatos técnicos ocultos que las cámaras guardan en el archivo de imagen)	Borra los metadatos y audita el fondo y los reflejos de cada toma antes de publicar
Ubicación en tiempo real (calle)	Dónde estás, ahora mismo, transmitido en directo	Retrasa u oculta la ubicación; nunca emitas un «aquí» estático al que se pueda volver
Vínculo seudónimo–atributo	Lo único oculto de lo que depende la marca (rostro, nombre real, ciudad)	Trata ese atributo como una credencial; reduce sin tregua su superficie pública
Dirección en circulación	Un domicilio que ya está en los datos de un broker o un foro	Elimina tus datos de los data broker; mantén el domicilio desvinculado de la persona pública
Exposición por un actor hostil	Tu ubicación, usada como arma por una rival, un troll o un ex	Haz el domicilio imposible de encontrar; no esperes ninguna contención de quien ya sabe

La tipología es diagnóstica, no decorativa. Un streamer con cámara facial en un estudio doméstico fijo vive sobre todo en las filas uno y cuatro; quien viaja transmitiendo desde la calle vive en la fila dos; un creador cuya identidad entera es un rostro oculto se juega la vida en la fila tres. Encuentra primero tu fila. Los puntos de la lista que le corresponden son los que hay que clavar; el resto es buena higiene, no tu primera línea.

La capa de género: cuando el doxxing se vuelve acoso y amenaza sexual
#

Para las streamers mujeres y las personas LGBTQ+, la exposición rara vez se detiene en la exposición: se convierte en acoso, amenaza sexual y miedo físico como un patrón predecible, no como una escalada de mala suerte. Esta es la dimensión que las listas de privacidad omiten de forma casi unánime, y omitirla produce defensas calibradas para una amenaza que, en el caso de las mujeres, no adopta esa forma. La dirección filtrada es la misma; lo que llega a ella, no.

El registro de casos hace concreta la asimetría. A Keffals, una mujer trans, no solo le hicieron doxxing: la sometieron a un swatting y la persiguieron a lo largo de varias mudanzas; el incidente de Valkyrae fue una amenaza presencial contra tres mujeres en pleno directo. Ninguno encaja con el modelo del «tuit embarazoso que resurge» que las guías genéricas dan por hecho de manera implícita. Los datos respaldan el patrón más allá de cualquier caso aislado: ONU Mujeres documenta que la violencia facilitada por la tecnología contra las mujeres —el doxxing, el software espía de pareja y el abuso basado en imágenes, entre otros— es una categoría diferenciada y en aumento de la violencia de género (ONU Mujeres), y Equality Now sostiene que la casi ausencia de una protección legal específica contra el doxxing deja a las mujeres más expuestas al acoso y a la persecución (Equality Now).

Para el modelado de amenazas, esto cambia dos cosas en concreto. Primero, el dato «inofensivo» no lo es por igual para todos. Una cara ante la cámara, una relación mencionada en directo, un barrio que se vislumbra en un vlog son materia prima para un ataque sexualizado o de acoso de un modo que una guía indiferente al género, escrita para un blanco abstracto, nunca tiene en cuenta. Segundo, el grafo social es un vector primario, no secundario: las parejas, la familia y los encuentros presenciales que una audiencia espera se convierten en el camino hacia el blanco. Por eso las defensas de más abajo tratan la compartimentación del domicilio y las relaciones como un control central para las creadoras mujeres y las personas LGBTQ+, no como un añadido avanzado.

La defensa del seudónimo soberano
#

Un seudónimo no es un disfraz que llevas hasta que alguien adivina tu nombre: es un cortafuegos estructural entre la persona que gana dinero y la persona legal que vive en algún sitio, y su trabajo es hacer que una sola filtración no sea fatal. Las guías para streamers tratan «usa un nombre artístico» como una línea más de la lista. Es la arquitectura de la que cuelga todo lo demás. Hecho como cortafuegos y no como disfraz, significa que la identidad operativa y la persona legal nunca comparten un correo, un teléfono, un método de pago, una dirección de entrega ni un alias reutilizado, de modo que cuando una señal se filtra, no arrastra consigo al resto de la cadena. El manual para auditar qué vincula ya a ambas es la huella digital permanente: la materia prima de quien hace doxxing es justo el rastro que ese manual te enseña a depurar.

La misma compartimentación que protege a un activista que publica bajo un Estado hostil protege a un streamer, porque el problema de fondo es idéntico: un adversario decidido trata una identidad filtrada como el primer movimiento, y la defensa duradera consiste en controlar hasta dónde pueden llegar a ti —qué dirección, qué jurisdicción, qué nombre se pueden usar de verdad en tu contra—, en vez de apostarlo todo a que nunca te identifiquen. En concreto, para un creador eso significa unos cuantos puntos innegociables:

Capa	La exposición	El control seudónimo
Identidad	Un solo campo filtrado (correo, teléfono, pago) deshace el resto	Separación estricta: la identidad pública no comparte cuenta, número ni dirección con la persona legal
Domicilio	Una ubicación física, a la que se puede volver, ligada al nombre público	Un domicilio nunca vinculado a la identidad pública; un agente registrado, un apartado de correos o una dirección comercial para todo lo que dé la cara
El atributo oculto	Un rostro, un nombre real o una ciudad que la marca necesita mantener en secreto	Reduce su superficie como si fuera una contraseña; da por hecho que las multitudes lo intentarán sin descanso
La presencia en tiempo real	Una señal de estar en la calle o «en directo desde aquí ahora mismo»	Retrasa, oculta o geovalla; desacopla dónde estás de cuándo dices que estás ahí

Aun así, sé honesto sobre los límites, porque una defensa que promete de más es, en sí misma, un fallo. Un seudónimo se degrada bajo correlación sostenida —cuanto más publicas, más material le das a un motor de inferencia—, así que compra seguridad y tiempo, no permanencia. Y la capa legal es endeble: en muchas jurisdicciones todavía no hay una ley específica contra el doxxing, las leyes sobre swatting varían mucho, y las protecciones que existen son remedios lentos y posteriores a los hechos, no un escudo en tiempo real. Trata la ley como un recurso al que llegarás con pruebas, no como un muro tras el que esconderte.

Los límites de lo que puedes hacer en solitario
#

Este es el límite honesto, y una guía que lo ocultara repetiría la misma omisión que esta serie nació para corregir. La OPSEC individual protege al individuo; no desmantela la infraestructura de acoso que abarata el doxxing a streamers, y frente a un foro organizado para encontrarte o una llamada de swatting ya cursada, la técnica personal es a la vez necesaria e insuficiente. Puedes compartimentar tu identidad, limpiar los fondos de tus imágenes y borrar tu dirección de cien sitios de brokers. No puedes, en solitario, cerrar el foro que coordina el acoso, obligar a una plataforma a actuar antes de que caiga el daño ni escribir la ley contra el doxxing que tu jurisdicción no tiene.

Los casos lo dicen cuando se leen en conjunto. A Keffals no le faltaba técnica; la cazó un foro organizado hasta que un gran proveedor de infraestructura por fin le cortó el servicio. Las llamadas de swatting contra creadores prosperan porque el sistema de respuesta a emergencias se puede usar como arma más rápido de lo que cualquier individuo puede blindarse. Lo que de verdad mueve estas condiciones es la palanca que los cypherpunks siempre han señalado allí donde la criptografía personal se encuentra con el poder institucional: la respuesta colectiva y el cambio de las reglas —plataformas que expulsen el acoso coordinado, proveedores de infraestructura que se nieguen a transportarlo, registros y leyes contra el swatting, y comunidades de creadores que compartan información sobre amenazas en vez de afrontarlas en soledad—. La defensa individual compra seguridad y tiempo. No eleva, por sí sola, lo que cuesta montar el acoso de entrada.

«La privacidad es el poder de revelarse al mundo de forma selectiva.» — Eric Hughes, Un manifiesto cypherpunk, 1993

Todo el oficio de un streamer es la revelación selectiva: mostrar la actuación mientras se guarda a la persona. El proyecto de quien hace doxxing es arrancarle lo selectivo. Defiende el caso individual y, después, presiona sobre las condiciones, porque ningún foro de acoso le concederá privacidad a un creador por su benevolencia. El resto del pilar de Privacidad recorre la misma lucha en sus otros frentes.

En conclusión — qué defensa encaja con tu riesgo
#

La primera línea correcta depende por completo de tu formato, de tu atributo oculto y de quién tiene motivos para venir a buscarte.

Si transmites desde la calle o viajas ante la cámara: tu modo de fallo es la ubicación en tiempo real. Desacopla dónde estás de cuándo lo dices —retrasa la transmisión, oculta el punto exacto y nunca establezcas un «aquí» estático al que se pueda volver—. Ninguna higiene de metadatos cierra una señal que el formato está hecho para transmitir en directo.
Si tu marca depende de un rostro o un nombre oculto: trata ese único atributo como una credencial, no como un secreto que te puedes tomar a la ligera. Reduce sin tregua su superficie pública, da por hecho que una multitud paciente está correlacionando cada filtración, y lee Tu voz y tu rostro ya son contraseñas antes de que la próxima revelación te presione.
Si eres creadora mujer o persona LGBTQ+: cuenta con la escalada por motivos de género desde el primer día. Es más probable que la exposición se convierta en acoso y amenaza sexual y que pase por tu domicilio y tus relaciones, así que compartimentar el domicilio y aislar el grafo social son controles centrales para ti, no avanzados.

En los tres escenarios se cumple la misma verdad que se cumplió en cada fallo de OPSEC anterior: una vez que tu identidad se trata como el primer movimiento, ya no puedes deshacer la filtración y volver a estar a salvo. Solo puedes decidir, antes de salir en directo, qué punto de fallo expone tu formato, y cerrar ese primero; después, actuar junto a otros creadores para que el propio acoso salga más caro.

Puntos clave

A la gente la atrapan en un punto, no en la lista entera: en cada caso documentado, el doxxing prosperó a través de un único modo de fallo —el fondo de una foto, una ubicación en tiempo real, un rostro oculto, una dirección filtrada, un par hostil—, así que encuentra tu modo y clava ese control primero.
Keffals, 2022 — el fondo es la filtración: tras el swatting, a Clara Sorrenti la obligaron a mudarse una y otra vez cuando usuarios de un foro cotejaron los detalles de las imágenes que ella publicaba; Cloudflare acabó cortándole el servicio al foro de acoso por una amenaza para la vida humana.
Valkyrae, Cinna y Emiru, 2025 — una transmisión desde la calle es una señal de ubicación en directo: las tres terminaron antes de tiempo un maratón después de que un acosador presencial que las rastreaba amenazara al grupo ante la cámara, sin necesidad de vulnerar ninguna base de datos.
Un seudónimo es un cortafuegos, no un disfraz: su valor es impedir que un solo campo filtrado deshaga el resto, así que la identidad pública no debe compartir correo, teléfono, pago ni dirección con la persona legal.
La capa de género que las guías se saltan: para las creadoras mujeres y las personas LGBTQ+, la exposición se convierte sistemáticamente en acoso y amenaza sexual —la UNESCO constató que el 73 % de las mujeres periodistas encuestadas había sufrido violencia en línea—, lo que convierte el aislamiento del domicilio y del grafo social en controles centrales, no en extras.
El límite: la OPSEC individual compra seguridad y tiempo, pero no puede cerrar el foro de acoso, obligar a una plataforma a actuar a tiempo ni escribir la ley contra el doxxing; eso exige acción de las plataformas, negativa de la infraestructura y defensa colectiva de los creadores.

Preguntas frecuentes
#

¿Cómo se hace doxxing a los streamers?
#

Casi siempre por correlación de lo que ya se transmitió, no por vulnerar una base de datos. Los puntos de fallo que se repiten son una ubicación oculta en el fondo o los metadatos de una foto, una ubicación en tiempo real transmitida durante una emisión desde la calle, un único atributo oculto (un rostro o un nombre real) del que depende la marca, un domicilio que ya se filtró a los datos de un data broker o de un foro, o un par hostil que saca a la luz una ubicación durante una pelea. El trabajo de quien hace doxxing es fundir señales dispersas e «inofensivas» en un nombre y un lugar.

¿Una VPN protege a un streamer del doxxing?
#

Solo frente a un vector concreto. Una VPN oculta tu dirección IP, lo cual importa, pero no hace nada contra los modos de fallo que de verdad atrapan a los streamers: un punto de referencia que se ve por una ventana, una entrega ante la cámara, una revelación del rostro o una dirección que ya circula por sitios de brokers. Trata la VPN como un elemento necesario, no como la defensa. Los controles decisivos son auditar el fondo, eliminar la dirección y compartimentar la identidad.

¿Por qué el doxxing ataca de forma distinta a las streamers mujeres?
#

Porque para las creadoras mujeres y las personas LGBTQ+ la exposición escala de forma predecible hacia el acoso y la amenaza sexual, en lugar de terminar en la vergüenza. ONU Mujeres trata la violencia de género facilitada por la tecnología —el doxxing, el software espía de pareja y el abuso de imágenes, entre otros— como una categoría diferenciada, y Equality Now vincula la falta de una ley específica contra el doxxing con un mayor riesgo de persecución para las mujeres. Como explica la sección de la capa de género, esto hace que los datos del rostro, las relaciones y el barrio sean de mayor riesgo, y convierte el aislamiento del domicilio y del grafo social en controles centrales.

¿De verdad un seudónimo protege a un streamer?
#

Sí, si se construye como cortafuegos y no como disfraz. La protección de un seudónimo viene de la separación estricta —la identidad pública y la persona legal sin compartir correo, teléfono, método de pago ni dirección—, de modo que un solo campo filtrado no deshaga el resto. Es una defensa dilatoria que se degrada bajo correlación sostenida, no un escudo permanente, pero es la arquitectura de la que depende cualquier otro control. Un nombre artístico que comparte tus datos reales de pago no protege nada.

¿Qué debería hacer primero si me han hecho doxxing?
#

Documéntalo todo con capturas de pantalla fechadas guardadas en un dispositivo personal; luego denuncia ante la plataforma y, si hay alguna amenaza física, ante tu policía local, y date de alta de antemano en un programa contra el swatting si funciona alguno en tu zona —algunos cuerpos de policía permiten que las personas en riesgo marquen su dirección para que los operadores sepan que una llamada puede ser fraudulenta—. En paralelo, da por hecho que tu domicilio está comprometido: empieza a eliminar tus datos de los data broker, y trata como también expuesta cualquier cuenta o persona vinculada a esa dirección. La limpieza reactiva es más difícil que la prevención, pero una cronología documentada es lo que necesitará cualquier respuesta posterior de la plataforma o legal.

#	Fuente	URL	Archivo
1	NBC News — Cloudflare, Kiwi Farms y Keffals (sep. 2022)	https://www.nbcnews.com/tech/internet/cloudflare-kiwi-farms-keffals-anti-trans-rcna44834	https://web.archive.org/web/*/https://www.nbcnews.com/tech/internet/cloudflare-kiwi-farms-keffals-anti-trans-rcna44834
2	Vice — Keffals y Kiwi Farms	https://www.vice.com/en/article/xgyagd/keffals-kiwi-farms	https://web.archive.org/web/*/https://www.vice.com/en/article/xgyagd/keffals-kiwi-farms
3	Fortune — Cloudflare bloquea Kiwi Farms por una amenaza para la vida humana (sep. 2022)	https://fortune.com/2022/09/05/kiwi-farms-so-bad-cloudflare-feared-immediate-threat-to-human-life-for-clara-sorrenti-keffals/	https://web.archive.org/web/*/https://fortune.com/2022/09/05/kiwi-farms-so-bad-cloudflare-feared-immediate-threat-to-human-life-for-clara-sorrenti-keffals/
4	Rolling Stone — Mujeres streamers de Twitch y el acoso (2025)	https://www.rollingstone.com/culture/culture-features/valkyrae-cinna-emiru-women-twitch-streamers-harassment-1235289509/	https://web.archive.org/web/*/https://www.rollingstone.com/culture/culture-features/valkyrae-cinna-emiru-women-twitch-streamers-harassment-1235289509/
5	Wikipedia — Dream (YouTuber), revelación del rostro oct. 2022	https://en.wikipedia.org/wiki/Dream_(YouTuber)	https://web.archive.org/web/*/https://en.wikipedia.org/wiki/Dream_(YouTuber)
6	Sportskeeda — swatting de streamers, Nadia Amine (2022)	https://www.sportskeeda.com/esports/news-swatting-turns-wholesome-cop-asks-chat-start-hype-train-swatted-warzone-streamer	https://web.archive.org/web/*/https://www.sportskeeda.com/esports/news-swatting-turns-wholesome-cop-asks-chat-start-hype-train-swatted-warzone-streamer
7	Tubefilter — Jacksfilms, SSSniperWolf y la desmonetización de YouTube (oct. 2023)	https://tubefilter.com/2023/10/23/youtube-demonetizes-sssniperwolf-jacksfilms-house/	https://web.archive.org/web/*/https://tubefilter.com/2023/10/23/youtube-demonetizes-sssniperwolf-jacksfilms-house/
8	UNESCO — The Chilling: violencia en línea contra las mujeres periodistas (2021)	https://www.unesco.org/en/articles/global-survey-reveals-rising-violence-against-women-journalists	https://web.archive.org/web/*/https://www.unesco.org/en/articles/global-survey-reveals-rising-violence-against-women-journalists
9	ONU Mujeres — Preguntas frecuentes sobre la violencia de género facilitada por la tecnología	https://www.unwomen.org/en/articles/faqs/digital-abuse-trolling-stalking-and-other-forms-of-technology-facilitated-violence-against-women	https://web.archive.org/web/*/https://www.unwomen.org/en/articles/faqs/digital-abuse-trolling-stalking-and-other-forms-of-technology-facilitated-violence-against-women
10	Equality Now — La falta de protección legal contra el doxxing y el riesgo para las mujeres	https://equalitynow.org/news/press-releases/lack-of-legal-protections-against-doxing-is-putting-women-at-greater-risk-of-online-stalking-and-harassment/	https://web.archive.org/web/*/https://equalitynow.org/news/press-releases/lack-of-legal-protections-against-doxing-is-putting-women-at-greater-risk-of-online-stalking-and-harassment/
11	PEN America — Manual de campo contra el acoso en línea: proteger la información frente al doxing	https://onlineharassmentfieldmanual.pen.org/protecting-information-from-doxing/	https://web.archive.org/web/*/https://onlineharassmentfieldmanual.pen.org/protecting-information-from-doxing/
12	Activist Checklist — Defensa contra el doxxing	https://activistchecklist.org/doxxing/	https://web.archive.org/web/*/https://activistchecklist.org/doxxing/

Cora Aegis

Cora Aegis escribe en CypherpunkGuide guías de OPSEC centradas en la privacidad y lee casos cerrados de acoso buscando el mecanismo que la mayoría de la información periodística pasa por alto: aquí, el único punto de fallo que convierte la transmisión de un streamer en una ubicación, y por qué golpea con más dureza a las mujeres.

Más sobre Cora →

Cómo se hace doxxing a activistas en regímenes autoritarios (2026)

Fri, 19 Jun 2026 00:00:00 +0000

Salir del país debería ser el final del peligro. Cruzas una frontera, pides asilo, vuelves a escribir bajo tu propio nombre, y el modelo de amenazas que arrastrabas en casa debería caducar al cruzar. Esa es la promesa del exilio, y es la premisa que casi todos los consejos de seguridad para activistas heredan sin decirlo: sal, mantente en la sombra un tiempo y el Estado del que huiste pierde su alcance.

No lo pierde. En 2023, la policía de seguridad nacional de Hong Kong dictó órdenes de detención y recompensas de un millón de dólares de Hong Kong (HK$1M) contra activistas residentes en Boston, Londres y Melbourne, al amparo de una ley que se arroga autoridad sobre lo que se dice al otro lado del planeta. Bielorrusia llegó a obligar a un avión comercial a salir del espacio aéreo internacional para capturar a un periodista disidente que viajaba a bordo. El informe de 2025 de Freedom House documentó 1.375 incidentes de represión transnacional física desde 2014 —es decir, persecución de un Estado contra sus críticos más allá de sus fronteras—, cometidos por 54 gobiernos en 107 países de acogida, y esa cifra excluye a propósito las campañas digitales que suelen llegar primero, porque son más difíciles de contar y todavía más difíciles de frenar.

Leemos tres de estos casos como siempre hace esta serie: no por la indignación, sino por el mecanismo. Al poner las órdenes de recompensa y los expedientes judiciales uno junto al otro, el patrón que emerge no es el que describen las listas de seguridad. El doxxing —la exposición pública de datos personales— rara vez es obra de un troll solitario con rencor; es el primer movimiento de una operación de Estado. A las mujeres las golpea de una forma que las guías indiferentes al género ni siquiera reconocen, y lo que de verdad te protege no es un seudónimo más ingenioso, sino desde dónde se publica tu trabajo, y cuándo.

La tabla siguiente es síntesis propia: tres casos documentados, ordenados según el eje que las guías de doxxing pasan por alto; no qué se filtró, sino cómo esa filtración se convirtió en capacidad de alcanzar a alguien al otro lado de una frontera.

Caso	El método de doxxing	Cómo lo operacionalizó el Estado	La lección OPSEC que aísla
Bielorrusia — Protasevich, 2021	Itinerario y horario de viaje, conocidos de antemano	Un vuelo comercial obligado a aterrizar para una detención física	Lo que te expone son los metadatos de horario y movimiento, no la identidad
Hong Kong — HKLeaks y recompensas, 2019-2023	~2.800 «fichas» de doxxing con datos personales; luego, recompensas por exiliados con nombre y apellido	Acoso colectivo que deriva en órdenes extraterritoriales y presión sobre familiares	Tu grafo social y tu familia son la superficie de ataque
China — red transfronteriza	Identidad y ubicación recopiladas y luego compartidas entre Estados	Abuso de Interpol, acoso por intermediarios, captación de contactos en el país de acogida	La jurisdicción misma es la variable que sí puedes cambiar

Léelos en conjunto y los controles se reordenan. A ninguna de estas personas la atraparon por tener un seudónimo débil. La alcanzaron porque un Estado trató una identidad filtrada como el primer paso de una operación que cruzaba una frontera, y ese es un problema distinto del que resuelve un manual de «cómo bloguear de forma anónima».

Qué significa el doxxing bajo un Estado autoritario
#

El doxxing en un contexto autoritario no es una crueldad en línea que termina en la humillación: es la fase de reconocimiento de la represión estatal, el paso que convierte a un crítico en un blanco al que se puede localizar, detener y presionar. El mismo acto —publicar el nombre real, la dirección, el centro de trabajo y los vínculos familiares de alguien— significa otra cosa cuando quien explota la filtración no es una turba anónima, sino un gobierno con órdenes judiciales, un servicio de inteligencia o un aparato diplomático. La literatura académica trata el doxxing como un espectro de intención, de «desanonimizar» a «marcar como blanco»; bajo un Estado hostil, esos extremos se funden en uno. La filtración es el señalamiento.

Ese reencuadre importa porque cambia lo que estás defendiendo. Frente al acoso, el objetivo es negar tu información a desconocidos. Frente a un Estado, esa información a menudo ya está en su poder; lo que niegas es el uso operativo de ella: el momento en que un nombre en una lista se convierte en una llamada a la puerta de un familiar. La revisión de literatura sobre doxing del International Centre for Counter-Terrorism rastrea cómo la táctica migró de la venganza personal a la herramienta política organizada; los casos de abajo son esa migración en su forma acabada.

Hay un segundo planteamiento que las guías habituales omiten por completo, y es el que justifica este artículo: la amenaza no afecta por igual según el género. Para las mujeres activistas, el doxxing deriva casi siempre en amenaza sexual —amenazas de violación, imágenes íntimas manipuladas y el uso de la familia y las relaciones como arma— con una intensidad que los blancos masculinos rara vez sufren. Esa asimetría no es un detalle menor; es un rasgo estructural de cómo opera la represión según el género, y cambia el cálculo defensivo. Le dedicamos su propia sección más abajo, porque ninguna otra guía lo hace.

Tres casos: Minsk, Hong Kong y una red sin fronteras
#

La forma más rápida de ver cómo una filtración se convierte en alcance es poner tres casos documentados uno junto a otro y seguir el mismo recorrido en cada uno: qué se sabía del blanco, qué hizo el Estado con esa información y qué habría podido cambiar —si es que algo— la OPSEC disponible. Son episodios ya zanjados y bien documentados, tomados de la información periodística de la época y de documentos primarios; los detalles se atribuyen a esas fuentes, no se reconstruyen aquí.

El mecanismo: metadatos de viaje, convertidos en arma en tiempo real. Roman Protasevich, periodista opositor bielorruso exiliado, embarcó en el vuelo FR4978 de Ryanair de Atenas a Vilna. Mientras el avión sobrevolaba espacio aéreo bielorruso, las autoridades transmitieron por radio una falsa amenaza de bomba y despegaron un caza MiG-29, obligando al aparato a aterrizar en Minsk. Protasevich y su acompañante Sofia Sapega fueron detenidos en la pista. El Estado no necesitó encontrarlo: conocía su itinerario y lo aprovechó, convirtiendo un vuelo rutinario en una intercepción controlada. (GPIL, Universidad de Bonn)

Lo que vino después corrige una lectura errónea muy extendida. A Protasevich lo condenaron a ocho años en mayo de 2023, y Lukashenko lo indultó diecinueve días después, después de arrancarle y exhibir su cooperación; su detención real estuvo más cerca de los dos años que de los ocho (Al Jazeera). A Sapega, condenada por separado a seis años, también la indultaron en 2023 y la entregaron a Rusia. La lección no es la pena. Es que lo que lo expuso fueron los metadatos de horario y movimiento, no la solidez de ningún seudónimo, y que un Estado es capaz de provocar un incidente internacional con tal de aprovecharlos.

— Bielorrusia — vuelo FR4978 de Ryanair, 23 de mayo de 2021

El mecanismo: doxxing colectivo que deriva en órdenes extraterritoriales. A partir de agosto de 2019, la red HKLeaks publicó «fichas de doxxing» que exponían los datos personales de manifestantes, periodistas y funcionarios —unas 2.800 personas, según el estudio forense de Citizen Lab, que halló indicios circunstanciales de que una organización gubernamental probablemente dirigió o apoyó activamente la campaña, en lugar de atribuirla a grupos de base. Los datos eran la materia prima; la Ley de Seguridad Nacional aportó el alcance.

Hacia 2023, ese alcance se había vuelto plenamente extraterritorial. Amparándose en la pretensión del artículo 38 de tener jurisdicción sobre actos cometidos en cualquier lugar y por cualquier persona, la policía de Hong Kong dictó órdenes de detención y recompensas de HK$1M: primero contra un primer grupo de ocho activistas en el extranjero en julio (Human Rights Watch), y luego contra cinco más en diciembre, entre ellos la activista afincada en Boston Frances Hui (Hong Kong Free Press). Cuando no se pudo alcanzar a los blancos nombrados, la presión se desplazó hacia quienes sí estaban a su alcance: la policía de seguridad nacional citó a los padres de Hui en Hong Kong, parte de una escalada documentada contra las familias de los activistas exiliados (HRW, 2025). La lección: tu grafo social y tus familiares son la superficie de ataque en cuanto tú quedas fuera de su alcance.

— Hong Kong — HKLeaks y las recompensas en el extranjero, 2019-2023

El mecanismo: saltos entre jurisdicciones y ejecución por intermediarios. Donde Bielorrusia actuó de forma directa y Hong Kong actuó mediante recompensas, el aparato chino, más amplio, actúa a través de los sistemas de otros Estados: abusa de las notificaciones rojas de Interpol, se apoya en contactos empresariales y de la diáspora del país de acogida y procesa a agentes que se hacen pasar por miembros de la comunidad. En Estados Unidos, varios casos federales han condenado a agentes que dirigían una «comisaría» clandestina en el extranjero, y a un topo que pasó años haciéndose pasar por activista prodemocracia mientras delataba a disidentes ante el Ministerio de Seguridad del Estado de Pekín (NBC News).

Este es el caso que aísla la variable más poderosa. Estas operaciones funcionan porque explotan las costuras entre sistemas legales: el hueco que abre una solicitud de extradición, un registro de visado o el departamento de cumplimiento de un registrador de dominios. Esto significa que lo único que una persona puede mover de verdad es la jurisdicción misma: dónde está registrado el dominio, dónde se aloja el servidor, qué plataforma custodia la cuenta. Es el punto del que parten las secciones finales.

— China — la red de represión transnacional

Leídos como un conjunto, los tres casos describen una escalada por peldaños, no tres sucesos sin relación. Bielorrusia muestra al Estado aprovechando metadatos que ya tenía. Hong Kong muestra la filtración (HKLeaks) y su ejecución (recompensas, presión familiar) como dos mitades de una sola operación que cruzó fronteras cuando los blancos las cruzaron. China muestra la forma madura: una represión canalizada a través de las instituciones de los mismos países que debían ofrecer refugio. En cada peldaño, la identidad nunca fue en realidad el secreto; lo fue la accesibilidad.

La capa de género: cuando el doxxing se vuelve amenaza sexual
#

Para las mujeres activistas, una campaña de doxxing rara vez se detiene en la exposición: termina casi siempre en amenaza sexual, y esa deriva es una táctica de represión deliberada, no un efecto secundario desafortunado. Esta es la dimensión que las guías de doxxing y las listas de OPSEC omiten de manera casi unánime, y omitirla produce defensas calibradas para una amenaza que las mujeres no sufren de esa forma. La exposición es la misma; lo que viene después, no.

Las protestas de Hong Kong hicieron visible el patrón a gran escala. Junto a los datos de HKLeaks, las manifestantes y periodistas afrontaron una campaña paralela de acoso machista: amenazas de violación y de muerte, y fotografías manipuladas para que parecieran sexualmente explícitas y difundidas para humillarlas. Las crónicas de la época documentaron imágenes de manifestantes alteradas para que parecieran desnudos, y periodistas identificadas con nombre y apellido que recibieron amenazas de violación mientras cubrían el movimiento (France 24, 2019). El objetivo de la imagen manipulada no es el engaño —todo el mundo sabe que es falsa—. El objetivo es asociar una humillación sexual a tu nombre en cada búsqueda futura, y dar a entender que tu cuerpo, y no solo tu argumento, es un blanco legítimo.

La táctica no ha hecho más que industrializarse. En 2025, activistas exiliadas de Hong Kong denunciaron una nueva oleada: imágenes falsas y sexualizadas de mujeres que figuran por su nombre en las listas de recompensas, impresas y enviadas por correo a sus vecinos en el Reino Unido y Australia; el caso de una activista destacada quedó bajo investigación de la policía de Thames Valley, y a la esposa de un activista la atacaron de igual modo con carteles sexuales enviados a su domicilio (Reuters, vía U.S. News). La escalada es precisa: de la imagen en línea al correo físico, del propio blanco a quienes lo rodean. Combina tres mecanismos de presión —la humillación sexual, la exposición de la familia y la comunidad, y el mensaje implícito sabemos dónde vives— en un solo acto.

Para el modelado de amenazas, esto cambia dos cosas en concreto. Primero, el dato «inofensivo» no lo es por igual para todos: una foto de la cara, una relación sentimental o el barrio donde vives son materia prima para un ataque sexualizado de un modo que las guías genéricas, escritas para un blanco sin distinción de género, nunca tienen en cuenta. Segundo, los vínculos familiares e íntimos son un vector primario, no secundario, y por eso las secciones defensivas de más abajo tratan el aislamiento del grafo social y un plan de comunicación familiar como controles centrales, no como añadidos avanzados. Esta vertiente de medios sintéticos —lo barato que resulta hoy producir una falsificación convincente— es la misma maquinaria que analizamos en Tu voz y tu rostro ya son contraseñas, y golpea con más dureza precisamente aquí.

Un modelo de amenazas para publicar bajo represión
#

La defensa que sobrevive a la represión transnacional se construye sobre un principio que las listas de herramientas invierten: trasladar tu infraestructura es más duradero que ocultar tu identidad. La jurisdicción puedes cambiarla; la capacidad de un Estado decidido para acabar desanonimizándote, no. Ocultar la identidad es una táctica dilatoria —valiosa, pero que se degrada con el tiempo a medida que un Estado correlaciona más datos—. La soberanía sobre la infraestructura es estructural: determina a quién se puede obligar a actuar contra ti, y esa es la variable sobre la que giraron todos los casos anteriores. Construye el modelo por capas, ajustado al alcance concreto frente al que te defiendes.

Separa cuanto antes la identidad de publicación de tu identidad legal. Antes de la primera publicación, decide si publicas como individuo seudónimo, como colectivo o como medio con nombre propio, porque la elección fija todo tu perfil de responsabilidad y cambiarla después sale muy caro. Un colectivo seudónimo difumina la atribución; un medio periodístico con nombre carga con la responsabilidad de un editor, pero puede invocar protecciones de libertad de prensa que un bloguero solitario no puede. No hay una respuesta universalmente correcta, solo una respuesta correcta para tu jurisdicción y tu tolerancia a la exposición. Lo que sí es universal: no dejes que la identidad operativa y la identidad legal compartan un correo, un teléfono, un método de pago ni un alias reutilizado. La maquinaria de desanonimización que ejecuta un motor de inferencia a escala de IA es, precisamente, la correlación de esos solapamientos «inofensivos».

Elige tu infraestructura por quién puede ser obligado, no por comodidad. Esta es la capa que las guías mayoritarias reducen a «usa una VPN», y es mucho más que eso. El registrador del dominio, el proveedor de alojamiento y el canal de distribución son, cada uno, un departamento de cumplimiento al que un Estado puede apretar; cada uno es, por tanto, una decisión jurisdiccional, no solo técnica. Registradores respetuosos con la privacidad que no recopilan ni entregan datos personales; alojamiento situado fuera del alcance del Estado en cuestión; sitios estáticos que no guardan ninguna base de datos de usuarios que incautar; y distribución descentralizada (el protocolo Nostr, IPFS, los servicios onion de Tor) que ninguna empresa puede recibir la orden de eliminar: esto no es paranoia, es la diferencia entre un medio que se da de baja con un solo requerimiento legal y otro que no. El principio es no concentrar nunca tu publicación bajo una única entidad a la que se pueda obligar en una sola jurisdicción.

Capa de publicación	Qué puede obligar un Estado hostil	La alternativa soberana
Registrador del dominio	Identidad del titular; suspensión del dominio	Un registrador respetuoso con la privacidad que no recopila ni entrega ningún dato personal
Alojamiento	Incautación del servidor, registros de acceso, órdenes de retirada	Un alojamiento fuera de la jurisdicción del adversario; un sitio estático sin base de datos de usuarios que incautar
Distribución	Eliminación de cuentas, expulsión de plataformas, borrado de contenido	Protocolos descentralizados (Nostr, IPFS, servicios onion de Tor) que ninguna empresa puede recibir la orden de eliminar
Momento de publicación	Correlación de zona horaria y patrón de actividad	Publicación programada, desacoplada de tu horario real; protocolos cuyas marcas de tiempo no delatan tu ubicación

Trata el horario como una huella. La intercepción de Protasevich giró en torno al horario de sus movimientos; la misma lógica vale para publicar. Los patrones de publicación —las horas en que estás activa, la zona horaria que dejan ver, el ritmo que se corresponde con la vida diaria de una persona— son metadatos que sobreviven incluso a un buen seudónimo. Varíalos a propósito. Separa el momento de escribir del de publicar programando las entradas, y prefiere protocolos en los que la marca de tiempo publicada no delate tu zona horaria física. Cuándo publicas puede desanonimizarte con la misma certeza que lo que publicas, y es la fuga de información de la que casi nadie se protege.

Planifica el vector familiar de forma explícita. Como los familiares se convirtieron en el punto de presión en Hong Kong en cuanto los propios activistas quedaron fuera de alcance, un modelo de amenazas serio incluye a las personas que te rodean: un acuerdo común sobre qué se puede hablar y qué no, el mínimo vínculo público posible entre tu identidad activista y tu familia, y un plan de comunicación que dé por hecho que sus dispositivos y cuentas pueden estar vigilados. Para la parte práctica de separar identidades y auditar qué te vincula ya, el manual de auditoría de una huella digital permanente es el complemento de esta sección: la materia prima del que hace doxxing es, justamente, el rastro que ese manual te enseña a encontrar y depurar. Las guías oficiales para víctimas, como el recurso del gobierno británico sobre represión transnacional, y las listas prácticas de Activist Checklist, conviene leerlas antes de necesitarlas, no después.

Los límites de la defensa individual
#

Este es el límite, y conviene ser honestos: un estudio de caso que lo ocultara repetiría la misma omisión que esta serie nació para corregir. La OPSEC protege al individuo; no cambia las condiciones que produjeron la represión, y frente a un Estado dispuesto a poner en juego un caza, una recompensa millonaria o el sistema legal de otro país, la técnica individual es a la vez necesaria e insuficiente. Puedes trasladar tu infraestructura, variar tu horario y aislar tu grafo social. No puedes, en solitario, revocar la pretensión de jurisdicción extraterritorial de un gobierno extranjero, impedir que presione a familiares que siguen dentro de sus fronteras ni evitar que abuse de una notificación de Interpol.

Los casos lo dicen cuando se leen en conjunto. Las precauciones de Protasevich no fallaron: un Estado, sin más, forzó el aterrizaje de su avión. El anonimato de los activistas de Hong Kong era irrelevante una vez que empezaron las recompensas y las citaciones a la familia. La red china funciona precisamente porque opera a través de instituciones de las que un individuo no puede salirse. Lo que de verdad cambia estas condiciones es aquello que los cypherpunks siempre han señalado allí donde la criptografía personal se encuentra con el poder institucional: la respuesta colectiva y el cambio de las reglas. Países de acogida que se nieguen a extraditar por cargos políticos y procesen a los agentes intermediarios; plataformas y registradores que se resistan a acatar exigencias extraterritoriales; organizaciones de libertad de prensa y redes de la diáspora que conviertan una recompensa en un coste diplomático en lugar de en una amenaza silenciosa. La defensa individual permite ganar seguridad y tiempo. Pero no cierra, por sí sola, las costuras entre jurisdicciones que la represión está diseñada para explotar.

«La privacidad es necesaria para una sociedad abierta en la era electrónica. … No podemos esperar que los gobiernos, las empresas u otras grandes organizaciones sin rostro nos concedan privacidad por su benevolencia.» — Eric Hughes, Un manifiesto cypherpunk, 1993

La organización sin rostro, aquí, es un Estado que cruzó una frontera para perseguir a quien lo criticaba, y la era electrónica es la ficha filtrada, la foto manipulada, la recompensa publicada en línea. Defiende el caso individual y, después, presiona sobre las condiciones, porque ningún gobierno que dicta una recompensa transnacional te concederá privacidad por su benevolencia. El resto del pilar de Soberanía recorre la misma lucha en sus otros frentes: el individuo enfrentado a un poder que solo responde a la presión.

En conclusión — qué protocolo encaja con tu riesgo
#

El nivel de defensa adecuado depende por completo de quién tiene motivos para seguirte al otro lado de una frontera, y de hasta dónde ya ha demostrado que está dispuesto a llegar.

Si eres activista de la diáspora o exiliada con un Estado adversario concreto: asume que tu identidad es conocida y centra la defensa, en cambio, en la accesibilidad. Tu primera línea es la jurisdicción de la infraestructura —registrador, alojamiento y distribución elegidos por quién no puede ser obligado—, junto con un plan explícito de comunicación familiar, porque los familiares son el punto de presión documentado en cuanto tú quedas fuera de alcance.
Si publicas periodismo de investigación o de movimientos sociales desde una jurisdicción hostil: define qué identidad asume la responsabilidad (seudónima, colectiva o medio con nombre) antes de la primera publicación, separa por completo la identidad operativa de la identidad legal, y trata las protecciones de libertad de prensa como un recurso real pero lento, posterior a los hechos: vale la pena invocarlo, no es un escudo en tiempo real.
Si eres mujer activista o periodista: cuenta desde el principio con la escalada por motivos de género. Es probable que el doxxing llegue como amenaza sexual y que pase por tu familia y tus vecinos, así que aislar el grafo social y minimizar los datos públicos de rostro y relaciones son controles centrales para ti, no avanzados.

En los tres casos se cumple la misma verdad que se cumplió en cada fallo de OPSEC anterior: una vez que un Estado trata tu identidad filtrada como el primer movimiento, ya no puedes deshacer esa filtración y volver a estar a salvo. Solo puedes decidir, antes de publicar, qué jurisdicción custodia tu trabajo y qué ritmo delata tu día a día; y, más allá del límite de lo que una persona puede hacer, actuar junto a otras para que el simple hecho de alcanzar a alguien al otro lado de una frontera salga caro.

Puntos clave

La amenaza es la accesibilidad, no la identidad: en cada caso, al activista no lo atraparon porque se rompiera un seudónimo, sino porque un Estado trató una identidad conocida como el primer paso de una operación transfronteriza.
Bielorrusia, 2021 — el horario es lo que expone: a Protasevich lo capturaron obligando a aterrizar al vuelo FR4978 de Ryanair gracias a unos metadatos de viaje conocidos de antemano; lo condenaron a ocho años y lo indultaron diecinueve días después, con una detención real más cercana a los dos años.
Hong Kong, 2019-2023 — la familia es la superficie de ataque: unas 2.800 fichas de doxxing de HKLeaks derivaron en recompensas extraterritoriales de HK$1M, y cuando los exiliados señalados por su nombre, como Frances Hui, resultaron inalcanzables, la presión se desplazó a los familiares dentro de Hong Kong.
La capa de género que las guías se saltan: para las mujeres, el doxxing se convierte casi siempre en amenaza sexual —de las imágenes explícitas manipuladas de 2019 a las imágenes falsas y sexualizadas enviadas por correo a los vecinos de las exiliadas en 2025—, lo que convierte el aislamiento del grafo social y la familia en controles centrales, no en extras.
Traslada la infraestructura, no solo la identidad: la jurisdicción —registrador, alojamiento, canal de distribución— es la variable que puedes cambiar; la eventual desanonimización por parte de un Estado decidido, no, así que elige cada capa por quién no puede ser obligado.
El límite: la OPSEC individual permite ganar seguridad y tiempo, pero no puede revocar la jurisdicción extraterritorial ni detener la presión familiar; eso exige que el país de acogida se niegue a extraditar, que las plataformas se resistan y que exista una defensa colectiva de la libertad de prensa.

Preguntas frecuentes
#

¿Cómo se hace doxxing a los activistas en regímenes autoritarios?
#

Mediante una combinación de filtraciones de datos colectivas o respaldadas por el Estado y registros oficiales. Los datos personales —nombre, dirección, centro de trabajo, familia e historial en redes sociales— se recopilan en perfiles públicos de «doxxing», a veces por redes que, según un estudio forense como el de Citizen Lab sobre HKLeaks, probablemente contaban con respaldo estatal. La filtración se operacionaliza después: se usa para dictar órdenes, publicar recompensas, presionar a empleadores o familiares o, como en el caso de Bielorrusia, para aprovechar un itinerario de viaje conocido. El doxxing suele ser la fase de reconocimiento de una operación estatal mayor, no un fin en sí mismo.

¿De verdad un gobierno extranjero puede detenerme por lo que publico en el extranjero?
#

Puede arrogarse la autoridad para ello, y puede dar curso a esa pretensión por otras vías incluso donde no logra alcanzarte físicamente. La Ley de Seguridad Nacional de Hong Kong afirma su jurisdicción sobre actos cometidos en cualquier lugar y por cualquier persona, y en 2023 la policía dictó órdenes de detención y recompensas de HK$1M contra activistas residentes en EE. UU., el Reino Unido y Australia. La detención directa en el extranjero es rara, pero las solicitudes de extradición, las notificaciones de Interpol, la presión sobre la familia que sigue dentro del país y el acoso por intermediarios en el país de acogida son cosas todas ellas documentadas. Trata la orden como real en sus efectos aunque no seas extraditable físicamente.

¿Qué importa más: ocultar mi identidad o mover mi infraestructura?
#

Trasladar tu infraestructura es la defensa más duradera. Ocultar la identidad es una táctica dilatoria que se degrada a medida que un Estado correlaciona más datos con el tiempo; las elecciones de infraestructura —qué registrador, alojamiento y canal de distribución custodian tu trabajo— determinan a quién se puede obligar legalmente a actuar contra ti, y esa es la variable sobre la que giraron todos los grandes casos. Haz ambas cosas, pero si tienes que priorizar, elige cada capa de tu sistema de publicación por la jurisdicción en la que se asienta y por quién no puede recibir la orden de retirarla.

¿Por qué el doxxing ataca de forma distinta a las mujeres activistas?
#

Porque para las mujeres la exposición deriva casi siempre en amenaza sexual como táctica deliberada —de las imágenes explícitas manipuladas en las campañas de Hong Kong de 2019 a las imágenes falsas y sexualizadas enviadas por correo a los vecinos de las exiliadas en 2025—. Como detalla la sección de la capa de género más arriba, esto hace que las fotos del rostro, los datos sobre relaciones personales y la información sobre el barrio donde vives sean de mayor riesgo para las mujeres, y que aislar el grafo social y la familia sean controles centrales en lugar de avanzados.

¿Qué debería hacer primero si creo que me están atacando?
#

Documéntalo todo con registros fechados guardados en un dispositivo personal, y contacta con una organización de libertad de prensa o de derechos humanos y con tu policía local en vez de gestionarlo en solitario: existe una guía oficial precisamente para esto, como el recurso del gobierno británico sobre represión transnacional. En paralelo, audita qué vincula públicamente tu identidad activista con tu identidad legal y con tu familia, y reduce esa vinculación. Asume que los dispositivos y cuentas de tus familiares pueden estar vigilados, y ponte de acuerdo con ellos sobre qué es seguro comentar. La limpieza reactiva es más difícil que la prevención, pero una cronología documentada es lo que necesitará cualquier respuesta legal o de incidencia política posterior.

#	Fuente	URL	Archivo
1	Human Rights Watch — Las órdenes de Hong Kong apuntan a activistas en el extranjero (jul. 2023)	https://www.hrw.org/news/2023/07/04/hong-kong-warrants-aim-activists-abroad	https://web.archive.org/web/*/https://www.hrw.org/news/2023/07/04/hong-kong-warrants-aim-activists-abroad
2	Hong Kong Free Press — Órdenes de detención y recompensas de HK$1M para 5 activistas en el extranjero (dic. 2023)	https://hongkongfp.com/2023/12/14/breaking-hong-kong-national-security-police-issue-arrest-warrants-hk1-million-bounties-for-5-overseas-activists/	https://web.archive.org/web/*/https://hongkongfp.com/2023/12/14/breaking-hong-kong-national-security-police-issue-arrest-warrants-hk1-million-bounties-for-5-overseas-activists/
3	Citizen Lab — HKLeaks: tácticas de acoso en línea encubiertas y abiertas (jul. 2023)	https://citizenlab.ca/research/hkleaks-covert-and-overt-online-harassment-tactics-to-repress-the-2019-hong-kong-protests/	https://web.archive.org/web/*/https://citizenlab.ca/research/hkleaks-covert-and-overt-online-harassment-tactics-to-repress-the-2019-hong-kong-protests/
4	Human Rights Watch — Hong Kong: escala el ataque a las familias de activistas exiliados (may. 2025)	https://www.hrw.org/news/2025/05/04/hong-kong-targeting-exiled-activists-families-escalates/	https://web.archive.org/web/*/https://www.hrw.org/news/2025/05/04/hong-kong-targeting-exiled-activists-families-escalates/
5	Al Jazeera — El activista bielorruso Protasevich, indultado (may. 2023)	https://www.aljazeera.com/news/2023/5/22/belarusian-activist-pardoned-by-minsk	https://web.archive.org/web/*/https://www.aljazeera.com/news/2023/5/22/belarusian-activist-pardoned-by-minsk
6	GPIL, Universidad de Bonn — La prohibición de aerolíneas bielorrusas tras el desvío del FR4978	https://gpil.jura.uni-bonn.de/2023/10/banning-belarusian-airlines-in-response-to-belarus-diversion-of-ryanair-flight-fr4978-as-a-third-party-countermeasure/	https://web.archive.org/web/*/https://gpil.jura.uni-bonn.de/2023/10/banning-belarusian-airlines-in-response-to-belarus-diversion-of-ryanair-flight-fr4978-as-a-third-party-countermeasure/
7	Freedom House — Represión transnacional (1.375 casos; 54 países de origen / 107 de acogida)	https://freedomhouse.org/report/transnational-repression	https://web.archive.org/web/*/https://freedomhouse.org/report/transnational-repression
8	France 24 — Manifestantes de HK afrontan amenazas de violación e imágenes manipuladas (sep. 2019)	https://www.france24.com/en/20190902-attacked-for-gender-not-views-hk-women-protesters-facing-troll-army	https://web.archive.org/web/*/https://www.france24.com/en/20190902-attacked-for-gender-not-views-hk-women-protesters-facing-troll-army
9	Reuters (vía U.S. News) — Activistas exiliados de HK atacados con imágenes falsas y sexualizadas (dic. 2025)	https://www.usnews.com/news/world/articles/2025-12-12/exiled-hong-kong-democracy-activists-say-theyre-targeted-by-fake-sexualised-images	https://web.archive.org/web/*/https://www.usnews.com/news/world/articles/2025-12-12/exiled-hong-kong-democracy-activists-say-theyre-targeted-by-fake-sexualised-images
10	Gobierno del Reino Unido — Qué hacer si eres víctima de represión transnacional	https://www.gov.uk/government/publications/transnational-repression/what-to-do-if-you-think-you-are-the-victim-of-transnational-repression	https://web.archive.org/web/*/https://www.gov.uk/government/publications/transnational-repression/what-to-do-if-you-think-you-are-the-victim-of-transnational-repression
11	ICCT — Doxing: una revisión de literatura (dic. 2024)	https://icct.nl/publication/doxing-literature-review	https://web.archive.org/web/*/https://icct.nl/publication/doxing-literature-review
12	NBC News — El caso del agente chino en Nueva York, un clásico esfuerzo de espionaje de Pekín	https://www.nbcnews.com/investigations/chinese-agent-case-new-york-classic-beijing-spy-effort-experts-say-rcna169506	https://web.archive.org/web/*/https://www.nbcnews.com/investigations/chinese-agent-case-new-york-classic-beijing-spy-effort-experts-say-rcna169506

Cora Aegis

Cora Aegis escribe en CypherpunkGuide guías de OPSEC centradas en la privacidad y lee casos cerrados de represión buscando el mecanismo que la mayoría de la información periodística pasa por alto: aquí, cómo una identidad filtrada se convierte en una operación de Estado que persigue a una activista al otro lado de una frontera.

Más sobre Cora →

Normas editoriales y metodología

Fri, 19 Jun 2026 00:00:00 +0000

Publicamos bajo un seudónimo. Es una decisión deliberada —explicada por extenso en la página de la autora—, pero nos impone una carga: no puedes contrastar nuestro trabajo con un currículum, así que el trabajo tiene que poder verificarse por sí mismo. Esta página es el registro permanente de cómo elegimos las fuentes, cómo investigamos, cómo corregimos los errores y cómo puedes verificar lo que publicamos. Es nuestro sustituto de una credencial, y queremos que sea un listón más alto que cualquier credencial.

Fuentes
#

Primero, las fuentes primarias. Citamos el manifiesto, la especificación, el escrito judicial o el propio conjunto de datos, no un resumen de segunda mano. Cuando nos apoyamos en el reportaje de otra persona, lo decimos y lo enlazamos.
Archivamos lo que enlazamos. Cada referencia externa queda registrada como una instantánea en archive.org junto a la URL original, porque el registro se pudre y un enlace muerto no prueba nada.
Afirmaciones con nombre, fuentes con nombre. Cuando citamos a una persona experta, atribuimos la cita. No inventamos fuentes, ni afiliaciones, ni credenciales —ni las nuestras ni las de nadie—.
Cada dato lleva su origen. Las cifras aparecen con su fuente y su año, para que puedas rastrearlas sin tener que fiarte de nuestra palabra.

Investigación primaria y metodología
#

Nuestro trabajo de mayor peso es la investigación primaria: mediciones que hacemos nosotros mismos, no afirmaciones que repetimos. La pieza insignia es una medición continua de cómo leen la web los sistemas automatizados —qué rastreadores de IA y de buscadores piden qué páginas, con qué conjunto de user-agents y con qué periodicidad—, junto con nuestro llms.txt legible por máquinas y comprobaciones periódicas de si nuestro material es citado por sistemas de IA, y dónde.

Sometemos esa investigación al mismo nivel de exigencia que pedimos a los demás:

Reproducible por diseño. Publicamos nuestro método con el detalle suficiente para repetirlo y, cuando una conclusión se apoya en datos, también esos datos —para que cualquier lector con las mismas herramientas pueda comprobarnos o contradecirnos—. Un resultado que no puedes reproducir es una opinión.
Medido, no afirmado. Solo publicamos mediciones que de verdad hemos hecho. Cuando una cifra es una estimación o una proyección, lo decimos.
Procedencia fechada. Cada investigación indica cuándo se recogieron los datos y durante qué periodo, para que juzgues lo actuales que son.

Correcciones
#

Cómo informar de un error. Escribe a cora@cypherpunkguide.com; cifra lo que sea delicado con nuestra clave pública (huella FFE1 ECFE 2C75 7E98 6077 AAE2 56FB 82BD 4541 5835).
Qué hacemos con él. Las correcciones de fondo se señalan en el artículo afectado, con la fecha y una nota de lo que cambió. No reescribimos en silencio una afirmación sustancial para fingir que siempre estuvo ahí.
Un registro fechado. Las actualizaciones importantes se fechan en el propio artículo; en la investigación, el cambio también queda registrado en los datos.

Verificación e integridad
#

Una sola voz que responde. Cora Aegis es un seudónimo único y constante, publicado en la página de la autora, una identidad verificada en Nostr (cora@cypherpunkguide.com) y un registro ORCID. La constancia es justo el punto: permite vincular cada afirmación a una sola voz que puede rendir cuentas.
Firma criptográfica. Nuestra clave OpenPGP está publicada (la huella de arriba): puedes obtenerla con gpg --locate-keys cora@cypherpunkguide.com (Web Key Directory) o descargarla. Las correcciones y las publicaciones de investigación que lleven nuestra firma se verifican con esta clave, así confirmas que una afirmación viene de nosotros y no fue alterada por el camino.
Independencia. Nos financian quienes nos leen, mediante varias vías transparentes —ahora, donaciones directas en Bitcoin y Monero; más adelante, una suscripción Premium y enlaces de afiliación acordes con nuestra línea editorial— y siempre te decimos cuál es cuál. No llevamos publicidad de vigilancia: ni redes publicitarias, ni píxeles de rastreo, ni contenido patrocinado. Respondemos ante quienes nos leen, no ante los anunciantes.

Divulgación
#

Seudónimo a propósito. Sería incoherente enseñar a resistir la vigilancia bajo un nombre legal que recolectarían los mismos data brokers de los que te ayudamos a escapar. El razonamiento completo está en la página de la autora.
El retrato es una ilustración. Toda imagen de Cora Aegis es una ilustración generada por IA, no una fotografía, y se indica como tal allí donde aparece.
Las relaciones se declaran. Cuando existe una relación de afiliación, se divulga con claridad y en su contexto, nunca enterrada.

Aviso Legal e Identidad de la Autora

Tue, 02 Jun 2026 00:00:00 +0000

Última actualización: 2 de junio de 2026

Quién publica este sitio
#

CypherpunkGuide es una publicación editorial independiente escrita bajo el seudónimo Cora Aegis.

Por qué un seudónimo
#

Escribimos sobre seguridad operativa, resistencia a la vigilancia y soberanía personal. Hacerlo bajo un nombre legal —recolectado por los mismos corredores de datos de los que te enseñamos a escapar— sería una contradicción. El seudónimo no es un truco; es la primera lección, y predicamos con el ejemplo. Seguimos el camino de otras publicaciones afines que protegen la identidad de sus autores por las mismas razones.

Qué significa esto
#

Cora Aegis es una persona real cuya identidad legal se mantiene en reserva de forma deliberada. No la revelaremos en respuesta a:

solicitudes de lectores,
consultas de periodistas supeditadas a que se desvele la identidad,
peticiones comerciales que no respondan a requisitos legales de KYC, ni
intentos hostiles de exponerla.

Podemos atender un proceso legal válido (una orden judicial o una citación de una jurisdicción competente), tras la revisión que corresponda y con un esfuerzo razonable por preservar la integridad del seudónimo dentro de lo que permita la ley.

Cómo operamos
#

Somos una publicación distribuida y no mantenemos una oficina física pública. El sitio está alojado en Suiza y el registro de nuestro dominio usa privacidad WHOIS por diseño.

Contacto
#

editor@cypherpunkguide.com — editorial
privacy@cypherpunkguide.com — privacidad y solicitudes relativas a tus datos
legal@cypherpunkguide.com — DMCA y asuntos legales y regulatorios

Consulta también nuestro Contacto, nuestra Política de Privacidad y nuestros Términos.

Contacto

Tue, 02 Jun 2026 00:00:00 +0000

Somos una publicación distribuida, sin oficina física pública. Escríbenos por correo electrónico:

editor@cypherpunkguide.com — editorial, propuestas de temas, correcciones y discrepancias de personas nombradas en nuestros textos (Cora Aegis)
privacy@cypherpunkguide.com — preguntas sobre privacidad y solicitudes de los titulares de datos
legal@cypherpunkguide.com — notificaciones DMCA y correspondencia legal y regulatoria

Cifrado. Para cualquier asunto delicado, cífralo, por favor. La clave OpenPGP de Cora Aegis (huella FFE1 ECFE 2C75 7E98 6077 AAE2 56FB 82BD 4541 5835) está disponible para descargar, o puedes obtenerla con gpg --locate-keys cora@cypherpunkguide.com.

Apoya nuestro trabajo. CypherpunkGuide se financia gracias a quienes la leen. Aquí publicaremos los datos para donar en Bitcoin y Monero. Respondemos ante quienes nos leen, no ante los anunciantes.

Consulta nuestro Aviso Legal para conocer la política sobre la identidad de la autora. En nuestras Normas editoriales y metodología explicamos cómo elegimos las fuentes, verificamos y corregimos nuestro trabajo.

Descargo de Responsabilidad

Tue, 02 Jun 2026 00:00:00 +0000

Última actualización: 2 de junio de 2026

No es asesoramiento profesional
#

CypherpunkGuide tiene una finalidad educativa. Nada de lo que encuentres aquí es asesoramiento legal, financiero, fiscal o de seguridad. Consulta a un profesional cualificado antes de actuar a partir de cualquier cosa que leas aquí, sobre todo en decisiones que afecten a tu dinero o a tu seguridad.

Riesgo de las criptomonedas y la autocustodia
#

La autocustodia y las criptomonedas conllevan un riesgo real de pérdida irreversible. Solo tú respondes de tus claves, de tu seguridad operativa y de tus decisiones. Empieza probando con cantidades pequeñas.

«Tal cual»
#

El contenido y las herramientas se ofrecen «tal cual», sin garantía de ningún tipo. No nos hacemos responsables de las decisiones que tomes a partir de nuestro contenido, de los servicios de terceros que enlazamos o mencionamos, ni de las interrupciones del servicio y la pérdida de datos. Ningún sistema es perfectamente seguro; hacemos cuanto podemos con los recursos a nuestro alcance y nos comprometemos a una divulgación transparente si ocurre un incidente.

Opiniones, no verdades absolutas
#

Nuestras posiciones editoriales son opiniones fundamentadas, ofrecidas de buena fe. Las personas razonables discrepan; lo celebramos.

Enlaces de afiliados
#

Cuando incluimos enlaces de afiliados, los declaramos sin rodeos, recomendamos solo herramientas que usamos nosotras mismas y jamás dejamos que una comisión tuerza nuestro criterio. No operamos redes publicitarias de vigilancia ni vendemos nunca tus datos: nos financian fuentes transparentes (donaciones, la primera fuente que estamos poniendo en pie; más adelante, una posible suscripción y enlaces de afiliados alineados con nuestra línea editorial). Consulta nuestra Política de Privacidad.

Enlaces de terceros
#

Enlazamos a recursos externos para tu comodidad. No los controlamos y no respondemos de su contenido ni de sus prácticas. Archivamos lo que citamos (por ejemplo, a través de la Wayback Machine) frente al deterioro de los enlaces.

Política de Privacidad

Tue, 02 Jun 2026 00:00:00 +0000

Última actualización: 10 de junio de 2026

La privacidad es el núcleo de esta publicación, así que esta política empieza por lo que no hacemos.

Lo que nos negamos a hacer
#

Nada de publicidad de vigilancia. Sin redes publicitarias, sin píxeles de rastreo, sin contenido patrocinado. Respondemos ante quienes nos leen, no ante los anunciantes.
Sin rastreadores de terceros. Sin Google Analytics, sin píxel de Meta, sin rastreo entre sitios.
Sin venta ni alquiler de tus datos. Nunca. A nadie.
Sin elaboración de perfiles de comportamiento y sin usar tus datos para entrenar IA.

Recopilamos lo mínimo imprescindible para funcionar, y te decimos exactamente qué es.

Qué recopilamos
#

Visitantes. Hoy no ejecutamos ninguna analítica del lado del cliente: ni scripts de analítica, ni huellas de navegador (fingerprinting); las páginas no instalan ninguna cookie. Nuestra red de distribución de contenidos (BunnyCDN, un proveedor de la UE que actúa como nuestro encargado del tratamiento) sirve las páginas y conserva registros de entrega con la anonimización de IP activada, junto con estadísticas agregadas (número de solicitudes, ancho de banda, tasa de caché y totales por país) que usamos para entender la carga del sitio, no a las personas. Si más adelante añadimos una analítica detallada, será autoalojada y sin cookies (Plausible autoalojado es el candidato previsto), y antes actualizaremos esta política.

Suscriptores del boletín (previsto: el boletín aún no está activo). Si te suscribes cuando se ponga en marcha: tu dirección de correo electrónico (para enviarte el boletín) y, de forma opcional, una preferencia de idioma. Solo conservaremos recuentos agregados de aperturas y clics; no haremos seguimiento individual a largo plazo.

Herramientas interactivas (cuando estén disponibles). Todos los cálculos se ejecutan del lado del cliente, en tu navegador. No recopilamos tus datos de entrada ni los resultados, salvo que pidas expresamente recibir un informe por correo electrónico; en ese caso recopilamos únicamente tu dirección de correo. Una prueba de conectividad o de fugas que necesite enviar una solicitud a nuestro resolutor registra la IP de origen de forma efímera (≤24 horas) y luego la elimina, conservando solo datos agregados a escala de país.

Por qué lo usamos
#

Para servir el sitio de forma fiable (entrega mediante la CDN y protección frente a abusos); para obtener estadísticas agregadas que nos digan qué se lee (nunca para publicidad ni ventas); para enviar el boletín y adaptarlo a tu idioma cuando se ponga en marcha; para entregarte el informe de una herramienta solo cuando lo pides; y para cumplir las obligaciones legales allí donde realmente correspondan.

Cuánto tiempo lo conservamos
#

Minimización de datos en todo momento: los datos del boletín, hasta que te das de baja (más una breve ventana para copias de seguridad); la analítica agregada, hasta 24 meses; los registros del resolutor, un máximo de 24 horas (después, solo agregados a escala de país); los informes de herramientas enviados por correo no se almacenan en nuestros servidores. Las copias de seguridad están cifradas.

Con quién los compartimos
#

No compartimos, vendemos ni alquilamos tus datos, salvo en supuestos muy acotados: encargados que actúan estrictamente en nuestro nombre (por ejemplo, el envío del correo), sujetos a confidencialidad; y procesos legales válidos de una jurisdicción competente, que revisamos y que impugnaremos cuando sean excesivamente amplios. Jamás compartimos datos con redes publicitarias, corredores de datos, plataformas sociales ni proveedores de entrenamiento de IA.

Tus derechos
#

Según el lugar donde vivas (GDPR/UK GDPR, CCPA/CPRA, la APPI de Japón, la LGPD y otras leyes), puedes tener derecho a acceder a tus datos, eliminarlos, corregirlos, portarlos u oponerte a su tratamiento, así como a no sufrir discriminación por ejercer esos derechos. No vendemos datos, de modo que la exclusión de la venta no aplica; aun así, lo afirmamos de forma explícita.

Para ejercer cualquier derecho, escribe a privacy@cypherpunkguide.com. Respondemos dentro del plazo que exija tu ley (por ejemplo, 30 días con el GDPR o 45 días con la CCPA) y es posible que antes verifiquemos tu identidad. Las solicitudes razonables son gratuitas.

Cookies
#

Este sitio hoy no instala ninguna cookie: no hay inicio de sesión ni sesiones, y tampoco banner de consentimiento, porque no hay nada que consentir. Tu preferencia de tema (claro/oscuro) se guarda en el localStorage de tu navegador y nunca sale de tu dispositivo; el idioma forma parte de la URL, no es una cookie. Sin cookies de publicidad ni de rastreo. Cuando incrustamos contenido multimedia de terceros, optamos por las versiones respetuosas con la privacidad y te avisamos cuando no es posible.

Financiación y enlaces de afiliados
#

Respondemos ante quienes nos leen, no ante los anunciantes. Nos sostienen fuentes de ingresos transparentes: donaciones en Bitcoin y Monero, la primera fuente que estamos poniendo en pie; en una fase posterior, una posible suscripción Premium y un número reducido de enlaces de afiliados alineados con nuestra línea editorial. Si llegamos a usar enlaces de afiliados, los declaramos sin rodeos y solo recomendamos herramientas que usamos nosotras mismas.

Menores
#

Este sitio no está dirigido a menores de 13 años (de 16 años en la UE). No recopilamos sus datos de forma consciente.

Cambios
#

Podemos actualizar esta política; los cambios sustanciales se anunciarán (con un aviso en el boletín y un banner en el sitio), junto con la fecha de «última actualización» que figura arriba.

Contacto
#

Preguntas sobre privacidad y solicitudes relativas a tus datos: privacy@cypherpunkguide.com. Somos una publicación distribuida y no mantenemos una oficina física pública. Consulta también nuestro Aviso Legal.

Términos del Servicio

Tue, 02 Jun 2026 00:00:00 +0000

Última actualización: 2 de junio de 2026

1. Aceptación
#

Al usar cypherpunkguide.com o al suscribirte a nuestro boletín, aceptas estos Términos. Si no los aceptas, te pedimos que no uses el sitio.

2. Qué ofrecemos
#

CypherpunkGuide es una publicación editorial: artículos sobre privacidad y OPSEC, autocustodia, soberanía y filosofía cypherpunk. A medida que la publicación crezca, podremos añadir herramientas interactivas gratuitas y un boletín (con un posible nivel Premium en el futuro). El contenido se ofrece solo con fines informativos y no sustituye al asesoramiento profesional legal, financiero o de seguridad.

3. Tus responsabilidades
#

Usa el sitio de forma lícita; no intentes vulnerar su seguridad ni extraer sus datos de forma abusiva; no suplantes a Cora Aegis ni a nuestro equipo; y, si en algún momento existen cuentas, no compartas sus credenciales.

4. Posición editorial
#

Tomamos posturas claras: la privacidad como derecho fundamental (en la línea de A Cypherpunk’s Manifesto, de Hughes), la autocustodia y la soberanía financiera, y el análisis crítico de la tecnología y las políticas de vigilancia. Son opiniones fundamentadas, no verdades absolutas: damos la bienvenida al desacuerdo respetuoso. Podemos negar el servicio a quien incurra en acoso o en discurso de odio.

5. Enlaces de afiliados e independencia
#

Todo el contenido es de criterio editorial propio. No aceptamos contenido patrocinado ni inserciones pagadas. Nos financian fuentes de ingresos transparentes (donaciones, la primera fuente que estamos poniendo en pie; más adelante, una posible suscripción y enlaces de afiliados alineados con nuestra línea editorial). Cuando aparecen enlaces de afiliados, se declaran sin rodeos y nunca alteran nuestras recomendaciones. Consulta nuestra Política de Privacidad y nuestro Descargo de Responsabilidad.

6. Autoría y seudónimo
#

CypherpunkGuide se escribe bajo el seudónimo editorial Cora Aegis. Consulta nuestro Aviso Legal para conocer la política completa sobre la identidad de la autora.

7. Correcciones
#

Corregimos los errores sustanciales de forma abierta: una nota de corrección en el artículo afectado, un aviso en el boletín y la conservación del original en la Wayback Machine. Si una persona aparece nombrada en un caso de estudio y discrepa de algún hecho, puede escribir a editor@cypherpunkguide.com para una revisión de buena fe.

8. Derechos de autor y DMCA
#

Respetamos los derechos de propiedad intelectual. Para presentar una notificación de retirada, escribe a legal@cypherpunkguide.com indicando: la obra reivindicada, la URL presuntamente infractora, tus datos de contacto, una declaración de buena fe, una declaración de exactitud y de legitimación, y tu firma. Respondemos en un plazo de 14 días y podemos presentar una contranotificación cuando consideremos que el uso es legítimo (fair use), periodístico o lícito por cualquier otra razón. No daremos curso a solicitudes excesivamente amplias o de mala fe.

9. Descargos de responsabilidad y limitación de responsabilidad
#

El contenido y las herramientas se ofrecen «tal cual», sin garantía. Consulta nuestro Descargo de Responsabilidad completo.

10. Ley aplicable
#

Digan lo que digan estos Términos, prevalecen las leyes locales de protección al consumidor y de protección de datos que te amparen (por ejemplo, el GDPR en la UE y el Reino Unido, la CCPA en California, la APPI en Japón o la LGPD en Brasil). Las disputas se resuelven primero mediante negociación de buena fe, después mediante mediación y, en último término, ante un tribunal competente.

11. Contacto
#

Editorial: editor@cypherpunkguide.com · Privacidad: privacy@cypherpunkguide.com · Legal: legal@cypherpunkguide.com

Sobre CypherpunkGuide

Mon, 01 Jun 2026 00:00:00 +0000

Por qué existimos
#

«La privacidad es el poder de revelarse al mundo de forma selectiva». — Eric Hughes, A Cypherpunk’s Manifesto, 1993

Tres décadas después, conservar ese poder cuesta más que nunca. Cada transacción, cada mensaje y cada movimiento queda registrado, cruzado y vendido. CypherpunkGuide existe para quien ha decidido que eso es inaceptable y busca formas prácticas y probadas de recuperarlo.

Empezamos por la privacidad, no por una tecnología concreta. La privacidad es el derecho; las herramientas son la forma de ejercerlo.

Quién es Cora Aegis
#

Cora Aegis es la voz editorial de esta publicación. El nombre es un seudónimo, y lo es a propósito. Escribimos sobre seguridad operativa, resistencia a la vigilancia y soberanía personal: hacerlo bajo un nombre legal, recolectado precisamente por los corredores de datos de los que te enseñamos a escapar, sería una contradicción. El seudónimo no es un truco. Es la primera lección.

Nuestra mirada es, sin complejos, la de una defensora. La privacidad y la soberanía no son preferencias abstractas: son el fundamento de la dignidad de la persona, el derecho a disponer de tu cuerpo, tu dinero y tu propia historia sin tener que pedir permiso antes.

Más sobre Cora Aegis →

Qué tratamos
#

Ordenamos nuestro trabajo en cuatro pilares, en la secuencia en que creemos que mejor se aprenden:

Privacidad y OPSEC — los cimientos. Modelado de amenazas, metadatos, vigilancia y las prácticas cotidianas que reducen tu superficie de ataque. Aquí empieza la mayoría de quienes nos leen, hayan tocado Bitcoin alguna vez o no.
Autocustodia — la privacidad llevada al terreno del dinero. Bitcoin no es nuestra portada: es el medio por el que la privacidad financiera y la resistencia a la censura se vuelven reales. Desde tu primera cartera de hardware hasta la multifirma, lo tratamos como una herramienta al servicio del primer pilar.
Soberanía — la privacidad extendida a toda una vida: comunicación, residencia, salud y la infraestructura silenciosa de la independencia.
Cypherpunk — la filosofía que lo une todo, leída en las fuentes originales y no en los eslóganes.

El camino va en una sola dirección: la privacidad como punto de partida, Bitcoin como uno de los medios, la soberanía como prolongación y la ética cypherpunk como horizonte.

Cómo trabajamos
#

La educación, primero. La mayor parte de lo que publicamos es explicativo —modelos de amenaza, comparativas, análisis de fuentes originales—, no propaganda de productos.
Herramientas que usamos de verdad. Cuando recomendamos algo, lo usamos nosotras mismas, nombramos sus contrapartidas y declaramos sin rodeos cualquier relación de afiliación.
Fuentes originales. Citamos el manifiesto, la especificación, el documento oficial; y archivamos lo que enlazamos, porque la memoria del registro se desgasta.
Practicamos nuestra propia OPSEC. Autoría seudónima, alojamiento respetuoso con la privacidad, sin analítica de vigilancia y sin rastreadores publicitarios.

Cómo nos financiamos
#

Nuestro trabajo se sostiene con varias fuentes de ingresos transparentes, y siempre te diremos cuál es cuál:

Donaciones directas en Bitcoin y Monero: publicaremos las direcciones en la página de Contacto en cuanto nuestro servidor de pagos autoalojado esté en marcha; es la primera fuente que estamos poniendo en pie.
Una suscripción Premium para quien quiera más profundidad (prevista para una fase posterior).
Enlaces de afiliados escogidos con cuidado a un puñado de herramientas que ya cumplen nuestros criterios editoriales: sin exageraciones, solo cosas que usamos y siempre declaradas.

Respondemos ante quienes nos leen, no ante los anunciantes. Esa sola frase guía cada decisión editorial.

Empieza aquí
#

Si acabas de llegar, comienza por Privacidad y OPSEC. Todo lo demás —Bitcoin incluido— cobra sentido cuando alcanzas a ver la amenaza de la que en realidad te defiendes.

ExposureCheck

Mon, 01 Jan 0001 00:00:00 +0000

Qué hace, en un minuto
#

ExposureCheck lee los datos que tú exportas de una plataforma: nunca una cuenta en vivo, nunca la de otra persona. Y plantea la pregunta que se haría un adversario: con todo esto junto, ¿qué se puede deducir de la persona que hay detrás?

Lee tu exportación GDPR de Reddit y tu archivo de X / Twitter (una carpeta o un .zip).
Avanza con una cascada que preserva el recall (tasa de detección): una primera pasada barata ordena cada publicación, una pasada cara lee las prioritarias y las señales débiles se conservan, porque el mosaico se arma con señales débiles y descartarlas sería un falso consuelo.
Extrae la capa de metadatos sin recurrir a conjeturas: el campo de ubicación que tú mismo pusiste, los enlaces salientes, los datos EXIF / GPS de las imágenes (la información que la cámara incrusta en cada foto), el modelo del dispositivo y la concentración de horarios que delata tu zona horaria. En X, eso revela más que el propio texto.
Informa con tarjetas de riesgo por categoría —ubicación, empleo, familia, horarios, finanzas, vínculos entre cuentas—, ordenadas por su aporte al riesgo, cada una con ejemplos enmascarados y arreglos concretos que generalizan antes de borrar.

Funciona en local, no escribe ningún dosier y nunca guarda en el disco un perfil tuyo.

¿No conoces la «reidentificación por mosaico»? Empieza por la amenaza, no por la herramienta: lee el artículo hermano, Audita tu propio historial como lo haría una IA, y vuelve después.

Lo que a propósito no hace
#

Nada de dosier. Nunca imprime «vives en X, trabajas en Y, te llamas Z». Las tarjetas muestran fragmentos enmascarados; el valor resuelto solo aparece cuando tú abres tu propia publicación original, ahí en el momento, sin que se guarde.
No exporta los hallazgos. No hace scraping (su única entrada son tus exportaciones). No publica ni borra nada por ti. No analiza el historial de nadie más.
No te vuelve anónimo. Reduce el riesgo. «Low» no es «a salvo», y los metadatos, los horarios y el estilo de escritura solo entran en parte en su alcance.

Qué sale de tu equipo, y qué no
#

Es lo primero que una herramienta de privacidad debería decirte, así que aquí va por delante. La inferencia corre sobre un backend que eliges tú, y esa elección —no la herramienta— decide qué viaja:

Backend	Qué es	¿Tus datos salen de tu equipo?
`local`	un modelo local de Ollama / llama.cpp / LM Studio	✅ No: se queda en tu ordenador
`heuristic`	un stub de expresiones regulares sin conexión, recall casi nulo	✅ No, pero solo para desarrollo / CI, no es una auditoría de verdad
`cloud`	cualquier endpoint compatible con OpenAI, con tu clave	⚠️ Sí: tus publicaciones van a ese proveedor

La herramienta en sí no tiene servidor, ni telemetría, ni cuenta. La autora no guarda ninguno de tus datos ni ninguna clave. Cuando eliges cloud, tu exportación va al proveedor de API que tú indicaste, y se aplican el registro, la retención y la política de entrenamiento de ese proveedor, además de la IP y la facturación atadas a tu clave. ExposureCheck no añade un salto; tampoco puede quitar el que tú decidiste dar.

La única advertencia sobre la nube que de verdad importa
#

Si la cuenta que auditas es una seudónima que mantienes aparte de tu identidad real y tu cuenta de IA o de nube está registrada o pagada a tu nombre real, entonces enviar ese historial a la nube le permite al proveedor enlazar identidad real ↔ cuenta anónima en su lado (una citación judicial, una filtración, un infiltrado). Esa es exactamente la desanonimización que esta herramienta existe para evitar.

En la práctica: para auditar una cuenta estrictamente anónima, usa --backend local (o una cuenta en la nube abierta y pagada de forma anónima). Para auditar tu cuenta pública, la de tu nombre real, la nube va bien. La herramienta lo advierte en pantalla y te pide que lo confirmes cuando viene al caso. Nunca forzamos el modo local —eso reduciría el público a nadie—; lo que hacemos es dejar la disyuntiva a la vista.

Cómo funciona
#

export ─▶ parse ─▶ prefilter (drop only TRUE-empty) ─┬─▶ deterministic: profile + EXIF + timing ─┐
 └─▶ cascade: cheap route ─▶ expensive read ─┤
 ▼
 risk-contribution scoring ─▶ category cards ─▶ no-dossier report

La cascada existe para que un historial de mil a tres mil publicaciones siga siendo asequible: la pasada barata decide qué merece la lectura cara en vez de mandarlo todo. Después, la puntuación por aporte al riesgo ordena las categorías por cuánto te acotan de verdad, y no por la confianza bruta del modelo, que no está calibrada.

Instalación
#

El núcleo —el análisis, el EXIF, la cascada y los backends HTTP de nube y local— usa solo la biblioteca estándar de Python. Ningún paquete de terceros toca tu exportación, de modo que el código en el que depositar tu confianza es mínimo.

# from source (a PyPI release ships with the first public version):
git clone https://github.com/coraaegis/exposurecheck && cd exposurecheck
pip install -e .

# or run without installing:
python -m exposurecheck --help

# Local model — nothing leaves your machine (recommended for anonymous accounts)
exposurecheck audit \
 --reddit ./reddit_export.zip \
 --twitter ./twitter_export \
 --backend local --expensive-model llama3.1 \
 --i-own-this-data

# Cloud — bring your own key; set it in the ENV, never on the command line
export OPENAI_API_KEY=sk-...
exposurecheck audit --twitter ./twitter_export --backend cloud --i-own-this-data

La clave de API se lee desde una variable de entorno a propósito: los argumentos de la línea de comandos se filtran al historial del intérprete y al listado de procesos.

Hoy ExposureCheck es una herramienta de línea de comandos, pensada para quien se mueve con soltura en una terminal —que es también donde viven sus primeros revisores—. El siguiente hito es una aplicación de un solo clic para quien no es técnico (un paquete con una interfaz local en el navegador y sin Python que instalar); la CLI se queda para los usuarios avanzados.

Confía como confiarías en cualquier herramienta de privacidad: comprobando, no por fe
#

La autora es seudónima, así que no te fíes de un nombre. Fíate, en cambio, de lo que puedes verificar:

Lee el código. Es de código abierto (MIT) y usa solo la biblioteca estándar, de modo que el árbol de dependencias que tienes que auditar es, en esencia, la propia biblioteca estándar.
Verifica la versión. Cada versión va firmada con PGP por Cora Aegis. Descarga la clave por WKD y comprueba la firma:
```
gpg --locate-keys cora@cypherpunkguide.com
gpg --verify exposurecheck-0.1.0.tar.gz.asc
```
Cada versión incluye sus sumas de verificación SHA-256, y las compilaciones son reproducibles: reconstruye desde el código etiquetado y confirma que el artefacto coincide.
Sin certificado de firma de código vinculado a una identidad, por diseño: ese tipo de certificado ataría el proyecto a una identidad legal, justo lo contrario de la idea. Un binario de Windows sin firmar puede mostrar el aviso de SmartScreen de «editor desconocido»; es lo esperable. Usa mejor un gestor de paquetes (pip / Scoop / Homebrew) o ejecuta desde el código fuente, y verifica la firma PGP.
El diseño de la salida es la salvaguarda. La regla de no escribir dosier está impuesta en el código: las etiquetas enmascaradas las genera la máquina, de modo que ni siquiera el texto del propio modelo puede colar un valor resuelto en el informe. Las defensas frente al doble uso —entrada condicionada a que seas el dueño, salida solo por categorías, enmascarado y una evaluación de abuso previa a la publicación— están documentadas en ABUSE-EVAL.md.

Una tabla transparente del flujo de datos y un modelo de amenazas publicado muestran qué pretende la herramienta. El código, la firma y la compilación reproducible son tu forma de confirmar que hace eso, y nada más.

Límites que conviene tener presentes
#

«Low» no es «a salvo». La herramienta reduce el riesgo; no certifica el anonimato.
El recall no es perfecto. Que no salte nada («sin hallazgos») no prueba que seas imposible de identificar, sobre todo con el backend heuristic, que está para pruebas, no para auditar.
Fuera de alcance: la identificación por el estilo de escritura, el cruce entre plataformas más allá de lo que contienen tus exportaciones, los metadatos a nivel de red y el contenido visual de las imágenes (la v1 solo lee EXIF y metadatos; mira la hoja de ruta).
La herramienta lee tus datos más delicados. Por eso, precisamente, funciona en local, usa solo la biblioteca estándar, es de código abierto y va firmada: para que aquello que ejecutas para medir tu exposición sea, en sí mismo, la superficie más pequeña y auditable posible.

Preguntas frecuentes
#

¿ExposureCheck sube mis publicaciones a algún sitio?
#

Solo si eliges el backend cloud, y entonces solo al proveedor de API cuya clave aportaste. Con local o heuristic, nada sale de tu equipo. La herramienta no tiene servidor ni telemetría propios.

¿Me va a decir mi dirección o mi nombre real?
#

No. Ese es el diseño deliberado de «nada de dosier». Muestra categorías enmascaradas y te lleva a tus propias publicaciones originales para que decidas qué cambiar. Nunca arma ni guarda un perfil tuyo.

Estoy auditando una cuenta anónima. ¿Es seguro el backend en la nube?
#

Usa --backend local para una cuenta estrictamente anónima, salvo que tu propia cuenta en la nube sea también anónima. Enviar el historial de una cuenta anónima a una cuenta de IA con tu nombre real enlaza a las dos en el lado del proveedor: justo el riesgo que esta herramienta te ayuda a encontrar.

¿De verdad es seguro pasarla por todo mi historial?
#

El código es abierto y usa solo la biblioteca estándar, así que puedes leer qué hace; la versión va firmada con PGP y es reproducible, así que puedes confirmar qué instalaste; y no escribe ningún perfil en el disco. Verifica esas tres cosas en vez de darlas por buenas: ahí está todo.

¿Por qué una línea de comandos y no una aplicación?
#

El público inicial es técnico, y una CLI es la forma más auditable. Una aplicación de un solo clic, con interfaz local en el navegador, es el siguiente hito para quien no es técnico.

Hecho por Cora Aegis. ¿Has encontrado un fallo de privacidad o de seguridad? La divulgación responsable es bienvenida: cora@cypherpunkguide.com (PGP por WKD). El código canónico y el nombre ExposureCheck viven en github.com/coraaegis/exposurecheck.

#	Fuente	URL	Archivo
1	FBI — «Galveston Man Sentenced to Federal Prison for Computer Hacking» (2012)	https://www.fbi.gov/sanantonio/press-releases/2012/galveston-man-sentenced-to-federal-prison-for-computer-hacking	https://web.archive.org/web/*/https://www.fbi.gov/sanantonio/press-releases/2012/galveston-man-sentenced-to-federal-prison-for-computer-hacking
2	CSO Online — «Embedded data, not breasts, brought down hacker» (2012)	https://www.csoonline.com/article/535700/embedded-data-not-breasts-brought-down-hacker.html	https://web.archive.org/web/*/https://www.csoonline.com/article/535700/embedded-data-not-breasts-brought-down-hacker.html
2b	Gizmodo — información sobre el rastreo de Ochoa por el GPS de la foto (iPhone, Wantirna South) (2012)	https://gizmodo.com/these-breasts-nailed-a-hacker-for-the-fbi-5901430	https://web.archive.org/web/*/https://gizmodo.com/these-breasts-nailed-a-hacker-for-the-fbi-5901430
3	NPR — «Betrayed By Metadata: John McAfee Admits He’s Really In Guatemala» (2012)	https://www.npr.org/sections/thetwo-way/2012/12/04/166487197/betrayed-by-metadata-john-mcafee-admits-hes-really-in-guatemala	https://web.archive.org/web/*/https://www.npr.org/sections/thetwo-way/2012/12/04/166487197/betrayed-by-metadata-john-mcafee-admits-hes-really-in-guatemala
4	The Next Web — «Vice leaves metadata in photo of John McAfee» (2012)	https://thenextweb.com/news/vice-leaves-metadata-in-photo-of-john-mcafee-pinpointing-him-to-a-location-in-guatemala	https://web.archive.org/web/*/https://thenextweb.com/news/vice-leaves-metadata-in-photo-of-john-mcafee-pinpointing-him-to-a-location-in-guatemala
5	The New York Times — «Web Photos That Reveal Secrets, Like Where You Live» (2010)	https://www.nytimes.com/2010/08/11/business/media/11photos.html	https://web.archive.org/web/*/https://www.nytimes.com/2010/08/11/business/media/11photos.html
6	Friedland y Sommer — «Cybercasing the Joint: On the Privacy Implications of Geo-Tagging» (USENIX HotSec 2010)	https://www.usenix.org/conference/hotsec10/cybercasing-joint-privacy-implications-geo-tagging	https://web.archive.org/web/*/https://www.usenix.org/conference/hotsec10/cybercasing-joint-privacy-implications-geo-tagging
7	ICSI — nota del proyecto «Cybercasing» (2010)	https://www.icsi.berkeley.edu/icsi/news/2010/08/cybercasing	https://web.archive.org/web/*/https://www.icsi.berkeley.edu/icsi/news/2010/08/cybercasing
8	CIPA — DC-008, estándar Exchangeable image file format	https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf	https://web.archive.org/web/*/https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf
9	MetaFilter — hilo que documenta los incidentes de las miniaturas incrustadas de 2003	https://www.metafilter.com/27225/Photoshop-Thumbnails-Boobs	https://web.archive.org/web/*/https://www.metafilter.com/27225/Photoshop-Thumbnails-Boobs
10	Stolen Camera Finder — búsqueda de fotos por número de serie	https://www.stolencamerafinder.com/	https://web.archive.org/web/*/https://www.stolencamerafinder.com/
11	Apple — Gestionar los metadatos de ubicación en Fotos (Guía de seguridad personal)	https://support.apple.com/guide/personal-safety/manage-location-metadata-in-photos-ips0d7a5df82/web	https://web.archive.org/web/*/https://support.apple.com/guide/personal-safety/manage-location-metadata-in-photos-ips0d7a5df82/web
12	Ayuda de Google Fotos — Editar la ubicación de las fotos	https://support.google.com/photos/answer/6153599?hl=en	https://web.archive.org/web/*/https://support.google.com/photos/answer/6153599?hl=en
13	ExifTool, de Phil Harvey — sitio oficial	https://exiftool.org/	https://web.archive.org/web/*/https://exiftool.org/
14	ExifCleaner — eliminador de metadatos de código abierto (GitHub)	https://github.com/szTheory/exifcleaner	https://web.archive.org/web/*/https://github.com/szTheory/exifcleaner
15	Signal Community — tratamiento de los metadatos según el tipo de archivo (foto frente a documento/adjunto)	https://community.signalusers.org/t/list-of-meta-data-which-should-be-displayed-when-sending-certain-file-formats/31798	https://web.archive.org/web/*/https://community.signalusers.org/t/list-of-meta-data-which-should-be-displayed-when-sending-certain-file-formats/31798

#	Fuente	URL	Archivo
1	FTC — Background Checks: What Employers Need to Know	https://www.ftc.gov/business-guidance/resources/background-checks-what-employers-need-know	https://web.archive.org/web/20260717052817/https://www.ftc.gov/business-guidance/resources/background-checks-what-employers-need-know
2	FTC — Employer Background Checks and Your Rights	https://consumer.ftc.gov/articles/employer-background-checks-and-your-rights	https://web.archive.org/web/20260423200314/https://consumer.ftc.gov/articles/employer-background-checks-and-your-rights
3	FTC — TruthFinder LLC, FTC v. (página del caso con enlace a la orden firmada)	https://www.ftc.gov/legal-library/browse/cases-proceedings/truthfinder-llc-ftc-v	https://web.archive.org/web/20260521224619/https://www.ftc.gov/legal-library/browse/cases-proceedings/truthfinder-llc-ftc-v
4	FTC — Fair Credit Reporting Act, revisada en marzo de 2026	https://www.ftc.gov/legal-library/browse/statutes/fair-credit-reporting-act	https://web.archive.org/web/20260719204956/https://www.ftc.gov/legal-library/browse/statutes/fair-credit-reporting-act
5	EEOC y FTC — Background Checks: What Job Applicants and Employees Should Know	https://www.eeoc.gov/laws/guidance/background-checks-what-job-applicants-and-employees-should-know	https://web.archive.org/web/20260723022448/https://www.eeoc.gov/laws/guidance/background-checks-what-job-applicants-and-employees-should-know
6	The Harvard Crimson — Doxxing Attacks, Employment Losses (dic. de 2023)	https://www.thecrimson.com/article/2023/12/8/doxxing-students-palestine-feature/	https://web.archive.org/web/20260720063907/https://www.thecrimson.com/article/2023/12/8/doxxing-students-palestine-feature/
7	Network World — Intercambio público sobre Cisco (mar. de 2009)	https://www.networkworld.com/article/763101/cisco-subnet-tweeted-out-of-a-job-the-cisco-fatty-story.html	https://web.archive.org/web/20250820182213/https://www.networkworld.com/article/763101/cisco-subnet-tweeted-out-of-a-job-the-cisco-fatty-story.html
8	SHRM — HR Weeds Out Applicants Through Public Social Media Searches (encuesta de 2015)	https://www.shrm.org/topics-tools/news/talent-acquisition/hr-weeds-applicants-public-social-searches	https://web.archive.org/web/20260410095524/https://www.shrm.org/topics-tools/news/talent-acquisition/hr-weeds-applicants-public-social-searches
9	Express Employment Professionals / Harris Poll — Social Media Integral to Recruiting (encuesta de 2022)	https://www.expresspros.com/newsroom/news-releases/news-releases/2023/05/social-media-integral-to-recruiting-as-most-businesses-use-it-to-source-research-and-screen-candidates	https://web.archive.org/web/20251216153245/https://www.expresspros.com/newsroom/news-releases/news-releases/2023/05/social-media-integral-to-recruiting-as-most-businesses-use-it-to-source-research-and-screen-candidates
10	AEPD — La protección de datos en las relaciones laborales	https://www.aepd.es/sites/default/files/2021-05/la-proteccion-de-datos-en-las-relaciones-laborales.pdf	https://web.archive.org/web/20260730164320/https://www.aepd.es/sites/default/files/2021-05/la-proteccion-de-datos-en-las-relaciones-laborales.pdf
11	AEPD — Ejercicio de derechos de protección de datos	https://www.aepd.es/derechos-y-deberes/ejerce-tus-derechos	https://web.archive.org/web/20260726193000/https://www.aepd.es/derechos-y-deberes/ejerce-tus-derechos
12	AEPD — Ayuda y reclamaciones	https://www.aepd.es/la-agencia/en-que-podemos-ayudarte	https://web.archive.org/web/20260730164409/https://www.aepd.es/la-agencia/en-que-podemos-ayudarte
13	AEPD — Antecedentes penales y acceso a un puesto de trabajo	https://www.aepd.es/preguntas-frecuentes/3-proteccion-de-datos-en-el-ambito-laboral/FAQ-0307-se-pueden-solicitar-los-antecedentes-penales-para-un-puesto-de-trabajo	https://web.archive.org/web/20260730164606/https://www.aepd.es/preguntas-frecuentes/3-proteccion-de-datos-en-el-ambito-laboral/FAQ-0307-se-pueden-solicitar-los-antecedentes-penales-para-un-puesto-de-trabajo
14	BOE — Estatuto de los Trabajadores, texto consolidado	https://www.boe.es/buscar/act.php?id=BOE-A-2015-11430	https://web.archive.org/web/20260729000929/https://www.boe.es/buscar/act.php?id=BOE-A-2015-11430
15	Inspección de Trabajo y Seguridad Social — Trámites para personas trabajadoras	https://oeitss.gob.es/tramites/personas-trabajadoras	https://web.archive.org/web/20260730164803/https://oeitss.gob.es/tramites/personas-trabajadoras
16	Cámara de Diputados — LFPDPPP vigente	https://www.diputados.gob.mx/LeyesBiblio/pdf/LFPDPPP.pdf	https://web.archive.org/web/20260627163419/https://www.diputados.gob.mx/LeyesBiblio/pdf/LFPDPPP.pdf
17	Secretaría Anticorrupción y Buen Gobierno — Competencia en protección de datos personales	https://www.gob.mx/buengobierno/prensa/la-secretaria-anticorrupcion-y-buen-gobierno-reafirma-su-compromiso-con-la-transparencia-y-la-proteccion-de-datos-personales	https://web.archive.org/web/20260730164956/https://www.gob.mx/buengobierno/prensa/la-secretaria-anticorrupcion-y-buen-gobierno-reafirma-su-compromiso-con-la-transparencia-y-la-proteccion-de-datos-personales
18	CONAPRED — Quejas y orientación	https://www.conapred.gob.mx/quejas/quejas-y-orientacion	https://web.archive.org/web/20260509170805/https://www.conapred.gob.mx/quejas/quejas-y-orientacion
19	PROFEDET — Orientación y representación laboral	https://www.gob.mx/profedet/que-hacemos	https://web.archive.org/web/20260730165106/https://www.gob.mx/profedet/que-hacemos
20	PRS — Constancia federal de antecedentes penales	https://constancias.oadprs.gob.mx/index	https://web.archive.org/web/20260730165442/https://constancias.oadprs.gob.mx/index

#	Fuente	URL	Archivo
1	PGP 2.6.2 User’s Guide — reconocimientos de PGP 2.0 (1994)	https://web.pa.msu.edu/reference/pgpdoc1.html	https://web.archive.org/web/20201112040702/https://web.pa.msu.edu/reference/pgpdoc1.html
2	Hal Finney — página personal archivada	https://fennetic.net/irc/finney.org/~hal/home.html	https://web.archive.org/web/20250314135429/https://fennetic.net/irc/finney.org/~hal/home.html
3	Hal Finney — Why Remailers I (1992)	https://nakamotoinstitute.org/library/why-remailers-i/	https://web.archive.org/web/20241005233552/https://nakamotoinstitute.org/library/why-remailers-i/
4	Hal Finney — Protecting Privacy with Electronic Cash (1993)	https://nakamotoinstitute.org/library/protecting-privacy-with-electronic-cash/	https://web.archive.org/web/20240813051548/https://nakamotoinstitute.org/library/protecting-privacy-with-electronic-cash/
5	Hal Finney — Detecting Double Spending (1993)	https://nakamotoinstitute.org/library/detecting-double-spending/	https://web.archive.org/web/20240521015620/https://nakamotoinstitute.org/library/detecting-double-spending/
6	Hal Finney — Politics vs Technology (1994)	https://nakamotoinstitute.org/library/politics-vs-technology/	https://web.archive.org/web/20240521015548/https://nakamotoinstitute.org/library/politics-vs-technology/
7	Hal Finney — PGP Web of Trust Misconceptions (1994)	https://nakamotoinstitute.org/library/pgp-web-of-trust-misconceptions/	https://web.archive.org/web/20240521015609/https://nakamotoinstitute.org/library/pgp-web-of-trust-misconceptions/
8	Hal Finney — anuncio de RPOW (2004)	https://cryptome.org/rpow.htm	https://web.archive.org/web/20200702094208/https://cryptome.org/rpow.htm
9	Hal Finney — modelo de seguridad de RPOW para IBM 4758	https://nakamotoinstitute.org/finney/rpow/secmodel.html	https://web.archive.org/web/20240715202954/https://nakamotoinstitute.org/finney/rpow/secmodel.html
10	Satoshi Nakamoto — Bitcoin: A Peer-to-Peer Electronic Cash System	https://bitcoin.org/bitcoin.pdf	https://web.archive.org/web/20210812170542/https://bitcoin.org/bitcoin.pdf
11	Hal Finney — respuesta a Bitcoin P2P e-cash paper (2008)	https://www.metzdowd.com/pipermail/cryptography/2008-November/014827.html	https://web.archive.org/web/20220407064228/https://www.metzdowd.com/pipermail/cryptography/2008-November/014827.html
12	Satoshi Nakamoto — lanzamiento de Bitcoin v0.1 (2009)	https://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html	https://web.archive.org/web/20200207210227/https://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html
13	Hal Finney — respuesta pública a Bitcoin v0.1 (2009)	https://www.metzdowd.com/pipermail/cryptography/2009-January/015004.html	https://web.archive.org/web/20260802040419/https://www.metzdowd.com/pipermail/cryptography/2009-January/015004.html
14	Hal Finney — «Running bitcoin» (2009)	https://x.com/halfin/status/1110302988	https://web.archive.org/web/20240719190909/https://x.com/halfin/status/1110302988
15	Transacción de Bitcoin `f4184fc5…e16`, bloque 170	https://blockstream.info/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16	https://web.archive.org/web/20201112014519/https://blockstream.info/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16
16	Hal Finney — Bitcoin and Me (2013)	https://bitcointalk.org/index.php?topic=155054.msg1644175	https://web.archive.org/web/20220309092611/https://bitcointalk.org/index.php?topic=155054.msg1644175

#	Fuente	URL	Archivo
1	EFF — Vigilancia a pie de calle: lectores automáticos de matrículas	https://sls.eff.org/technologies/automated-license-plate-readers-alprs	https://web.archive.org/web/*/https://sls.eff.org/technologies/automated-license-plate-readers-alprs
2	EFF — Un policía de Texas usó 83.000 cámaras para rastrear a una paciente de aborto (mayo de 2025)	https://www.eff.org/deeplinks/2025/05/she-got-abortion-so-texas-cop-used-83000-cameras-track-her-down	https://web.archive.org/web/*/https://www.eff.org/deeplinks/2025/05/she-got-abortion-so-texas-cop-used-83000-cameras-track-her-down
3	IPVM — El abuso policial de los lectores de matrículas de Flock se triplica en una agencia en cuanto se ponen a mirar	https://ipvm.com/reports/flock-police-triple-audit	https://web.archive.org/web/*/https://ipvm.com/reports/flock-police-triple-audit
4	ACLU — Campaña «Get the Flock Out» y ley modelo	https://www.aclu.org/campaigns-initiatives/get-the-flock-out	https://web.archive.org/web/*/https://www.aclu.org/campaigns-initiatives/get-the-flock-out
5	ACLU-WA — El gobernador Ferguson firma la SB 6002, la Driver Privacy Act	https://www.aclu-wa.org/press-releases/gov-ferguson-signs-sb-6002-the-driver-privacy-act-into-law/	https://web.archive.org/web/*/https://www.aclu-wa.org/press-releases/gov-ferguson-signs-sb-6002-the-driver-privacy-act-into-law/
6	Institute for Justice — Plate Privacy Project (casos de acecho policial con lectores de matrículas)	https://ij.org/issues/ijs-project-on-the-4th-amendment/license-plate-readers/	https://web.archive.org/web/*/https://ij.org/issues/ijs-project-on-the-4th-amendment/license-plate-readers/
7	Servicio de Estudios del Congreso — Lectores automáticos de matrículas (IF13068)	https://www.congress.gov/crs-product/IF13068	https://web.archive.org/web/*/https://www.congress.gov/crs-product/IF13068
8	Fiscal General de California — Bonta demanda a El Cajon por compartir datos ALPR de forma ilegal	https://oag.ca.gov/news/press-releases/attorney-general-bonta-sues-el-cajon-illegally-sharing-license-plate-data-out	https://web.archive.org/web/*/https://oag.ca.gov/news/press-releases/attorney-general-bonta-sues-el-cajon-illegally-sharing-license-plate-data-out
9	RadarTest — Análisis de PhotoBlocker y productos reflectantes para matrículas	https://radartest.com/photoblocker-review.asp	https://web.archive.org/web/*/https://radartest.com/photoblocker-review.asp
10	NCSL — Lectores automáticos de matrículas: leyes estatales	https://www.ncsl.org/technology-and-communication/automated-license-plate-readers-state-statutes	https://web.archive.org/web/*/https://www.ncsl.org/technology-and-communication/automated-license-plate-readers-state-statutes
11	TribLive — Condenan a un exagente que usó equipo policial para acechar a una mujer (McSherry, Pensilvania)	https://triblive.com/local/valley-news-dispatch/ex-cop-who-used-police-gear-to-stalk-woman-pleads-guilty-sentenced-to-jail-probation/	https://web.archive.org/web/*/https://triblive.com/local/valley-news-dispatch/ex-cop-who-used-police-gear-to-stalk-woman-pleads-guilty-sentenced-to-jail-probation/
12	KAKE — El jefe de policía de Sedgwick rastreó a su exnovia 164 veces con cámaras de matrículas (Nygaard, Kansas)	https://www.kake.com/home/sedgwick-police-chief-tracked-ex-girlfriend-164-times-using-license-plate-cams/article_21fdfdba-5dc5-11ef-95c4-8be8baa3f10c.html	https://web.archive.org/web/*/https://www.kake.com/home/sedgwick-police-chief-tracked-ex-girlfriend-164-times-using-license-plate-cams/article_21fdfdba-5dc5-11ef-95c4-8be8baa3f10c.html
13	TMJ4 — Un exagente de Milwaukee se declara culpable tras acechar a su ex con tecnología policial (Ayala, Wisconsin)	https://www.tmj4.com/news/local-news/in-your-community/milwaukee-county/former-milwaukee-officer-pleads-guilty-to-misdemeanor-for-stalking-ex-girlfriend-with-police-technology	https://web.archive.org/web/*/https://www.tmj4.com/news/local-news/in-your-community/milwaukee-county/former-milwaukee-officer-pleads-guilty-to-misdemeanor-for-stalking-ex-girlfriend-with-police-technology
14	EFF — Get the Flock Out of Here (2026)	https://www.eff.org/deeplinks/2026/06/get-flock-out-here	https://web.archive.org/web/*/https://www.eff.org/deeplinks/2026/06/get-flock-out-here
15	TechTimes — Flock Safety supera las 100.000 cámaras mientras 53 ciudades cancelan (junio de 2026)	https://www.techtimes.com/articles/319317/20260629/flock-safety-crosses-100000-cameras-as-53-cities-cancel-over-unauthorized-federal-data-access.htm	https://web.archive.org/web/*/https://www.techtimes.com/articles/319317/20260629/flock-safety-crosses-100000-cameras-as-53-cities-cancel-over-unauthorized-federal-data-access.htm
16	EFF y ACLU — La policía de San Francisco comparte de forma ilegal datos ALPR con el ICE y estados antiaborto (septiembre de 2025)	https://www.eff.org/deeplinks/2025/09/eff-aclu-sfpd-stop-illegally-sharing-data-ice-and-anti-abortion-states	https://web.archive.org/web/*/https://www.eff.org/deeplinks/2025/09/eff-aclu-sfpd-stop-illegally-sharing-data-ice-and-anti-abortion-states

#	Fuente	URL	Copia archivada
1	NIST — SP 800-63B-4: autenticadores y resistencia al phishing	https://pages.nist.gov/800-63-4/sp800-63b/authenticators/	https://web.archive.org/web/20260701051113/https://pages.nist.gov/800-63-4/sp800-63b/authenticators/
2	NIST — SP 800-63B-4: gestión de eventos de autenticación y recuperación de cuentas	https://pages.nist.gov/800-63-4/sp800-63b/events/	https://web.archive.org/web/20260323072006/https://pages.nist.gov/800-63-4/sp800-63b/events/
3	FIDO Alliance — lanzamiento del Passkey Index y resultados de 2025	https://fidoalliance.org/fido-alliance-launches-passkey-index-revealing-significant-passkey-uptake-and-business-benefits/	https://web.archive.org/web/20260420062740/https://fidoalliance.org/fido-alliance-launches-passkey-index-revealing-significant-passkey-uptake-and-business-benefits/
4	FIDO Alliance — despliegue de claves sincronizadas: prácticas emergentes para servicios de consumo	https://fidoalliance.org/wp-content/uploads/2024/05/Synced-Passkey-Deployment_-Emerging-Practices-for-Consumer-Use-Cases_2024-Final.pdf	https://web.archive.org/web/20260420102322/https://fidoalliance.org/wp-content/uploads/2024/05/Synced-Passkey-Deployment_-Emerging-Practices-for-Consumer-Use-Cases_2024-Final.pdf
5	FIDO Alliance — Credential Exchange Format, estándar propuesto (9 de marzo de 2026)	https://fidoalliance.org/specs/cx/cxf-v1.0-ps-errata-20260309.pdf	https://web.archive.org/web/20260515224326/https://fidoalliance.org/specs/cx/cxf-v1.0-ps-errata-20260309.pdf
6	Google — gestionar el PIN de Google Password Manager	https://support.google.com/chrome/answer/16608973	https://web.archive.org/web/20260729220641/https://support.google.com/chrome/answer/16608973
7	Google — recuperar una cuenta de Google o Gmail	https://support.google.com/accounts/answer/7682439?hl=en	https://web.archive.org/web/20260713163540/https://support.google.com/accounts/answer/7682439?hl=en
8	Google — anuncio de Recovery Contacts (15 de octubre de 2025)	https://blog.google/innovation-and-ai/technology/safety-security/how-google-protects-against-scams-2025/	https://web.archive.org/web/20260524055556/https://blog.google/innovation-and-ai/technology/safety-security/how-google-protects-against-scams-2025/
9	Google — actualización del despliegue y adopción de claves de acceso (2 de mayo de 2024)	https://blog.google/innovation-and-ai/technology/safety-security/google-passkeys-update-april-2024/	https://web.archive.org/web/20260711072347/https://blog.google/innovation-and-ai/technology/safety-security/google-passkeys-update-april-2024/
10	Apple — resumen de seguridad del Llavero de iCloud	https://support.apple.com/en-gb/guide/security/sec1c89c6f3b/web	https://web.archive.org/web/20260312052028/https://support.apple.com/en-gb/guide/security/sec1c89c6f3b/web
11	Apple — configurar un contacto de recuperación para la Cuenta de Apple	https://support.apple.com/en-us/102641	https://web.archive.org/web/20260628000018/https://support.apple.com/en-us/102641
12	Apple — configurar una clave de recuperación para la Cuenta de Apple	https://support.apple.com/en-ie/109345	https://web.archive.org/web/20260516085000/https://support.apple.com/en-ie/109345
13	Microsoft — qué son las claves de acceso y por qué importan	https://support.microsoft.com/en-us/windows/security/identity-signin/what-are-passkeys-and-why-they-matter	https://web.archive.org/web/20260722085522/https://support.microsoft.com/en-us/windows/security/identity-signin/what-are-passkeys-and-why-they-matter
14	Microsoft — ayuda con el formulario de recuperación de la cuenta Microsoft	https://support.microsoft.com/en-us/accounts-billing/manage/help-with-the-microsoft-account-recovery-form	https://web.archive.org/web/20260727062121/https://support.microsoft.com/en-us/accounts-billing/manage/help-with-the-microsoft-account-recovery-form
15	Microsoft — cómo obtener un código de recuperación de la cuenta Microsoft	https://support.microsoft.com/en-us/accounts-billing/manage/how-to-get-a-microsoft-account-recovery-code	https://web.archive.org/web/20260713003505/https://support.microsoft.com/en-us/accounts-billing/manage/how-to-get-a-microsoft-account-recovery-code
16	Microsoft Entra — claves de acceso de forma predeterminada y retirada de SMS y voz	https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement	https://web.archive.org/web/20260724230317/https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement
17	GitHub — gestionar tus claves de acceso	https://docs.github.com/en/authentication/authenticating-with-a-passkey/managing-your-passkeys	https://web.archive.org/web/20260708055407/https://docs.github.com/en/authentication/authenticating-with-a-passkey/managing-your-passkeys
18	GitHub — configurar métodos de recuperación del 2FA y recuperar credenciales perdidas	https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication-recovery-methods	https://web.archive.org/web/20260716133240/https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication-recovery-methods
19	GitHub — recuperar tu cuenta si pierdes las credenciales del 2FA	https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/recovering-your-account-if-you-lose-your-2fa-credentials	https://web.archive.org/web/20260728005320/https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/recovering-your-account-if-you-lose-your-2fa-credentials
20	Google — iniciar sesión con una clave de acceso en lugar de una contraseña	https://support.google.com/accounts/answer/13548313?hl=en	https://web.archive.org/web/20260721063041/https://support.google.com/accounts/answer/13548313?hl=en
21	Google — resolver problemas frecuentes de la verificación en dos pasos	https://support.google.com/accounts/answer/185834?hl=en	https://web.archive.org/web/20260627232455/https://support.google.com/accounts/answer/185834?hl=en
22	Apple — acerca de la seguridad de las claves de acceso	https://support.apple.com/en-us/102195	https://web.archive.org/web/20260728162533/https://support.apple.com/en-us/102195
23	Apple — acerca de las llaves de seguridad para la Cuenta de Apple	https://support.apple.com/en-gb/102637	https://web.archive.org/web/20260217211459/https://support.apple.com/en-gb/102637
24	Microsoft — retirada gradual de los códigos SMS para cuentas personales	https://support.microsoft.com/en-us/accounts-billing/manage/microsoft-to-stop-sending-sms-codes-for-personal-accounts	https://web.archive.org/web/20260714002357/https://support.microsoft.com/en-us/accounts-billing/manage/microsoft-to-stop-sending-sms-codes-for-personal-accounts
25	Apple — usar la recuperación de cuenta cuando no puedes restablecer la contraseña de tu Cuenta de Apple	https://support.apple.com/en-gb/118574	https://web.archive.org/web/20260309005225/https://support.apple.com/en-gb/118574

Privacidad, OPSEC y soberanía personal | CypherpunkGuide on CypherpunkGuide

Tras comprar Bitcoin: verificación de autocustodia en 10 pasos (2026)

Primer principio: la autocustodia traslada el riesgo #

Recepción, Firma y Recuperación son pruebas distintas #

La verificación de autocustodia en 10 pasos #

Paso 1: conserva la compra y protege la cuenta del exchange #

Paso 2: decide cuánta responsabilidad puedes asumir hoy #

Paso 3: obtén la billetera de una fuente verificable #

Paso 4: crea la billetera y anota la receta completa de recuperación #

Paso 5: comprueba la copia antes de confiarle el saldo completo #

Paso 6: genera una dirección nueva y verifica todos sus caracteres #

Paso 7: haz un retiro de prueba que limite el riesgo #

Paso 8: demuestra la Recepción #

Paso 9: demuestra la Firma con un gasto pequeño #

Paso 10: demuestra la Recuperación y completa el plan operativo #

Qué reveló nuestra prueba aislada con Bitcoin Core 31.1 #

En conclusión: termina el traspaso antes de mover el saldo #

Preguntas frecuentes #

¿Debo retirar el bitcoin de un exchange de inmediato? #

¿Necesito una billetera de hardware? #

¿Un retiro de prueba correcto demuestra la autocustodia? #

¿Puede cualquier billetera recuperar mi bitcoin con la frase semilla? #

¿Qué registros fiscales debo guardar después de comprar bitcoin? #

Cora Aegis

Fuentes primarias y archivos #

Recuperar una contraseña de Bitcoin: qué puede y qué no puede hacer la IA (2026)

¿Se puede recuperar una contraseña perdida de Bitcoin? #

Qué hizo la IA en una recuperación publicada en 2026 #

La IA diseña los candidatos; el software los comprueba #

Qué encontramos en nuestro laboratorio sintético de 11 ejecuciones #

BTCRecover, Hashcat, IA local o servicio de recuperación #

Protocolo de recuperación sin conexión en siete pasos #

Cómo evaluar un servicio de recuperación sin entregar la billetera #

En conclusión: decide por el tipo de fallo y por qué secretos expones #

Preguntas frecuentes #

¿Puede la IA recuperar la contraseña olvidada de una billetera Bitcoin? #

¿Puede BTCRecover probar por fuerza bruta cualquier contraseña de Bitcoin? #

¿Una passphrase BIP39 es lo mismo que la contraseña de una billetera? #

¿Es seguro entregar mi archivo wallet.dat a un servicio de recuperación? #

¿Qué debo hacer justo después de recuperar el acceso? #

Cora Aegis

Fuentes y copias archivadas #

Metodología — cómo KYC Drift registra las declaraciones de la IA alojada

Estado del piloto #

Qué registra el conjunto de datos #

Qué queda fuera de alcance #

De dónde salen los valores #

Vocabulario controlado y regla de cero casillas vacías #

Evidencia, fechas e integridad #

Origen, integridad, aplicación, actualidad y conflicto #

Cambios, correcciones y objeciones #

Objetivo de actualización y límite actual #

Por qué no hay puntuaciones #

Selección y licencia #

Custodia de Bitcoin bajo coacción: guía para sobrevivientes 2026

Por qué los consejos habituales de custodia fallan cuando la amenaza vive en casa #

La matriz de capacidad del adversario #

Antes de la billetera: asegura el dispositivo y el plan de seguridad #

Opciones de custodia bajo coacción, y sus límites honestos #

El registro público de Bitcoin es su propia exposición #

Una respuesta por etapas: ajusta el movimiento al momento #

Cuando Bitcoin no es la respuesta #

En conclusión: arma un plan que encaje con tu riesgo #

Preguntas frecuentes #

¿Me protege un hardware wallet si mi pareja me ve usarlo? #

¿Es seguro usar una billetera señuelo o “de coacción” bajo presión? #

¿Debería poner a una amistad o a un familiar en un multisig? #

¿Qué hago primero si creo que mi dispositivo está vigilado? #

¿Es mejor Bitcoin que una cuenta bancaria para irse con seguridad? #

Referencias #

Cora Aegis

El Manifiesto Cypherpunk: qué dice y por qué sigue vigente

Qué dice de verdad el Manifiesto cypherpunk #

Tres textos, una idea: May, Hughes y Chaum #

La mujer que le puso nombre: Jude Milhon #

El balance: las predicciones de 1993 frente a 2026 #

«Los cypherpunks escriben código»: la ética en 2026 #

En conclusión: por qué un ensayo de 1993 sigue marcando el plano #

Preguntas frecuentes #

¿Qué es el Manifiesto cypherpunk? #

Primer principio: la autocustodia traslada el riesgo
#

Recepción, Firma y Recuperación son pruebas distintas
#

La verificación de autocustodia en 10 pasos
#

Paso 1: conserva la compra y protege la cuenta del exchange
#

Paso 2: decide cuánta responsabilidad puedes asumir hoy
#

Paso 3: obtén la billetera de una fuente verificable
#

Paso 4: crea la billetera y anota la receta completa de recuperación
#

Paso 5: comprueba la copia antes de confiarle el saldo completo
#

Paso 6: genera una dirección nueva y verifica todos sus caracteres
#

Paso 7: haz un retiro de prueba que limite el riesgo
#

Paso 8: demuestra la Recepción
#

Paso 9: demuestra la Firma con un gasto pequeño
#

Paso 10: demuestra la Recuperación y completa el plan operativo
#

Qué reveló nuestra prueba aislada con Bitcoin Core 31.1
#

En conclusión: termina el traspaso antes de mover el saldo
#

Preguntas frecuentes
#

¿Debo retirar el bitcoin de un exchange de inmediato?
#

¿Necesito una billetera de hardware?
#

¿Un retiro de prueba correcto demuestra la autocustodia?
#

¿Puede cualquier billetera recuperar mi bitcoin con la frase semilla?
#

¿Qué registros fiscales debo guardar después de comprar bitcoin?
#

Fuentes primarias y archivos
#

¿Se puede recuperar una contraseña perdida de Bitcoin?
#

Qué hizo la IA en una recuperación publicada en 2026
#

La IA diseña los candidatos; el software los comprueba
#

Qué encontramos en nuestro laboratorio sintético de 11 ejecuciones
#

BTCRecover, Hashcat, IA local o servicio de recuperación
#

Protocolo de recuperación sin conexión en siete pasos
#

Cómo evaluar un servicio de recuperación sin entregar la billetera
#

En conclusión: decide por el tipo de fallo y por qué secretos expones
#

Preguntas frecuentes
#

¿Puede la IA recuperar la contraseña olvidada de una billetera Bitcoin?
#

¿Puede BTCRecover probar por fuerza bruta cualquier contraseña de Bitcoin?
#

¿Una passphrase BIP39 es lo mismo que la contraseña de una billetera?
#

¿Es seguro entregar mi archivo `wallet.dat` a un servicio de recuperación?
#

¿Qué debo hacer justo después de recuperar el acceso?
#

Fuentes y copias archivadas
#

Estado del piloto
#

Qué registra el conjunto de datos
#

Qué queda fuera de alcance
#

De dónde salen los valores
#

Vocabulario controlado y regla de cero casillas vacías
#

Evidencia, fechas e integridad
#

Origen, integridad, aplicación, actualidad y conflicto
#

Cambios, correcciones y objeciones
#

Objetivo de actualización y límite actual
#

Por qué no hay puntuaciones
#

Selección y licencia
#

Por qué los consejos habituales de custodia fallan cuando la amenaza vive en casa
#

La matriz de capacidad del adversario
#

Antes de la billetera: asegura el dispositivo y el plan de seguridad
#

Opciones de custodia bajo coacción, y sus límites honestos
#

El registro público de Bitcoin es su propia exposición
#

Una respuesta por etapas: ajusta el movimiento al momento
#

Cuando Bitcoin no es la respuesta
#

En conclusión: arma un plan que encaje con tu riesgo
#

Preguntas frecuentes
#

¿Me protege un hardware wallet si mi pareja me ve usarlo?
#

¿Es seguro usar una billetera señuelo o “de coacción” bajo presión?
#

¿Debería poner a una amistad o a un familiar en un multisig?
#

¿Qué hago primero si creo que mi dispositivo está vigilado?
#

¿Es mejor Bitcoin que una cuenta bancaria para irse con seguridad?
#

Referencias
#

Qué dice de verdad el Manifiesto cypherpunk
#

Tres textos, una idea: May, Hughes y Chaum
#

La mujer que le puso nombre: Jude Milhon
#

El balance: las predicciones de 1993 frente a 2026
#

«Los cypherpunks escriben código»: la ética en 2026
#

En conclusión: por qué un ensayo de 1993 sigue marcando el plano
#

Preguntas frecuentes
#

¿Qué es el Manifiesto cypherpunk?
#

¿Quién escribió el Manifiesto cypherpunk y quién acuñó la palabra «cypherpunk»?
#

¿En qué se diferencia el Manifiesto cypherpunk del Manifiesto criptoanarquista?
#

¿Sigue vigente el Manifiesto cypherpunk en 2026?
#

¿Tengo que ser programador para ser cypherpunk?
#

«Eliminar» es una ilusión de la interfaz
#

El vector de 2026: tus publicaciones ya entrenan modelos de AI
#

Lo que el vuelo de 12 horas de Justine Sacco sigue enseñando en 2026
#

El manual de auditoría de cuentas antiguas: una autoevaluación en seis pasos
#

Cuando el riesgo no es simétrico: mujeres y personas en la mira
#