Se bienvenido a estas tierras digitales...
...especialmente si eres un molino....
El tercer interruptor: cuando la inteligencia artificial también depende de que otro nos deje pensar

Hace apenas unas semanas desarrollé aquí, en mi blog, las consecuencias de considerar la defensa como servicio: capacidades militares críticas convertidas en suscripciones, comunicaciones tácticas que pueden degradarse o apagarse: ¿qué ocurre cuando el botón de apagado lo tiene otro? En aquel post, la lección era clara: una fuerza armada puede comprar capacidad, pero no debería ceder jamás el control de aquello que compromete su soberanía operativa. (El Quijote Digital)
Antes, al mirar el humilde datáfono de un bar, aparecía el mismo fantasma. Europa cobra en euros, paga impuestos en euros, legisla en Bruselas y presume de mercado único. Pero una parte decisiva del pago cotidiano circula por raíles que no son europeos. Allí formulé otra versión de la misma tesis: Europa no carece de moneda; carece de raíles. Y cuando no se controlan los raíles, tampoco se controla del todo el viaje. (El Quijote Digital)
Pues bien, hoy he leído el artículo de Mari Sako en Communications of the ACM, “The Importance of Geopolitics in AI Development”, y considero que me permite añadir una tercera pieza al tablero: la inteligencia artificial. Y lo inquietante es que, en este caso, el interruptor no está solo en una red de satélites ni en una red de pagos. Está repartido entre chips, centros de datos, energía, talento, capital riesgo, modelos fundacionales, jurisdicciones, controles de exportación y empresas privadas que ya no son simples proveedoras tecnológicas, sino actores geopolíticos de primer orden.
La inteligencia artificial parece intangible. Se presenta como software, como nube, como modelo, como conversación. Pero esa apariencia engaña. La IA tiene cuerpo. Tiene una anatomía material: semiconductores, tierras raras, litografía avanzada, electricidad, refrigeración, fibra óptica, centros de datos, APIs, permisos de uso y cadenas de suministro. Puede que el modelo responda en lenguaje natural, pero antes alguien tuvo que fabricar el chip, alimentar el centro de datos, alojar el modelo, entrenarlo, servirlo y decidir bajo qué condiciones puede utilizarse.
Durante años pensamos la geopolítica como una cuestión de mapas: mares, fronteras, estrechos, gasoductos, puertos, bases militares. La novedad es que el mapa ya no termina en el territorio. La geografía se ha desplazado hacia la infraestructura. La frontera ya no es solo el río, el puerto o la montaña. También es el nodo de cómputo, el firmware del acelerador, el contrato de nube, el régimen de exportación, la cláusula de uso aceptable y la jurisdicción que decide si una empresa puede seguir prestando servicio.
La IA, por tanto, no elimina la geopolítica. La actualiza.Y quizá la hace más incómoda. Porque a diferencia de la carrera nuclear, que fue esencialmente estatal, discreta y militar, la carrera de la IA está impulsada por empresas privadas, capital financiero y adopción social masiva. No hablamos únicamente de laboratorios nacionales ni de arsenales bajo mando gubernamental. Hablamos de compañías que entrenan modelos, plataformas que intermedian capacidades cognitivas, proveedores que empaquetan inteligencia como servicio y ciudadanos, empresas y administraciones que incorporan esos sistemas a sus procesos cotidianos.
Aquí aparece el verdadero cambio de época: los Estados ya no gobiernan solos la infraestructura estratégica. La co-gobiernan, la negocian o la padecen junto a empresas privadas cuyo tamaño, velocidad y capacidad de inversión superan con frecuencia a los aparatos públicos.
Y eso nos devuelve al mismo punto de los dos posts anteriores.
En la defensa como servicio, el riesgo consistía en convertir una capacidad militar crítica en una relación contractual vulnerable. En el datáfono, el riesgo era descubrir que el gesto más cotidiano de la economía —pagar— depende de redes ajenas. En la inteligencia artificial, el riesgo es más profundo: que la capacidad de calcular, automatizar, decidir, clasificar, traducir, detectar, vigilar, defender o innovar quede condicionada por infraestructuras que no controlamos.
No es solo que otro pueda apagarnos un servicio.Es que otro puede decidir qué tipo de inteligencia podemos desplegar.Nos ha pasado ya con FABLE5.
Puede limitar el modelo. Puede modificar sus condiciones. Puede prohibir usos. Puede degradar el acceso. Puede subir precios. Puede retirar una API. Puede cambiar unilateralmente el comportamiento del sistema. Puede cumplir órdenes de otra jurisdicción. Puede condicionar actualizaciones. Puede dejar obsoleta una arquitectura entera mediante una decisión comercial que, desde fuera, parecerá simplemente “producto”.
Y, por supuesto, puede observar.
A estas alturas, conviene evitar la caricatura. No se trata de defender una autarquía tecnológica imposible. Europa, y España en particular, no van a fabricar mañana todos los chips, todos los modelos, todos los centros de datos, todos los sistemas operativos, todas las herramientas de desarrollo y todas las capas de nube que necesita una economía avanzada. Esa fantasía sería tan estéril como peligrosa.
La pregunta madura no es si ¿dependemos o no dependemos?. Todas las sociedades complejas dependen. La pregunta correcta es otra: ¿De qué dependemos, de quién dependemos, bajo qué jurisdicción dependemos y qué ocurre si esa dependencia se convierte en presión?
Ahí empieza la política tecnológica seria.
Lo que el artículo de Sako ayuda a ver es que la rivalidad entre Estados Unidos y China en IA no es solo una competición por tener el modelo con mejor benchmark. Es una competición por controlar los recursos que hacen posible la IA: hardware, energía, datos, talento, capital, ecosistemas empresariales y capacidad de adopción. Estados Unidos juega con una industria privada extraordinariamente fuerte, con capital abundante, con liderazgo en hardware avanzado y con empresas que marcan la frontera de los modelos fundacionales. China juega otra partida: despliegue rápido, eficiencia de costes, adaptación industrial, integración en sectores productivos y una relación mucho más directa entre empresa, Estado y estrategia nacional.
Decir que uno “va por delante” y otro “va por detrás” puede ser tranquilizador, pero quizá no sea del todo correcto. Puede que no estén jugando exactamente al mismo juego. Silicon Valley corre hacia la frontera. China corre hacia la absorción industrial masiva. Uno intenta construir el modelo más avanzado; el otro quiere que la IA se derrame de forma rápida por logística, manufactura, puertos, comercio electrónico, finanzas, vehículo eléctrico, sanidad y administración.
Y Europa, demasiadas veces, observa, regula y compra.
Este es el punto en el que el debate europeo se vuelve incómodo. Europa tiene talento, universidades, industria, mercado, regulación, dinero público y una larga tradición de ingeniería. Pero sigue reaccionando tarde ante las capas críticas. Nos ocurrió con la nube. Nos ocurre con los pagos. Nos ocurre con los semiconductores. Nos ocurre con la defensa. Y corremos el riesgo de que vuelva a ocurrir con la inteligencia artificial.
La respuesta europea instintiva suele ser normativa. Regular el mercado, definir obligaciones, clasificar riesgos, proteger derechos, sancionar abusos. Todo eso es necesario. Pero no basta.
Una norma no entrena un modelo.
Una directiva no fabrica un chip.
Un reglamento no construye un centro de datos.
Una estrategia no sustituye a una cadena de suministro.
Una soberanía declarada en PowerPoint no resiste una interrupción de servicio.
La lección del datáfono sirve aquí perfectamente: Europa no carece de normas; carece de cimientos. Y en inteligencia artificial los cimientos son computación, datos, energía, talento, modelos, seguridad, interoperabilidad, capacidad industrial y control operativo.
La geoeconomía ha convertido la interdependencia en un arma. Durante años, la globalización nos prometió eficiencia: producir donde fuera más barato, computar donde fuera más escalable, pagar donde fuera más cómodo, defendernos con quien innovara más rápido. Pero la eficiencia sin control crea vulnerabilidades. Y las vulnerabilidades estratégicas tienen una propiedad desagradable: casi siempre se descubren tarde, cuando ya no son dependencias, sino palancas de presión.
En ese sentido, los controles de exportación de chips, las restricciones a inversiones, las sanciones tecnológicas, las listas de entidades, las cláusulas de uso de modelos, los vetos a adquisiciones y la localización de centros de datos no son asuntos técnicos marginales. Son la nueva gramática del poder.
La IA no flota sobre la política.
La IA es política computada.
Por eso las grandes tecnológicas ya no pueden ser leídas solo como empresas. Son actores de diplomacia corporativa. Cuando un directivo de una gran compañía de IA habla de China, de seguridad nacional, de inversión, de código abierto o de regulación, no está simplemente opinando. Está posicionando a su empresa ante gobiernos, mercados, inversores y competidores. Está negociando margen de maniobra. Está enviando señales.
Y los Estados, por su parte, tampoco tratan ya a esas empresas como simples proveedores. Las necesitan para sostener liderazgo tecnológico, capacidad militar, productividad económica y ventaja estratégica. De ahí nace una relación ambigua: el Estado regula a la empresa, pero depende de ella; la empresa se presenta como innovadora privada, pero necesita licencias, contratos públicos, protección diplomática y acceso a infraestructuras críticas.
La frontera entre política industrial y política exterior se está borrando.
Y en medio de todo esto aparece España.
Para España, la pregunta no debería ser si podemos competir mañana con Estados Unidos o China en modelos fundacionales gigantes. Esa no es la única métrica. La pregunta debería ser más concreta, más estratégica y más útil:
¿Qué capacidades mínimas de IA necesita controlar España para no quedar sometida a decisiones ajenas en defensa, administración pública, sanidad, justicia, educación, infraestructuras críticas, agricultura, industria y ciberseguridad?
No todas las capas son igual de sensibles. No todo requiere soberanía absoluta. Pero algunas cosas no deberían cederse sin más. Los datos críticos, las claves, la infraestructura troncal, los entornos de inferencia en usos sensibles, los modelos aplicados a seguridad nacional, los sistemas de auditoría, los mecanismos de continuidad operativa, los contratos de reversibilidad, la capacidad de migrar, la trazabilidad de actualizaciones y la posibilidad real de operar en modo degradado si el proveedor falla o se retira.
La soberanía tecnológica no consiste en hacerlo todo solo.
Consiste en saber qué no puedes permitirte perder.
Aplicado a la IA, eso significa que una administración pública no debería introducir modelos externos en procesos sensibles sin preguntarse dónde se procesan los datos, bajo qué jurisdicción, con qué garantías de auditoría, con qué dependencia contractual, con qué posibilidad de desconexión y con qué alternativa si el proveedor cambia las reglas.
En este sentido, vuelvo a traer aquí mi intervención en el Parlamento de Andalucía alertando sobre la necesidad de revisar previamente los modelos: https://www.noticiasdealmeria.com/profesor-de-la-ual-advierte-de-los-riesgos-del-chatgpt
Una empresa estratégica no debería automatizar decisiones críticas sobre una API que mañana puede encarecerse, degradarse o desaparecer. Un sistema de defensa no debería depender de un modelo cuyo comportamiento, pesos, telemetría o filtros de uso no controla. Una universidad no debería formar talento solo para consumir plataformas ajenas, sino también para comprender, auditar, desplegar y gobernar tecnología.
En definitiva: usar IA no es lo mismo que tener capacidad en IA.
Europa confunde a menudo adopción con soberanía. Que una empresa europea use herramientas de IA no significa que Europa tenga una industria de IA. Que una administración contrate una solución en la nube no significa que el Estado haya ganado capacidad digital. Que una pyme automatice tareas con un modelo extranjero no significa que el tejido productivo haya reducido su dependencia. Puede incluso haberla incrementado, solo que de una forma más cómoda y menos visible.
Esto es lo peligroso de los interruptores modernos: no parecen interruptores.
Parecen servicios.
Parecen eficiencia.
Parecen innovación.
Parecen experiencia de usuario.
Parecen un datáfono que pita, un satélite que conecta, un chatbot que responde.
Pero cuando llega la crisis, se revelan como lo que eran: puntos de control.
El futuro de la inteligencia artificial no se decidirá solo en los laboratorios. Se decidirá también en los ministerios de industria, en las agencias de ciberseguridad, en los presupuestos de defensa, en los contratos de nube, en las universidades, en los centros de datos, en las redes eléctricas, en las políticas de compra pública, en la formación profesional, en los estándares abiertos y en la valentía de llamar infraestructura crítica a lo que ya funciona como infraestructura crítica.
La IA será una tecnología de propósito general, sí. Pero precisamente por eso no puede tratarse como una aplicación más. Si va a atravesar todos los sectores, todos los sectores quedarán expuestos a su geopolítica. Agricultura, logística, banca, energía, transporte, defensa, salud, educación, justicia y administración pública no dependerán solo de “software inteligente”. Dependerán de quién controle las condiciones materiales de esa inteligencia.
Y aquí conviene cerrar el círculo.
En el datáfono descubrimos que pagar era una cuestión de poder.
En la defensa como servicio descubrimos que comunicar en combate era una cuestión de soberanía.
En la inteligencia artificial estamos descubriendo que computar, decidir y automatizar también lo son.
El error sería pensar que hablamos de tres problemas distintos. No lo son. Son tres manifestaciones de la misma renuncia: aceptar que las capas críticas de la vida económica, militar y cognitiva queden gobernadas por infraestructuras que no controlamos, con la esperanza de que nunca se usen contra nosotros.
Pero la esperanza no es una estrategia industrial.
La comodidad no es soberanía.
La regulación no es capacidad.
Y contratar inteligencia no equivale a poseer criterio.
Europa necesita IA, desde luego. Necesita usarla, regularla, auditarla y desplegarla. Pero, sobre todo, necesita construir las condiciones para que su uso no dependa siempre de un permiso externo. Necesita nube, chips, modelos, datos, energía, talento y empresas capaces de operar bajo jurisdicción europea. Necesita cooperación público-privada, sí, pero con una línea roja clara: se puede externalizar capacidad auxiliar; no se puede externalizar el control de las funciones que sostienen la autonomía política, económica y estratégica.
Porque el tercer interruptor no está en un único botón.
Está en todas partes.
En el chip que no llega.
En el centro de datos que no es nuestro.
En la API que cambia.
En el modelo que se retira.
En la licencia que se restringe.
En la inversión que se redirige.
En la cláusula que nadie leyó.
En la jurisdicción que no responde ante nuestros ciudadanos.
Y quizá esa sea la gran lección de esta nueva geopolítica de la inteligencia artificial: el poder ya no consiste solo en conquistar territorio, ni siquiera en controlar rutas comerciales. Consiste en decidir quién puede computar, con qué medios, bajo qué reglas y durante cuánto tiempo.
De poco sirve tener excelentes científicos, magníficas empresas y una administración deseosa de modernizarse si, llegado el momento decisivo, la pregunta fundamental no la respondemos nosotros.
¿Puede Europa pensar con sus propias máquinas?
¿Puede España defenderse, producir, investigar, pagar y decidir sin pedir permiso tecnológico a terceros?
¿O hemos confundido acceso con soberanía?
La respuesta, como tantas veces en esta historia, no estará en los discursos. Estará en los raíles, en los satélites, en los chips, en los centros de datos, en las claves, en los contratos y en las manos que sujetan el interruptor.
Externalizar capacidad, sí.
Externalizar el control, jamás.
En octubre de 2022, en plena contraofensiva ucraniana, varios drones submarinos cargados de explosivos se aproximaban a la flota rusa fondeada en Sebastopol. A unos setenta kilómetros del objetivo perdieron el enlace: la red de satélites Starlink que debía guiarlos no estaba activa sobre Crimea, y su propietario se negó a activarla. La decisión no la tomó un gobierno ni un mando militar. La tomó Elon Musk¹. Tomad buena nota, la decisión operativa cayó en manos de una empresa.

