El lanzamiento apurado que sale caro después
El patrón se repite mucho: una empresa decide automatizar su soporte, conecta un asistente de IA a sus canales, y como base de conocimiento le da lo que tiene a mano — un PDF viejo, algunas conversaciones pasadas, quizás nada más que las instrucciones generales del negocio. El asistente arranca a responder desde el primer día, y durante las primeras conversaciones parece funcionar bien. El problema aparece en la segunda semana, cuando llegan preguntas para las que no hay respuesta clara en ningún lado — y el asistente, en vez de decir "no tengo esa información", inventa algo razonable.
Por qué "razonable" es el problema, no la solución
Una respuesta inventada que suena razonable es más peligrosa que una obviamente mala, porque nadie la detecta a tiempo. Un cliente que recibe una fecha de entrega equivocada o una condición de garantía que no existe no tiene forma de saber que está mal — simplemente actúa en base a esa información, y el problema aparece después, cuando ya generó una expectativa que la empresa no puede cumplir.
La causa raíz: automatizar antes de curar
El error no es tecnológico, es de secuencia. Lanzar un asistente de IA antes de tener una base de conocimiento que efectivamente cubra el rango de preguntas reales de los clientes es como abrir un local de atención al público y contratar gente sin entrenarla en las políticas de la empresa — van a hacer lo mejor que puedan con sentido común, que no siempre coincide con lo que la empresa realmente hace.
Cómo se evita: curar antes, medir después, ampliar siempre
El orden que funciona es el inverso al apuro: antes de conectar el asistente a un canal en vivo, armar la base de conocimiento cubriendo al menos las preguntas más frecuentes reales. Después, lanzar con un mecanismo de verificación que impida que el asistente responda sobre temas no cubiertos — que derive en cambio a un humano. Y a partir de ahí, tratar cada derivación por falta de información como una tarea pendiente: ampliar la base de conocimiento con lo que faltó.
Derivar no es un fracaso del lanzamiento
Muchas empresas tienen la expectativa implícita de que un buen lanzamiento significa que el asistente responde "todo" desde el primer día, y eso genera la presión equivocada — la de preferir una respuesta inventada a una derivación. Es al revés: un asistente que deriva con criterio cuando no tiene información suficiente es una señal de que el sistema está bien diseñado, no de que está fallando.
La base de conocimiento nunca "termina"
Ni siquiera una base bien curada el día del lanzamiento se mantiene completa para siempre — el producto cambia, las políticas cambian, aparecen preguntas nuevas. La diferencia entre una implementación que sigue funcionando bien seis meses después y una que se degrada es tener el hábito de revisar qué preguntas no se pudieron responder con confianza, y cerrar esos huecos de forma continua.