Solución · AI Operations
Tus prompts están en producción y nadie sabe con certeza qué versión está corriendo
El prompt es la pieza que más manda en el comportamiento de tu IA, y en casi todas las empresas se edita a mano, sin revisión, sin historial y sin forma de volver atrás. Montamos y operamos la función que lo convierte en un artefacto versionado, probado antes de subir y reversible en un minuto.
El problema
El artefacto que más manda en tu IA es el único que nadie gobierna
- Nadie puede afirmar con certeza qué versión del prompt está sirviendo ahora mismo, quién la cambió por última vez ni por qué.
- Un cambio de una línea se publica directamente sobre producción, porque no existe un entorno donde probarlo antes con casos reales.
- Cuando la calidad cae, no se puede volver a la versión anterior: no está guardada en ningún sitio, o está en el historial de una conversación de chat.
- El mismo prompt vive duplicado en el código, en una herramienta y en el portapapeles de alguien, y cada copia lleva meses derivando por su cuenta.
- Cuando el proveedor actualiza el modelo hay que revisar prompts, pero nadie sabe cuáles hay, cuáles dependen de ese modelo ni con qué criterio se validaron.
- El equipo ha dejado de tocar los prompts. No porque estén bien: porque cambiarlos da miedo y nadie quiere ser quien rompa producción un jueves.
Coste de seguir igual
Estás operando un sistema cuya pieza de mayor impacto no tiene control de cambios. El coste llega por dos lados a la vez. Primero, la regresión que nadie vio venir y que descubre un cliente. Y después, más caro, la parálisis: cuando cambiar el prompt es una apuesta, el equipo deja de tocarlo y el sistema deja de mejorar justo cuando el mercado empieza a moverse. A eso se suma un tercer frente que aparece en cuanto alguien pregunta desde fuera: sin historial no puedes reconstruir qué instrucciones gobernaban tu sistema el día que tomó una decisión concreta.
La solución
Montamos y operamos la gestión del cambio de tus prompts: versión, prueba, despliegue por fases y vuelta atrás
- 1Inventariamos y consolidamos. Sacamos cada prompt de donde esté —código, herramientas, documentos, cabezas— y lo convertimos en un artefacto con identificador, dueño, versión e historial, con una única fuente de verdad de la que leen todos los entornos.
- 2Separamos entornos y ponemos un gate. Un cambio nace fuera de producción, pasa por la batería de casos y solo sube si supera el umbral acordado. El mismo gate para todo el mundo, sin excepciones por urgencia: la urgencia se gestiona con un camino rápido documentado, no saltándose el control.
- 3Construimos la batería de pruebas del prompt: un conjunto de casos reales y adversariales, congelado y versionado, que se ejecuta contra cada candidato y compara su salida con la de la versión que está viva. Sin comparación contra la versión viva, un resultado bueno no significa nada.
- 4Desplegamos por fases. La versión nueva entra primero sobre una porción del tráfico, con la anterior corriendo en paralelo sobre las mismas entradas, y solo entonces al total. La vuelta atrás es un cambio de puntero: un minuto, sin desplegar código y sin reunión.
- 5Operamos la función en el día a día: quién puede cambiar qué, qué se revisa antes de subir, qué queda registrado de cada cambio para poder reconstruirlo después, y la revisión programada cada vez que el proveedor mueve el modelo por debajo.
Lo que cambia
Lo que dejas de perder
La pregunta «qué versión está corriendo» pasa de ser una investigación a ser una consulta: hay un identificador, un historial y un dueño por cada prompt en producción.
Mecanismo
Un cambio deja de ser una apuesta: se compara contra la versión viva sobre los mismos casos antes de subir, y sube por fases sobre una parte del tráfico.
Mecanismo
La vuelta atrás deja de depender de que alguien recuerde el texto anterior: es un cambio de puntero a una versión guardada, sin desplegar código.
Mecanismo
Qué medimos: tiempo desde que se detecta una regresión hasta que se revierte, % de cambios que pasan por el gate, cambios revertidos sobre el total y número de prompts en producción sin dueño identificado.
Qué medimos
Ficha técnica
- Trabajo que elimina
- editar prompts a mano sobre producción, sin historial, sin comparación contra la versión viva y sin forma de volver atrás cuando la calidad cae
- Implementación habitual
- 4–8 semanas
- Entrada
- una propuesta de cambio sobre un prompt en producción: un ajuste de instrucción, un cambio de modelo o una corrección tras un incidente
- Salida
- una versión nueva probada contra la batería de casos, comparada con la viva, desplegada por fases y reversible en un minuto, con su registro de quién, cuándo y por qué
- Compatible con
- OpenAIAnthropicAzure OpenAIGoogle Vertex AILangSmithLangfusePromptfooBraintrustGitHub ActionsGitLab CI
- Puede conectarse con
- Tu repositorio y tu circuito de revisión de códigoTus registros de producción, de donde salen los casos de pruebaTu función de evaluación continua de calidad, si ya la tienes montadaTu registro de trazabilidad y tu inventario de sistemas de IA
- Qué medimos
- tiempo desde que se detecta una regresión hasta que se revierte% de cambios que pasan por el gate antes de producción% de cambios revertidos sobre el total desplegadoprompts en producción sin dueño identificado
- Adecuado para
- empresas con IA en producción y varias personas tocando prompts —CIO, COO o responsable de IA— que necesitan poder cambiar rápido sin romper y demostrar qué gobernaba al sistema en cada momento
- No adecuado para
- quien tiene un solo prompt estable que no se toca desde hace meses, o quien busca medir si la respuesta del agente es buena: eso es evaluación de calidad, una función distinta y complementaria
Preguntas frecuentes
En qué gobiernan. La evaluación continua mide si la respuesta de tu agente es buena hoy: muestrea conversaciones reales, las puntúa contra un criterio y detecta que la calidad ha caído. Esta función gobierna el cambio del artefacto que produce esa respuesta: dónde vive el prompt, quién puede tocarlo, qué prueba tiene que pasar antes de subir, cómo se despliega y cómo se vuelve atrás. Son complementarias y funcionan mejor juntas —la batería de casos y las métricas de calidad se alimentan de lo mismo—, pero resuelven problemas distintos: una te dice que algo se rompió, la otra hace que romperlo sea reversible y raro.
Git es el cimiento y lo usamos, pero por sí solo resuelve la mitad. Te da historial y revisión, y eso ya es más de lo que tiene la mayoría. Lo que no te da: un entorno donde probar el candidato contra casos reales antes de subir, la comparación automática contra la versión que está viva, el despliegue sobre una parte del tráfico y la vuelta atrás sin desplegar código —que es lo que necesitas a las once de la noche—. Además, en muchos equipos quien mejor escribe los prompts no trabaja en el repositorio, y obligarle a pasar por una pull request para cambiar una frase acaba en la copia paralela de siempre.
Al revés: lo que frena hoy es el miedo. En los equipos sin control de cambios los prompts se tocan poco y con la respiración contenida, porque cualquier ajuste puede romper algo que nadie va a detectar hasta que se queje un cliente. Cuando probar cuesta minutos y volver atrás cuesta un minuto, el coste de equivocarse baja tanto que la gente vuelve a experimentar. El gate no está para añadir burocracia: está para que el cambio sea barato. Y para lo verdaderamente urgente hay un camino rápido documentado, con revisión posterior obligatoria.
¿Lo montamos en tu negocio?
Tú tienes el problema localizado. Nosotros lo dejamos funcionando y medido.