Cómo elegir un proveedor de agentes de IA gestionados

El agente funciona en la demo. El problema aparece a los noventa días

El patrón se repite con una regularidad incómoda. Un equipo comercial de agentes de IA hace una demo impecable con datos curados, el flujo cubre exactamente el caso que se mostró y el comité de compra sale convencido. Nadie en esa sala pregunta qué pasa cuando un cliente escribe algo que el flujo no anticipó, o cuántas conversaciones al mes va a manejar el agente en la vida real contra las quince que se probaron en la demo. La empresa firma pensando que compró un servicio gestionado de agentes de IA, y en la práctica compró una configuración inicial y una promesa verbal de que “el equipo del proveedor está encima”.

El problema no aparece el primer día, aparece cuando el volumen sube o cuando entra un caso raro que nadie configuró. El agente responde mal, o peor, responde con seguridad algo incorrecto, y el cliente final se entera antes que el equipo interno. Cuando alguien pide explicaciones, el proveedor no tiene un panel que muestre qué pasó, o lo tiene y no lo comparte porque “es parte de su propiedad intelectual”. La empresa terminó dependiendo de una caja negra que no puede auditar, pagando una mensualidad fija por un resultado que nadie puede demostrar que mejoró. Eso no es un problema de la tecnología: es un problema que se decidió mal antes de firmar, cuando nadie exigió ver cómo se iba a medir el servicio.

Qué distingue al proveedor correcto, y por qué no es la demo

Toda demo de agentes de IA se parece a todas las demás: son rápidas, contestan bien, y están diseñadas para que el comprador diga que sí. La diferencia entre un proveedor que va a operar de verdad y uno que va a desaparecer después del cobro del primer mes no está en la demo, está en lo que acepta poner por escrito antes de que exista contrato. Un proveedor que ya operó agentes en producción sabe exactamente qué número va a mover, porque lo ha visto moverse antes en otros clientes. Un proveedor que solo ha hecho pilotos o integraciones puntuales evita ese compromiso, porque comprometerse a un número significa exponerse a que se lo reclamen.

Esto tiene una consecuencia práctica en la negociación: la métrica de referencia no puede ser una métrica de vanidad, como “conversaciones atendidas” o “tiempo de actividad del sistema”. Tiene que ser una métrica de negocio, como el porcentaje de casos resueltos sin intervención humana, el tiempo promedio hasta la resolución, o el costo por conversación comparado contra el proceso actual. Qué incluye un servicio gestionado de agentes de IA (y qué debería incluir) es la pregunta que resuelve, en gran parte, si el proveedor ya pensó en esto o lo está improvisando frente a ti.

Las 10 preguntas que filtran al proveedor correcto

Estas preguntas no buscan quedar bien en la reunión, buscan que el proveedor se comprometa con algo verificable antes de que exista una firma. Si una de estas preguntas genera una respuesta vaga o una promesa sin número, ahí está la señal, no en lo que digan después.

• ¿Qué número de referencia van a usar para medir el antes y el después? Si no puede nombrar la métrica exacta en la primera reunión, no la va a poder reportar en el mes seis.
• ¿Cuántos agentes tienen hoy operando en producción, no en piloto, y en qué industria? Un proveedor con clientes reales en producción responde esto sin dudar y sin verificar una presentación.
• ¿Qué porcentaje de las conversaciones termina escalado a un humano, y por qué se escalan esas y no otras? La respuesta muestra si entienden los límites de su propio sistema.
• ¿Qué SLA de disponibilidad y tiempo de respuesta están dispuestos a firmar, y qué penalidad aplica si lo incumplen? Sin penalidad, el SLA es una frase decorativa, no un compromiso.
• ¿Cómo se entera la empresa de un incidente, y en cuánto tiempo? Un proveedor serio tiene un proceso de notificación ya definido, no uno que va a “armar cuando pase”.
• ¿Qué pasa con el servicio cuando el modelo subyacente cambia de versión? Los modelos cambian de comportamiento entre versiones, y alguien tiene que hacerse responsable de volver a validar el flujo.
• ¿Quién tiene acceso y control sobre los prompts, los flujos y las reglas de negocio configuradas? La respuesta anticipa si vas a poder auditar tu propio sistema o vas a depender de que ellos te muestren capturas de pantalla.
• ¿Qué pasa con mis datos si termino el contrato? Exportación completa, borrado verificable, o silencio: solo una de esas tres respuestas es aceptable.
• ¿Cuál es la condición de salida si decido migrar a otro proveedor? Si la respuesta incluye penalidades altas o un periodo de transición sin soporte, ya sabes cómo va a terminar la relación.
• ¿Qué pasó la última vez que un agente falló en producción con un cliente suyo? Si la respuesta es “nunca nos ha pasado”, o miente o no tiene la trazabilidad para saberlo, y ninguna de las dos opciones es tranquilizadora.

Qué pedir de referencias verificables (y qué no sirve como prueba)

El logo de un cliente en una landing page no es una referencia, es marketing. Una referencia verificable es una conversación directa con la persona que opera el agente día a día del lado del cliente, no con quien firmó el contrato ni con el gerente de marketing que aprobó el caso de éxito. Esa persona te puede decir, sin filtro, cuánto trabajo real le tomó mantener el sistema funcionando y qué tan seguido tuvo que intervenir a mano.

• Un contacto operativo real, no comercial: alguien que use o supervise el agente todos los días, con nombre y correo verificable, no una cita anónima en un caso de estudio.
• El número de antes y el número de después, con fecha, no un porcentaje suelto sin línea base. Un porcentaje de mejora sin decir la línea base ni la fecha no es un dato: es una frase.
• Un incidente real que hayan manejado juntos: qué pasó, cuánto tardaron en notificarlo, y qué cambió después para que no volviera a pasar.
• Cuánto tiempo lleva ese cliente en producción, no en piloto. Un piloto corto no dice nada sobre cómo se comporta el sistema en un pico de demanda real.

