Mantenimiento de un agente IA: qué debe prever el contrato

Nicolas12 de noviembre de 202612 min de lectura

Un agente IA que funciona el día de la validación no funcionará necesariamente seis meses después. El modelo subyacente cambia de versión, una API evoluciona, los datos de entrada se transforman, y el primer incidente serio llega antes de que alguien haya decidido quién interviene y a qué precio. La mayoría de los contratos que se firman hoy describen la construcción, muy rara vez la vida del sistema después de la puesta en producción. La factura se paga entonces en jornadas de corrección fuera de presupuesto o, peor aún, en un agente desconectado por falta de acuerdo sobre los costes.

Key Takeaways
Un contrato de mantenimiento de agente IA debe cubrir tres perímetros distintos: la corrección de averías, la adaptación a cambios externos (modelos, conectores, datos) y las evoluciones que pide el negocio.
Las tres causas de cancelación citadas por Gartner (2025) son los costes que se descontrolan, el valor poco claro y los controles de riesgo insuficientes: cada una tiene su cláusula.
Sin tope de consumo ni cláusula de no regresión, la actualización de un modelo de terceros puede mover la factura y la calidad sin que el cliente tenga voz.
Los accesos (claves de API, repositorio, prompts, registros) y la salida del contrato se negocian en la firma, no en el momento del divorcio.
Ningún ratio estándar dice cuántas horas prever: pida al proveedor que justifique su tarifa fija con el historial de sus propios incidentes.

Por qué un agente se degrada aunque el código no cambie

Un agente IA no es un programa inmóvil. Es una cadena de componentes, varios de los cuales pertenecen a terceros: el modelo, los conectores hacia las herramientas de negocio, los datos de referencia, la orquestación y los prompts que sostienen el conjunto. El código que usted pagó puede seguir idéntico hasta el último carácter mientras el comportamiento del sistema cambia, porque uno de los eslabones se movió al otro lado de la frontera.

Tres movimientos producen la mayoría de los incidentes:

El modelo cambia. Los proveedores publican nuevas versiones, retiran las antiguas y a veces modifican el formato de las respuestas. Un agente ajustado a una versión precisa deja de funcionar el día en que esa versión se retira, a menudo con poco preaviso.
Los datos cambian. Un plan contable revisado, un catálogo nuevo, una renovación del sitio web o la fusión de dos bases bastan para romper una clasificación o una extracción que funcionaba.
El uso cambia. El agente trataba 40 solicitudes al día, ahora trata 400. Los límites de peticiones, los tiempos de respuesta y el coste por consulta no siguen la misma curva.

Esto es lo que mide Gartner cuando la firma estima que solo unos 130 proveedores, entre los miles que se presentan como proveedores de IA agéntica, ofrecen capacidades reales de agente. La distancia entre la demostración y la producción se ha convertido en un asunto de contrato, no en un asunto técnico.

Las seis cláusulas que marcan la diferencia

Un contrato de mantenimiento legible se reduce a seis bloques. Si falta uno, faltará en el peor momento.

Cláusula	Qué debe decir	Qué cuesta su ausencia
Perímetro	Qué incidentes están cubiertos, con qué tarifa fija (horas, tickets, días) y a partir de cuándo una solicitud pasa a ser una evolución facturada	Cada corrección se convierte en una negociación y el presupuesto se desvía sin tope
Actualizaciones del modelo	Quién vigila las versiones, quién prueba antes del cambio, quién paga la puesta al día tras una retirada	El agente cae en la fecha impuesta por el proveedor y la reparación se factura como urgencia
Costes variables	Quién paga el consumo, con qué tope mensual, qué umbral de alerta y qué nivel de detalle en la factura	Una factura de API imprevisible, descubierta a final de trimestre
Supervisión y registros	Qué indicadores se siguen, con qué frecuencia, en qué formato y con qué acceso para el cliente	Un incidente avisado por un usuario molesto antes de que lo avise el sistema
Propiedad y accesos	A quién pertenecen los prompts, el código, los juegos de prueba y los registros; qué accesos se entregan al cliente	Una dependencia total: imposible que otro proveedor retome el sistema
Duración y salida	Duración firme, preaviso, procedimiento de fin, inventario de entrega y traspaso de activos	Una renovación tácita que le ata un año más, o una salida sin documentación

La columna central es la que se discute. La de la derecha es la que cuesta.

Actualizaciones del modelo: exija una cláusula de no regresión

