CONSTRUIR O CONTRATAR

Cómo crear un agente de IA, o por qué a veces conviene no crearlo

Construir un agente de IA adentro es una decisión razonable y a veces la correcta. Acá están las ocho líneas de costo que aparecen después del prototipo, las condiciones en las que construir gana y las condiciones en las que contratar gana.

Comparativa6 min de lecturaActualizado 14/09/2026Moment of Peopleッ

Respuesta corta

Crear un agente de IA requiere seis piezas: acceso a un modelo, una capa de recuperación sobre el conocimiento de la empresa, integraciones con los sistemas donde ejecuta acciones, un conjunto de evaluaciones, observabilidad y una regla de derivación a personas. El prototipo se construye en días. El costo real está en sostener esas seis piezas cuando cambia el catálogo, cambia el modelo y alguien tiene que responder un domingo.

Qué hay que construir, en concreto

Antes de decidir conviene ver la lista completa. Un agente de IA que atiende clientes reales tiene seis piezas, y ninguna es opcional.

  1. Acceso al modelo. Un modelo de lenguaje al que se le manda cada mensaje, con su costo por token y su latencia.
  2. Recuperación. El agente no sabe nada de tu empresa: hay que darle el catálogo, las fichas técnicas, las políticas y las reglas comerciales, indexarlas y recuperar el fragmento correcto en cada consulta.
  3. Acciones. Consultar stock, leer precio vigente, crear una cotización, abrir un caso. Cada una es una integración con permisos, errores y estados intermedios.
  4. Evaluaciones. Un conjunto de casos de prueba con la respuesta correcta esperada, que se corre cada vez que tocás un prompt o cambia el modelo.
  5. Observabilidad. Trazas de qué preguntó el usuario, qué recuperó el agente, qué decidió, qué ejecutó, cuánto costó y cuánto tardó.
  6. Derivación a personas. La regla escrita de cuándo el agente deja de responder y le pasa el caso a alguien, con el contexto completo.

El prototipo cubre las piezas 1 y 2 y da una demo que impresiona. La demo no es el sistema.

Las ocho líneas de costo que aparecen después

Estas son las líneas que casi nunca están en la estimación inicial. No llevan cifras porque MoPッ no tiene una medición publicable de cuánto cuesta cada una, y publicar un número inventado sería peor que no publicar ninguno.

1. Costo de modelo. Es el único que todos estiman, y suele estimarse bajo. Lo que lo infla no es el volumen de conversaciones sino el tamaño del contexto: cuanto más conocimiento le mandás al modelo por consulta, más caro sale cada mensaje.

2. Recuperación. Índice, embeddings, reindexado cada vez que cambia una ficha o una lista de precios, y el trabajo de calidad que hace que recupere el fragmento correcto y no uno parecido. Esta pieza es la que más determina si el agente responde bien, y la que más se subestima.

3. Evaluaciones. Sin un set de casos con respuesta esperada, cada cambio es una apuesta. Con set, alguien tiene que construirlo, mantenerlo y correrlo. El día que el proveedor del modelo publica una versión nueva, la pregunta "¿esto sigue andando igual?" solo tiene respuesta si hay evaluaciones.

4. Observabilidad. Trazas, costo por conversación, latencia, tasa de derivación. Sin esto no podés responder por qué el agente le dijo eso a ese cliente, y esa pregunta llega siempre.

5. Guardia. El agente atiende cuando tu equipo no está, que es justamente su gracia. Alguien tiene que estar disponible el sábado a las 22 cuando la integración con el ERP devuelve error y el agente empieza a contestar mal a todo el mundo.

6. Mantenimiento de prompts. Cada regla de negocio nueva es una línea de instrucción, y las instrucciones se pisan entre sí. A los seis meses hay un documento de prompts que nadie se anima a tocar. Es deuda técnica, con la particularidad de que no compila y no tiene tests salvo que hayas hecho la línea 3.

7. Integraciones. WhatsApp Business API con su proveedor, ERP, CRM, sistema de tickets. Cada una tiene su autenticación, su límite de llamadas, su comportamiento raro y su ventana de mantenimiento. Y cada una cambia sin avisarte.

8. Revisión de seguridad. Dónde viven los datos, qué se retiene y por cuánto tiempo, qué acciones puede ejecutar el agente sin aprobación humana, cómo se audita cada acción. Si vendés a empresas grandes o al Estado, esta revisión la va a pedir alguien, y prepararla es trabajo real.

Ninguna de estas ocho desaparece si contratás. Cambia quién las sostiene y cómo se pagan. Cambia quién las sostiene.

Cuándo construir gana, con condiciones

Construir es la decisión correcta si se cumplen la mayoría de estas condiciones. No es una lista de consuelo.

  • Tenés un equipo que puede ser dueño del sistema. No una persona entusiasmada: al menos dos personas que puedan sostener guardia, evaluaciones y despliegue, y que vayan a seguir en la empresa.
  • La lógica del agente es tu diferencial. Si la forma en que tu empresa cotiza o diagnostica es el negocio, tercerizar esa lógica es tercerizar el negocio.
  • Ya corrés infraestructura parecida. Si ya tenés observabilidad, CI, gestión de secretos y alguien de guardia, el costo marginal de agregar un agente es mucho menor que el de empezar de cero.
  • Tenés requisitos de datos que ningún proveedor cumple. Residencia de datos específica, aislamiento, o una normativa interna que exige control total del stack.
  • El horizonte es largo y el volumen alto. Si el sistema va a vivir años y procesar mucho, el costo fijo de construir se amortiza.
  • El caso es interno y de bajo riesgo. Un agente que ayuda a tu propio equipo tolera errores que un agente de cara al cliente no tolera. Es el mejor lugar para aprender. El mejor lugar para equivocarse.

