¿Lo pueden construir ustedes? (Y por qué igual no deberían)

Hay una pregunta que me hacen mucho, y me encanta que salga a la mesa: “¿Esto lo podemos desarrollar nosotros internamente?”. Me encanta, porque la respuesta honesta es: sí, se puede. Pero hoy quiero explicar porqué, aun así, creo que es una mala idea…

No lo digo desde el típico papel de “cómprame a mí, por favor”, sino desde el aprendizaje que nos ha dejado el habernos dado contra la pared durante más de tres años construyendo esto. 

El demo es fácil, lo que viene después es el verdadero problema.

Partamos derribando un mito. Armar un bot que responde WhatsApp hoy en día no tiene ninguna ciencia, porque cualquier ingeniero con acceso a la API de OpenAI, y un tutorial de YouTube, lo levanta en un fin de semana. 

Lo difícil y costoso es lo que viene después: lograr que ese agente de verdad responda bien, frente a clientes reales y con dinero de verdad en juego. Y no solo eso, sino que hacer que el sistema escale, sea seguro, pueda mantenerse y mejorarse por sí solo. Que se integre a todo el stack de forma perfecta y que los agentes de verdad puedan operar en nombre de la empresa y generar trabajo, no solamente automatización. Ahí es cuando la cosa se pone interesante.

Un modelo de lenguaje alucina por diseño… es la naturaleza de esta tecnología, pero frente a clientes reales, un agente que se inventa un descuento, confirma un stock que no existe o agenda una cita en un horario imposible, te cuesta clientes, reputación y hasta demandas.

La solución a esto no es escribir un mejor prompt o usar un modelo más caro, eso lo hemos intentado, y no lleva muy lejos. La solución es crear un producto de verdad, con infraestructura pura y dura; permisos estrictos de qué puede y no puede decir/hacer, guardrail que previenen hasta 10x las alucinaciones, playbooks probados en millones de interacciones, benchmark de cientos de industrias y eval que corren y detectan errores antes de salir a producción. 

Todo esto toma tiempo y muchas iteraciones y errores caros, que en Vambe nos tomó más de 2.300 implementaciones, cientos de clientes levantado problemas y muchas frustraciones para poder de verdad dominar cómo hacer AI para el front office de una forma que en verdad está cambiando los números de última línea de miles de negocios en Latam.

¿Se puede construir internamente? Claro. Pero aquí está el truco, cada riel que nosotros creamos existe porque algo falló antes. Un equipo interno tiene que descubrir cada una de esas fallas solo, experimentando con sus propios clientes. Nosotros ya cometimos esos errores miles de veces.

El conocimiento no se programa, se acumula.

Hay cosas que no están en el training set de ningún modelo del mundo, por ejemplo:

• ¿Qué secuencia exacta de mensajes convierte mejor en una automotora?
• ¿Cuándo es el momento exacto para reactivar una conversación fría? (Encontramos que es entre 2.5 y 4 minutos, por si tenían la duda, ni más ni menos que el primer toque de whatsapp).
• ¿Por qué los templates de menos de 45 caracteres tienen mejor tasa de respuesta?
• ¿Cómo cambia el comportamiento de compra de la gente a fin de mes?

Nada de eso se programa, se aprende viendo miles de operaciones reales, midiendo, fallando y ajustando en el camino.

Un equipo interno, por más talentoso que sea, parte desde cero y aprende únicamente de su propio embudo. Una muestra de uno solo… y no es un tema de capacidad técnica, es que la curva de aprendizaje se construye con volumen y tiempo.

Sequoia (para los que no saben, preguntenle a ChatGPT lo que es) dice algo muy cierto: “Por cada dólar que se gasta en software, se gastan seis en servicios de soporte”. Los agentes de IA ya no asisten el trabajo, ahora hacen el trabajo y  para hacer un trabajo real no basta con la inteligencia bruta del modelo, se necesita el juicio acumulado de haber visto cientos de veces qué es lo que funciona en cada industria, se necesita una capa de inteligencia software y miles de cosas para ponerlo a trabajar en la práctica en el mundo real, donde nuestros clientes los necesitan, es decir hoy la capa aplicativa está demostrando ser clave. 