El punto que más se olvida y el más caro. Su agente se calibró sobre una versión concreta de un modelo. El día en que el editor anuncia su retirada se abren dos caminos: migrar con prisa o dejar que el agente se pare.

Una cláusula de no regresión correcta se apoya en cuatro compromisos:

Versión fijada. El contrato nombra la versión utilizada y prohíbe cualquier cambio sin validación escrita.
Vigilancia y preaviso. El proveedor se compromete a avisar en cuanto se anuncie una retirada, con la fecha de fin de soporte y un plan de migración.
Juego de pruebas. Se conserva un conjunto de casos de referencia que se reejecuta antes de cualquier cambio. Es la única forma de demostrar que un modelo nuevo no degrada las respuestas.
Quién paga. La migración impuesta por un tercero no es una evolución de negocio. Debería estar incluida en la tarifa de mantenimiento o, al menos, presupuestada de antemano. Es exactamente el tipo de arbitraje que conviene escribir en blanco y negro, y también lo primero que revisamos en una auditoría y consejo de un dispositivo existente.

Sin esos cuatro puntos, la calidad de su agente depende de un calendario decidido en otra parte. Gartner cifra el riesgo: al menos el 30 % de los proyectos de IA generativa se abandonarán tras la fase de prueba antes de finales de 2025, por la calidad de los datos, controles de riesgo insuficientes, costes que suben o valor de negocio poco claro, según Gartner (2024). Un abandono de cada tres no es un problema de modelo: es un problema de explotación.

Costes variables: tope, alerta, refacturación

Un agente cuesta dos veces. Una para construirlo, otra para hacerlo funcionar. El segundo gasto es variable: depende del volumen de solicitudes, de la longitud de los contextos y del modelo elegido. Un contrato que no menciona ese gasto lo deja mecánicamente a cargo del cliente, sin límite y sin visibilidad.

Tres elementos que deben figurar:

Un tope mensual de consumo, con la regla aplicada en caso de exceso: parada, paso a un modelo más económico o acuerdo previo.
Un umbral de alerta, por ejemplo al 80 % del tope, dirigido a una persona con nombre y no a un buzón de soporte.
Una facturación detallada por uso, con el volumen de solicitudes, el coste unitario y el total. Un proveedor que no puede producir ese nivel de detalle no puede pilotar su presupuesto.

Añada la infraestructura y las licencias de las herramientas conectadas (base vectorial, plataforma de orquestación, herramienta de tickets): son suscripciones que se acumulan y que nadie vigila una vez entregado el proyecto. La automatización de un proceso de negocio multiplica ese tipo de dependencias, lo que hace aún más necesario el seguimiento presupuestario.

Propiedad, accesos y salida: se negocian en la firma

Un agente IA concentra activos que tienen valor y que a menudo están mal documentados: los prompts, los juegos de prueba, los conectores, los registros de ejecución, las reglas de negocio codificadas en la orquestación. Si el contrato no dice a quién pertenecen, el proveedor saliente los considera su saber hacer y el entrante empieza de cero.

Lo que hay que asegurar:

La propiedad explícita del código, los prompts y los juegos de prueba, con una licencia de uso para los componentes de terceros.
La entrega de los accesos durante el contrato, no al final: repositorio de código, cuentas de API, consola del proveedor del modelo, herramienta de orquestación. No una copia, los accesos reales.
La conservación y entrega de los registros de ejecución, con la duración prevista por la ley y por sus propias obligaciones de cumplimiento.
Un procedimiento de fin: preaviso de salida, inventario de entrega, documentación de explotación, periodo de asistencia a la reanudación.

El tema se trata en detalle en dos artículos vecinos: a quién pertenece un agente desarrollado para usted y cambiar de proveedor sin perderlo todo. Un tercero, más previo, detalla qué debe contener un presupuesto de agente IA antes incluso de hablar de mantenimiento.

Lo que no debería figurar en un contrato de mantenimiento

Algunas cláusulas vacían el contrato de su sustancia. Se detectan rápido.

«El proveedor no es responsable de las evoluciones de los modelos de terceros». Tomada al pie de la letra, esa frase excluye la mayoría de las averías reales. Puede entenderse para un cambio de tarifa impuesto por el editor, no para un agente que deja de responder.
Una tarifa que solo cubre la corrección. La adaptación a los datos y a los conectores es la parte más frecuente del trabajo. Dejarla fuera del perímetro es organizar la facturación por intervención.
Un compromiso de disponibilidad sin indicador. «La mejor disponibilidad posible» no compromete a nada. Hace falta una medida, una fuente de esa medida y una consecuencia en caso de incumplimiento.
Un preaviso de resolución largo con renovación tácita. Doce meses de preaviso sobre un sistema que cambia cada trimestre es una trampa.

