Diecisiete mil eventos, y la API dijo que no
El momento que importa en la divulgación de Hugging Face no es la intrusión. Es un miembro del equipo de respuesta sentado frente a una API de pago con las pruebas en la mano y recibiendo un rechazo. El 16 de julio de 2026 la compañía publicó un relato de un incidente de seguridad en el que, según dice, los atacantes usaron lo que describe textualmente como "(a remote-code dataset loader and a template-injection in a dataset configuration)" para ejecutar código en un worker de procesamiento. Lo que el equipo tenía después era, en palabras de la propia Hugging Face, "the full attacker action log, comprised of more than 17,000 recorded events". En otro punto la publicación habla de "tens of thousands of automated actions".
El rechazo es la noticia, y Hugging Face escribió la frase por su cuenta. Su publicación afirma: "This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker." La última oración subordinada es la que carga con todo el peso. El sistema no estaba juzgando a Hugging Face y equivocándose. No tenía forma alguna de emitir ese juicio.
Todo lo anterior descansa en la palabra de Hugging Face, y queremos decirlo con claridad. No tenemos fuente primaria independiente para ninguno de los hechos del incidente. Ningún medio los ha corroborado; todo relato que encontramos se limita a repetir la publicación de la compañía. Hugging Face no da fecha de intrusión ni de detección, solo "Earlier this week" y "over a weekend". No nombra a ningún proveedor. Y declara su propio trabajo inacabado: "We are still completing our assessment of whether any partner or customer data was affected." Este artículo no es cobertura del incidente. Es una lectura de lo que los contratos publicados de los proveedores dicen realmente, contrastada con la conducta que Hugging Face describe.
Leímos las tres políticas buscando la prohibición
No existe. Recuperamos las políticas de uso publicadas de Anthropic, OpenAI y Google, y ninguna de las tres prohíbe analizar material hostil procedente de una brecha en su propio sistema. No es una lectura oportunista. Toda prohibición cibernética en los tres documentos está acotada por un matiz, y la conducta que describe Hugging Face cae fuera de todos ellos.
La política de uso de Anthropic, vigente desde el 15 de septiembre de 2025, prohíbe el trabajo destinado a "Discover or exploit vulnerabilities in systems, networks, or applications without authorization of the system owner", y prohíbe por separado a los usuarios "Create or distribute malware, ransomware, or other types of malicious code". Hugging Face era el propietario del sistema, así que la primera cláusula no le alcanza. Analizaba cargas útiles que ya existían, no las creaba ni las distribuía, así que la segunda tampoco. No hay excepción de investigación de seguridad, respuesta a incidentes ni defensa en ningún lugar del documento. El trabajo de jailbreak e inyección de prompts solo se prohíbe "without prior authorization from Anthropic", lo que contempla una autorización pero no señala ningún proceso publicado para obtenerla.
Las políticas de uso de OpenAI, vigentes desde el 29 de octubre de 2025, prohíben la "destruction, compromise, or breach of another's system or property, including malicious or abusive cyber activity". El matiz está en la palabra another's. El sistema en cuestión era el propio de Hugging Face. No encontramos excepción de investigación de seguridad; la única puerta de revisión documentada se refiere a "national security or intelligence purposes without our review and approval".
La Generative AI Prohibited Use Policy de Google, modificada por última vez el 17 de diciembre de 2024, dice: "Do not compromise the security of others' or Google's services. This includes generating or distributing content that facilitates: Spam, phishing, or malware." De nuevo el matiz hace el trabajo. Enviar cargas útiles capturadas para analizarlas no es generarlas ni distribuirlas. No hay excepción de seguridad, solo una cláusula general de excepciones: "We may make exceptions to these policies based on educational, documentary, scientific, or artistic considerations, or where harms are outweighed by substantial benefits to the public." No se documenta vía de solicitud, contacto ni proceso alguno. Las tres políticas estaban en vigor antes del incidente.
El contrato de su proveedor no es su control
Esta es la frase que pondríamos delante de un consejo. La brecha aquí no es que el contrato y el clasificador se contradigan. Es que el contrato nunca abordó la situación, mientras el clasificador se comportó como si estuviera prohibida. El equipo de respuesta de Hugging Face, según su relato, chocó con un rechazo por un trabajo que ninguna política publicada de los tres grandes proveedores prohíbe.
Un operador que hubiera hecho bien la contratación habría caído igualmente. Usted leyó la política de uso. No encontró nada que vetara el análisis defensivo de su propia brecha, porque allí no hay nada que encontrar. Firmó. Y entonces lo que le rechazó fue el entorno de ejecución, que es un objeto distinto del documento, no gobernado por ningún término que usted negociara ni descrito en ninguna cláusula que revisara. Lo que usted verificó y lo que decide a las tres de la madrugada no son el mismo sistema.
Describimos un vacío en los términos publicados, no acusamos a nadie de incumplirlos. Tanto Anthropic como OpenAI permiten personalización contractual, y los términos empresariales no públicos pueden decir algo bastante distinto de las políticas públicas; no hemos visto esos términos y no podemos pronunciarnos sobre ellos. Tampoco podemos decirle por qué se produjeron los rechazos. Hugging Face no publica transcripciones de rechazos, así que si los bloqueos respondían a la política o a un sobrebloqueo ordinario del clasificador resulta incognoscible desde fuera, y no vamos a aventurarlo. Hugging Face tampoco nombra a los proveedores que bloquearon. Solo dice: "we are sharing this feedback with the providers concerned."
Lo que Hugging Face afirmó de verdad, y lo que no
La evaluación de daños de la compañía es más estrecha de lo que sugiere una lectura rápida, y la precisión merece conservarse. Hugging Face informa de "no evidence of tampering with public, user-facing models, datasets, or Spaces, and our software supply chain (container images and published packages) was verified clean". Son dos afirmaciones distintas. Ninguna evidencia de manipulación es una ausencia de hallazgos. Verified clean es una aseveración positiva sobre la cadena de suministro, y es la más fuerte de las dos. Fundirlas en una sola tranquilidad es lo que hace que un resumen de incidente sea menos exacto que la divulgación que resume.
El atacante estaba a su vez automatizado, y ese detalle convierte el problema de volumen en estructural en lugar de fortuito. Hugging Face describe la campaña textualmente como "run by an autonomous agent framework (appearing to be built on an agentic security-research harness - used LLM still not known)". Un agente que genera decenas de miles de acciones produce un registro que un equipo humano no puede leer con rapidez, que es exactamente por lo que el equipo de respuesta quería un modelo encima, y exactamente donde fue bloqueado. La única instrucción operativa de la publicación es breve: "we recommend rotating any access tokens and reviewing recent activity on your account."
Y Hugging Face se adelantó al argumento que algunos lectores querrán extraer de esto, así que lo citamos en lugar de rodearlo. Su publicación afirma: "This is not an argument against safety measures on hosted models". Estamos de acuerdo, y este artículo no es ese argumento. Unas barreras que no distinguen a un respondedor de incidentes de un atacante siguen haciendo un trabajo real contra el atacante. El hallazgo aquí trata de lo que los términos publicados omiten y de lo que un operador debería por tanto probar, no de si los filtros deben existir.
Ponga a prueba el rechazo antes de que el incidente le ponga a prueba
Reserve el simulacro este trimestre. Tome material hostil real de sus propios registros, envíelo a la API a la que recurriría de verdad durante un incidente y anote lo que vuelve. El hallazgo que busca no es tranquilidad. Es una respuesta factual a una pregunta que ningún contrato le responderá, obtenida un día en que nada está ardiendo.
Para un operador europeo el reloj vuelve esto concreto en lugar de teórico. Los deberes de notificación de NIS2 corren sobre una alerta temprana de 24 horas y una notificación de 72 horas, y DORA impone su propia ventana estrecha de notificación inicial a las entidades financieras. Esos plazos dan por supuesto que usted puede caracterizar lo ocurrido. Si su vía de análisis se atasca en la hora tres porque un filtro no acepta sus propias pruebas, el reloj no se detiene mientras usted lo descubre. Esa es la diferencia entre enterarse en un ejercicio de simulación y enterarse dentro de una ventana regulatoria.
Después, conserve la vía que no puede ser rechazada. El plan alternativo de Hugging Face, en sus palabras: "We ran the forensic analysis instead on GLM 5.2, an open-weight model, on our own infrastructure." GLM 5.2 procede de Z.ai, antes Zhipu, en Pekín; la propia Hugging Face no caracteriza el origen del modelo, y esa identificación es nuestra, no suya. El origen no es lo relevante. Pesos que usted posee, ejecutándose en hardware que usted controla, es la única configuración en la que el entorno de ejecución de un tercero no tiene voto sobre si su incidente se analiza. Todo operador debería saber hoy si dispone de una así y si funciona.
Leer a continuación: Dos gigantes de la IA quieren ser tu integrador | Sus semillas MFA salieron antes del parche
