Contrato mínimo para un agente IA en producción (4 condiciones no negociables)

La mayoría de implementaciones de agentes IA no fallan por la tecnología. Fallan porque no había contrato de inicio.

Con “contrato” no nos referimos a un documento legal. Nos referimos a: un conjunto de condiciones concretas que deben ser ciertas antes de activar el agente sobre datos y procesos reales de un negocio. Sin estas condiciones, lo que se pone en marcha no es un agente en producción. Es un experimento a cargo del cliente.

En serpixel (Clever European Business, S.L.) tenemos cuatro condiciones no negociables que verificamos antes de firmar cualquier implementación. No las ponemos para protegernos: las ponemos porque es la única manera de garantizar que lo que entregamos funciona cuando importa y se puede parar cuando falla.

Condición 1: un agente, un workflow, una métrica

El primer punto de fallo de casi todas las implementaciones es el scope. No la tecnología, no el modelo, no las integraciones: el scope.

Cuando un proyecto empieza con “queremos un agente para la atención al cliente” sin especificar mucho más, lo que tenemos es una intención, no un proyecto. Un proceso vago no se puede implementar de forma productiva. Y, lo que es peor, no se puede fallar de manera detectada: un agente con scope difuso falla silenciosamente, y nadie sabe cuándo.

La pregunta de filtro es concreta: ¿qué métrica cambiará en la semana cuatro?

Si la respuesta es “mejorar la atención al cliente” o “ser más eficientes”, no es una respuesta: es una aspiración. La respuesta que aceptamos es de otro tipo: “el porcentaje de borradores de pedido aceptados sin edición humana pasará del 0% actual al 70% en cuatro semanas.” O: “el tiempo medio de primera respuesta a correos de soporte pasará de 6 horas a menos de 30 minutos.”

Con una métrica de este tipo, el proyecto tiene forma. Podemos definir casos de éxito, casos límite y condiciones de fallo. Podemos diseñar un harness de evaluación. Podemos saber si el agente funciona o no.

Sin ella, estamos haciendo un proyecto de investigación, y nadie le ha explicado al cliente que él paga por la investigación.

Condición 2: interoperabilidad verificable vía MCP

Un agente que no toca las herramientas del negocio no es un agente. Es un chatbot caro.

La distinción es funcional. Un chatbot conversa. Un agente ejecuta acciones reales: leer un correo, identificar al cliente en el CRM, consultar el stock en el ERP, crear un borrador de pedido, derivar a una persona cuando el caso es ambiguo. Si el agente no hace ninguna de estas acciones, no reduce horas de trabajo mecánico. Reduce tiempo de respuesta a preguntas, que es un problema diferente.

Hoy, el estándar que permite verificar esta interoperabilidad de forma auditable es el Model Context Protocol (MCP). Un agente con integraciones documentadas vía MCP permite saber exactamente: con cuántos sistemas habla, cómo habla, y con qué permisos. Si un proveedor no puede describir las integraciones de su agente en términos de herramientas, métodos y permisos, la gobernanza del sistema es difícil de establecer.

La pregunta de filtro: ¿con cuántos sistemas internos habla el agente vía MCP, y qué métodos expone cada uno?

No hace falta que el cliente entienda el protocolo en detalle. Debe entender la lista: “el agente lee del CRM, escribe borradores de pedido en el ERP, no escribe en el CRM, no envía correos de forma autónoma.” Con esta lista, el cliente sabe exactamente dónde puede fallar el agente y qué alcance tiene un error.

Condición 3: kill-switch efectivo en menos de cinco minutos

El mecanismo para apagar el agente es la primera pieza que se diseña, no la última.

El argumento es operativo. Un agente que toca datos reales puede causar daño rápidamente. Si un agente procesa pedidos de WhatsApp y empieza a generar entradas incorrectas en el ERP, el daño es proporcional al número de pedidos que pasan hasta que alguien lo detecta y para el sistema. Si llegar al proveedor tarda dos horas, el daño puede ser de dos horas de pedidos incorrectos.

