media research global

EE.UU. excluye a DeepSeek de compras federales por cadena de IA

La orden FASCSA no solo prohíbe productos de DeepSeek: alcanza a cualquier producto de terceros "desarrollado usando" sus modelos, lo que convierte el linaje de los modelos de IA en un artefacto de cumplimiento con plazos de reporte de días, no meses.

·19 min de lectura ·Equipo Vantis
En 30 segundos
  • El 20 de octubre de 2026, el Departamento de Seguridad Nacional de EE.UU. (DHS) publicó una orden bajo la Federal Acquisition Supply Chain Security Act (FASCSA) que excluye a Hangzhou DeepSeek y sus afiliadas de las compras del gobierno civil federal, con órdenes paralelas de Defensa (DoW) e Inteligencia (DNI). Es la primera exclusión gubernamental completa de un proveedor de modelos de IA bajo esa ley.
  • Lo que hace compleja esta orden no es el nombre DeepSeek, sino una cláusula de terceros que alcanza a "productos y servicios desarrollados usando implementaciones DeepSeek". Como DeepSeek publica sus modelos R1 y V3 como pesos abiertos, pueden estar integrados en productos comerciales sin ninguna marca visible, lo que convierte una prohibición de proveedor en un problema de trazabilidad de modelos que hoy casi nadie puede resolver con las herramientas que tiene.
  • Evaluación (confianza media): esto es un precedente, no un caso aislado. Un fallo judicial de septiembre de 2026 ya estableció que el riesgo de cadena de suministro bajo FASCSA no requiere intención maliciosa del proveedor. Cualquier organización —también en Chile y LatAm— que dependa de una sola familia de modelos fundacionales adquiere con esto un riesgo de concentración regulatoria, no solo técnico. La alternativa que no podemos descartar es que la autoridad use esta herramienta con moderación en el futuro; por ahora, dos precedentes en un año sugieren lo contrario.

Qué pasó

La orden y sus tres versiones

El 20 de octubre de 2026 el DHS publicó en el Federal Register la orden que excluye a DeepSeek de las compras y sistemas de TI de las agencias civiles federales de EE.UU., y exige retirar "todos los productos de DeepSeek y afiliados, y los productos y servicios de terceros desarrollados usando implementaciones DeepSeek" de esos sistemas. Órdenes paralelas del Departamento de Guerra (DoW, ex Defensa) y de la Directora de Inteligencia Nacional (DNI) cubren, respectivamente, los sistemas de defensa y de inteligencia.

Según reportes periodísticos citados en la nota de CSA, la orden fue firmada el 24 de julio de 2026 —casi tres meses antes de su publicación— y la ventana de 60 días para que las agencias pidieran excepciones se cerró el 22 de septiembre, cuatro semanas antes de que el documento fuera públicamente visible. CSA aclara que trabajó con reportes secundarios para estas fechas porque la orden firmada solo está disponible como imágenes escaneadas en el registro público.

La justificación de DHS, según la cobertura citada, tiene tres componentes: posibles vulnerabilidades técnicas en los productos de DeepSeek, la obligación legal de la empresa de dar acceso al gobierno de la República Popular China, y el valor de inteligencia que tendrían los datos recolectados por sus aplicaciones. Como antecedentes documentados, la nota cita el hallazgo de Wiz Research de enero de 2025 —una base de datos ClickHouse de DeepSeek sin autenticación que exponía más de un millón de líneas de registro, incluyendo historial de chats y llaves de API— y un informe de abril de 2025 del comité selecto de la Cámara de Representantes de EE.UU. sobre el Partido Comunista Chino, que alega que DeepSeek enrutó datos de usuarios estadounidenses hacia infraestructura vinculada a China. Ambos incidentes son sobre el servicio alojado de DeepSeek. CSA es explícito: no tiene evidencia pública de código malicioso en los archivos de pesos abiertos que la empresa publica, y la extensión de la orden a esos pesos autoalojados parece apoyarse en preocupación de cadena de suministro más que en un compromiso técnico documentado del artefacto mismo.

Por qué "desarrollado usando" es la parte que importa

Una exclusión de proveedor clásica es un ejercicio de higiene de compras: identificar contratos, dejar de comprar, desinstalar. La cláusula de terceros cambia la naturaleza de la tarea. Una agencia que nunca contrató a DeepSeek puede estar usando un producto comercial cuya función de resumen llama, por debajo, a un modelo derivado de DeepSeek alojado por un proveedor de nube estadounidense. Un contratista puede tener un asistente de código interno corriendo sobre una destilación cuantizada de R1. Ninguno de los dos casos deja una factura, un dominio o un binario con la marca DeepSeek. El monitoreo de red hacia la infraestructura de DeepSeek, que DHS habría indicado como medida provisional, no detecta pesos corriendo localmente.

