Qué cambia cuando un prototipo con IA pasa a producción

Un prototipo con IA está listo para producción cuando su comportamiento útil resiste fallas habituales, entradas inciertas y cambios rutinarios bajo una responsabilidad operativa definida. La demostración prueba que algo puede funcionar. La preparación para producción define cuándo se puede depender de ello y qué ocurre fuera de esas condiciones.

Tratemos esa transición como una revisión de evidencia, no como una última ronda de ajustes al prompt.

Convertí los supuestos en un acuerdo de funcionamiento

Enumerá entradas admitidas, salidas esperadas, límites de permisos y acciones permitidas. Identificá qué proveedor recibe cada dato, cómo se configura la retención y quién aprobó ese recorrido. No asumás que los ajustes de una cuenta de desarrollo son iguales a los de producción.

Los atajos suelen quedar en scripts: credenciales amplias, archivos locales, contexto ilimitado y limpieza manual. Cada atajo necesita un reemplazo operativo o una razón documentada para quitar la capacidad afectada.

La discusión de Google SRE sobre revisiones de preparación presenta la preparación operativa como trabajo compartido entre desarrollo y quienes operan el servicio. En una función con IA, incluí el comportamiento del modelo y la recuperación de información junto a la infraestructura.

Fijá una base que permita comparar

Versioná prompt, selección de modelo, configuración de búsqueda y casos de evaluación. Registrá resultados por idioma y tipo de falla. Cambiar de proveedor o ampliar el contexto debe activar otra evaluación, no heredar automáticamente la aprobación anterior.

Definí criterios de lanzamiento según las consecuencias del error. Un buen promedio no compensa una filtración por permisos. Reservá casos fuera del ajuste cotidiano y guardá suficiente historial de configuración para investigar resultados sin conservar contenido sensible innecesario.

Ejemplo hipotético: un asistente documental bajo carga

Un prototipo resume un documento interno a la vez. Durante un piloto hipotético, varias personas suben archivos grandes simultáneamente. Las solicitudes vencen y los reintentos automáticos inician más trabajo mientras las llamadas originales siguen activas.

El diseño de producción limita tamaño y concurrencia, reserva consumo antes del envío y asigna una identidad persistente a cada tarea aceptada. Muestra el estado pendiente en vez de inducir envíos repetidos. Si el proveedor no responde, las personas conservan acceso al original para completar el trabajo manualmente.

La prueba debe interrumpir al proveedor después de aceptar una tarea y reiniciar el trabajador. Pasar significa alcanzar un estado conocido sin contenido no autorizado ni efectos duplicados. No significa obtener una respuesta de IA en toda circunstancia.

Los controles van fuera del prompt

Antes de ampliar el acceso, verificá lo siguiente:

• El servidor limita las consultas y herramientas según permisos.
• La salida generada se valida antes de entrar en campos confiables.
• Hay límites de tiempo, reintentos, contexto e iteraciones de herramientas.
• Operaciones puede desactivar la ruta de IA sin bloquear trabajo ajeno.
• La interfaz distingue pendiente, fallido y no disponible.

Pedirle al modelo que respete esas reglas no equivale a implementarlas. Probá el componente que las aplica por separado del texto que produce el modelo.

Entregá una función que se pueda operar

Asigná responsables para incidentes, cupos de consumo y cambios de configuración. Incluí un procedimiento de reversión, una cola de excepciones y una forma de vincular reportes con operaciones. Ensayá la alternativa manual con alguien que no haya construido el prototipo.

Antes de fijar el lanzamiento, simulá acceso denegado, caída del proveedor y reversión de configuración. Los puntos sin resolver definen el alcance pendiente de software a la medida. Registrá quién acepta cada limitación restante y a cuáles usuarios afecta antes de habilitar el acceso.