Agentes de IA como servicio o desarrollo propio: cómo decidir

El error de comparar solo el precio de arrancar

La comparación que casi toda empresa hace antes de decidir es una tabla con dos columnas: cuánto cuesta contratar el servicio gestionado frente a cuánto cuesta el equipo interno para construirlo. Esa tabla mira un solo momento, el de arrancar, y ese es justo el momento más barato de todo el proyecto. La cotización del proveedor trae un número de agentes, un plazo de implementación y una mensualidad que suena razonable. El presupuesto interno suma sueldos de dos o tres perfiles y una licencia de infraestructura. Con esos dos números en la mano, alguien firma. Y ahí empieza el problema real, el que no aparece en ninguna de las dos columnas.

El problema aparece entre el mes seis y el mes doce, cuando el agente deja de ser una novedad y pasa a ser parte de la operación diaria. Cambia el catálogo, cambia la política de devoluciones, sale un producto nuevo, el modelo detrás del agente se actualiza y hay que revisar los prompts otra vez. En la empresa que tercerizó, cada uno de esos cambios pasa por un ticket, una cola de soporte y a veces un costo adicional que el contrato original no contemplaba. En la empresa que lo construyó puertas adentro, cada uno de esos cambios depende de que la persona que entiende el sistema siga trabajando ahí. He visto agentes de IA empresariales abandonados en los dos escenarios, no porque la tecnología fallara, sino porque nadie calculó quién iba a sostener el sistema cuando dejara de ser un proyecto y se volviera una obligación permanente.

Qué significa en la práctica contratar agentes de IA como servicio

“Agentes de IA como servicio” es el nombre comercial de un arreglo específico: un proveedor externo diseña, aloja, monitorea y actualiza el agente, y la empresa paga una tarifa recurrente por tenerlo funcionando. No es lo mismo que comprar un software que se instala y queda quieto. Es contratar una operación continua, con un equipo del otro lado que responde cuando el agente falla, cuando hay que sumar un caso de uso nuevo o cuando el modelo subyacente cambia de versión. Si todavía no tienes claro qué incluye ese arreglo en la práctica, conviene revisar antes qué es un servicio gestionado de agentes de IA. Quien firma ese contrato no está comprando un agente: está comprando que otro cargue con el trabajo de mantenerlo vivo.

Ese setenta por ciento no es abstracto. Es monitoreo diario de que el agente sigue respondiendo bien, es corregir el prompt cuando aparece un patrón nuevo de preguntas, es actualizar la integración cuando el sistema de origen cambia su forma de entregar datos, es dar soporte al usuario final cuando algo sale mal a las once de la noche de un viernes. Nada de eso se ve en la demo inicial, y todo eso es lo que decide si el agente sigue vivo en el año dos o se convierte en un proyecto abandonado que nadie se anima a apagar del todo.

El costo total a tres años, línea por línea

Comparar “cuánto cuesta el agente” es la pregunta equivocada, porque el costo no es un número, es una suma de líneas que se comportan distinto según quién sostiene la operación. Esta es la estructura que uso para poner los dos caminos en la misma tabla, sin inventar una cifra de proveedor que en tu mercado y tu industria puede variar muchísimo. Para el detalle mes a mes de la línea que más se subestima, conviene revisar cuánto cuesta mantener un agente de IA al mes.

• Diseño e implementación inicial: el costo de definir el caso de uso, construir los flujos y ponerlo en producción. Es la línea más parecida entre las dos opciones y, casi siempre, la única que se compara antes de firmar.
• Infraestructura y consumo del modelo: lo que cuesta correr el agente mes a mes, que crece con el volumen de conversaciones. En desarrollo propio lo paga la empresa directo; en servicio gestionado suele ir incluido o prorrateado dentro de la mensualidad.
• Mantenimiento y ajuste continuo: revisar prompts, corregir respuestas erradas, sumar casos de uso nuevos. En tercerizado es la mensualidad o un plan de horas; en interno es el sueldo de quien lo sostiene, exista o no trabajo esa semana en particular.
• Soporte y guardia: quién responde cuando el agente falla en producción, sea de día, de noche o un fin de semana. El servicio gestionado suele traer esto dentro del contrato; el desarrollo propio necesita definir una guardia interna o vivir con el riesgo de que nadie atienda la caída.
• Rotación y conocimiento: el costo de que la persona que entiende el sistema se vaya de la empresa. En el modelo tercerizado ese riesgo lo absorbe el proveedor, al menos en teoría; en el interno, la salida de un ingeniero clave puede dejar el agente sin nadie que lo entienda de verdad.
• Cambio de escala: qué pasa cuando la empresa pasa de un agente a cinco, o de mil conversaciones al mes a cien mil. Esta línea casi nunca crece de forma lineal en ninguno de los dos modelos, y es la que más sorprende a los tres años si nadie la proyectó desde el inicio.