Ni DHS ni CISA han publicado, hasta la fecha de la nota de CSA, una definición operativa de qué cuenta como "desarrollado usando". Firmas legales consultadas en el reporte leen el texto de DoW/DNI como aplicable a un modelo DeepSeek sin importar dónde esté alojado —incluida una instancia de pesos abiertos integrada localmente— y leen el lenguaje de DHS como sugerente de que productos construidos con el asistente de código de DeepSeek también quedan cubiertos.

El mecanismo que lo hace vinculante para privados

La cláusula FAR 52.204-30 es el canal por el que la orden sale de las redes de las agencias. Obliga al contratista principal a hacer una "indagación razonable" sobre artículos cubiertos, a trasladar la cláusula a subcontratos de todos los niveles —incluidos los comerciales— y a reportar cualquier uso identificado, incluido el reportado por un subcontratista en cualquier nivel, dentro de tres días hábiles, con detalles de mitigación dentro de diez días hábiles. La revisión trimestral obligatoria en SAM.gov no se traslada a los subcontratos, pero el deber de reporte sí. Son plazos que una organización sin inventario de modelos previo difícilmente puede cumplir investigando sobre la marcha.

Por qué importa acá

Esta orden no tiene efecto legal directo sobre organizaciones chilenas: FASCSA es una ley de compras del gobierno federal de EE.UU. y no es equivalente ni está referenciada por la Ley 21.663 (marco de ciberseguridad) ni por la Ley 21.719 (protección de datos personales). Dicho eso, hay tres razones concretas por las que esto sí debería entrar al radar de un CISO o jefe de TI en Chile.

Primero, exposición indirecta real. Cualquier empresa chilena que sea proveedora de software, BPO, desarrollo o consultoría para una organización que a su vez contrata con el gobierno federal de EE.UU. —directamente o como subcontratista en cualquier nivel— puede quedar alcanzada por la cláusula FAR 52.204-30 si alguno de sus productos usa, aunque sea indirectamente, un modelo DeepSeek o un derivado. Evaluación, confianza media: no tenemos evidencia de casos chilenos concretos hoy, y la alternativa plausible es que la mayoría de los contratos locales no invoquen esta cláusula porque no participan de cadenas de suministro federal de EE.UU. Pero cualquier empresa chilena que exporte servicios de software a clientes estadounidenses con exposición gubernamental debería verificarlo, no asumirlo.

Segundo, el precedente es el verdadero titular. El fallo del Circuito de D.C. de septiembre de 2026 —sobre un caso previo contra Anthropic bajo la misma ley— estableció que el "riesgo de cadena de suministro" no requiere intención maliciosa del proveedor. Esa es una idea que trasciende Estados Unidos: significa que una decisión regulatoria o geopolítica, y no solo una falla técnica o un compromiso, puede volver inutilizable un modelo de IA de un día para otro. Evaluación, confianza alta: cualquier organización que concentre su arquitectura de IA en una sola familia de modelos fundacionales —sea DeepSeek, OpenAI, Anthropic o cualquier otro— tiene un riesgo de concentración regulatoria que debería gestionarse igual que un riesgo de proveedor único en cualquier otra capa crítica.

Tercero, el ejercicio de fondo es trasladable aunque la ley no lo sea. La pregunta que esta orden obliga a responder —"¿qué modelo de IA hay realmente detrás de cada herramienta que usamos, y de dónde viene su linaje?"— es exactamente la que debería hacerse cualquier organización chilena que esté formalizando su gobierno de IA, especialmente los operadores de importancia vital (OIV) bajo la Ley 21.663, cuyos reglamentos de implementación aún están en desarrollo y es razonable anticipar que incorporen exigencias sobre gestión de riesgo tecnológico y de proveedores. Y para efectos de la Ley 21.719, la preocupación de fondo de esta orden —que datos de usuarios terminen accesibles para un gobierno extranjero a través de la infraestructura de un proveedor de IA— es estructuralmente la misma pregunta que exige hacerse cualquier evaluación de transferencia internacional de datos.

Anatomía del ataque

Mapeo a marcos públicos, para que puedas cruzarlo con tu propia matriz de cobertura.

MITRE ATT&CKT1195Supply Chain Compromise · Initial AccessMITRE ATLASAML.T0010AI Supply Chain Compromise · Initial Access
Qué hacer, fase por fase