El kill-switch correcto cumple tres condiciones:

1. Accionable por el cliente. No hace falta llamar al proveedor. Puede ser una variable de entorno, un botón en el panel de administración, una llamada API documentada, o una configuración en la herramienta interna del cliente. Lo que no es un kill-switch es decir “manda un correo al equipo de serpixel y respondemos en dos horas”.

2. SLA de efectividad inferior a cinco minutos. Desde el momento en que el cliente lo pulsa hasta que el agente deja de procesar nuevos casos. No desde que el cliente envía la solicitud: desde que pulsa el botón.

3. Fallback humano documentado. El kill-switch no está completo sin saber quién coge el proceso cuando el agente está apagado. Si el agente procesa 200 pedidos al mes y se apaga, alguien los tiene que procesar. Esa persona, con qué herramientas y en qué tiempo, tiene que estar documentado en el SOW y probado, no pensado deprisa mientras el proceso se acumula.

La pregunta de filtro: ¿en cuántos minutos puedo parar el agente si empieza a causar daño, y sin llamar a nadie?

Condición 4: harness de evaluación en producción

La diferencia entre un agente que se implementa y un agente que funciona a largo plazo es la evaluación continua.

Un harness de evaluación offline es un conjunto de casos de prueba estáticos: 50 mensajes representativos con las respuestas esperadas, que pasan automáticamente contra el modelo y marcan pass/fail. Sirve para verificar el comportamiento inicial, para detectar regresiones cuando cambias una versión del modelo. Pero no es evaluación de producción.

Un harness de producción evalúa el agente sobre tráfico real. Casos reales, con las distribuciones de entradas que el negocio genera cada día: mensajes en el idioma del cliente real, con los errores ortográficos de los clientes reales, con las referencias a productos con nombres no estándar que ponen los clientes reales. Mide cuatro cosas:

• Precisión. ¿Qué porcentaje de casos procesa el agente correctamente?
• Latencia. ¿Cuánto tiempo tarda en procesar cada caso?
• Coste por acción. ¿Cuál es el coste de inferencia por caso procesado?
• Deriva de comportamiento. ¿La calidad de hoy es la misma que hace un mes?

La deriva importa. Los modelos de lenguaje cambian (nuevas versiones, fine-tunings del proveedor), los datos del negocio cambian (nuevos productos, nuevos procesos, nuevos tipos de cliente), y el comportamiento del agente puede degradarse sin que nadie lo note hasta que lo nota el cliente.

La pregunta de filtro: ¿quién leerá los datos de evaluación cada semana, y qué decisión estará asociada a la lectura?

Si no hay una persona designada y una decisión asociada (si la precisión baja del umbral X, se hace Y), el harness es un instrumento sin nadie al volante.

El contrato es la garantía mínima

Cuatro condiciones. Scoping acotado, interoperabilidad verificable, kill-switch efectivo, evaluación continua. Ninguna de las cuatro es sofisticada: todas se pueden explicar en cinco minutos a un director de operaciones sin formación técnica.

Lo que las hace difíciles no es la comprensión: es que requieren trabajo previo. Documentar el proceso paso a paso es incómodo. Definir una métrica de resultado con baseline es difícil cuando no hay datos previos. Diseñar el kill-switch y el fallback humano requiere imaginar un fallo que nadie quiere que ocurra. Montar el harness de producción desde el primer día es más caro que no tenerlo.

Pero el coste de omitir cualquiera de las cuatro no recae sobre el proveedor. Recae sobre el negocio del cliente.

Esta es la razón por la que no firmamos implementaciones que no cumplan las cuatro. No es una postura comercial. Es la única manera que conocemos de garantizar que lo que ponemos en producción funciona cuando importa y se puede parar cuando falla.

Si tienes una idea de proceso y quieres saber si pasa este filtro, hablamos 30 minutos. Llevamos el proceso sobre la mesa y salimos sabiendo si hay un agente que tiene sentido implementar, y si lo hay, cuáles serían las cuatro condiciones aplicadas a tu caso.