Un rechazo no salvó al sitio: lo bajó el registrador
El proveedor de hosting FlokiNET rechazó una solicitud de retirada contra icepi.cx, un sitio que publica identidades laborales de empleados de agencias federales de Estados Unidos. Horas después, el dominio dejó de resolver igual: su registrador, CentralNic, lo puso en serverHold sin publicar ninguna decisión. El sitio volvió a estar accesible bajo otro dominio, con otro registrador.
La secuencia importa más que el caso. Una empresa privada, contratada por una agencia de gobierno, envió una notificación automatizada. El hosting dijo que no. Y el contenido desapareció de todos modos por una vía que nadie audita: la capa de infraestructura.
Si tu startup depende de un dominio y de un proveedor de nube para existir, este episodio te muestra exactamente dónde está tu punto único de falla.
¿Y esto cómo se aplica en tu negocio?
Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.
👥 Quiero el Kit →Qué pasó, paso a paso
La notificación describía el sitio como parte de una campaña de doxxing, es decir, la publicación de datos privados de personas privadas para que cualquiera pueda ubicarlas. FlokiNET sostuvo en su blog que eso no es lo que el sitio hace: publica identidades de trabajo de empleados públicos —para quién trabajan, cuál es su rol y cómo se los contacta en ese rol—, no detalles de su vida privada.
El hosting reconoció además que el origen del dataset es incómodo: provino de una brecha de datos y nadie en él eligió estar ahí. Aun así concluyó que publicarlo sirve a un propósito de rendición de cuentas que un proveedor de hosting debe proteger, y rechazó la solicitud.
El problema es que la solicitud que decidió el resultado no fue la que llegó a FlokiNET. CentralNic, el registrador, alcanzó la conclusión opuesta la misma mañana, no publicó nada, y una audiencia global perdió acceso al sitio.
Quién es ZeroFox y por qué su historial cambia el cálculo
El caso no es solo sobre un sitio. Es sobre quién puede comprar remociones.
Según Gadget Review, el contrato con ID 70CMSD26C00000006 se adjudicó en julio de 2026 por US$14,57 millones, con US$13 millones ya obligados, y se dirige directamente a la Oficina de Inteligencia de Homeland Security Investigations de ICE. Se recibieron tres ofertas y ganó una. La fuente original cifra el acuerdo en US$15 millones y señala que la empresa puede presentar notificaciones en nombre del departamento hasta 2028.
The Intercept reportó, según la misma cobertura, un memo filtrado que describe el programa internamente como una "Doxing Mitigation Initiative", y citó a un funcionario de ICE que advirtió que podría usarse contra denunciantes y críticos internos en lugar de contra amenazas externas.
El historial de la empresa es el otro dato relevante. En 2015, ZeroFox entregó a las autoridades de Baltimore una lista de "actores de amenaza" que incluía a organizadores pacíficos de Black Lives Matter, señalados —según el reporte— en parte por su cantidad de seguidores. En 2021, el FBI contrató a la compañía de todos modos. ZeroFox es propiedad del fondo de private equity Haveli Investments, que la adquirió por aproximadamente US$350 millones en 2024, y emplea a Bryan Ware, ex subdirector de ciberseguridad del DHS.
Sophia Cope, abogada del Electronic Frontier Foundation, reconoció que el doxxing es un riesgo real y que los agentes de ICE enfrentan amenazas genuinas, pero trazó una línea: si el programa protege a la agencia de la rendición de cuentas sobre información que ya es pública, "eso es una preocupación seria".
Por qué el registro decidió lo que el hosting no
Hay una asimetría estructural que este caso expone con claridad.
- El hosting lee. FlokiNET tuvo que abrir el sitio, mirar el dataset y ponderar interés público contra riesgo personal. Ese trabajo humano es lo que la llevó a rechazar.
- El registrador no. CentralNic aplicó
serverHoldsin publicar fundamento alguno. La vía más rápida para hacer desaparecer contenido no pasó por quien examina, sino por quien solo ejecuta. - El notificante tampoco. FlokiNET señala que la parte que acusa y la que contacta ya no son la misma: no se puede ver quién dentro de ICE decidió que el sitio debía caer, ni qué se le mostró antes de decidir.
El propio hosting lo resume con una idea que aplica a cualquier plataforma: una notificación automatizada no elimina el trabajo de verificar si la acusación es cierta. Solo lo traslada al receptor. La detección por IA puede encontrar material candidato, pero no puede distinguir periodismo de rendición de cuentas de una campaña de acoso. Esa es exactamente la decisión que la detección no sabe tomar.
Qué significa esto para tu startup
Si construyes producto en internet, tu exposición no se limita a tu código ni a tu base de usuarios. Se extiende a tres capas que probablemente nunca revisaste: el registrador de tu dominio, tu proveedor de DNS y tu CDN.
El modelo de negocio detrás de las remociones masivas no es nuevo: el copyright funciona así desde hace décadas. Una empresa vende monitoreo, rastrea coincidencias, envía cartas de demanda de forma automática y cobra una parte de lo que el receptor paga para que las cartas se detengan. El volumen es el producto y la verificación es un costo que lo reduce. Lo que cambió en este caso es el cliente: ya no es solo una empresa privada, es una institución gubernamental.
Y la legislación, como señala FlokiNET respecto de normas tipo DSA, carga obligaciones sobre los proveedores de hosting y no pide nada a quien presenta la notificación.
Tres acciones concretas para protegerte
1. Audita tu cadena de infraestructura, no solo tu hosting. Haz una lista con tu registrador, tu DNS, tu CDN y tu proveedor de nube. Pregúntate, para cada uno, qué evidencia exige antes de suspender un servicio. Si la respuesta es "ninguna verificable", tienes un riesgo que no estabas midiendo.
2. Documenta tu política de notificaciones antes de recibir la primera. Define por escrito quién la revisa, qué se exige al notificante (a quién representa, bajo qué base legal, quién responde si la acusación es falsa) y si la notificación fue generada por detección automatizada. Un proveedor no puede ponderar bien una acusación sin saber si un humano la miró alguna vez.
3. Ten un dominio de respaldo y un canal de comunicación propio. El sitio del caso volvió a estar online bajo otro dominio con otro registrador. Esa continuidad no fue improvisada: fue preparación. Si tu producto vive de un solo dominio, un serverHold te deja sin negocio y sin forma de avisar a tus usuarios.
Conclusión
La parte incómoda de este caso no es que un hosting rechazara una solicitud. Es que el rechazo no importó. El contenido cayó igual, por una capa que no examina, no publica y no rinde cuentas.
Para un founder, la lección es operativa: la moderación de contenido y los takedowns dejaron de ser un problema exclusivo de las grandes plataformas. Cualquier producto con usuarios, datos o contenido publicado está expuesto a un proceso automatizado que puede llegar por tres puertas distintas. Saber cuáles son, y qué exige cada una antes de actuar, es parte de construir infraestructura seria.
Fuentes
- FlokiNET — ICE wants its mask back, and hired a company to ask
- Gadget Review — ICE Contracts Controversial AI Firm to Obscure Agent Identities
¿Y esto cómo se aplica en tu negocio?
Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.
👥 Quiero el Kit →