Estructurado sobre las seis funciones del NIST CSF 2.0, según el ciclo de respuesta a incidentes de NIST SP 800-61r3 (abril 2025, reemplaza al r2). Proteger y Detectar vienen abiertas.

GV GobernarQuien decide, que se reporta y a quien

Esta orden no crea una obligación de reporte a ANCI ni está dentro del alcance de la Ley 21.663 — es jurisdicción federal de EE.UU. Lo que sí debería hacer cualquier comité de riesgo o directorio es tratar el linaje de modelos de IA como una categoría de riesgo de proveedor con el mismo estatus que la concentración en un solo proveedor de nube o de telecomunicaciones. El ejercicio de gobierno correcto es decidir, a nivel de política, quién en la organización aprueba el uso de un modelo fundacional nuevo, quién mantiene el inventario de modelos, y bajo qué criterio se evalúa el riesgo de que una decisión regulatoria externa vuelva inutilizable un componente central de un producto.

  • Asignar formalmente la propiedad del inventario de modelos de IA (quién lo mantiene, con qué frecuencia se audita).
  • Incorporar el riesgo de concentración en un solo proveedor/familia de modelos de IA al registro de riesgos de TI que ya se reporta al comité o directorio.
  • Definir, antes de que ocurra, el criterio interno para decidir si un desarrollo regulatorio externo (una exclusión, una sanción, un retiro de certificación) obliga a reemplazar un modelo en producción.
ID IdentificarSi esto me toca, por donde me toca

El punto de partida es saber qué se tiene. No basta con una lista de productos de IA contratados: hay que bajar al nivel de modelo base, porque la cláusula de terceros de esta orden —y el riesgo real que ilustra— se activa por linaje, no por marca.

  • Levantar un inventario de todo modelo de IA en uso, incluidos despliegues autoalojados en registros de modelos, imágenes de contenedores y estaciones de trabajo de desarrollo (Ollama, LM Studio, vLLM, llama.cpp).
  • Para cada entrada del inventario, registrar la familia de modelo base (no solo el nombre del producto que lo envuelve), incluyendo si es una destilación, un ajuste fino (fine-tune) o una fusión de pesos.
  • Solicitar por escrito a cada proveedor SaaS que incorpore funciones de IA una declaración de qué modelo base alimenta cada función.
  • Si la organización vende o subcontrata para clientes con exposición a compras federales de EE.UU., verificar explícitamente si alguno de sus productos usa un modelo DeepSeek o un derivado.
PR ProtegerComo evito que ocurra

Las medidas inmediatas (bloquear apps de consumo) son necesarias pero cosméticas por sí solas: no tocan los pesos autoalojados, que son el verdadero vector que esta orden intenta cerrar. El control que de verdad reduce el riesgo es contractual y arquitectónico.

Controles priorizados

P1: esta semana · P2: este mes · P3: este trimestre

PrioControlEsfuerzoMapeo
P1 Reemplazar o retirar modelos DeepSeek y derivados identificados en productos propios por una version/familia de modelo alternativa con linaje verificado, equivalente a aplicar la 'correccion del fabricante' en este caso de cadena de suministro de IA alto MITRE ATT&CK M1016 CIS Controls v8 2.5 ISO 27001 A.8.19
P1 Mitigacion temporal: bloquear a nivel de proxy, firewall y MDM las aplicaciones y endpoints de API de consumo de DeepSeek mientras se completa el inventario y la evaluacion de exposicion real bajo MITRE ATT&CK M1021 CIS Controls v8 9.2 ISO 27001 A.8.23
P1 Reduccion de exposicion: no exponer a internet interfaces de administracion de servidores de inferencia autoalojados (Ollama, vLLM, llama.cpp, LM Studio) ni paneles de registros de modelos; restringir su acceso a redes internas segmentadas y con autenticacion fuerte medio MITRE ATT&CK M1030 CIS Controls v8 4.4 ISO 27001 A.8.20
P2 Exigir a proveedores de SaaS/IA declaracion escrita de linaje de modelo base y deber de notificar cambios de modelo subyacente antes de renovar o ampliar contratos medio MITRE ATT&CK M1013 CIS Controls v8 15.1 ISO 27001 A.5.19
P2 Configurar politicas de admision en registros de modelos y repositorios de artefactos que rechacen pesos con linaje no verificado o declarado como excluido por un organismo regulatorio relevante para el negocio medio MITRE ATT&CK M1033 CIS Controls v8 2.5 ISO 27001 A.8.19
P3 Diseñar la integracion de IA detras de una capa de abstraccion (gateway de modelos) con al menos un modelo de respaldo evaluado de otra familia/proveedor alto CIS Controls v8 11.1 ISO 27001 A.5.30

