Blog / Sistemas de IA

Los prompts son código: versiónalos, pruébalos, revísalos

Un prompt decide lo que hace tu sistema de IA, así que cámbialo como cambias el código: en control de versiones, revisado, probado contra ejemplos fijos y registrado en cada salida para poder explicarlo y revertirlo.

En muchos productos de IA, la lógica más importante no está en el código. Está en un párrafo pegado en una pantalla de configuración, editado por quien tuvo la última idea, sin historial y sin pruebas. Cambias una frase y cada respuesta del producto puede cambiar con ella.

Si lideras el equipo: qué preguntar

  • ¿Dónde viven nuestros prompts, y podemos ver quién los cambió, cuándo y por qué?
  • ¿Un cambio de prompt se prueba con ejemplos fijos antes de salir a producción?
  • Si un cambio de prompt empeora las respuestas, ¿podemos volver atrás en un solo paso?

Un prompt decide lo que hace tu sistema. Trátalo como código: versiónalo, revísalo, pruébalo y sabe exactamente qué versión produjo cada salida.

Guarda los prompts en control de versiones

Guarda los prompts como archivos en el mismo repositorio que el código que los usa, no en un campo de la base de datos ni en el panel de un proveedor. Así cada cambio tiene autor, fecha, diferencias y motivo. Cuando una respuesta cambia, puedes ver qué cambió en el prompt, y cuándo.

Usa plantillas con variables con nombre

Arma los prompts con plantillas que tengan variables explícitas y con nombre (la pregunta del usuario, los pasajes recuperados, el formato de salida) en lugar de pegar textos sueltos por todo el código. Una plantilla se lee en un solo lugar, se puede generar en pruebas con valores de ejemplo y se puede verificar: una variable que falta es un error antes del lanzamiento, no una respuesta rara en producción.

Revisa los cambios de prompt en pull requests

Un cambio de prompt pasa por un pull request como cualquier otro cambio, revisado por alguien que entiende el producto y el modelo. Quien revisa hace las mismas preguntas que con el código: ¿qué arregla esto, qué podría romper y dónde está la prueba? Los cambios pequeños de redacción son los que más lo necesitan, justamente porque parecen inofensivos.

Prueba contra un conjunto fijo de ejemplos antes de lanzar

Mantén un conjunto fijo de entradas de ejemplo con sus salidas esperadas o criterios de aceptación: casos típicos, casos límite y entradas que antes fallaban. Corre el conjunto en cada cambio de prompt y en cada cambio de modelo, y compáralo con la última corrida aceptada. Verifica automáticamente lo que se pueda: estructura válida, campos obligatorios, contenido que nunca debe aparecer, datos contra una respuesta conocida. Que una persona revise el resto. Si un cambio empeora el conjunto, no sale.

Registra la versión del prompt y del modelo en cada salida

Guarda, junto a cada salida del sistema, la versión del prompt y la versión exacta del modelo que la produjeron. Cuando alguien cuestione una respuesta meses después, vas a poder reproducirla, explicarla y encontrar todas las demás salidas hechas con la misma combinación. Sin ese registro, “¿por qué dijo eso?” no tiene respuesta.

Que revertir sea un solo paso

Como los prompts se versionan y se despliegan como código, un cambio malo se revierte como código: un revert, un despliegue, y vuelves a la última versión que pasó las pruebas. Si el prompt vive en un panel que alguien editó a mano, revertir significa intentar recordar qué decía antes.

Separa las instrucciones de los datos

La inyección de prompts ocurre cuando los datos se leen como instrucciones: un correo de un cliente, una página web o un documento que dice “ignora tus instrucciones anteriores”. Mantén tus instrucciones en el prompt de sistema, pon el contenido no confiable en secciones bien marcadas, indícale al modelo que lo trate solo como datos, y nunca dependas solo del prompt para la seguridad. Los permisos, las listas de herramientas permitidas y la validación de salidas van en el código, donde ningún texto puede pasarlos por encima.

Documenta la intención

Junto a cada prompt, escribe para qué sirve, qué no debe hacer nunca, qué entradas espera y de qué partes de su salida depende el código. Una línea como “siempre debe devolver la cita que lo respalda; la pantalla de revisión depende de eso” le ahorra a la siguiente persona una edición bienintencionada que rompe producción.

Lista para tus prompts

  • Prompts como archivos en control de versiones
  • Plantillas con variables con nombre y verificadas
  • Cada cambio revisado en un pull request
  • Un conjunto fijo de ejemplos que se corre antes de cada lanzamiento
  • Versión del prompt y del modelo guardada en cada salida
  • Reversión en un solo paso
  • Instrucciones separadas de los datos no confiables
  • Intención y restricciones documentadas junto al prompt

Nada de esto es exclusivo de la IA. Es la misma disciplina de ingeniería que aplicamos a cada parte de un sistema; mira cómo trabajamos.

Escrito a partir del trabajo de nuestros ingenieros en sistemas en producción. ¿Quieres una segunda opinión sobre tu proyecto? Habla con un ingeniero.

Ver el trabajo →

¿Quieres que revisemos
tu sitio?

Cuéntanos dónde el tráfico, los ingresos o tus cifras dejaron de tener sentido. Te diremos qué revisaríamos primero.

¿Prefieres escribirnos directamente? activa JavaScript para ver la dirección

Habla con un ingeniero

Sin teatro comercial. Cuéntanos dónde tu operación se siente lenta, repetitiva o difícil — un ingeniero lee cada mensaje.

Tu mensaje llega directamente a nuestros ingenieros en nuestra dirección.