Dos empresas lanzan un agente de IA sobre el mismo modelo. En la primera procesa las consultas de forma estable durante meses; en la segunda hoy responde de maravilla y mañana suelta un disparate. El dueño de la segunda concluye que «la IA todavía está verde» y aplaza el tema un año. En realidad acaba de pagar una diferencia que no está en los modelos, sino en cómo el proveedor construyó las restricciones alrededor del modelo. Esa diferencia se ve en la etapa de negociación, si uno sabe qué preguntar.
Seis preguntas al proveedor
La demo aquí no ayuda: en una presentación el agente siempre funciona, porque se le muestra un caso preparado. Las restricciones, en cambio, se verifican conversando.
Pregunta | La respuesta que conviene escuchar |
|---|---|
¿Cómo restringís al agente? | Cada tarea está descrita por separado: objetivo, pasos, criterios de aceptación, formato de respuesta, prohibiciones |
¿Cuántas tareas ejecuta un agente? | Una. La tarea amplia se reparte entre varios |
¿Qué pasa con un resultado incorrecto? | No pasó los criterios de aceptación: no se cuenta y no llega al cliente |
¿Escribís en los prompts «eres el mejor experto»? | No, los roles son funcionales: qué entra, qué sale, dónde está el límite de calidad |
¿De dónde toma el agente los datos actuales? | De una fuente viva: tu CRM, base de conocimiento, documentación del fabricante, no solo de la memoria del modelo |
Los resultados son inestables: ¿qué hacéis? | Acotamos la tarea y reforzamos las restricciones |
Si ante una queja por inestabilidad te proponen pasar a un modelo más potente, eso es cambiar el motor donde faltan el volante y los frenos.
Cuatro señales de alerta en la propuesta comercial
Cero escalados. Si la propuesta dice que el agente responde solo a todas las consultas, el proveedor o no lo ha medido o no te mostrará los errores. La norma de trabajo del escalado, es decir la proporción de consultas que el agente deriva conscientemente a una persona, es de 10–20 % según nuestras propias implantaciones.
Sin criterios de aceptación. «Lanzamos un agente para soporte» no es el objeto de un contrato. El objeto del contrato es una cifra que debe moverse y la forma de medirla.
Demo con datos ajenos. Un agente que luce bien en el ejemplo de una presentación no dice nada sobre tu flujo: tus clientes formulan las cosas de otra manera, el surtido es distinto y tú tienes tus propias excepciones.
Una sola tarea grande. «El agente cubrirá todo el servicio al cliente» cuesta más caro y se rompe más a menudo que tres agentes acotados lanzados uno tras otro.
Qué hay detrás de estas preguntas
Tres cosas determinan si el agente será predecible. Ninguna de ellas tiene que ver con qué modelo hay dentro.
Restricciones. En ingeniería se les llama harness: la envoltura alrededor del modelo que define qué puede hacer el agente, qué ve y con qué reglas se cuenta su resultado. Suena contraintuitivo, pero cuanto más acotada la tarea y más estrictos los criterios, más estable es el resultado. Un modelo mediocre con restricciones estrictas es más predecible que el más inteligente sin ellas. Esto no es solo sobre IA: recuerda al mejor empleado al que no le dieron una tarea clara.
Formulación. La receta popular «dale un rol al modelo y se volverá más inteligente» no funciona. El rol no le añade conocimiento al modelo: activa un estereotipo promediado de los datos de entrenamiento, y el agente empieza a sonar como una wiki corporativa cautelosa. Lo que funciona es la descripción funcional: qué recibe el agente en la entrada, qué devuelve en la salida, dónde está el límite de calidad. Compara «eres el mejor revisor con veinte años de experiencia» con «recibes los cambios y devuelves como máximo cinco observaciones marcadas como crítico / advertencia / menor». La segunda formulación se puede verificar, la primera no.
Actualidad. Cada modelo tiene una fecha después de la cual no sabe nada: ni precios nuevos, ni surtido nuevo, ni reglas de devolución nuevas, ni una versión nueva de una herramienta. Un agente que se apoya solo en la memoria del modelo le contará a los clientes con toda seguridad la verdad del año pasado. Por eso se conecta al agente a una fuente viva —tu CRM, la base de conocimiento, el catálogo— y lee de ahí en el momento de responder.
Cómo se ve en una implantación real
Una empresa manufacturera con una red de 500 distribuidores (no revelamos el nombre por acuerdo) puso un agente entre los distribuidores y el sistema contable. Antes ese papel lo cumplían dos gestores: el distribuidor escribía una pregunta sobre existencias o sobre el estado de un envío, y el gestor abría el ERP y respondía.
La estabilidad aquí la sostienen cuatro capas, no la elección del modelo. La base de conocimiento le da al agente los hechos. Los guardrails son reglas duras que físicamente no permiten salirse de lo autorizado, entre ellas el acceso de solo lectura al sistema contable. Un modelo supervisor aparte revisa la respuesta antes del envío. El escalado deriva el caso a una persona cuando la confianza no es suficiente.
Resultado: 95 %+ de precisión en las consultas típicas, el resto de los casos va a una persona. La rutina que costaba ≈700 000 UAH al año (≈17 000 USD) la cubre un agente cuyo desarrollo costó ≈110 000 UAH (≈2700 USD) más ≈18 000 UAH al año (≈440 USD) de mantenimiento; el efecto neto del primer año es de ≈572 000 UAH (≈14 000 USD), con retorno en 2–3 meses. Personas despedidas: cero. El análisis completo del caso con cifras va en un artículo aparte.
Para el equipo técnico
Tres observaciones de fuentes abiertas que confirman lo mismo desde otro ángulo.
El estudio del grupo de la Universidad de Princeton «Towards a Science of AI Agent Reliability» (aceptado en ICML 2026) separa dos propiedades que a menudo se confunden: precisión y fiabilidad. Los autores proponen doce métricas en cuatro dimensiones —consistencia, robustez, predictibilidad y seguridad— y, tras evaluar 15 modelos en dos benchmarks, concluyen que el crecimiento de las capacidades dio apenas un incremento pequeño de fiabilidad. Un modelo más inteligente por sí solo no añade estabilidad.
El equipo de Manus describió que reescribió la envoltura de su agente cuatro veces, cada vez después de encontrar una mejor forma de construir el contexto. Los modelos, mientras tanto, seguían siendo los mismos.
Vercel publicó un análisis titulado «We removed 80% of our agent's tools»: a su agente interno para trabajar con datos le quitaron la mayoría de las herramientas especializadas y lo redujeron a una sola. La tasa de éxito subió del 80 % al 100 % con menos pasos y menos tokens. Menos opciones, menos margen para el error.
De ahí tres reglas de trabajo: un agente para una tarea, criterios de aceptación en el código, datos actuales a través de MCP, el protocolo con el que el agente consulta fuentes externas en el momento de responder. Para la documentación de bibliotecas ese papel lo cubre, por ejemplo, Context7.
Qué firmar en el contrato del piloto
La verificación del proveedor no termina en una conversación, sino en la redacción del contrato. Tres cosas sin las cuales no conviene empezar un piloto: una cifra concreta que debe moverse; la forma de medirla, acordada antes de arrancar; y una fecha para revisar juntos el resultado.
En Grow2.ai se ve así. Starter: 1800 € por un piloto de 14 días, luego desde 49 € al mes. Practice: 3600 € por 21 días, luego desde 99 €. Operator: desde 6000 € por 30 días, luego desde 149 €. Aparte quedan los costes del modelo. El piloto se paga por adelantado; si en la revisión del día 30 el KPI acordado no se ha movido, devolvemos el importe íntegro. Grow2.ai es la división de IA de Auspex; la configuración de los procesos y del CRM en los que vivirá el agente la asume Auspex.
¿Quieres revisar por qué tu agente funciona de forma inestable? La auditoría de IA gratuita de 2 minutos lo analiza sobre tu proceso concreto, y una revisión de treinta minutos con el fundador repasa la redacción de tu contrato con el proveedor. El mapa más amplio está en el hub Agentes de IA para negocios.