No existe un parche de fabricante en el sentido tradicional porque el riesgo no es una vulnerabilidad de codigo: es de linaje y cadena de suministro. El equivalente funcional a 'aplicar el parche' es reemplazar el modelo por uno con origen verificado; mientras eso ocurre, el bloqueo de endpoints de consumo y la segmentacion de interfaces de inferencia autoalojadas son las mitigaciones que reducen exposicion real sin esperar guia regulatoria definitiva.

DE DetectarComo me doy cuenta de que ya ocurrio

Qué necesitas tener logueado

  • Logs de proxy web / firewall de siguiente generación (DNS y conexiones salientes)
  • Logs de creación de procesos (Sysmon Event ID 1 o EDR equivalente) en estaciones y servidores que ejecuten herramientas de inferencia local de LLM
  • Telemetría de MDM para aplicaciones instaladas en dispositivos móviles
  • Logs de acceso a registros de modelos / repositorios de artefactos de IA (model registry, container registry)

Reglas y consultas de detección

sigmaPosible uso de modelo DeepSeek o infraestructura asociada (detección conductual) 
title: Possible DeepSeek Model Usage or Hosted Service Connection
id: 9b4e2f7a-3c6d-4e1a-8f9b-2d5c7a1e4b6f
status: experimental
description: |
    Deteccion por comportamiento, a ajustar al entorno. No existen IOCs publicos de compromiso para este caso: la orden FASCSA no documenta malware en los pesos abiertos de DeepSeek, sino un riesgo de cadena de suministro y linaje de modelo. Esta regla busca senales de uso del servicio alojado de DeepSeek (DNS/conexion saliente) o de ejecucion local de herramientas de inferencia con referencia al termino 'deepseek' en linea de comandos, para apoyar inventario y cumplimiento de politica de IA, no deteccion de amenaza activa.
references:
    - https://labs.cloudsecurityalliance.org/research/csa-research-note-deepseek-fascsa-exclusion-order-20261024-c/
author: Vantis
date: 2026-10-24
logsource:
    category: network_connection
    product: proxy
detection:
    selection_dns:
        DestinationHostname|contains: 'deepseek.com'
    selection_proc:
        CommandLine|contains: 'deepseek'
    condition: 1 of selection_*
falsepositives:
    - Uso legitimo y autorizado del modelo o servicio por personal tecnico, de datos o investigacion
    - Nombres de proyecto o variables internas que contengan la cadena 'deepseek' sin relacion con el modelo real
    - Trafico de terceros que mencione el termino en contenido no relacionado (documentacion, noticias)
level: low
tags:
    - attack.initial_access
    - attack.t1195
Requiere: Logs de proxy web o firewall con inspeccion de capa de aplicacion (campo DestinationHostname) y, opcionalmente, telemetria de creacion de procesos con linea de comandos completa
sentinel-kqlConexiones salientes o ejecucion de procesos relacionados con DeepSeek (Microsoft Sentinel) 
let deepseek_domains = dynamic(["deepseek.com"]);
DeviceNetworkEvents
| where RemoteUrl has_any (deepseek_domains)
| extend Hallazgo = "Conexion a servicio alojado DeepSeek"
| project Timestamp, DeviceName, InitiatingProcessAccountName, RemoteUrl, RemoteIP, Hallazgo
| union (
    DeviceProcessEvents
    | where ProcessCommandLine has "deepseek"
    | extend Hallazgo = "Posible ejecucion local de modelo/herramienta DeepSeek"
    | project Timestamp, DeviceName, InitiatingProcessAccountName=AccountName, RemoteUrl=ProcessCommandLine, RemoteIP="", Hallazgo
)
| order by Timestamp desc
Requiere: Tablas DeviceNetworkEvents y DeviceProcessEvents de Microsoft Defender for Endpoint habilitadas (bundle E5)
splunkConexiones o referencias a DeepSeek en proxy, DNS o linea de comandos (Splunk) 
index=proxy OR index=dns OR index=edr (dest="*deepseek.com*" OR query="*deepseek.com*" OR process="*deepseek*")
| stats count by src_ip, user, dest, query, process
| sort - count
Requiere: index=proxy con logs de proxy web, index=dns con resoluciones DNS, e index=edr con telemetria de procesos y linea de comandos
wazuhReferencia a DeepSeek en ejecucion de procesos o herramientas de inferencia local 
<rule id="100911" level="5">
  <if_sid>530</if_sid>
  <match>deepseek</match>
  <description>Deteccion conductual: posible uso de modelo o servicio DeepSeek detectado en linea de comandos. Ajustar a contexto del entorno; no implica compromiso.</description>
  <group>ai_supply_chain,deepseek,experimental,</group>