La cuestión de fondo es cuando se define la «defensa como servicio» (Defense-as-a-Service).² Del mismo modo que las empresas dejaron de comprar servidores para alquilar software en la nube, los ejércitos empiezan a dejar de adquirir capacidades para alquilarlas. La Royal Navy británica externaliza ya tareas de vigilancia antisubmarina, y Estados Unidos diseña sus sistemas de gestión del campo de batalla como suscripciones; los drones, el reconocimiento y, sobre todo, las comunicaciones, se ofrecen empaquetados, actualizables y facturables por uso.
La disuasión ya no reside en el armamento, sino en la capacidad de innovar más rápido que el adversario. Ucrania lo ha demostrado: gana terreno quien itera su tecnología en semanas, no quien tarda décadas en homologar una plataforma. Los Estados son lentos; el mercado, veloz. Y ningún ministerio de Defensa puede replicar por sí solo el ritmo de innovación de la industria civil.
Pero hay una pregunta que la lógica del «como servicio» tiende a esconder, y que conviene formular sin rodeos: ¿qué ocurre cuando lo que has alquilado deja de funcionar en el peor momento posible?
El caso de Sebastopol no es una anécdota de Silicon Valley. Es la radiografía de un riesgo estructural. Cuando una capacidad militar crítica se externaliza, no se externaliza solo el equipo: se externaliza la decisión sobre su uso. Quien controla la infraestructura controla el interruptor. Y ese interruptor (el kill switch, os recomiendo la lectura sobre la pérdida de soberanía que publiqué el 20 de mayo) puede accionarse por motivos comerciales, por presión política de un tercer país o, sencillamente, porque los intereses del proveedor dejan de coincidir con los nuestros. El riesgo de este modelo es que se depende de tecnología que puede retirarse. Lo que se contrata, se puede descontratar.
En ningún dominio es esto más peligroso que en el de las comunicaciones tácticas. Una fuerza armada sin comunicaciones no es una fuerza degradada: es una fuerza ciega, muda y descoordinada. Las comunicaciones son el sistema nervioso de cualquier operación; por ellas circulan las órdenes, la posición de las unidades, la imagen del campo de batalla y, no lo olvidemos, datos extraordinariamente sensibles sobre nuestras propias vulnerabilidades. Ceder esa capa a un proveedor extranjero equivale a entregarle, simultáneamente, tres llaves: la de cortar el servicio, la de degradarlo selectivamente y la de observar cuanto por él transita. Desde la ciberseguridad, esto tiene un nombre técnico preciso: hemos convertido nuestra cadena de mando en un único punto de fallo bajo gobierno ajeno, y hemos ampliado nuestra superficie de ataque hasta los servidores, las actualizaciones y la voluntad de una empresa sobre la que no tenemos jurisdicción.

