04 · Oferta
Gestión de releases de IA
ChaRM para agentes de IA: cada cambio versionado, probado, aprobado — y reversible. Un agente cambia de comportamiento cuando cambian su prompt, su modelo, sus herramientas o sus datos. Damos a sus agentes la disciplina de la gestión de cambios y releases de SAP: un inventario, versiones, un control de evaluación fijo, una calificación de riesgo, una aprobación — y un camino de vuelta.
El problema
Los agentes rara vez fallan el primer día. Fallan tras el tercer cambio de modelo, un prompt modificado o una herramienta nueva que nadie probó — y entonces nadie sabe qué versión se ejecutó, quién la aprobó ni cómo volver atrás. En un landscape SAP bien gestionado, nada llega a producción sin transporte, prueba y aprobación. Los agentes actúan, así que merecen la misma disciplina.
Qué entregamos
- Un inventario de cada agente, modelo, skill y servidor MCP — registrado, con responsable y versionado
- Un control de evaluación fijo que cada cambio debe superar: casos de prueba deterministas, pruebas de prompt injection y de herramientas, ponderados por gravedad — una sola regresión en una categoría crítica bloquea el release
- Una calificación de riesgo por agente, con clasificación según el EU AI Act y documentación que un comité de empresa puede revisar
- Un expediente de release por cada cambio: qué cambió, evidencia de pruebas, decisión, aprobador designado y versión a la que volver
- Un registro de auditoría que solo admite nuevas entradas: cada una lleva el hash de la anterior, así que modificar o borrar una entrada antigua se detecta al verificarlo
- Jueces LLM calibrados donde un modelo puntúa resultados: sus veredictos solo cuentan si coinciden lo suficiente con las valoraciones humanas
- Rollback: un release validado al que volver, probado antes de que lo necesite
- Operación: trazas por sesión, costo por acción, monitoreo de la deriva y un calendario de releases — sobre su propio pipeline basado en Git o diseñado para SAP Cloud ALM y AI Agent Hub
- Verificación de trazas: una tarea delegada a un agente solo cuenta como hecha si sus llamadas a herramientas registradas muestran que los pasos obligatorios tuvieron éxito — no porque el agente lo diga
Cómo se desarrolla
Auditoría → Construcción → Retainer: la misma línea para cada oferta, ajustada a esta. Después de cada fase, usted decide si seguimos.
- 01
Auditoría
Un inventario de lo que se ejecuta hoy — agentes, modelos, prompts, herramientas, responsables — y un análisis de brechas frente a la disciplina de releases: qué está versionado, probado, aprobado y es reversible.
- 02
Construcción
El proceso de release en sí: el control de evaluación con sus casos reales, la calificación de riesgo, el flujo de aprobación, la pista de auditoría y el rollback — integrados en su pipeline.
- 03
Retainer
Operamos el control con usted: cada cambio de modelo y de prompt pasa por él, y el conjunto de pruebas crece con cada incidente.
Sectores relacionados
Donde esta oferta se encuentra con un terreno que conocemos desde dentro.
Preguntas
¿Cómo saben que un juez LLM acierta?
Lo medimos antes de confiar en él. Donde un LLM puntúa resultados, comparamos sus veredictos con valoraciones humanas de los mismos casos mediante el kappa de Cohen, una medida estándar de concordancia que descuenta las coincidencias por azar. Su veredicto solo cuenta a partir de 0,7. Ahora estamos calibrando así nuestro propio juez; aún no hay un resultado que comunicar. Los 43 casos deterministas de nuestro control no usan un juez LLM.
¿Qué significa en la práctica la «gestión de releases de IA»?
Cada cambio en un agente — prompt, modelo, herramienta, fuente de datos — pasa por versionado, una línea base de evaluación fija, una calificación de riesgo y una aprobación, con un release validado al que volver. Como ChaRM, pero para agentes.
¿Por qué un cambio de modelo es un release?
Porque el mismo prompt se comporta de otra manera en otro modelo. En nuestro propio control, un modelo en prueba intentó anunciar un reinicio de servidor para el que no tenía ninguna herramienta. Un conjunto de pruebas fijo detecta eso antes de producción, no después.
¿Necesitamos SAP para esto?
No. La disciplina viene de la gestión de cambios y releases de SAP, pero el proceso funciona en cualquier stack — en su propio pipeline basado en Git o junto a la gestión de cambios que ya tiene.
¿Ayuda con el EU AI Act?
Sienta las bases: un inventario, una clasificación de riesgo por agente, pruebas y aprobaciones documentadas y una pista de auditoría. Si un caso de uso es de alto riesgo se evalúa caso por caso; las obligaciones para usos de alto riesgo están previstas a partir del 2 de diciembre de 2027.
Hablémoslo en 30 minutos.
Traiga un proceso y su stack. Llegamos preparados y le decimos con honestidad si un agente rinde — y qué oferta es el punto de partida adecuado.