Un contrato de desarrollo común describe un mundo en el que el software se rompe por culpa del contratista. De ahí el período de garantía, el procedimiento de aceptación y la responsabilidad por defectos. Todo eso se sostiene mientras el producto consista en código que ambas partes ven y controlan.
Un agente de IA está hecho de otra manera. Además del código, incluye un modelo alquilado, un conjunto de instrucciones de texto para ese modelo y permisos de acceso a tus sistemas. El código no se va a ir a ninguna parte, pero el modelo tiene su propio calendario de vida. Y lo escribe el proveedor.
¿Por qué el modelo sobre el que funciona tu agente tiene fecha de retiro?
Los proveedores de modelos describen ese calendario públicamente. Anthropic distingue cuatro estados: active, con soporte completo; legacy, que ya no recibirá actualizaciones; deprecated, cuando el modelo todavía funciona pero ya tiene asignada una fecha de retiro y un reemplazo recomendado; y retired, cuando las solicitudes fallan con un error.
Anthropic avisa del retiro de un modelo lanzado públicamente con al menos 60 días de antelación a los clientes que lo tienen en producción. OpenAI mantiene una lista pública equivalente de modelos obsoletos con sus fechas de desactivación. La documentación señala aparte que las plataformas asociadas, Amazon Bedrock y Google Cloud, fijan sus propias fechas. El estado de un mismo modelo en la nube donde corre tu agente puede ser distinto del que tiene en la API del proveedor, y te vas a enterar en el peor momento.
Lo segundo que conviene saber antes de firmar: pasar a una versión nueva cuesta trabajo, y no el que presupuesta el cliente. En casa lo medimos así. En la primavera de 2026, Grow2.ai, nuestra división de IA, migró su propia flota de agentes a la siguiente versión del modelo: hubo que reescribir los prompts de sistema y arreglar varios bugs en la capa que envuelve al modelo, que la versión anterior, más lenta, disimulaba con éxito. Aparte, ajustamos las configuraciones de la API: el presupuesto fijo para el «pensamiento» del modelo dio paso a uno adaptativo; es decir, el límite dentro del cual antes acotábamos el gasto se calcula de otra forma en la versión nueva. Es nuestra propia medición sobre nuestra propia flota, no una norma del sector.
Ninguno de esos trabajos se parece a «cambiar la línea con el nombre del modelo». Y ninguno está descrito en un SOW típico.
Bloque 1. ¿Por qué los prompts son producto y deben figurar entre los entregables?
En el SOW hay una tabla de entregables con una columna de criterios de aceptación. En un proyecto de CRM contiene cosas claras: el informe de diagnóstico, el embudo configurado, la base importada. En un agente, la mayor parte del valor está en textos que no llegan a esa tabla.
Qué debe entrar en la lista:
- los prompts de sistema de todos los roles del agente, con su historial de versiones y no solo el último archivo en el momento de la entrega
- la configuración del modelo: identificador, parámetros de llamada, límites y restricciones
- el set de evaluación: escenarios con el resultado esperado descrito de antemano
- las descripciones de las herramientas y los esquemas de llamada, incluidos los permisos que la cuenta del agente recibe en tus sistemas
- el registro de decisiones: por qué el prompt está formulado así, qué variantes se descartaron y por qué motivo
La línea más valiosa aquí es la tercera. El set de evaluación es con lo que, dentro de seis meses, vas a demostrar que el agente se comporta distinto después de actualizar el modelo. Sin él, ambas partes describirán la calidad con palabras, y en una disputa las palabras no pesan nada. Preparar ese set es un trabajo aparte de varios días, y debe estar dentro del alcance o quedar honestamente fuera de él, con su propio precio.
Conviene atar la aceptación a ese mismo set. En las plantillas típicas el cliente tiene unos pocos días hábiles para aceptar por escrito o rechazar de forma motivada, y el silencio a menudo cuenta como aceptación. En un agente, «echar un vistazo» durante esos días no aporta casi nada: la aceptación debe significar ejecutar el set de evaluación y dejar registrado el resultado de cada escenario.
Bloque 2. ¿En qué se diferencia una licencia sobre los prompts de ser su propietario?
La sección de propiedad intelectual de un contrato de TI típico funciona así. Cada parte conserva lo que tenía antes de empezar el trabajo o lo que creó al margen de él: eso es el background IP. Y sobre los entregables el cliente recibe una licencia: tras el pago total, mundial y perpetua.
Después vienen tres palabras. En un proyecto de CRM nadie las lee; en uno de agentes conviene leerlas dos veces: no exclusiva, intransferible, no sublicenciable. Y además la precisión «para las necesidades internas del cliente». Usar los prompts se puede. Entregárselos a otro equipo para que los siga desarrollando, según la letra del texto, no.
Del otro lado del texto está el derecho del contratista a la reutilización. La redacción estándar le permite llevarse del proyecto conocimientos generales, técnicas, bibliotecas generalizadas y fragmentos de código, siempre que no se revele información confidencial del cliente. Sin esa cláusula el trabajo del contratista no tiene sentido económico: no puede reinventar el router para cada cliente.
La frontera hay que trazarla por el contenido. Conviene considerar específico del cliente lo que contiene su terminología, los nombres de las etapas de sus oportunidades, las reglas de descuento, los guiones del equipo de ventas, la lista de excepciones a la política. Y general, la arquitectura de la solución y las plantillas de las que se ha recortado todo lo anterior. Es mejor describir esa frontera con dos o tres ejemplos en el propio SOW: en una formulación abstracta se desdibuja ya en el primer mes de trabajo.
Bloque 3. ¿Cómo dejar por escrito el procedimiento de migración del modelo?
El contrato ya tiene el armazón para este bloque: la sección de gestión de cambios. Cualquiera de las partes presenta una solicitud por escrito, el contratista evalúa el impacto en el alcance, los plazos y el coste, y el cambio entra en vigor cuando ambas lo firman. Falta una sola cosa: un disparador que no dependa de la voluntad de las partes.
Aquí el disparador es que el proveedor publique la fecha de retiro o pase el modelo a deprecated. A continuación se describe quién hace qué:
- quién sigue los anuncios del proveedor y en qué plazo avisa a la otra parte
- cuánto tiempo hay para el análisis de impacto desde el momento del anuncio
- la ejecución del set de evaluación en el modelo nuevo antes del cambio, con un informe escrito de las diferencias
- si habrá una ventana en la que la versión anterior y la nueva funcionen en paralelo, y quién la paga
El dinero es donde suele estar el hueco. La palabra «soporte» casi nunca tiene definición en el contrato, y cada parte la entiende a su favor. Conviene separarlo así: la ejecución del set y el informe de diferencias entran en el soporte, y reescribir prompts por encima del número de horas acordado va como un change order aparte, a la tarifa del contrato. El número de horas lo pones tú, según el tamaño del agente; eso sí, no lo dejes sin nombrar.
Sobre la garantía, aparte. En los contratos típicos el período de garantía de conformidad con la especificación se cuenta en semanas después de la aceptación, no en meses. Una migración que ocurra ocho meses después no entra en esa ventana bajo ninguna interpretación, así que invocar la garantía en esa conversación es inútil. O has acordado la migración como un bloque aparte, o no la has acordado.
Bloque 4. ¿Qué se considera una migración fallida?
«El agente funciona después de la actualización» no es un criterio de aceptación: el criterio tiene que ser comparativo y numérico. Cómo tomar la línea base de la que sale ese número y cómo formular el umbral en el SOW se explica aparte, en el artículo sobre la tasa de aceptación; aquí solo importa que en el contrato figure una cifra y no un adjetivo.
Se ve más o menos así: sobre el mismo set de evaluación, la proporción de escenarios superados sin intervención humana no es inferior al valor base registrado antes de la migración, con una tolerancia acordada de antemano. La línea base se deja asentada en un acta: fecha, identificador del modelo y resultado de cada escenario por separado.
Aquí mismo conviene detallar qué se hace cuando no se alcanza el indicador. Nuestro procedimiento de aceptación da dos ciclos de corrección, tras los cuales el cliente tiene derecho a rescindir el SOW. Trasladar ese esquema tal cual a la migración es arriesgado para ambas partes: la diferencia puede resultar una propiedad del modelo nuevo y no de la calidad del trabajo del contratista. Una salida más sensata es volver al modelo anterior mientras siga disponible y revisar el alcance antes de su fecha de retiro.
También existe un caso peor: parte de los escenarios no se recupera en el modelo nuevo de ninguna manera, por más que se reescriba el prompt. Justamente por eso en el contrato debe constar quién paga por comprobar ese hecho. De lo contrario, la comprobación se convierte en una disputa sobre quién tiene la culpa y dura más que la migración misma.
¿Qué sigue sin garantizar el contrato?
Para esto no hace falta un «contrato de IA» aparte: los cuatro bloques encajan en las secciones existentes del contrato marco y del SOW. Pero hay un límite, y es mejor decirlo en voz alta antes de firmar.
Lo que no hacemos: no prometemos que la migración será gratis ni garantizamos que el comportamiento del agente se mantendrá idéntico después de cambiar de modelo. Esa garantía no la puede dar nadie que no escriba el modelo él mismo. Lo que sí se puede acordar es el orden de actuación, el reparto de costes y el criterio; con eso basta para que una actualización del modelo no se convierta en un conflicto.
Qué revisar en tu contrato vigente
- abre tu contrato vigente y busca la palabra «prompt» en la lista de entregables: si no está, esa es la primera corrección
- pregúntale al contratista si existe un set de evaluación para tu agente y dónde se guarda
- revisa en la documentación del proveedor qué estado tiene el modelo con el que trabajas ahora
El tercer punto lleva cinco minutos y con frecuencia resulta el más desagradable: el modelo con el que arrancaste hace seis meses ya está en la lista deprecated con fecha asignada.
Si después de esta revisión tienes en las manos un contrato sin ninguno de los cuatro bloques, envíanoslo. En una sola reunión vemos qué bloques faltan, qué corregir primero y qué de todo eso es siquiera negociable.
Y un detalle que por alguna razón nunca entra en el contrato y después cuesta una semana: quién tiene las claves de API y bajo qué razón social está registrada la cuenta con el proveedor del modelo. Revísalo de paso.