Construir un agente de IA es la parte barata: el costo aparece en el mes catorce

¿Puede un equipo de producto competente construir su propio agente de IA? Sí, y en menos tiempo del que suele estimar. Con un modelo por API, un canal conectado y las instrucciones bien escritas hay algo andando en dos o tres semanas. Esa parte no es difícil y hace rato que dejó de serlo.

La pregunta que casi nadie hace en esa reunión es otra: quién lo va a estar operando el mes catorce.

¿Qué parte del trabajo se hace una vez y qué parte no termina nunca?

Se hace una vez el prototipo: elegir el modelo, conectar el canal, escribir las instrucciones, integrar el primer sistema. Es trabajo real y es acotado.

No termina nunca lo otro, que son cinco frentes a la vez. Los casos nuevos que aparecen en producción y que nadie previó. Las evaluaciones que hay que correr para saber si un cambio mejoró o rompió algo. Los cambios del canal, que en WhatsApp incluyen precios y políticas que Meta actualiza por su cuenta. Los cambios del proveedor del modelo, que deprecia versiones con un calendario propio. Y el conocimiento del negocio, que se desactualiza solo: cada precio nuevo, cada política interna que cambia, cada producto que sale de catálogo.

Ninguno de los cinco aparece en la estimación inicial, porque los cinco son consecuencia de estar en producción, no de construir.

¿Por qué el mes catorce y no el segundo?

Porque el primer año lo tapa el entusiasmo. En los primeros meses el agente es un proyecto con dueño: la persona que lo armó lo mira todos los días, corrige a mano lo que ve raro y conoce de memoria por qué cada instrucción dice lo que dice.

Alrededor del año pasan tres cosas juntas. Esa persona rota a otro proyecto, porque un equipo de producto tiene un roadmap que atender. La versión del modelo sobre la que estaba armado entra en calendario de deprecación. Y las instrucciones acumularon parches de doce meses que nadie documentó. El resultado no es una caída: es una degradación lenta que nadie mide, porque nunca se definió con qué medirla.

¿Qué se necesita para que la calidad no dependa de que alguien esté mirando?

Un conjunto de evaluaciones que corra como corren los tests de regresión de cualquier sistema serio. Casos reales congelados, con la respuesta esperada, que se ejecutan en cada cambio de instrucciones y en cada cambio de modelo. Sin eso, cambiar un prompt es desplegar a ciegas.

Esa es la diferencia entre un número puntual y un número sostenido. En Takenos, el agente de soporte resuelve 7 de cada 10 conversaciones sin intervención humana, en torno a un minuto por ticket. Cualquier equipo puede llegar a un 70% una semana buena. Lo que cuesta es que ese 70% siga ahí el mes catorce, con otro modelo abajo, con el catálogo cambiado y sin la persona que lo armó.

¿Cuándo conviene igual construirlo en casa?

Hay tres casos claros, y decirlos hace más creíble el resto.

Cuando el agente es el producto que la empresa vende. Si la ventaja competitiva está en la conversación misma, tercerizarla es tercerizar el producto.

Cuando existe un equipo dedicado de verdad y no prestado. Dedicado significa que hay alguien cuyo trabajo, en su descripción de puesto, es operar esto, y que no se lo sacan cuando el roadmap aprieta.

Cuando el proceso es tan específico que el valor está en un detalle que nadie de afuera va a entender antes de doce meses de industria.

Si ninguno de los tres aplica, lo que se está evaluando no es construir contra comprar. Es construir contra construir y después mantener.

¿Cuál es la pregunta que ordena la decisión?

No "¿podemos construirlo?", porque la respuesta casi siempre es que sí. La pregunta es quién va a estar de guardia el día que el proveedor deprecie la versión del modelo que están usando, y con qué conjunto de casos van a verificar que la migración no rompió nada.

Si esa respuesta tiene nombre y apellido y presupuesto, construir es una decisión razonable. Si no lo tiene, el agente ya está construido y el problema recién empieza.