Cuando los agentes de IA empiezan a mantener sistemas de IA, la evaluación pasa a ser el control

Hay un mito persistente sobre la IA en producción: que lo difícil es ponerla en marcha. En realidad, ponerla en marcha es cuando empieza un segundo trabajo. Los modelos se actualizan o se retiran. Los precios cambian. Aparecen opciones más rápidas y más baratas. Solo en septiembre de 2026, OpenAI lanzó tres modelos nuevos en su API y Google puso un nuevo modelo por defecto en disponibilidad general en Gemini Enterprise. Cada uno de esos lanzamientos es una posible mejora, y una posible regresión, para sistemas que ya están en producción.

AIP Evolve, de Palantir, resulta interesante porque automatiza ese segundo trabajo.

Qué anunció Palantir

Según el anuncio de Palantir del 8 de septiembre, AIP Evolve está en disponibilidad general para entornos con AIP habilitado y acceso a AI FDE. Coordina grupos de agentes de AI FDE para mejorar sistemas de IA construidos en Foundry. El equipo define:

• Un objetivo: migración de modelo, reducción de coste, reducción de latencia, mejora de la puntuación de evaluación o un objetivo propio.
• Una estrategia de validación: casos de prueba seleccionados o suites de evaluación existentes, con puntuación configurable y un nivel aceptable de divergencia en las respuestas.
• Restricciones: qué tipos de cambio pueden proponer los agentes y cuántas iteraciones pueden ejecutar.

Los agentes trabajan hacia el objetivo y producen una propuesta con los cambios, los resultados de la validación, comparaciones de respuestas, evidencias y valoraciones de confianza. Las personas la revisan, y los cambios se integran mediante el flujo de ramas de Palantir. La compañía afirma que los primeros usuarios lo han empleado para reducir costes de IA, mejorar evaluaciones y migrar cargas a modelos de código abierto; esos resultados son afirmaciones de Palantir.

Qué cambia realmente

El ciclo de optimización de un sistema de IA (probar un modelo más barato, ajustar un prompt, comparar respuestas, decidir) era manual y ocasional. AIP Evolve lo vuelve agéntico y, potencialmente, continuo.

Eso cambia el papel de las personas. Dejan de hacer cada cambio y pasan a definir qué es un cambio aceptable. Los artefactos más importantes ya no son el prompt ni la elección del modelo. Son:

• La suite de evaluación, que define qué significa “mejor”.
• El umbral de divergencia, que define cuánto pueden cambiar las respuestas antes de rechazar un cambio.
• Las restricciones, que definen qué pueden tocar los agentes.
• El paso de revisión, que decide si la evidencia es suficiente.

1. Objetivo y restricciones
2. Los agentes proponen cambios
3. Validación contra la suite de evaluación
4. Revisión humana de la evidencia
5. Integración mediante revisión de ramas

El controlDecisiones humanas

La evaluación pasa a ser el control

Aquí es donde muchos equipos subestimarán el reto. Un agente de optimización hace exactamente lo que premia la evaluación. Si la suite de pruebas cubre los casos habituales y no los raros y costosos, un cambio de modelo puede superar todas las comprobaciones y aun así fallar donde importa. El coste baja, la puntuación se mantiene y una clase de casos extremos empeora sin que nadie lo note.

Dicho de otro modo, la mejora automatizada es tan segura como la evaluación que optimiza. Los equipos sin una suite de evaluación seria no deberían ver AIP Evolve como un atajo. Deberían verlo como un motivo para construirla.

Cambio controlado, tomado de la ingeniería de software

Las decisiones de diseño de AIP Evolve reflejan lo que ya hacen los equipos de software maduros: tipos de cambio acotados, límite de iteraciones, evidencias adjuntas a cada propuesta, revisión antes de integrar y un flujo basado en ramas. Es el modelo adecuado para sistemas de IA en producción, en cualquier plataforma.

Lo que cualquier empresa puede aprovechar

No hace falta usar Foundry para aplicar la lección:

1. Construya y versione una suite de evaluación para cada sistema de IA en producción, incluidos los casos raros y costosos.
2. Registre líneas base de calidad, coste y latencia, para juzgar cualquier cambio.
3. Trate los cambios de modelo y de prompt como cambios de código: propuestos, probados, revisados e integrados, con marcha atrás posible.
4. Deje constancia de por qué se aceptó cada cambio. Seis meses después, ese registro es lo que permite confiar en el sistema.
5. Planifique migraciones continuas. Los lanzamientos de modelos son ya mensuales. Reserve tiempo para evaluarlos.

Para organizaciones en Latinoamérica que pagan los modelos en dólares, y en España con presupuestos en euros, tener líneas base de coste por sistema convierte cada migración en una decisión financiera medible, no en una apuesta.

La IA en producción no es “desplegar y olvidar”. La hagan personas o agentes, el mantenimiento necesita los mismos controles. Vea en nuestra guía del stack de 2026 cómo encajan la evaluación y el ciclo de vida en el resto del sistema.