Iniciar un piloto de IA generativa nunca había sido tan fácil. Un equipo pequeño, un modelo capaz y unas cuantas semanas bastan para una demostración convincente: un asistente de ventas que redacta planes de cuenta, un agente de servicio que responde preguntas sobre políticas, un copiloto de finanzas que escribe comentarios sobre variaciones. La dirección ve la demostración, aprueba el siguiente paso y luego el piloto se queda en pausa durante meses.
Cuando los pilotos se estancan, el modelo rara vez es la causa. Se estancan porque nadie es dueño del resultado, nadie puede demostrar que las respuestas son lo bastante buenas, nadie conoce el costo a pleno volumen, nadie está listo para dar soporte a la herramienta, y a las personas que deberían usarla nunca se les pidió cambiar su forma de trabajar.
Dónde se estancan los pilotos
Cada una de estas brechas es común, y cada una tiene una solución común. Juntas explican por qué tantas organizaciones encadenan piloto tras piloto sin nada en producción. La salida es cerrar bien las brechas para un caso de uso y luego reutilizar lo construido para los siguientes. El primer caso de uso concentra la mayor parte del esfuerzo; los siguientes lo heredan.
Nombre a un responsable que responda por el resultado
Un caso de uso en producción necesita un responsable de negocio: un directivo cuyo equipo lo usará y a quien se le medirá por el resultado. Ese responsable define qué es un buen resultado, acepta el riesgo restante y abre espacio para el cambio en la forma de trabajar. También decide cuándo el piloto tuvo éxito, lo que evita el caso común de un piloto que sigue corriendo porque nadie tiene la autoridad para terminarlo. Los equipos de tecnología son dueños de la plataforma y de la construcción. No pueden ser dueños del resultado.
Si ningún directivo de negocio está dispuesto a hacerse cargo de un piloto, esa es información útil. Suele significar que el caso de uso resuelve un problema por el que nadie está pagando, y la decisión más sensata es detenerlo pronto.
Demuestre la calidad antes de escalar
Una demostración muestra que el asistente puede acertar. La producción exige evidencia de que acierta con suficiente frecuencia, en los casos que importan. Construya un set de evaluación con casos reales y las respuestas esperadas, acuerde el umbral de calidad con el responsable y ejecute el set después de cada cambio en el modelo, las instrucciones o los datos. Explicamos cómo construir un set así en nuestro artículo sobre cómo preparar los datos para los agentes de IA.
Siga evaluando después del lanzamiento. Revise cada semana una muestra de respuestas en producción, dé seguimiento a la proporción que aprueba y turne a una persona los casos inciertos o de alto riesgo. La evaluación no es una fase que termina; es la forma en que el caso de uso sigue siendo confiable mientras el modelo, los datos y el negocio cambian a su alrededor.
Conozca el costo por respuesta
Los costos de un piloto son pequeños y nadie los vigila. A volumen de producción, el costo de cada solicitud se convierte en una línea del presupuesto de alguien. Mida el costo por respuesta, por documento o por conversación desde el primer día del piloto, y proyéctelo a pleno volumen antes de aprobar el despliegue. En cada revisión, el costo debe aparecer junto al valor, para el mismo periodo y en la misma moneda.
La mayoría de las palancas son decisiones de diseño: usar el modelo más pequeño que supere el umbral de calidad, enviar solo el contexto que necesita una solicitud, reutilizar resultados para preguntas repetidas y fijar alertas de gasto para cada caso de uso. Un caso de uso cuyo valor no cubre su costo de operación a escala no debe llegar a producción, por impresionante que sea la demostración.
Planee el soporte y el cambio antes de salir en vivo
Los usuarios necesitan saber dónde reportar una respuesta equivocada y qué tan pronto se corregirá. Alguien tiene que hacerse cargo de las instrucciones, del set de evaluación y de las conexiones a los datos cuando el equipo del proyecto se vaya. Escriba ese modelo de soporte antes de salir en vivo, como lo haría con cualquier aplicación de negocio, y decida cómo se libera una nueva versión: quién la aprueba, cómo se prueba y cómo se enteran los usuarios de lo que cambió.
El cambio es la tarea más grande. Las personas adoptan una nueva forma de trabajar cuando encaja con las herramientas que ya usan, cuando sus jefes lo esperan y cuando la forma anterior se retira. Las sesiones de capacitación por sí solas rara vez lo logran; rediseñar el proceso en torno al asistente casi siempre lo logra.
De un caso de uso a un portafolio
El segundo caso de uso debería costar mucho menos que el primero, porque reutiliza lo que el primero construyó: identidad y accesos, registro de actividad, el set de evaluación y sus herramientas, el monitoreo de costos y el modelo de soporte. Trate estos elementos como una plataforma compartida, no como partes de un solo proyecto. Una plataforma compartida también evita el problema contrario, en el que cada área compra su propio asistente, con sus propios controles, para la misma necesidad.
Elija los siguientes casos de uso por valor y factibilidad, y ordénelos en olas, con los fundamentos de datos y el gobierno avanzando en paralelo. Una vista de portafolio también permite a la dirección comparar los casos de uso con las mismas medidas y mover la inversión hacia los que rinden.
Un gobierno que acelera
Un buen gobierno hace que escalar sea más rápido, porque cada equipo conoce el estándar antes de empezar. Basta con un conjunto breve de filtros:
- un responsable de negocio con nombre y una medida de valor acordada;
- un set de evaluación, y un umbral de calidad que se cumplió;
- un costo por uso conocido, proyectado a pleno volumen;
- un modelo de soporte y un plan para el cambio en la forma de trabajar;
- una revisión de riesgos, con personas que aprueban cualquier acción que tenga consecuencias.
Revise el portafolio cada trimestre frente a estos filtros y al valor entregado. Escale lo que funciona, corrija lo que está cerca y detenga lo que no. Ese ritmo, más que cualquier decisión tecnológica, es lo que convierte una colección de pilotos en una capacidad duradera.