Sumadas estas seis líneas durante tres años, el patrón que más se repite en el mercado es que el desarrollo propio arranca más barato y termina más caro cuando la empresa no tenía ya un equipo de ingeniería trabajando en algo parecido, y que el servicio gestionado arranca más caro y se vuelve más predecible, aunque nunca tan barato como prometía la primera cotización. No es una regla fija: es una tendencia que cambia según cuánta de esa estructura ya tiene instalada la empresa antes de decidir.

Qué se pierde de verdad al tercerizar

Tercerizar no es regalar el problema, es cambiarlo de forma. Lo que se pierde no es “control” en abstracto, es control operativo concreto sobre decisiones que antes la empresa tomaba en minutos y que ahora dependen de la cola de otro. Estas son las pérdidas reales, no las que se mencionan en la reunión de ventas:

• Velocidad de cambio: un ajuste que un ingeniero interno resolvería en una tarde puede esperar el ciclo de soporte del proveedor, que suele moverse en días o semanas según el nivel de contrato firmado.
• Conocimiento acumulado: el proveedor aprende de tu operación, pero ese aprendizaje vive en sus sistemas y en su gente, no en la tuya. Si cambias de proveedor, casi siempre empiezas de cero otra vez.
• Visibilidad del sistema: cuando el agente responde mal, la empresa depende de que el proveedor le explique qué pasó, en vez de poder abrir el sistema y verlo con su propia gente.
• Margen de negociación futura: mientras más dependiente esté la operación del agente, menos margen tiene la empresa para negociar precio o condiciones cuando llegue la renovación del contrato.

Ninguna de estas pérdidas es motivo automático para descartar el servicio gestionado. Son el precio real de comprar velocidad de arranque y tranquilidad operativa, y hay negocios donde ese precio vale la pena sin mucha discusión. El error no es pagarlo: es firmarlo sin haberlo nombrado antes.

Qué se pierde de verdad al desarrollarlo puertas adentro

El desarrollo propio también cobra un precio, solo que se paga distinto: no en la factura mensual, sino en foco de equipo y en riesgo concentrado en pocas personas. Estas son las pérdidas que casi nunca aparecen en el argumento a favor de construir:

• Foco del equipo de ingeniería: cada hora que un ingeniero interno dedica a sostener el agente es una hora que no dedica al producto principal de la empresa. Un agente de soporte no es el negocio; a veces termina compitiendo con el negocio por la misma gente.
• Riesgo concentrado en pocas personas: si el sistema lo entienden de verdad una o dos personas, la empresa depende de que ninguna renuncie en el momento equivocado. Es una dependencia tan real como la de un proveedor externo, solo que se siente menos porque está adentro.
• Disciplina de mantenimiento sin presión de contrato: un proveedor externo tiene un contrato que lo obliga a responder. Un equipo interno sin ese marco tiende a posponer el mantenimiento del agente cuando aparece una prioridad más urgente, hasta que el agente empieza a fallar en silencio.
• Costo de evaluación continua: sostener la calidad de un agente exige medirlo todo el tiempo contra casos nuevos, y ese trabajo de evaluación es tan especializado como el de construirlo, algo que la práctica seria de diseño de agentes documenta bien y que pocas empresas presupuestan de entrada.

Construir puertas adentro tiene sentido cuando la empresa ya cuenta con el equipo de ingeniería y de datos trabajando en algo parecido, y el agente se vuelve una extensión natural de lo que ya hacen. Tiene mucho menos sentido cuando se arma un equipo nuevo solo para este proyecto, porque ahí el costo de aprendizaje se suma al costo de mantenimiento, y los dos terminan pagándose del mismo presupuesto.

El escenario híbrido que gana más seguido de lo que se admite

Planteada como blanco o negro, la decisión empuja a elegir un bando y defenderlo en la siguiente reunión de directorio. En la práctica, el escenario que mejor sostiene tres años casi nunca es puro: es un híbrido donde el proveedor externo carga con la infraestructura, el monitoreo de base y la operación diaria, y un responsable interno, no necesariamente un equipo grande, mantiene el criterio de negocio sobre qué debe hacer el agente y por qué.

Ese responsable interno no programa el agente línea por línea. Revisa las conversaciones reales, decide qué casos de uso suma después, y negocia el contrato con el proveedor desde el conocimiento del negocio, no desde la dependencia total. Es la diferencia entre tercerizar la operación y tercerizar también el criterio: lo primero es razonable en la mayoría de los casos, lo segundo es lo que después sale caro, porque nadie adentro de la empresa puede evaluar si lo que el proveedor está haciendo de verdad sirve. Para calcular si ese responsable interno alcanza para uno o para varios agentes a la vez, conviene revisar cuántos agentes de IA necesita una empresa antes de fijar el alcance del contrato.

