01
La demo prueba posibilidad, no utilidad
Un prototipo suele responder una pregunta estrecha: ¿puede un modelo generar un resultado impresionante a partir de una entrada preparada? Un sistema de producción debe responder otras más difíciles. ¿Quién es responsable de la decisión? ¿A qué datos puede acceder? ¿Cómo se mide la calidad? ¿Qué ocurre cuando un proveedor tarda, un documento está mal formado o la respuesta es segura pero incorrecta?
Por eso la elección del modelo rara vez es la primera decisión más importante. El trabajo duradero está alrededor: identidad, límites de datos, evaluación, integración, observabilidad y recuperación. Si esas fronteras siguen implícitas, el prototipo no ha reducido el riesgo real del producto.
02
Empieza por una decisión verificable
El mejor primer caso de uso se repite, tiene un coste relevante y es lo bastante acotado para que una persona competente pueda valorar el resultado. «Revisar este contrato de proveedor contra estas cláusulas» puede convertirse en sistema. «Usar IA para trabajo legal» no.
La verificación modifica la arquitectura. Puede exigir citas al documento original, salida estructurada, umbrales de confianza o una interfaz que muestre el trabajo del modelo en contexto. Son requisitos de producto, no mejoras para el final.
- Una entrada definida y una decisión útil
- Una persona o regla capaz de valorar la salida
- Una acción reversible o aprobación explícita
- Una medida base de coste, demora o calidad
03
La evaluación forma parte de la entrega
Un puñado de prompts exitosos no constituye una evaluación. Prepara un conjunto pequeño y representativo con casos habituales, excepciones incómodas y fallos conocidos. Define qué significa «bueno» antes de ajustar el sistema.
En operación, captura la evidencia necesaria para entender cambios: tipo de entrada, fuentes recuperadas, herramientas utilizadas, latencia, coste, correcciones humanas y resultado final. La observabilidad sirve cuando permite decidir si el sistema mejora o simplemente desplaza el trabajo.
04
Entrega el bucle completo más pequeño
Un buen piloto tiene forma de producción, pero un alcance deliberadamente pequeño. Autentica a un usuario real, lee únicamente datos permitidos, ejecuta un flujo, muestra evidencia, trata el fallo y registra un resultado.
El objetivo no es retirar a las personas cuanto antes. Es crear un bucle controlado donde el sistema gane responsabilidad mediante evidencia. Produce menos demos espectaculares y mucho más software que los equipos continúan utilizando.