Conviene aquí evitar el error contrario, igual de costoso: el autarquismo. No se trata de fabricar cada componente en territorio nacional ni de renunciar a la innovación que ofrece la industria. El planteamiento maduro no es externalizar o no externalizar, sino dónde se traza la línea de lo que jamás se cede.
Estados Unidos lleva esa línea escrita desde 1998 en su Federal Activities Inventory Reform Act, que distingue las funciones inherentemente gubernamentales (las que comprometen el ejercicio del poder soberano) de aquellas que pueden contratarse.² Es exactamente la doctrina que España y Europa necesitan trasladar a su política de defensa con criterio técnico, no solo presupuestario. Aplicada a las comunicaciones tácticas, esa frontera es nítida: se puede comprar capacidad, pero no se cede el control. Las claves criptográficas, el código fuente, la infraestructura troncal, la gestión del espectro y el botón de encendido son soberanía, y la soberanía no se subcontrata.
La buena noticia es que España y la Unión Europea no parten de cero. Disponemos de los mimbres para hacerlo bien: la constelación europea IRIS³ y el programa GovSatCom (concebidos de forma explícita para garantizar la autonomía estratégica y la soberanía digital de la UE) como alternativa a una conectividad por satélite hoy dominada por actores estadounidenses;⁴ una industria nacional capaz (de Indra a GMV, de Hispasat al INTA) de desarrollar radio definida por software (SDR), redes resilientes y criptografía propia; y un nuevo ciclo de inversión en defensa que, bien orientado, puede financiar autonomía en lugar de comprar dependencia. La pregunta no es si tenemos los recursos, sino si tendremos el criterio para gastarlos en capacidad bajo control y no en comodidad bajo riesgo.
Porque la lección de Sebastopol es, en el fondo, muy española y muy quijotesca: de poco sirve la mejor armadura si la decisión de bajar la visera la toma otro. La defensa como servicio puede ser una herramienta magnífica para innovar al ritmo del adversario. Pero el día que de verdad importe, querremos que el interruptor de nuestras comunicaciones esté en una mano que responda ante los ciudadanos españoles, y no en la de un consejero delegado que decide, desde su despacho, qué guerras se libran y cuáles no.
Este, tecnología-defensa-soberanía es el motivo por el que este año he llevados a mis estudiantes de Periféricos e Interfaces (Universidad de Almería) a Tecnobit.
Externalizar capacidad, sí. Externalizar el control, jamás.
Notas
¹ Elon Musk reconoció después que se negó a activar Starlink sobre Crimea por temor a ser cómplice de un acto «mayor» de guerra; precisó que la red no estaba operativa en la zona y que no la activó, más que haberla «apagado». Cf. «Musk stopped Ukraine attack on Russian fleet with Starlink refusal», NBC News, 7-9-2023,https://www.nbcnews.com/news/world/musk-stopped-ukraine-attack-russian-fleet-starlink-rcna104019 y la verificación de Snopes, https://www.snopes.com/news/2023/09/14/musk-internet-access-crimea-ukraine/
² Federal Activities Inventory Reform (FAIR) Act of 1998, Public Law 105-270, firmada el 12 de octubre de 1998. Texto íntegro: https://www.congress.gov/105/plaws/publ270/PLAW-105publ270.pdf ; sobre la definición de función «inherentemente gubernamental», cf. la implementación de la OMB, https://clintonwhitehouse5.archives.gov/textonly/OMB/fedreg/fair-act.html
³ IRIS² (Infrastructure for Resilience, Interconnectivity and Security by Satellite): constelación de 290 satélites dotada con 2.400 millones de euros en el marco financiero 2021-2027, concebida para garantizar la autonomía estratégica y la soberanía digital de la UE e integrada con el programa GovSatCom. Comisión Europea, https://defence-industry-space.ec.europa.eu/eu-space/iris2-secure-connectivity_en ; y «EU launches government satcom program in sovereignty push», SpaceNews, https://spacenews.com/eu-launches-government-satcom-program-in-sovereignty-push/
Un molino llamado SMI: leer un BSOD con una IA local cuando el culpable no está donde Windows dice (CASO II)
PC confidencial que «falla aleatoriamente»
Workstation Intel reciente con SGX habilitado, Windows 11, perfil de uso mixto: durante la jornada cargan enclaves para servicios de atestación remota, un runtime confidencial basado en el Intel SGX SDK, y un cliente de juegos que en sus ratos libres invoca un anticheat también basado en enclaves. Por encima de todo eso, la imagen corporativa ha instalado un agente de seguridad EDR con un módulo comercial. El usuario reporta:
- BSOD intermitentes, dos o tres por semana, sin coincidir nunca con la misma aplicación en foco.
- Bug check siempre el mismo:
0x133(DPC_WATCHDOG_VIOLATION). - Una correlación que sólo aparece después de mirar mucho: los crashes son más probables durante sesiones largas con enclaves activos. No es determinista; es una distribución sesgada.
El primer reflejo es revisar drivers gráficos (y en mi experiencia cabe destacar un crash importante en un servidor de BB.DD. al actualizar los drivers gráficos, allá por el año 2000, asi que no es extraño sospechar), de red y de almacenamiento. El segundo (también malo) es pasar el verifier.exe en modo paranoico, lo que dispara más BSODs sin acercar la respuesta. El tercero (el útil) es preguntarse qué dice exactamente WER.
Abrimos CrashDetectorwithAI tras el siguiente crash. La aplicación presenta de forma estructurada algo equivalente a esto:
Crash event detected
─────────────────────────────────────────────
EventID: 1001 (BugCheck)
BugCheckCode: 0x00000133
Parameters: 0x0000000000000000
0x0000000000000501
0x0000000000000500
0xFFFFF80712345678
FaultBucketId: 0x133_0_nt!KeAccumulateTicks
ReportSignature: BlueScreen / 133 / nt / 10.0.26100.xxxx
WHEA records: none in last 5s
Minidump: C:\Windows\Minidump\051826-…dmp
Y, debajo, la respuesta del modelo local (Phi-4 vía ONNX) en streaming, que viene a decir, con palabras propias y prudentes, algo como:
Se trata de un
DPC_WATCHDOG_VIOLATION. El parámetro 1 con valor0indica que se ha superado el umbral acumulado de DPC en un solo procesador. Los valores0x501y0x500son los ticks observado y permitido, expresados en unidades del kernel. La dirección final apunta ant!KeAccumulateTicks, lo cual es habitual: el watchdog se dispara desde la contabilidad de tiempo del kernel, no desde la DPC culpable. Causas frecuentes: driver con DPC excesivamente larga, problema de firmware/BIOS que bloquea la CPU, o controlador de almacenamiento (storport/NVMe) bajo presión. Recomendaciones iniciales: actualizar BIOS, drivers de chipset y de almacenamiento; revisar utilidades de fabricante que interactúen con el firmware; ejecutar LatencyMon en estado normal de uso.
El culpable: una suite de seguridad SGX-aware que abusa de SMM
En el caso real que motiva este artículo, el responsable resultó ser un patrón más sutil que el clásico abuso de SMI por una utilidad de fabricante. La cadena fue ésta:
- El driver kernel-mode del agente EDR ejecuta cada 5–8 segundos una secuencia que termina escribiendo en una MSR registrada por el firmware como gatillo de software SMI. La razón nominal es muestrear el estado de los enclaves cargados: número, identidad, signature hash, y la última información de la atestación.
- El handler SMI correspondiente, alojado en SMRAM, hace dos cosas distintas. Primero, lee un puñado de MSRs relacionados con SGX (
IA32_SGXLEPUBKEYHASH0..3,IA32_FEATURE_CONTROL, revisión de microcódigo, indicadores de SGX2). Esa parte es barata: decenas de microsegundos. Segundo, y aquí es donde el handler pierde la inocencia, consulta a Intel Management Engine vía la interfaz HECI/MEI para validar el estado de las claves de atestación. Esa consulta puede gastar entre 5 y 15 ms según lo que ME esté haciendo en su propio dominio, que el SO ni ve ni controla. - A la vez, cada SMI invocado mientras hay enclaves activos provoca un Asynchronous Enclave Exit en cada núcleo donde un enclave estuviera en ejecución. Recordemos lo establecido en la entrada del 15 de mayo: SMM no puede leer el EPC, pero la transición no es gratuita. Cada AEX implica salvar el estado del enclave en la SSA, sustituir los registros visibles por valores sintéticos, y, al volver, un
ERESUMEque cuesta del orden de 50–200 µs por núcleo afectado. - Multiplicado por la cadencia observada de 8–15 SMIs por segundo (los
116 / 10sque vimos en MSR0x34), y por dos o tres enclaves activos durante la jornada, el sistema acumula ventanas SMM que en el peor caso, cuando ME está contendido por sus propias tareas de fondo, superan el umbral del DPC watchdog y disparan el0x133.
Lo elegante de este patrón es doble. Por un lado, WER no puede ver nada de lo anterior: el handler vive en firmware, la consulta a ME ocurre fuera del espacio observable por el kernel, y el AEX se resuelve antes de que el SO siquiera registre que la SMI ha existido. El bucket dice nt!KeAccumulateTicks y se queda tan tranquilo. Por otro lado, el coste indirecto sobre el rendimiento de los enclaves SGX (la degradación silenciosa que no llega a BSOD pero ralentiza cualquier carga confidencial seria) es invisible para el equipo de seguridad que opera la suite: ellos miden el coste de su agente en espacio de usuario, donde la huella es un servicio que consume 20 MB de RAM y 0,3% de CPU. La factura real, pagada en latencia SMM y en throughput de enclave, queda fuera de su panel.
La resolución, una vez identificado el patrón, es proporcional:
- Desactivar el módulo SGX Visibility del EDR en la consola del agente. El resto del EDR (detección de comportamiento, prevención de ejecución, telemetría kernel-mode) puede mantenerse intacto. La «visibilidad sobre enclaves» que se pierde con esto es, en la práctica, decorativa: el agente no podría inspeccionar el EPC ni aunque tuviese privilegio para hacerlo.
- Si el equipo de seguridad necesita esa visibilidad por requisitos de compliance, migrar a herramientas basadas en DCAP (Data Center Attestation Primitives, parte del SGX SDK de Intel). DCAP expone el estado de los enclaves desde kernel-mode sin atravesar firmware: el coste, para el plano de la plataforma, es despreciable.
- Para casos OEM con handlers HECI generosos, actualización de firmware a una versión donde la consulta a ME se difiera, se cachee o se agrupe.
- Verificación posterior: el MSR
0x34cae por debajo de 1 SMI/s en idle, LatencyMon vuelve a verde, el contador de AEX expuesto por el SGX SDK deja de mostrar correlación con la actividad del agente, y los0x133desaparecen del Visor de Eventos.
Referencias
- Entrada relacionada en este blog: Forense de memoria en SGX ante sospecha de intromisión vía SMI (15 mayo 2026).
- Entrada relacionada en este blog: Un molino llamado SMI: leer un BSOD con una IA local cuando el culpable no está donde Windows dice (CASO I) (18 mayo 2026).
