01 El cambio del dashboard al agente
Durante quince años la promesa de digitalización en data centers fue dashboards mejores. Más gráficos, más heatmaps, más correlaciones automáticas. El operador, al final, seguía siendo quién tomaba la decisión y ejecutaba el comando.
El cambio que está ocurriendo en 2025-2026 es un cambio de naturaleza, no de grado: los agentes de IA llegan a la posición del operador que toma decisiones rutinarias y ejecuta comandos sobre el equipo crítico, con humanos supervisando excepciones. Esto no es ciencia ficción — ya hay sistemas en producción en hyperscalers— pero tampoco es un reemplazo total del operador. Es una redefinición del trabajo.
02 Casos públicos: lo que ya pasó
El caso más documentado públicamente es el de DeepMind en data centers de Google. En 2016 anunciaron una reducción de 40 % en consumo de enfriamiento aplicando un modelo de aprendizaje profundo a setpoints —equivalente a una mejora de aproximadamente 15 % en PUE. En 2018 el sistema dejó de ser recomendaciones para un operador y pasó a controlar directamente bajo supervisión humana. Hoy opera en múltiples sitios de Google con ocho mecanismos de seguridad de respaldo.
Microsoft ha reportado públicamente experimentos similares en sus data centers Azure, con énfasis en gestión de carga térmica y mantenimiento predictivo. Los detalles técnicos son menos abiertos pero la dirección es la misma.
Esto significa para un operador mexicano dos cosas: primero, que las pruebas de concepto ya existen y están validadas. Segundo, que la arquitectura segura también está entendida — el patrón de múltiples capas de seguridad, supervisión humana y rollback automático es el que aplica.
03 Anatomía de un agente de operación
Un agente de operación crítica seria tiene cinco componentes:
1. Capa de observación
Lectura del BMS en tiempo real, más contexto del CMMS (qué equipos están en mantenimiento), DCIM (carga actual versus capacidad), pronóstico meteorológico para 24-72 horas y tarifa eléctrica por período. El agente no opera en ciego.
2. Capa de razonamiento
Modelos de lenguaje grandes (LLMs) afinados con manuales operativos del sitio, más modelos específicos para predicción (carga térmica esperada, PUE objetivo, riesgo de falla por equipo). El razonamiento no es opaco; cada decisión queda explicada con las variables que la respaldan.
3. Capa de política de seguridad
Reglas duras inviolables. Ejemplo: nunca subir setpoint de chilled water arriba de 14 °C sin aprobación humana, nunca apagar más de un CRAH redundante a la vez, nunca cambiar configuración eléctrica crítica. Esta capa veta cualquier acción del razonamiento.
4. Capa de ejecución con audit log
Comandos firmados al BMS vía APIs o protocolos nativos (BACnet, Modbus). Cada comando queda registrado con timestamp, usuario (en este caso el agente identificado), valor anterior, valor nuevo y motivo. Inmutable.
5. Capa de rollback
Si la condición esperada después de un comando no se materializa en N segundos, el sistema revierte automáticamente. Esto exige que el agente formule hipótesis verificables, no solo decisiones.
04 Tres niveles de autonomía
El espectro de agentes va de sugerencias a control directo. En la práctica de operación crítica, conviene pensar en tres niveles claramente separados:
| Nivel | Lo que hace | Dónde aporta | Dónde NO entrar |
|---|
| L1 — Asistencia | Sugiere acciones, redacta tickets, escribe reportes | Reducir tiempo administrativo, capturar conocimiento | No tiene acceso a comandos |
| L2 — Control supervisado | Ejecuta comandos rutinarios con aprobación humana de pantalla | Optimización de eficiencia, programación de mantenimientos | Cambios eléctricos críticos, fail-over |
| L3 — Autónomo limitado | Ejecuta dentro de bandas pre-autorizadas, escala fuera | Setpoints térmicos, distribución de carga entre CRAHs | Cambios eléctricos, mantenimientos, gestión de incidentes graves |
El error común es saltar directo a L3. El camino seguro es L1 durante 3-6 meses para construir confianza y dataset, después L2 en un subconjunto de variables menos críticas, después L3 en un dominio acotado (típicamente enfriamiento). Esto es lo que hizo Google a lo largo de varios años.
05 Riesgos reales y cómo se mitigan
Hay cuatro categorías de riesgo que un Facility Manager serio debe entender antes de meter un agente a operación crítica:
Riesgo 1: Alucinación y razonamiento incorrecto
Los LLMs pueden producir explicaciones plausibles que no se sostienen. La mitigación no es confiar en el LLM; es verificar cada decisión contra reglas duras (cap de seguridad) y contra modelos específicos del dominio. El LLM razona, pero no decide solo.
Riesgo 2: Adversario o falla de instrumentación
Un sensor que comienza a dar valores extraños puede llevar al agente a tomar decisiones equivocadas. La mitigación es redundancia de sensores críticos, detección de outliers contra historial y degradación graceful (si los sensores no convergen, el agente devuelve control al humano y mantiene la última configuración estable).
Riesgo 3: Concentración de decisión
Si un agente opera múltiples sitios y comete un error sistemático, el daño es paralelo. La mitigación es deployment por sitio con diferencias controladas, no flota uniforme.
Riesgo 4: Erosión del conocimiento humano
Si el agente hace las cosas y los operadores ya no las practican, en 18 meses el equipo no sabe operar el sitio manualmente. La mitigación es práctica programada con el agente en modo asistencia, no autónomo, durante turnos específicos.
El riesgo que casi nadie nombra. El riesgo legal y de SLA. Si el agente comete un error, quién responde frente al cliente y frente al regulador. Esto debe estar en contrato con el proveedor de la plataforma y en póliza de responsabilidad civil del operador. Hoy es zona gris en México; conviene definirla en el momento de firmar.
06 Cómo se integra con un BMS legado
La pregunta operativa práctica es: tengo un BMS de hace 8 años con protocolos mixtos, ¿cómo entra un agente?
Patrón recomendado
- Capa de lectura no intrusiva — el agente lee del BMS por SNMP, BACnet read-only o un mirror de la base de datos del BMS. Esto no requiere tocar el BMS.
- Capa de comando vía interfaz autenticada — las acciones se ejecutan a través de la interfaz autenticada del BMS (API si la tiene, o terminal con usuario y bitácora). El BMS sigue siendo la fuente de verdad.
- Sandbox de prueba — antes de cualquier comando real, el agente prueba en un digital twin del sitio o en un sitio piloto con menor criticidad.
- Audit log paralelo — el agente mantiene su propio audit log, reconciliable con el del BMS, para responder a auditoría sin depender de un solo log.
Esto evita el patrón clásico de "rip and replace" que casi nunca termina. Un agente serio convive con el BMS legado durante años y, en la medida que el equipo crece confianza, asume más capas.
07 Lo que viene en 12-24 meses
Tres tendencias que vale seguir si va a operar infraestructura crítica en México en los próximos dos años:
Agentes multi-sitio coordinados
Un agente que gestione una flota de edge data centers (50-500 kW por sitio) tomando decisiones de balanceo y mantenimiento coordinadas. Esto baja el costo por sitio y es donde la economía de los agentes empieza a tener mucho sentido.
Operación con tarifa dinámica
En México, con suministro calificado y mercados spot, un agente que opera reactivos y demanda contra precio horario puede ahorrar entre 5 y 15 % sobre la factura eléctrica. El requisito es integración con el ISO (CENACE) y modelo de pronóstico de precio.
Audit log verificable criptográficamente
Para regulación y SLA, audit logs que pueden probarse no han sido manipulados (firmados con cadena de hash, ancla externa) serán requisito en contratos de colocation con clientes serios. Esto ya empieza a aparecer.
La pregunta técnica que nos hacen más seguido. ¿Cuándo es el momento correcto para introducir un agente? Respuesta corta: cuando ya tiene instrumentación suficiente para que un humano opere bien, un agente también. Si su BMS hoy entrega datos cada 15 minutos y no hay audit log, primero arregle eso. El agente sobre un cimiento débil multiplica los problemas, no los resuelve.
El cambio en el perfil del equipo
Una pregunta que casi nadie hace al inicio y que aparece al año: cómo cambia el equipo que opera el sitio cuando hay un agente. La respuesta honesta es que el head-count baja menos de lo que el vendedor de IA promete y el perfil sube más de lo que se anticipa. En operaciones que ya tienen agente, los Facility Managers reportan que dejaron de contratar ingenieros junior para guardias y empezaron a contratar perfiles mixtos: alguien que entiende termodinámica de chillers y a la vez puede revisar las explicaciones del agente y detectar cuándo no cuadran.
Eso es un cambio de mercado laboral con implicaciones de costo y de capacitación. Conviene pensar en planes de upskilling para el equipo actual antes de que el agente llegue.
Lo que medir antes y después
Cualquier piloto serio de agente debe tener una línea base bien construida con seis meses de datos previos a la introducción. Las métricas que importan: PUE acumulado, número de incidentes por mes, MTTR promedio, número de cambios de setpoint manuales por semana, tiempo de FM dedicado a tareas administrativas. Sin esta línea base es imposible distinguir la mejora atribuible al agente del ruido natural de operación. Y ese ruido es grande — un sitio bien operado tiene meses buenos y meses malos sin ninguna intervención.
El cálculo económico que conviene hacer
Para un sitio de 1 MW operando en GDMTH con un PUE actual de 1.55, un agente que estabilice el PUE en 1.45 ahorra del orden de varios cientos de miles de pesos al año solo en energía, dependiendo de la región y de la mezcla de horario. Sumando reducción de incidentes, reducción de mantenimiento correctivo y tiempo de FM liberado, el caso de negocio cierra en 18-30 meses para sitios medianos y antes para hyperscalers. Para sitios chicos (menos de 200 kW), el costo del agente puede no justificarse aún; ahí lo razonable es esperar a la oleada de agentes multi-sitio que llegan al mercado.
¿Operas infraestructura crítica?
Cuéntanos qué corres en una llamada técnica de 30 minutos sin slides. Diagnóstico, no demo.
Agenda llamada técnica →