Este híbrido no es gratis ni es automático. Exige que alguien adentro tenga tiempo real asignado a esa función, no un “encargado” de nombre que en la práctica atiende otra cosa todo el día. Cuando ese rol no existe de verdad, el híbrido se degrada al peor de los dos mundos: se paga la mensualidad del proveedor y además se pierde el criterio, porque nadie interno está revisando nada.

Las cinco preguntas que resuelven la decisión

Después de estructurar el costo, lo que queda es una decisión de contexto, no de preferencia. Estas cinco preguntas, respondidas con honestidad sobre la operación real de la empresa, definen el lado hacia el que conviene inclinarse:

• ¿Ya tenemos un equipo de ingeniería con capacidad ociosa real, no prestada de otro proyecto? Si la respuesta es no, construir puertas adentro empieza restando foco a lo que sí genera ingreso hoy.
• ¿Cuántas veces por semana vamos a necesitar cambiar algo del agente? Un agente que cambia seguido premia la velocidad de un equipo interno; uno estable premia la previsibilidad de un contrato gestionado.
• ¿Qué tan crítico es el agente si falla un sábado a la noche? Mientras más crítico, más pesa tener un contrato de soporte con garantía explícita, en vez de depender de que alguien conteste el celular.
• ¿Quién adentro de la empresa puede evaluar si el proveedor está haciendo bien su trabajo? Sin ese criterio interno, tercerizar significa firmar un cheque en blanco en cada renovación de contrato.
• ¿Qué pasa si el proveedor sube el precio o cierra en dos años? Si la respuesta es “no tenemos plan B”, ya existe una dependencia que conviene resolver antes de que se vuelva urgente.

Ninguna de estas preguntas se responde bien en la reunión donde se firma el contrato. Se responden mirando la operación real de la empresa, no la promesa del proveedor ni el entusiasmo del equipo que quiere construir. Si este marco no alcanza para tu caso, vale la pena revisar aparte los criterios que definen la decisión con más detalle.

Cuándo la respuesta cambia con el tiempo

La decisión no se toma una sola vez y queda fija durante tres años. El contexto que la sostiene cambia, y con él cambia la respuesta correcta, aunque la mayoría de las empresas nunca vuelve a revisarla después de firmar el primer contrato.

• El volumen se multiplicó: lo que empezó como quinientas conversaciones al mes hoy son veinte mil. La estructura de costos que tenía sentido al inicio deja de ser la más eficiente a esa escala, en cualquiera de los dos modelos.
• El agente pasó de accesorio a crítico: si dejó de ser un experimento y hoy sostiene una parte real de la atención al cliente o de una operación interna, el nivel de control y de garantía que se necesita cambia con él.
• La empresa ya construyó capacidad propia por otro motivo: si se armó un equipo de datos e ingeniería de IA para otro proyecto, sostener el agente puertas adentro deja de sumar el costo de aprendizaje que antes lo hacía caro.
• El proveedor cambió sus condiciones: una subida de precio, un cambio de dueño en la empresa proveedora o una caída real en la calidad del soporte son razones legítimas para reabrir la comparación, no señales para ignorar.

Revisar esta decisión cada doce meses, con la misma estructura de costo del inicio, cuesta una tarde de trabajo. No revisarla nunca es lo que convierte un acuerdo razonable en un contrato que nadie recuerda por qué se firmó así. El proceso completo para volver a decidir, cuando ya hay un agente funcionando y no se arranca de cero, está desarrollado en cómo decidir si construyes o compras una solución de IA.

La pregunta no es build o buy: es quién sostiene la operación

Vuelvo a la tesis del inicio porque es la que de verdad importa: construir el agente es la parte visible, rápida y barata del proyecto. Sostenerlo vivo es la parte invisible, lenta y cara, y es la que se paga todos los meses durante los tres años que siguen a la firma. Cualquier comparación que no ponga esa parte en el centro está comparando lo fácil, no lo que decide si el proyecto funciona o se abandona.

La empresa que decide bien esto no es la que elige el bando más de moda: es la que se sienta a proyectar las seis líneas de costo a tres años antes de firmar nada, y la que deja a alguien adentro con tiempo real para sostener el criterio, tercerice lo que tercerice de la operación. Esa disciplina, más que la elección entre servicio gestionado y desarrollo propio, es la que determina si el agente sigue vivo en el año tres o si se convierte en otro proyecto de IA que nadie se anima a apagar.