Cuándo contratar gana, con condiciones

  • No tenés quién sostenga la guardia. Es la condición que más decide en la práctica y la que menos se dice en voz alta.
  • El tiempo hasta producción importa. Si necesitás estar atendiendo este trimestre, construir te pone en producción cuando la ventana ya se cerró.
  • Las integraciones son de catálogo, no diferenciales. Conectar WhatsApp Business API o un ERP conocido es trabajo resuelto. Rehacerlo no te da ninguna ventaja.
  • Vas a pasar una revisión de seguridad o un pliego. Un proveedor con documentación de seguridad, modelo de permisos y auditoría escrita acorta ese trámite meses.
  • El diferencial está en el diseño operativo, no en el agente. Definir bien qué se automatiza, qué se deriva y con qué criterio suele valer más que el modelo que responde.
  • El volumen es moderado. Con pocas conversaciones de alto valor, el costo fijo de construir no se amortiza nunca.

Hay un camino intermedio que funciona y que casi nadie propone: contratar la capa operativa y construir adentro solo la pieza que es realmente tuya, por ejemplo el motor de reglas de precio, y exponerla como un servicio que el agente consulta. Así no rehacés la infraestructura y sí conservás el diferencial. Comprá la base, construí la punta.

Lo que no cambia en ninguna de las dos opciones

La derivación a una persona. Construyas o contrates, alguien tiene que escribir el criterio: monto por encima de cierto valor, pedido de descuento, reclamo, cuenta marcada como estratégica, o pedido explícito del cliente de hablar con alguien. Un agente sin ese criterio escrito no es más autónomo: es más peligroso, porque va a intentar responder también donde no debería. El criterio se escribe.

Referencia

La tabla que te podés llevar

Línea de costo Construir en casa Contratar
Modelo Factura directa del proveedor, variable con el tamaño del contexto Dentro del alcance del proyecto
Recuperación e indexado Equipo propio, reindexado en cada cambio de catálogo El proveedor mantiene el conocimiento cargado
Evaluaciones Hay que construir y mantener el set de casos El proveedor lo corre; pedí ver el criterio
Observabilidad Stack propio de trazas, costo y latencia Panel del proveedor; pedí ver el export
Guardia Tu gente, fines de semana incluidos Contrato de soporte; pedí el horario por escrito
Mantenimiento de prompts Deuda creciente sin tests si no hay evaluaciones Parte del servicio continuo
Integraciones Una por una, con su mantenimiento De catálogo cuando el sistema es conocido
Revisión de seguridad Hay que documentar todo desde cero Documentación existente; pedila antes de firmar
Gana si Tenés equipo dueño, la lógica es tu diferencial, volumen alto y horizonte largo Necesitás producción este trimestre, no tenés guardia, o el diferencial es el diseño operativo

Dónde entra MoPッ

De la teoría a tu operación

MoPッ es la opción "contratar" de esta página, así que el sesgo está declarado. Lo concreto: SmartBot se entrena con el catálogo, las fichas técnicas y las reglas de precio de la empresa, consulta stock y precio vigente en el ERP, arma la cotización preliminar y ejecuta las acciones que estén autorizadas; PanelCRM unifica las líneas, aplica SLA, asigna por regla, registra cada acción con su resultado y deriva a una persona según el criterio escrito en el diseño. El plazo habitual para salir a producción en SmartBots comerciales es de cuatro semanas, según alcance. Si tu equipo cumple las condiciones de la sección "cuándo construir gana", decilo en la primera llamada y la conversación va a durar menos. Sesgo declarado.

Preguntas

Lo que preguntan antes de decidir

Necesitás seis piezas: acceso a un modelo de lenguaje, una capa de recuperación sobre el conocimiento de tu empresa, integraciones con los sistemas donde el agente ejecuta acciones, un conjunto de evaluaciones, observabilidad y una regla escrita de derivación a personas. El prototipo de las dos primeras se hace en días. Las otras cuatro son las que determinan si el sistema sobrevive al mes ocho.

Para casos acotados, sí, y es el camino más barato para aprender: respuestas frecuentes, captación de datos, derivación simple. Donde los constructores no-code se quedan cortos es cuando la respuesta correcta depende de un dato vivo en tu sistema, cuando hay reglas de precio por cliente, o cuando alguien tiene que auditar qué acción se ejecutó y quién la autorizó.

No publicamos un número de lo que cuesta construir un agente de IA adentro, porque no tenemos una medición que lo respalde y un número inventado te haría tomar una decisión peor. Lo que sí podemos darte es la lista completa de líneas de costo de esta página, para que tu equipo la estime con sus propios sueldos, su volumen y su stack.

Si tenés evaluaciones, corrés el set y sabés en una tarde qué se rompió. Si no las tenés, te enterás por un cliente. Esa diferencia es el argumento más fuerte a favor de invertir en evaluaciones desde el primer día, construyas o contrates. Si contratás, preguntá al proveedor cómo valida un cambio de modelo antes de aplicarlo.

Sí, en las dos direcciones, y el camino más común es empezar con un caso interno construido en casa para aprender, y contratar cuando el caso pasa a ser de cara al cliente y aparece la exigencia de disponibilidad. Lo que conviene conservar en cualquier migración es el conocimiento cargado y el set de evaluaciones: son lo más caro de reconstruir.

En SmartBots comerciales el plazo habitual de MoPッ es de cuatro semanas, y varía según la cantidad de líneas, equipos e integraciones. Las fases son relevamiento, carga de conocimiento y reglas, integración, prueba supervisada y salida a producción. El detalle del modelo de seguridad y de la gobernanza de acciones está en la página de implementación y seguridad.