Respuesta directa: un contrato de servicios de IA debe convertir promesas en evidencia verificable. Además de alcance, precio y plazo, el SOW debe definir resultado, aceptación, datos y propiedad intelectual, modelos y terceros, riesgo y seguridad, operación y cambios, además de transferencia y salida. La redacción jurídica depende de la jurisdicción; esta guía organiza decisiones comerciales y técnicas para revisión legal.
Los contratos tradicionales de software suelen tratar la entrega como determinista. El comportamiento de IA puede cambiar con datos, modelos, prompts, políticas y uso. Por eso, “funciona” no es un criterio suficiente. El contrato debe decir cómo se probará el desempeño, bajo qué condiciones, quién acepta el riesgo residual y qué ocurre cuando la solución se degrada.
AI Contract Evidence-7: siete evidencias antes de firmar
Para cada dimensión, exija una obligación, la evidencia que demuestra cumplimiento y la decisión resultante. Puntúe 0–3: ausente, descrita, medible o probada operativamente. Una propuesta barata sin evidencia de aceptación, datos o salida solo posterga costo y riesgo.
En una contratación regional, no copie el mismo anexo entre países sin revisión. Mantenga una arquitectura común de evidencias, pero documente responsables, residencia y transferencia de datos, subcontratistas, moneda, impuestos, idioma operativo, jurisdicción y requisitos sectoriales para cada mercado.
1. Resultado: ¿qué cambio de negocio se compra?
Defina proceso, audiencia, decisión o tarea, baseline, métrica y ventana de observación. Separe entregables — discovery, prototipo, integraciones, evaluaciones y runbooks — de resultados que también dependen de adopción del cliente. Asigne product owner, supuestos y dependencias. Evite “mejorar eficiencia con IA”.
2. Aceptación: ¿qué prueba libera cada fase y pago?
Anexe conjunto de evaluación, casos normales, excepciones, umbrales, revisión humana y ambiente de prueba. Cubra calidad, latencia, disponibilidad, costo por tarea, seguridad y experiencia. Defina quién ejecuta y observa, cómo se resuelven diferencias y cuándo se repite. Acepte evidencia, no una demo.
Use gates progresivos: continuar después de discovery; probar valor con datos representativos; readiness para producción; y estabilización post-lanzamiento. Sistemas probabilísticos pueden usar rangos, pero método, muestra y regla de decisión deben ser reproducibles.
3. Datos y propiedad: ¿quién puede usar qué y para qué?
Inventaríe inputs, datos derivados, feedback, logs, prompts, embeddings, outputs y datos personales. Especifique finalidad, acceso, retención, ubicación, eliminación, subprocesadores y uso para entrenamiento. Distinga activos previos de código, configuración, evaluaciones y contenido creados. Adapte todo a privacidad, PI y regulación sectorial local.
4. Modelos y terceros: ¿qué dependencias pueden cambiar?
Liste modelos, APIs, librerías, nubes, versiones y restricciones críticas. Exija informar sustituciones materiales, probar upgrades y evaluar impacto en precio, desempeño o derechos. Defina quién aprueba cambios, cómo se controla lock-in y qué componentes son reemplazables. La cadena debe ser suficientemente visible para gobernarla.
5. Riesgo y seguridad: ¿qué controles se vuelven obligaciones?
Conecte nivel de riesgo con accesos, separación de ambientes, evaluaciones, supervisión humana, red teaming proporcional, incidentes, logs y auditoría. NIST recomienda gestionar tecnologías y proveedores terceros durante el ciclo de vida; SP 800-218A aplica desarrollo seguro a software de IA. Defina plazos y responsabilidades sin prometer riesgo cero.
6. Operación y cambio: ¿quién mantiene la calidad?
Defina SLOs, observabilidad, soporte, escalamiento, costo operativo, mantenimiento de evaluaciones y revisión. Active revalidación ante cambios de modelo, datos, finalidad, autonomía o incidentes. Separe defecto, mejora y cambio de alcance. El Playbook de NIST pide monitoreo continuo de recursos terceros.
7. Transferencia y salida: ¿el cliente puede continuar o migrar?
Liste código, repositorios, documentación, configuración, prompts, evaluaciones, datos exportables, credenciales, runbooks y capacitación. Defina formato, plazo y prueba de portabilidad. Cubra transición, devolución o eliminación de datos y continuidad. La dependencia permanente puede ser una decisión económica, pero no una sorpresa.
Estructure el paquete contractual
- MSA: términos comerciales, confidencialidad, responsabilidad y reglas generales. SOW: resultado, fases, equipo, dependencias, precio, aceptación y cambios. Anexo de IA: datos, modelos, evaluaciones, riesgos y controles. Anexo operativo: SLOs, soporte, incidentes, monitoreo y costos. Plan de salida: portabilidad, transferencia y cierre.
Prueba final antes de firmar
Elija un escenario crítico y una falla plausible. Pida al proveedor identificar obligación, evidencia, decisor, tiempo y remedio. Si la respuesta depende de buena voluntad o de una reunión futura, el SOW no está listo. Las cláusulas modelo de la UE son referencia útil, pero no constituyen un contrato completo y requieren adaptación.
Próximo paso
Empiece con la guía de RFP en https://makinai.co/insights/es/como-crear-rfp-servicios-ia, compare estrategia e implementación en https://makinai.co/insights/es/consultora-estrategia-o-empresa-implementacion-ia y modele inversión en https://makinai.co/insights/es/cuanto-cuesta-consultoria-ia-presupuesto-plazo. Para conectar decisión, construcción y operación, visite https://makinai.co/services/es/consultoria-estrategia-ia-transformacion.