A la inversa, los compromisos de plazo de restablecimiento y los niveles de servicio merecen una negociación aparte, tanto varían las fórmulas según la criticidad del proceso automatizado. Ese asunto tiene su propio artículo.

Cómo leer una propuesta de mantenimiento en una hora

Un método simple, sin necesidad de competencia técnica:

Resalte cada aparición de la palabra «evolución». Acaba de encontrar la frontera entre la tarifa fija y la facturación por intervención.
Busque la palabra «modelo» y compruebe que se nombra una versión. Sin versión, no hay compromiso.
Busque un tope de consumo. Si no aparece, pídalo.
Cuente las entregas periódicas: informe de incidentes, consumo, indicadores de calidad. Sin entregas, no hay pilotaje.
Compruebe qué recupera en caso de salida y en qué plazo.
Pida el historial: cuántos incidentes ha tratado el proveedor en dispositivos comparables y en cuánto tiempo. Es la única base honesta para dimensionar una tarifa.

Un proveedor serio responde a esas seis preguntas por escrito. Un proveedor que responde «lo veremos caso por caso» en realidad le propone pagar el mantenimiento a precio de urgencia, incidente a incidente. La misma lógica se aplica cuando compara proveedores: las señales de alerta suelen ser visibles antes de la firma, como recuerda nuestro artículo sobre los proveedores de IA poco serios.

Preguntas frecuentes

¿Hay que pagar mantenimiento desde el primer año?

Sí, pero no al precio de un año completo de explotación. El primer año contiene un periodo de estabilización durante el cual se corrigen los defectos de juventud: corresponden a la garantía de buen funcionamiento, no a una tarifa de mantenimiento. Pida una garantía explícita de tres a seis meses tras la validación y después una tarifa que empiece al terminar esta.

¿Qué pasa si el proveedor del modelo retira la versión utilizada?

Hay tres desenlaces posibles y solo uno es aceptable: la migración está planificada e incluida en la tarifa. Los otros dos son la migración facturada como urgencia o el agente que se detiene en la fecha de fin de soporte. La cláusula de no regresión descrita antes existe para hacer obligatorio el primer desenlace.

¿El mantenimiento cubre las nuevas necesidades?

No, y es normal: una necesidad nueva es un proyecto, con su propio encuadre y su propio precio. Lo que debe cubrirse es la adaptación del sistema a un entorno que cambia sin que usted haya pedido nada. La distinción entre adaptación sufrida y evolución solicitada es el punto más rentable de aclarar en todo el contrato.

¿Cuántas horas o días hay que prever cada mes?

Ningún ratio estándar se aplica, y quien le dé uno sin mirar su dispositivo lo está inventando. La cifra correcta se construye con tres datos: el número de integraciones con sistemas de terceros, el volumen de cambios previstos en esos sistemas y el historial de incidentes del proveedor. Pida que la tarifa se justifique con esos tres elementos y prevea una cláusula de revisión anual del volumen.

¿Se puede cambiar de proveedor a mitad de contrato?

Técnicamente sí, siempre que se tengan los accesos y la documentación. Es precisamente por eso que la cláusula de entrega de accesos y el inventario de fin deben firmarse al principio. Si el proveedor se niega a nombrar los activos que posee, considere que la salida será conflictiva y negocie ese punto antes que cualquier otro.

Conclusión

El mantenimiento de un agente IA no es un servicio accesorio añadido al final del presupuesto. Es la cláusula que decide si su sistema aguanta en el tiempo o se apaga al primer cambio de modelo. Tres perímetros, un tope de consumo, una cláusula de no regresión, accesos reales y una salida organizada: cinco puntos que obtener antes de la firma, y muchas menos sorpresas desagradables después.

NexeAI acompaña a los dirigentes de pymes en estos temas, desde el encuadre inicial hasta la reanudación de un dispositivo existente: auditoría y consejo, diseño de agentes IA y formación de los equipos que van a explotarlos. Si tiene un contrato de mantenimiento sobre la mesa y dudas sobre su perímetro, escríbanos: le diremos qué falta, cláusula por cláusula.

Compartir este artículo