</rule>
Requiere: Modulo de monitoreo de procesos o comando (auditd en Linux, Sysmon en Windows) integrado con el agente Wazuh
Falsos positivos esperables

Estas reglas son de deteccion conductual experimental, no de compromiso: el termino 'deepseek' y el dominio deepseek.com corresponden a infraestructura y producto legitimos del proveedor. Van a generar coincidencias sobre uso autorizado de investigadores, equipos de datos o desarrolladores evaluando el modelo, y sobre menciones de texto no relacionadas con ejecucion real (documentacion, commits, nombres de variable). Usense para construir el inventario de exposicion a modelos de IA y apoyar la indagacion razonable exigida por FAR 52.204-30, no para bloquear automaticamente sin revision humana. Correlacionar con el rol del usuario, el activo y el contexto de negocio antes de escalar cualquier hallazgo.

RS ResponderContencion y erradicacion

Si el inventario identifica un modelo DeepSeek o un derivado en un producto que se vende o se usa en contexto de un cliente con exposición a compras federales de EE.UU., el reloj de cumplimiento corre en días, no en semanas.

  • Documentar el hallazgo: producto afectado, modelo base identificado, nivel de la cadena donde se encontró (propio, subcontratista, proveedor de infraestructura).
  • Si corresponde contractualmente, notificar al oficial de contratos o canal designado dentro del plazo aplicable (reportado como tres días hábiles para el hallazgo, diez días hábiles para el detalle de mitigación).
  • Aislar o reemplazar el componente identificado mientras se evalúa el reemplazo definitivo, evitando una remoción apresurada sin plan de respaldo si el componente es crítico para la operación.
  • Revisar logs de uso del servicio o del modelo (si hubo llamadas a API externas) para descartar exfiltración de datos sensibles durante el período de uso no inventariado.
RC RecuperarVolver a operar y no repetirlo

Reemplazar un modelo no es un cambio neutro: puede alterar el comportamiento del producto, los resultados de evaluación previa y, en contextos regulados, el alcance de una autorización ya otorgada.

  • Evaluar si el modelo de reemplazo cambia el comportamiento funcional, los resultados de evaluación (accuracy, seguridad, sesgo) o el perímetro de autorización del sistema.
  • Actualizar el inventario de modelos y el AI Bill of Materials con el nuevo linaje, y documentarlo en una ficha de modelo (model card) que registre familia base, fuente de ajuste fino y fuente de destilación si aplica.
  • Incorporar la lección al proceso de adquisición de IA: exigir representaciones contractuales de linaje de modelo antes de integrar cualquier proveedor nuevo, no después de un evento regulatorio.

Llévatelo

Lo de arriba explica. Esto se ejecuta. Son archivos, no capturas de pantalla: se abren, se pegan y funcionan.

Una página · PDF Qué hacer esta semana 3 controles de prioridad 1, con checkbox. Para imprimir y llevar a la reunión del lunes. Reglas · TXT Reglas de detección 4 reglas listas para pegar — Sigma, Sentinel, Splunk, Wazuh.

La regla Sigma es la canónica: es el formato neutral del que se derivan las demás. Si tu SIEM no aparece en la lista, esa se convierte con pySigma. Las traducciones a motores concretos van sin validar contra tu modelo de datos — revisa los nombres de tabla y campo antes de subirlas a producción.

Fuentes

¿Esto te aplica y no sabes por dónde partir?

Revisamos tu exposición real frente a lo que describe este análisis: superficie expuesta, cobertura de detección y brechas frente a la Ley 21.663. Diagnóstico de 15 minutos, sin costo.

Agendar diagnóstico

Relacionado

research

Tres plataformas de IA filtran credenciales en ataques encadenados

Fireworks AI, OpenCode y Railway reportaron intrusiones en dos semanas que expusieron llaves de OpenAI, Anthropic y Goog…

23-10-2026
research

Cuatro fallas de octubre exponen el riesgo de custodios de credenciales

OpenCode, Zeabur, UpdraftCentral y la autoridad certificadora eMudhra expusieron en la misma semana credenciales que no…

22-10-2026
research

Filtración en OpenCode Console expone claves de proveedores de IA

El incidente afectó al 1,4% de los usuarios de la consola hospedada y derivó en cargos no autorizados en cuentas de Open…

20-10-2026