Antes de que un agente de IA hable con tus clientes de verdad, debería pasar por al menos dos entornos distintos, no uno solo, y confundirlos es un error habitual que cuesta caro. Ya hemos explicado cómo se diseña el primero de ellos, el sandbox para probar un agente de IA antes de producción: un espacio con datos y herramientas simuladas, pensado para experimentar sin ningún riesgo. Este artículo se centra en el siguiente escalón, la pre-producción, que es un entorno distinto con un propósito distinto, y que muchas empresas se saltan sin darse cuenta de que lo están haciendo.
Qué diferencia a la pre-producción del sandbox
El sandbox está pensado para la fase de experimentación temprana: datos ficticios o anonimizados, herramientas externas simuladas, margen amplio para que el agente falle sin consecuencias mientras el equipo todavía está ajustando su comportamiento básico. La pre-producción (o staging) tiene un propósito distinto: es un ensayo general lo más fiel posible a la producción real, con la misma infraestructura, las mismas integraciones activas contra sistemas de prueba equivalentes a los reales, y casi siempre con datos que se parecen mucho más a los de producción, aunque sigan sin ser datos de clientes reales.
La analogía que mejor lo explica es la de un ensayo de teatro. El sandbox es el momento en que los actores aprenden el papel por partes, repitiendo escenas sueltas hasta que les salen bien. La pre-producción es el ensayo general con vestuario, luces y el escenario real, la última vez que se puede detectar un fallo antes de que haya público pagando entrada en la sala.
Qué debe tener un entorno de pre-producción bien montado
La misma infraestructura que producción, no una versión simplificada
Si en producción el agente corre sobre un servidor con una configuración concreta, con ciertos límites de capacidad y ciertas reglas de red, la pre-producción debería replicar esas condiciones lo más fielmente posible. Probar en un entorno de pre-producción con una infraestructura mucho más ligera que la real es una forma habitual de no detectar problemas de rendimiento o de configuración hasta que ya es tarde.
Integraciones reales contra sistemas de prueba equivalentes
A diferencia del sandbox, donde las herramientas externas suelen estar simuladas, en pre-producción conviene conectar contra las versiones de prueba (sandbox) de esos mismos sistemas externos cuando existan: la pasarela de pago en modo test, el CRM en su entorno de pruebas, la API del proveedor logístico con sus credenciales de desarrollo. El objetivo es probar la integración real, no una simulación de cómo debería comportarse.
Un volumen y una variedad de casos representativos del tráfico real
La pre-producción es el momento de someter al agente a un volumen de peticiones parecido al que va a recibir en producción, no solo a un puñado de casos de prueba manuales. Esto permite detectar problemas que solo aparecen con volumen: tiempos de respuesta que se degradan, límites de uso de alguna API externa que se alcanzan antes de lo esperado, o comportamientos inconsistentes que no se ven con pruebas aisladas.
Un checklist de salida cerrado antes de empezar
Igual que ocurre con los criterios de aprobación del sandbox, la pre-producción necesita su propio checklist de salida, pero centrado en aspectos distintos: rendimiento bajo carga, comportamiento ante fallos de un sistema externo (¿qué hace el agente si el CRM no responde a tiempo?), y confirmación de que todas las integraciones funcionan con las credenciales y configuraciones reales, no con atajos usados durante el desarrollo.
Por qué saltarse la pre-producción es un riesgo distinto al de saltarse el sandbox
Saltarse el sandbox suele significar que el agente todavía comete errores básicos de comportamiento cuando llega a producción. Saltarse la pre-producción y pasar del sandbox directamente a producción suele significar algo distinto y, en cierto modo, más traicionero: el agente puede comportarse bien en el nivel de decisiones y respuestas, porque ya se probó en el sandbox, pero fallar por motivos de infraestructura o integración que el sandbox nunca podía detectar, porque ahí las herramientas externas eran simuladas. Son fallos que aparecen específicamente con sistemas reales bajo condiciones reales, y la pre-producción es el único entorno diseñado para sacarlos a la luz antes de que los vea un cliente.
¿Es siempre necesario tener los tres entornos separados?
No en todos los casos. Para un agente muy sencillo, con una sola integración y un volumen bajo previsto, puede ser razonable fusionar sandbox y pre-producción en un único entorno de pruebas, siempre que ese entorno cubra tanto la experimentación inicial como el ensayo con integraciones reales antes de producción. Lo que no es razonable, ni siquiera en un proyecto sencillo, es eliminar por completo cualquier fase intermedia y pasar directamente de las pruebas manuales del desarrollador a que el agente hable con clientes reales. La complejidad del proceso que automatiza el agente, y el riesgo asociado a un fallo, son los criterios que deben decidir cuántos escalones intermedios necesitas, no la prisa por lanzar el proyecto.
Conclusión
El entorno de pre-producción no es una repetición del sandbox con otro nombre, es el ensayo general con las condiciones reales de infraestructura, integraciones y volumen que el sandbox, por diseño, no puede replicar del todo. Es el último filtro antes de que un fallo lo vea un cliente real, y tratarlo como un trámite opcional es una de las formas más silenciosas de que un proyecto de IA aparentemente bien probado falle en sus primeras semanas de vida real.
En MG Solutions incluimos esta fase de pre-producción como paso obligado antes de activar cualquier agente con clientes reales. Si quieres revisar cómo montaríamos este proceso para tu caso, reserva una primera reunión.