Gestión de operaciones de IA

Las operaciones gestionadas de IA no se pueden dirigir con una lista de modelos. Recorremos cada flujo en producción desde el disparador hasta el resultado: quién lo inicia, qué instrucciones y fuentes de conocimiento utiliza, qué proveedor y versión intervienen, a qué herramientas y cuentas accede, qué datos atraviesan cada límite, dónde una persona aprueba o corrige una acción y qué registro posterior acredita que el trabajo terminó. El inventario también recoge tareas programadas, rutas de respaldo silenciosas, pasos manuales y copias paralelas que ya no coinciden con el diseño original.

Cada elemento recibe un objetivo de negocio, un responsable funcional y otro técnico, un nivel de riesgo, condiciones válidas de funcionamiento y una forma documentada de pausarlo, reducir su autonomía o retirarlo. Fijamos versiones cuando el proveedor lo permite y registramos la variabilidad cuando no es posible. La referencia inicial incluye errores conocidos, latencia, coste, correcciones humanas, antigüedad del conocimiento, permisos, límites de terceros e incidentes abiertos. Si los datos no permiten afirmar que algo está sano, dejamos visible esa carencia en lugar de convertirla en una cifra tranquilizadora.

La monitorización de agentes de IA debe seguir una ejecución a través de llamadas al modelo, recuperación de contexto, uso de herramientas, aprobaciones, reintentos y registro final de negocio. Un identificador de correlación une flujo y versión, estados de inicio y cierre, latencia, consumo del modelo, resultado de cada herramienta, número de intentos, decisión de política, intervención humana y clase de error. Cuando la plataforma lo admite, trazas, métricas, registros y eventos comparten una nomenclatura coherente. Así se distingue una caída del conector de una respuesta deficiente, una acción correctamente bloqueada o un tiempo de espera del proveedor.

Observabilidad no significa guardar indefinidamente cada prompt, documento de cliente o argumento de herramienta. Antes de instrumentar identificamos datos personales, credenciales, secretos empresariales y registros sujetos a regulación. Después aplicamos minimización, enmascarado, acceso por función, conservación y borrado adecuados al entorno. Las decisiones de muestreo y ocultación se documentan porque limitan lo que podrá demostrarse en una investigación. El panel general muestra el estado del servicio; la evidencia sensible queda en una ruta de auditoría con acceso restringido.

Cada flujo gestionado necesita un conjunto de evaluación derivado de su trabajo real. Debe incluir casos habituales, errores costosos, límites de permisos, entradas ambiguas, variantes lingüísticas cuando correspondan e incidentes aprendidos en producción. Los criterios pueden combinar comprobaciones deterministas, respuestas de referencia, reglas de negocio y juicio humano cualificado. Versionamos la entrada, el comportamiento esperado, el evaluador, la lógica de puntuación y sus limitaciones. Un porcentaje genérico de precisión no representa un sistema que también debe negarse, escalar, respetar un esquema y elegir la herramienta correcta.

Todo cambio entra en una cola con motivo, propietario, flujos afectados, riesgo y ruta de reversión. Antes de publicar, el conjunto pertinente se ejecuta contra la versión actual y la candidata. Un cambio de mayor impacto puede exigir reproducción en ensayo, ejecución en sombra, tráfico limitado o aprobación explícita. Después de la publicación observamos indicadores equivalentes para detectar regresiones. Una actualización o retirada del proveedor también es un cambio, aunque NobleJackal no la haya iniciado; cuando el comportamiento no puede fijarse, esa incertidumbre forma parte de la decisión operativa.

La gravedad se determina por el impacto. El retraso de un resumen interno no se gestiona como el fallo de un agente capaz de enviar comunicaciones, modificar una ficha de cliente, revelar datos protegidos o iniciar un pago. Acordamos por escrito severidad, rutas de detección, responsable de respuesta, comunicación y criterios de recuperación. Los procedimientos separan contención y corrección: revocar una credencial, pausar el flujo, volver a revisión manual, recuperar una versión de conocimiento, desactivar un modelo o mantener el trabajo en cola hasta que vuelva una dependencia. Los tiempos de respuesta solo se aplican dentro del horario contratado.

Tras un incidente relevante no culpamos únicamente a la última frase generada. Revisamos instrucciones, contexto recuperado, identidad y permisos, validación de argumentos, comportamiento de integraciones, decisión humana, carencias de telemetría y cambios del proveedor. La medida correctora puede ser un prompt, pero también reducir un permiso, añadir aprobación, validar una herramienta, cambiar una regla o retirar el flujo. Cuando sea lícito y técnicamente viable, el caso pasa al conjunto de regresión. Una excepción repetida no se da por resuelta porque un reintento acabara funcionando.

La frecuencia de trabajo responde al riesgo y al volumen, no a la necesidad de producir un informe vistoso. Las alertas de alto impacto se atienden cuando se producen dentro del periodo contratado. La revisión periódica estudia incidentes, evolución de evaluaciones, correcciones humanas, vigencia del conocimiento, cambios de proveedor, latencia, consumo y riesgos abiertos. El registro explica qué se modificó, qué se dejó igual y por qué. En cada hito también se revisa si el flujo sigue justificando su coste, si conviene aumentar o reducir autonomía y si otro modelo, herramienta o proceso manual resolvería mejor el trabajo.

Por eso la propuesta de Gestión de Operaciones de IA identifica sistemas, entornos, horarios, canales, niveles de severidad, objetivos de respuesta y restauración, capacidad de cambio incluida, cadencia de informes, obligaciones del cliente y exclusiones. Los costes de modelos, nube, observabilidad y licencias solo se incluyen si se enumeran. Los flujos nuevos, rediseños mayores, urgencias fuera de horario y certificaciones de cumplimiento no se añaden de forma implícita. El plan de salida entrega registros, configuraciones, riesgos abiertos y procedimientos para evitar que el conocimiento operativo quede encerrado en una persona.