Cómo los LLMs están cambiando las operaciones de TI

Hace dos años, integrar un LLM en operaciones de TI era un experimento de laboratorio. Hoy, equipos de SRE y DevOps en empresas reales están usando modelos como GPT-4, Claude y Llama para reducir el tiempo de resolución de incidentes, generar documentación automáticamente y diagnosticar problemas complejos a partir de logs.

Este artículo no es sobre el potencial futuro de la IA en TI. Es sobre lo que ya funciona en producción.

Casos de uso con impacto real

1. Diagnóstico asistido de incidentes

El caso de uso más maduro. Cuando un sistema falla, los equipos de operaciones enfrentan cientos de líneas de logs, métricas dispersas y runbooks desactualizados. Un LLM puede:

• Resumir logs de múltiples fuentes en lenguaje natural
• Identificar patrones anómalos que un operador podría pasar por alto
• Sugerir pasos de diagnóstico basados en el contexto del error

# Ejemplo: enviar logs al LLM para diagnóstico
import anthropic
 
client = anthropic.Anthropic()
 
def diagnose_incident(logs: str, metrics: str) -> str:
    message = client.messages.create(
        model="claude-opus-4-6",
        max_tokens=1024,
        messages=[
            {
                "role": "user",
                "content": f"""Eres un SRE senior. Analiza los siguientes logs y métricas
                e identifica la causa raíz del incidente. Sugiere pasos de remediación.
                
                LOGS:
                {logs}
                
                MÉTRICAS:
                {metrics}
                """
            }
        ]
    )
    return message.content[0].text

Equipos que implementan esto reportan una reducción del 30-40% en MTTR (Mean Time To Resolution).

2. Generación automática de runbooks

Los runbooks son la documentación operacional más valiosa y la más difícil de mantener actualizada. Los LLMs pueden generarlos a partir de:

• Tickets de incidentes históricos resueltos
• Código de scripts de automatización existente
• Diagramas de arquitectura en lenguaje natural

La clave no es reemplazar al ingeniero, sino usar el LLM como primer borrador que el equipo refina y valida.

3. Análisis de configuraciones IaC

Infrastructure as Code tiene la particularidad de que los errores son fáciles de introducir y difíciles de detectar antes del despliegue. Los LLMs son buenos en:

# Terraform con problemas de seguridad
resource "aws_s3_bucket" "data" {
  bucket = "company-data"
  acl    = "public-read"  # ← LLM detecta esto como riesgo
}

Herramientas como Checkov + LLM pueden no solo detectar el problema sino explicar el riesgo y sugerir la corrección en contexto.

4. ChatOps con capacidad de acción

La próxima frontera: LLMs con herramientas (function calling / tool use) integrados en Slack o Teams que pueden ejecutar acciones reales:

• Consultar el estado de servicios en Datadog/Prometheus
• Escalar o reducir recursos en AWS
• Abrir tickets en Jira o PagerDuty
• Ejecutar scripts de remediación aprobados

El patrón más seguro es el "human-in-the-loop": el LLM propone acciones, el operador aprueba con un clic.

Lo que no funciona (todavía)

Toma de decisiones completamente autónoma en producción. Los LLMs alucinan. En un entorno de producción, una acción incorrecta puede costar mucho. Los mejores sistemas mantienen al humano en el ciclo para acciones destructivas.

Diagnóstico sin contexto de arquitectura. Un LLM genérico no sabe cómo está construida tu infraestructura. Los mejores resultados vienen cuando alimentas al modelo con documentación de arquitectura, topologías de red y dependencias de servicios como contexto adicional.

Reemplazar la instrumentación. El LLM es tan bueno como los datos que recibe. Si tus logs son inconsistentes o tus métricas están incompletas, el diagnóstico será deficiente. La observabilidad sigue siendo fundamental.

Stack recomendado para empezar

Para un equipo de TI que quiere empezar a explorar LLMs en operaciones:

Consideraciones de seguridad

Antes de enviar logs e información de infraestructura a un LLM en la nube, considera:

• Sanitización de datos: elimina IPs internas, credenciales, y PII antes de enviar
• Contratos de datos: verifica los términos de uso del proveedor de API
• Modelos locales: para ambientes con datos sensibles, considera Llama 3 o Mistral corriendo on-premises

Conclusión

Los LLMs en operaciones de TI ya pasaron la fase de experimento. La pregunta para los equipos en 2025 no es si explorar esta tecnología, sino por dónde empezar. Mi recomendación: empieza por diagnóstico de incidentes con acceso de solo lectura, mide el impacto en MTTR, y expande desde ahí con base en resultados reales.