IA en operaciones: dónde sí, dónde con permiso y dónde nunca

En los últimos meses, en casi todos los entornos AWS en los que trabajo —ya sean cuentas de producción, de QA o arquitecturas multi-cuenta más complejas— me encuentro con la misma escena: alguien del equipo ya está usando IA para algo operativo, con o sin autorización formal. Un script que resume incidentes, un asistente que redacta el primer borrador de un runbook, una regla que agrupa alertas repetidas. La adopción no espera a que exista una política.

Y eso, en sí mismo, no es un problema. El problema aparece cuando nadie se ha detenido a decidir dónde tiene sentido esa automatización y dónde no. Porque no es lo mismo dejar que un modelo silencie una alerta que sabe reconocer, que dejar que decida si un cambio de configuración se aplica a mitad de la noche en una cuenta compartida por media docena de servicios.

La pregunta que de verdad importa

Cuando toca sentarse a decidir qué automatizar, la pregunta inicial casi nunca es útil: “¿es capaz la IA de hacer esto?”. Hoy, técnicamente, casi siempre la respuesta es sí. La pregunta que sí cambia el resultado es otra: si se equivoca, ¿cuánto tarda alguien en darse cuenta, y qué le cuesta a la operación mientras tanto?

Con esa pregunta como filtro, las tareas empiezan a ordenarse solas en tres grupos.

1. Automatización sin dudarlo: repetitiva, reversible y de bajo impacto

Aquí es donde la IA aporta valor real y el riesgo es mínimo:

• Reducción de ruido en alertas. En cualquier cuenta con cierto volumen, una parte importante de las notificaciones son duplicados, falsos positivos o eventos que se resuelven solos en minutos. Agrupar, correlacionar con despliegues recientes y suprimir patrones ya conocidos (por ejemplo, un job nocturno que dispara la misma alarma cada noche) es de las mejoras más rentables que puede tener un equipo. La condición: el modelo tiene que estar afinado a la operación real, no ser un ajuste genérico —de lo contrario, se cambia un tipo de ruido por otro.
• Primeros borradores de documentación operativa. Runbooks desactualizados son casi una constante en cualquier organización: el documento que era correcto hace dos años y hoy referencia un servicio que ya no existe. Pedirle a un modelo que genere un primer borrador a partir del historial de incidentes y los cambios reales en la infraestructura ahorra horas, siempre que alguien que conoce el sistema lo revise antes de publicarlo.
• Previsión de capacidad y detección de anomalías, como sugerencia. Un pico de tráfico estacional que ocurre una vez al año no le da a un equipo humano suficiente experiencia acumulada; a un modelo entrenado con varios años de esos mismos picos, sí. Aquí el valor está en que la IA proponga y una persona confirme, no en que dispare el escalado por su cuenta.

2. Con acompañamiento: la IA prepara, una persona autoriza

Hay una categoría intermedia que muchos equipos automatizan demasiado rápido: remediaciones concretas y bien delimitadas, como reiniciar un servicio que se queda en un estado conocido, o vaciar una cola cuando supera un umbral definido. Esto puede automatizarse, pero con dos condiciones que no son negociables:

• El caso de fallo tiene que estar definido con precisión y probado, no ser una heurística amplia.
• Tiene que existir un límite de intentos. Si la corrección no funciona en una ventana de tiempo razonable, el sistema escala a una persona en lugar de repetir el mismo intento fallido indefinidamente. Una automatización que insiste en la solución equivocada es peor que no tener automatización.

Lo mismo aplica a los cambios de infraestructura: la IA puede preparar el cambio, contrastarlo contra patrones conocidos e incluso estimar su alcance, pero el momento de ejecutarlo en producción lo decide una persona con nombre y apellido.

3. Nunca sin una persona al mando

Hay decisiones donde el coste de un error no es proporcional al tiempo que se ahorra automatizándolas, y en entornos multi-cuenta ese coste se multiplica: una acción mal calibrada aplicada vía una política o un runbook compartido no afecta a un solo servicio, afecta a todas las cuentas que dependen de esa misma base.

• Clasificar la severidad de un incidente. Marcar un sev-1 real como bajo retrasa la respuesta correcta; marcar como crítico algo menor moviliza a un equipo a las tres de la madrugada sin necesidad. Sea cual sea el criterio, tiene que quedar una persona responsable de esa llamada.
• Incidentes de seguridad. Correlacionar logs para encontrar señal rápido es donde la IA ayuda de verdad. Decidir si se aísla una cuenta, se revoca acceso o se contiene un compromiso activo requiere contexto de negocio y legal que ningún modelo tiene.
• Declarar una causa raíz. Que un modelo señale una correlación entre un despliegue y un cambio en las métricas es un buen punto de partida para investigar; ya escribí sobre por qué el RCA autónomo todavía no llega. Escribir esa correlación como causa confirmada en un postmortem es otra cosa: si es la correlación equivocada, la organización deja de corregir el problema real y este vuelve a aparecer.
• Decidir a quién escalar. Quién está disponible, quién ya lleva dos guardias seguidas, qué otra cosa está en curso en paralelo: es contexto humano que ningún modelo tiene acceso a evaluar bien.

Lo que no se mide y también tiene coste

Hay un efecto que rara vez aparece en la revisión de un incidente concreto, pero que a mediano plazo pesa: si la IA absorbe toda la parte rutinaria, el equipo deja de acumular la experiencia con la que reconoce los casos límite cuando de verdad importan. Y los casos límite son, casi por definición, los que requieren más criterio, no menos. Un equipo que delega demasiado puede funcionar de maravilla durante meses, hasta que aparece algo que no se parece a nada que el modelo —ni las personas— hayan visto antes.

Esto no es un argumento contra automatizar. Es un argumento a favor de decidir, con intención, qué repeticiones estamos dispuestos a dejar de hacer.

Cómo lo abordo en la práctica

Lo que suelo recomendar se resume en unos pocos criterios que conviene fijar antes de que un incidente los fuerce en caliente:

1. Definir por escrito qué categorías de acción puede ejecutar la IA sin supervisión y cuáles necesitan aprobación previa.
2. Que la responsabilidad sobre lo irreversible recaiga siempre en una persona que revisa antes de que se ejecute, no que figure “en el bucle” solo de nombre.
3. Incorporar límites de reintento en cualquier automatización, con escalado automático si no se resuelve.
4. Seguir rotando a las personas por las tareas rutinarias de vez en cuando, aunque la IA ya pueda con ellas, para que esa práctica no desaparezca del equipo.
5. Revisar el límite periódicamente: lo que hoy es un caso bien entendido puede dejar de serlo cuando cambia la arquitectura.

Al final, la pregunta relevante no es si usar IA en operaciones —eso ya está pasando, con o sin permiso—, sino en qué parte del trabajo se usa: donde libera tiempo y reduce ruido, o donde en algún momento va a tener que tomar una decisión que no le corresponde.