El piso se mueve debajo de tus pies

Esto lo aprendimos a la mala, así que se los regalo:

Cada vez que OpenAI o Anthropic lanzan una actualización, el comportamiento de lo que ya tenías programado cambia. Prompts que andaban perfectos dejan de funcionar. Casos que ya estaban resueltos se rompen de la nada y estas actualizaciones salen cada dos o tres meses. 

Si construyes tu solución interna amarrada a un modelo específico, cada release significa rehacer el trabajo. Nuestra postura técnica es tratar al modelo como infraestructura intercambiable, ruteamos entre proveedores, usamos el modelo más pesado solo cuando es estrictamente necesario y, cuando sale una versión nueva, la testeamos contra nuestros propios benchmarks antes de que toque a un solo cliente real.

Eso requiere evaluaciones propias, métricas automatizadas y un equipo dedicado exclusivamente a mantenerlas, es un trabajo de tiempo completo que no termina nunca.

Aquí es donde le hago la pregunta clave a cualquier empresa que evalúa el camino interno: ¿Quieren estar en el negocio de mantener IA, o en el de vender más en su propio core? y ojo esto no pasa solo con modelos, pasa con actualizaciones de API de los cientos de sistemas a los que se deben integrar si de verdad quieren armar un sistema de trabajo de IA proactivo que en verdad opera su empresa, no un bot que responde preguntas frecuentes. 

y ojo esto no pasa solo con modelos, pasa con actualizaciones de API de los cientos de sistemas a los que se deben integrar si de verdad quieren armar un sistema de trabajo de IA proactivo que en verdad opera su empresa, no un bot que responde preguntas frecuentes. 

La matemática detrás y el build versus buy

Cuando una empresa nos dice lo hacemos nosotros, hacemos tres preguntas:

1. ¿Cuántos recursos le van a dedicar y cuándo creen que van a poder lanzarlo con clientes reales?
2. Una vez lanzado este primer caso de uso, ¿qué pasa cuando los demás equipos necesitan lanzar sus agentes para diferentes procesos, pre ventas, post ventas, otros departamentos, etc.?, ¿quién lo va a hacer?,  ¿cuánto se van a demorar y cómo lo van a hacer cuando cada una de esas áreas quiera hacer cambios cada semana? 
3. ¿Cómo van a prevenir las alucinaciones y escalar toda la infraestructura de mensajería en 10 canales diferentes, y cómo van a mantener y mejorar el sistema para que se mantenga siempre en el frontier? 

Y el costo más grande, porque cada día que pasan construyendo, son días que la competencia se aleja y cientos de clientes que pierden. 

Nosotros salimos a producción en días y trabajamos bajo un resultado comprometido. En Vambe usamos un framework que llamamos No Delta No Deal,  si no podemos demostrar un impacto (delta) cuantificable entre tu escenario actual y el escenario con nosotros, no cobramos. 

No quiero que esto se lea como “nadie puede hacer lo que hacemos nosotros”, hay cosas que sí podría replicar otra empresa con suficiente tiempo, equipo y presupuesto.

Lo que no se puede igualar es la experiencia de los errores y haber convertido cada uno de ellos en un riel, un playbook, benchmark o un conocimiento que nos permite hacer cada vez implementaciones más rápidas, efectivas y seguras.

Al final del día, el dilema de build versus buy no se debería responde con el orgullo del equipo de ingeniería, o sueños internos de la empresa, se debería responder mirando el  P&L, la expertise y el foco de nuestra empresa. 

La pregunta correcta nunca es si podemos construirlo. Casi siempre la respuesta es sí.

La verdadera pregunta es: 

¿Es este el mejor uso que le podemos dar a nuestros próximos 18 meses?

Ampliar la forma en cómo vemos las cosas simplemente nos permite tomar mejores decisiones al tener un mayor contexto. Al final del día, funcionamos igual que una IA... o bueno, no lo sé, tal vez los LLM funcionan igual que nosotros? 

Pastelero sus pasteles señores.