Si el proveedor ofrece referencias pero pide que las preguntas se envíen por escrito y las conteste él mismo “para coordinar mejor”, esa referencia ya no es independiente. Pide la llamada directa, corta, sin el proveedor en la línea. Qué documentos exigirle a un proveedor de IA antes de firmar detalla la contraparte de esta verificación: qué papel, no solo qué conversación, debería respaldar cada afirmación.

Las señales de alerta que anticipan un mal contrato

Ninguna de estas señales aparece sola, aparecen en combinación, y cuando lo hacen suelen anticipar exactamente el mismo problema: estás por comprar horas de consultoría disfrazadas de producto.

• Promete autonomía total del agente desde el primer mes. Ningún sistema de agentes serio opera sin supervisión humana desde el día uno; quien lo promete o no entiende el riesgo o lo está ocultando.
• No menciona límites del sistema sin que se lo pidas. Un proveedor que ya operó en producción conoce los casos donde el agente falla, y los menciona antes de que preguntes, no después.
• No menciona ningún incidente pasado. Todo sistema con suficiente volumen ha fallado alguna vez. Que no tengan una historia que contar es la historia.
• Cotiza un precio cerrado sin haber revisado tus datos ni tu proceso actual. Sin diagnóstico previo, ese número es una suposición con forma de contrato.
• Vende “inteligencia artificial” en vez de un resultado de negocio. El lenguaje de la propuesta habla de tecnología y no de la métrica que va a mover, y eso es señal de que todavía no diagnosticaron nada.
• Evita hablar de la fase de salida cuando se la mencionas. Cambia de tema, la difiere para “cuando llegue el momento”, o la trata como un detalle legal menor.

Qué exigir en la prueba antes de comprometerte a un contrato largo

Una prueba no sirve para “ver cómo funciona”, sirve para responder una pregunta concreta con datos reales de tu operación, no con datos de demostración. Antes de aceptar el piloto, la empresa tiene que dejar por escrito qué métrica se va a medir, con qué línea base y en qué fecha se cierra la evaluación. Sin esos tres elementos, el piloto se puede estirar indefinidamente y terminar convertido en el contrato de facto sin que nadie lo haya firmado como tal.

• Alcance acotado y con datos reales, no un subconjunto curado que evite los casos difíciles de tu operación.
• Plazo cerrado, con fecha de inicio y de cierre acordada antes de empezar, no “hasta que funcione”.
• Métrica de éxito pactada por escrito antes del primer día, no negociada al final según cómo salieron los números.
• Condición de salida sin penalidad si el piloto no cumple la métrica, incluyendo qué pasa con los datos cargados durante la prueba.

Esto también responde la pregunta de fondo entre agentes de IA como servicio o desarrollo propio: un piloto bien diseñado te da evidencia real para decidir, en vez de una intuición basada en qué tan simpático fue el equipo de ventas.

De quién es la configuración y los datos cuando termina el contrato

Aquí es donde más empresas quedan atrapadas sin haberlo decidido a propósito. Los prompts, los flujos de conversación, las reglas de negocio que se configuraron durante meses de ajuste fino son, en la práctica, el activo que hace que el agente funcione bien para tu operación específica. Si esa configuración vive dentro de una plataforma propietaria del proveedor, sin posibilidad real de exportarla a un formato que otro proveedor pueda leer, la empresa no compró un sistema: alquiló el criterio de alguien más sobre cómo debería funcionar su propio proceso.

Antes de firmar, pide que quede explícito en el contrato: quién es dueño de la configuración, en qué formato se puede exportar, y qué pasa con el historial de conversaciones que alimentó ese ajuste. Esto no es un detalle legal menor dentro del despliegue de agentes de IA empresariales: es la diferencia entre poder migrar de proveedor sin perder meses de trabajo, o quedar rehén de uno solo porque ahí vive todo lo que se aprendió sobre tu negocio.

Las condiciones de salida se negocian antes de firmar, no cuando ya quieres irte

Nadie negocia bien una salida cuando ya está enojado con el proveedor y necesita irse rápido. Por eso las condiciones de salida se definen en la misma mesa donde se negocia el precio, no después. Un contrato que no menciona qué pasa si una de las partes decide terminar la relación no es un contrato incompleto: es una señal de que el proveedor prefiere que esa conversación nunca ocurra en condiciones donde tú tengas poder de negociar.

• Periodo de aviso razonable, definido en semanas, no en un “se conversa en su momento”.
• Soporte de transición durante la migración, no un corte inmediato del servicio el día que se vence el contrato.
• Exportación completa de datos y configuración, en un formato utilizable, sin costo adicional ni negociación posterior.
• Sin penalidades por salir dentro de los términos pactados. Una penalidad alta por cancelar antes de tiempo es, en la práctica, un candado disfrazado de cláusula estándar.

Cómo elegir un consultor de IA para tu empresa (sin arrepentirte a los tres meses) trata el mismo problema desde el lado de la contratación de personas en vez de proveedores de agentes, y la lógica de fondo es idéntica: la salida se negocia con la misma seriedad que la entrada, porque es la parte del contrato que solo importa cuando ya es tarde para negociarla bien.

Mi criterio antes de firmar cualquier contrato de agentes gestionados

El criterio final no es complicado, aunque casi nadie lo aplica en la reunión de venta: cualquier proveedor de agentes de IA que no pueda mostrarte una métrica de negocio, un incidente que resolvió y una condición de salida sin penalidad, todavía no está listo para operar tu proceso, sin importar qué tan bien haya salido la demo.