La demo salió perfecta. El cliente se entusiasmó, preguntó cuándo podía empezar a usarlo con su equipo, y vos dijiste que en un par de semanas. Ahí empieza lo difícil, porque un prototipo muestra lo que el sistema hace cuando todo sale bien, y un producto se define por lo que hace cuando algo sale mal. Con IA, ese "algo" ocurre con frecuencia.
Cuando el proveedor falla
Tu sistema depende de un servicio externo que a veces va lento, devuelve errores o directamente no responde. En el prototipo eso se resuelve recargando la página. En producción necesitás decidir de antemano qué pasa.
- Timeouts razonables en cada llamada, para que el usuario no se quede esperando indefinidamente.
- Reintentos con espera creciente para errores transitorios, y sin reintentar los que no tienen sentido repetir, como una entrada inválida.
- Un camino alternativo: un mensaje claro al usuario, una respuesta guardada, un modelo de respaldo o la derivación a una persona.
- Que la falla de la IA no tumbe el resto de la aplicación. Si el asistente se cae, la pantalla de pedidos tiene que seguir andando.
Decidí también qué hacer con los límites del proveedor, que existen: topes de solicitudes por minuto, de tamaño de contexto, de uso. Un pico de usuarios puede chocar con ellos justo el día del lanzamiento.
Límites de uso y de gasto
Un prototipo lo usan cinco personas que saben lo que hacen. Producción lo usa gente que prueba cosas raras, pega documentos gigantes o automatiza consultas. Hacen falta topes por usuario, límites de tamaño de entrada y alertas de gasto en el panel del proveedor. Un corte de emergencia que puedas accionar sin desplegar es una buena inversión. Más sobre el tema en el artículo de costos, pero acá el punto es que esto se diseña antes del lanzamiento, no después del primer susto.
Trazabilidad
Cuando un usuario diga "el sistema me respondió una barbaridad", vas a necesitar reconstruir qué pasó. Eso exige haber guardado lo suficiente:
- La entrada del usuario y la salida completa del modelo.
- El texto exacto del prompt que se armó, con el contexto recuperado.
- La versión del prompt y el identificador del modelo usados en esa llamada.
- Parámetros como la temperatura, el tiempo que tardó y la cantidad de tokens.
- Un identificador de la solicitud para cruzar los registros de tu sistema con los del proveedor.
Guardar todo esto trae una obligación: tratar esos registros como datos sensibles, porque contienen lo que los usuarios escribieron. Definí cuánto tiempo se conservan, quién accede y qué se enmascara. La trazabilidad y la privacidad tiran en direcciones opuestas y hay que encontrar un punto intermedio consciente.
Versionar los prompts como código, en el repositorio y con revisión, evita el clásico "alguien tocó el texto en el panel y ahora anda distinto". Y los cambios de modelo, aunque el proveedor los llame equivalentes, pasan por tu conjunto de pruebas antes de salir.
Supervisión humana
Según lo que haga el sistema, conviene que una persona intervenga en algún punto. No todo requiere revisión, pero sí lo que tiene consecuencias: enviar un correo a un cliente, modificar un registro, tomar una decisión sobre alguien. Un esquema común es que el sistema proponga y la persona confirme, y que con el tiempo, y con datos de cuántas propuestas se aceptan sin cambios, se decida dónde se puede automatizar más.
Pensá también en cómo se reportan los problemas: un botón para marcar una respuesta como mala, un canal para que el equipo del cliente avise, y alguien responsable de mirarlo.
Lo que se promete
El prototipo genera expectativas que el producto no siempre puede cumplir. Un cliente que vio una demo cuidada supone que el sistema acierta siempre. Conviene decirle con claridad, antes de la puesta en marcha:
- Qué tareas resuelve bien y cuáles no.
- Que puede equivocarse con seguridad aparente, y cómo detectar esos casos.
- Qué nivel de revisión humana se espera de su lado.
- Qué ocurre si el proveedor cambia condiciones o retira un modelo.
Escribirlo en el alcance del proyecto te protege a vos y le da al cliente una idea realista de lo que compra. Decir "esto va a fallar en estos casos" al principio cuesta mucho menos que explicarlo después de un incidente.
Lo que viene después de lanzar
El trabajo no termina con el despliegue. Los modelos cambian, los usuarios encuentran usos que no previste y los datos se corren con el tiempo. Reservá horas de mantenimiento: revisar una muestra de conversaciones cada tanto, actualizar el conjunto de pruebas con los casos nuevos, vigilar los costos y los avisos del proveedor. Si el contrato no contempla ese seguimiento, el sistema va a ir degradándose sin que nadie lo note, y ese deterioro silencioso es lo que más se paga al año siguiente.