Contrato desarrollo ia clausulas — Guía práctica para revisar contratos de desarrollo con IA: propiedad, mantenimiento, datos, proveedores y dependencias de modelos.
Un contrato de desarrollo con IA debe dejar claro quién posee el software, qué datos puede usar el proveedor, cómo se mantienen los modelos y quién responde cuando el sistema falla. Las cláusulas que gobiernan propiedad intelectual, acceso a datos, dependencias de modelos, criterios de aceptación y salida del proveedor son las que definen si el cliente queda en control o en rehén. Esta guía no es asesoría legal: es una lectura técnica para que equipos de producto, ingeniería y dirección sepan qué revisar antes de firmar.
La urgencia no es teórica. McKinsey reportó en 2024 que el 65% de las organizaciones ya usaba IA generativa de forma regular, casi el doble que diez meses antes (McKinsey, 2024). Stack Overflow encontró que el 62,3% de los desarrolladores profesionales usaba herramientas de IA en el proceso de desarrollo en 2024, frente al 44% del año anterior (Stack Overflow Developer Survey, 2024). Cuando una práctica se vuelve parte del delivery cotidiano, el contrato tiene que tratarla como condición operativa, no como nota al pie.
Datos clave del sector:
Gartner proyecta que para finales de 2026, el 40% de las apps empresariales tendrán agentes IA integrados.
El 80% de las empresas que desplegaron agentes IA reportan ROI medible en menos de 6 meses.
Las empresas que implementan agentes IA recuperan entre 40 y 60 minutos por empleado por día.
Por qué un contrato de software tradicional no alcanza para proyectos con IA
Un contrato estándar cubre alcance, entregables, precio, plazos, soporte y propiedad del código. En proyectos con IA, eso es necesario pero insuficiente. La solución puede depender de modelos externos, datos internos, prompts, pipelines de evaluación, embeddings, bases vectoriales, agentes y herramientas de terceros. Además, el comportamiento del sistema varía cuando cambia el modelo, el proveedor, el contexto disponible o la calidad de los datos.
“Ver también: Arquitectura multi-agente produccion sin humo
Dos marcos ayudan a ordenar la discusión técnica antes de convertirla en lenguaje legal:
- Teoría principal-agente: el cliente delega en un proveedor que sabe más sobre el stack real, las herramientas usadas, los datos procesados y los límites de los modelos. Esa asimetría no desaparece con confianza comercial. Se reduce con disclosure de herramientas, criterios de aceptación, auditoría y obligación de informar dependencias críticas.
- NIST AI Risk Management Framework: transforma "riesgo de IA" en funciones operativas concretas: gobernar, mapear, medir y gestionar. Llevado al contrato, eso significa definir gobernanza, clasificación de riesgos, pruebas, monitoreo, documentación, intervención humana y respuesta ante incidentes (NIST AI RMF 1.0).
Cómo definir el alcance para que los entregables sean verificables
La primera cláusula crítica es el alcance. "Crear un asistente de ventas" es vago; "crear un asistente que consulte documentación aprobada, redacte respuestas sugeridas y permita revisión humana antes de enviarlas" es verificable. La segunda descripción permite evaluar el sistema, limitar riesgos y separar automatización de asistencia.
El contrato debería identificar:
- Flujos principales que cubrirá la solución y qué queda fuera.
- Sistemas con los que se integrará, idiomas y canales soportados.
- Tipos de usuarios y permisos.
- Entregables técnicos: repositorio, documentación, configuración, scripts, pruebas, ambientes y credenciales.
- Criterios de aceptación verificables: casos de prueba, escenarios de ejemplo, revisión de seguridad y comportamiento ante errores.
Si el proveedor usa IA para acelerar el desarrollo, esa decisión también debe estar cubierta. No hace falta prohibirla, pero sí definir herramientas autorizadas, límites para datos del cliente, revisión humana de entregables y responsabilidad por licencias. La IA puede asistir al equipo; no debería diluir la responsabilidad profesional del proveedor.
Propiedad intelectual: cómo separar código, prompts y activos intermedios
La propiedad intelectual debe separar piezas. Si todo se agrupa bajo "la solución", aparecen conflictos más tarde. Un contrato bien planteado debería distinguir:
| Activo | Titular habitual |
|---|---|
| Código fuente desarrollado para el cliente | Cliente |
| Componentes preexistentes del proveedor | Proveedor |
| Librerías open source | Terceros (licencia aplicable) |
| Prompts y plantillas de instrucciones | A definir explícitamente |
| Configuraciones de agentes o workflows | A definir explícitamente |
| Índices, embeddings o bases vectoriales | A definir explícitamente |
| Datos aportados por el cliente | Cliente |
| Datos generados durante el uso | A definir explícitamente |
| Documentación técnica y operativa | Cliente |
El punto delicado son los activos intermedios: prompts, evaluaciones, pipelines, scripts de ingestión y conectores. Aunque no sean "la app" visible, pueden ser esenciales para mantenerla. Si el cliente no tiene acceso a ellos, queda dependiente del proveedor para cualquier cambio operativo.
Uso de datos: qué procesar, dónde, cuánto tiempo y con quién
La cláusula de datos debe indicar qué datos se usan, para qué, dónde se procesan, quién puede acceder y durante cuánto tiempo se conservan. En soluciones con IA, los datos aparecen en muchos lugares: logs, prompts, respuestas del modelo, documentos indexados, capturas de errores, trazas de agentes y entornos de prueba.
El contrato debe responder explícitamente:
- ¿Qué datos del cliente se pueden procesar?
- ¿Se permite usar datos reales en desarrollo o solo datos anonimizados?
- ¿El proveedor puede usar datos del cliente para entrenar, ajustar o mejorar modelos?
- ¿Qué proveedores externos reciben datos?
- ¿Qué ocurre con los datos al terminar el contrato?
- ¿Cómo se eliminan copias, logs e índices?
La autorización para entrenar modelos debe ser explícita. La confidencialidad general ya no alcanza si no regula herramientas de IA. La cláusula debería cubrir entrenamiento, logging, retención, subprocesadores, entornos no aprobados y eliminación de copias derivadas.
IBM reportó que el costo promedio global de una filtración de datos llegó a USD 4,88 millones en 2024, y que el uso extensivo de IA y automatización en seguridad redujo el costo promedio de brecha en USD 1,88 millones (IBM, 2024). La IA puede reducir riesgo cuando está gobernada; puede ampliarlo cuando mueve datos sin control.
Dependencias de modelos y proveedores externos: qué pasa cuando algo cambia
Muchas soluciones de IA dependen de modelos alojados por terceros. Esa dependencia afecta disponibilidad, costos, privacidad, latencia y calidad de salida. El contrato debe identificar las dependencias relevantes y definir qué pasa si un modelo cambia, sube de precio, deja de estar disponible o deja de cumplir requisitos.
Una buena cláusula de dependencia debería cubrir:
- Quién aprueba cambios de modelo y cómo se prueban antes de producción.
- Quién asume costos adicionales por migración o recalibración.
- Qué alternativas existen si un proveedor externo falla.
- Qué nivel de portabilidad debe mantener la solución.
- Qué partes del sistema quedan acopladas a un proveedor específico.
Gartner proyectó que el 75% de los ingenieros de software empresariales usará asistentes de código con IA para 2028, frente a menos del 10% a inicios de 2023 (Gartner, 2024). Las herramientas de IA se vuelven parte del proceso; el contrato debe pedir visibilidad suficiente sobre las que afectan seguridad, propiedad, costo o continuidad.
Seguridad y control de accesos en sistemas que ejecutan acciones
La IA no elimina las obligaciones normales de seguridad; las amplía, porque el sistema puede tener acceso a documentos, datos internos, herramientas y acciones automatizadas. El contrato debe exigir:
- Controles de acceso por rol y gestión segura de secretos.
- Separación de ambientes y protección de datos sensibles.
- Registro de operaciones relevantes y trazabilidad de acciones.
- Protocolo de notificación, investigación y mitigación ante incidentes.
En sistemas con agentes, la seguridad debe incluir límites de herramientas. Un agente con acceso amplio puede producir daños aunque el modelo no tenga "intención". El contrato debe reflejar qué acciones están permitidas, cuáles requieren aprobación humana y cuáles están prohibidas.
Mantenimiento en IA: por qué "arreglar bugs" no es suficiente
Una solución con IA no queda congelada después del despliegue. Cambian modelos, datos, documentos, APIs, dependencias, patrones de uso y expectativas de calidad. Mantenimiento puede incluir actualización de prompts, revisión de evaluaciones, reindexación de documentos, monitoreo de costos, ajuste de límites, actualización de librerías y análisis de respuestas problemáticas.
El contrato debería definir:
| Dimensión | Qué precisar |
|---|---|
| Alcance del soporte | Qué está incluido, qué se considera bug vs. mejora |
| Tiempos de respuesta | Por severidad |
| Monitoreo | Quién monitorea costos, errores y latencia |
| Cambios en producción | Cómo se aprueban |
| Documentación | Qué se mantiene actualizada y por quién |
Si el mantenimiento queda fuera del alcance inicial, debe decirse con claridad. El cliente debería saber qué esfuerzo operativo necesita después del lanzamiento: la IA no es solo una entrega, es una capacidad que requiere cuidado continuo.
Criterios de calidad y responsabilidad por errores del sistema
En IA, la calidad no se mide igual que en software determinista. Puede haber respuestas variables, falsos positivos, omisiones o resultados correctos con redacción distinta. El contrato debe evitar promesas absolutas, pero tampoco puede aceptar calidad indefinida. La solución está mejor protegida cuando existen escenarios de evaluación, criterios de aceptación y límites documentados.
Cuando el sistema comete un error, la responsabilidad debe conectarse con causa, alcance y controles. No es igual:
“Ver también: Agentes ia desarrollo software: valor para clientes
- Un error por implementación defectuosa.
- Un error por datos desactualizados o mal diseño de prompt.
- Un uso fuera del alcance previsto.
- Una decisión humana tomada contra advertencias del sistema.
La supervisión humana no debe ser una frase decorativa. Debe estar integrada en los flujos donde el impacto lo justifique: aprobaciones, revisión, registro de decisiones, reversión de acciones y escalamiento.
Licencias y componentes de terceros: lo que no conviene descubrir tarde
El contrato debe exigir que el proveedor respete licencias aplicables y comunique restricciones relevantes. No significa aprobar cada paquete menor, pero sí que el cliente no debería descubrir que una pieza esencial impone limitaciones incompatibles con su uso comercial.
En entregables asistidos por IA, esta cláusula debería cubrir:
- Dependencias con licencias incompatibles con uso comercial.
- Generación accidental de contenido infractor.
- Paquetes sugeridos sin revisión de licencias.
- Ausencia de trazabilidad sobre componentes críticos.
Una práctica útil es pedir inventario de dependencias relevantes, revisión de licencias, SBOM cuando el contexto lo justifique y obligación de remediación si aparece un conflicto.
Salida del proveedor: cómo garantizar continuidad operativa al cambiar
Una de las cláusulas más subestimadas es la salida. El cliente necesita más que el código: puede necesitar documentación, variables de configuración, instrucciones de despliegue, scripts de migración, descripción de servicios externos, estructura de datos, prompts, evaluaciones y procedimientos de operación.
El contrato debe definir qué se entrega al cierre, en qué formato y bajo qué condiciones, incluyendo transferencia de conocimiento, eliminación de accesos, entrega de credenciales administradas por el cliente y soporte de transición. Una buena salida no significa romper la relación; significa que la relación no depende de una caja negra.
Señales de alerta antes de firmar
Hay señales que conviene revisar con cuidado antes de firmar:
- El contrato no menciona datos ni proveedores externos.
- La propiedad intelectual se define de forma genérica.
- No queda claro si los datos pueden usarse para entrenar modelos.
- El proveedor no entrega prompts, configuraciones ni documentación.
- No existen criterios de aceptación.
- El mantenimiento se describe solo como "soporte".
- No hay plan si cambia el modelo o suben los costos.
- La solución depende de una cuenta controlada por el proveedor.
- No se explica cómo terminar el contrato sin perder operatividad.
Ninguna de estas señales implica mala fe. Sí indica que el contrato no refleja la realidad técnica del proyecto.
Cómo revisar el contrato desde ingeniería antes de que lo firme legal
La revisión legal es imprescindible, pero ingeniería puede aportar preguntas que reducen riesgo práctico. Antes de firmar, conviene reunir a producto, tecnología, seguridad, operaciones y legal para revisar:
- ¿Podemos operar esto sin el proveedor?
- ¿Sabemos qué datos salen de nuestros sistemas?
- ¿Podemos cambiar de modelo si hace falta?
- ¿Tenemos pruebas para aceptar la entrega?
- ¿Sabemos cuánto puede costar operar la solución?
- ¿Está claro qué pasa después del lanzamiento?
- ¿Tenemos acceso a los activos necesarios para mantenerla?
La adopción legal de IA también está avanzando: LegalOn Technologies reportó que el uso de IA para revisión contractual creció 75% interanual, con el 14% de los equipos legales encuestados ya usándola, frente al 8% a inicios de 2024 (LegalOn Technologies, 2025). Legal e ingeniería pueden trabajar con playbooks, riesgos, evidencias y criterios verificables, en lugar de revisar la IA como una categoría abstracta.
Cómo ayuda solu30
En solu30 ayudamos a equipos que están evaluando, contratando o construyendo soluciones con IA a traducir objetivos de negocio en arquitectura, criterios técnicos y condiciones operativas claras. Podemos acompañar la revisión técnica de propuestas, definir alcances realistas, identificar dependencias de modelos, diseñar criterios de aceptación y preparar una base sólida para que legal trabaje con menos ambigüedad.
No damos asesoría legal, pero sí ayudamos a que el contrato refleje cómo la solución va a funcionar en producción.
“Ver también: Empresas: interfaces conversacionales de datos
Checklist para evaluar si un agente IA está listo para producción:
- El agente fue testeado con casos reales de error, no solo el "happy path"
- Tiene un umbral de confianza definido: si no llega, escala a humano
- Los logs de decisión son auditables por el equipo
- El rollback está documentado y es ejecutable en <30 minutos
- Hay un responsable humano asignado para revisión periódica
Preguntas frecuentes
¿Qué cláusulas son más importantes en un contrato de desarrollo con IA?
Las más importantes suelen ser propiedad intelectual, uso de datos, confidencialidad, seguridad, mantenimiento, dependencias de modelos, criterios de aceptación, responsabilidad, componentes de terceros y salida del proveedor.
¿Conviene exigir la propiedad de los prompts?
Depende del proyecto, pero si los prompts son esenciales para operar o mejorar la solución, el cliente debería tener acceso, licencia suficiente o propiedad según lo acordado. No deberían quedar ocultos si son parte central del valor entregado.
¿Qué debe decir el contrato sobre datos sensibles?
Debe definir qué datos pueden procesarse, quién accede, dónde se almacenan, cuánto tiempo se conservan, cómo se protegen y cómo se eliminan. También debe indicar si terceros reciben datos y bajo qué condiciones.
¿El contrato debe mencionar modelos específicos?
Sí, cuando el modelo sea una dependencia relevante. También conviene definir cómo se aprueban cambios de modelo y cómo se evalúa su impacto en calidad, costo, privacidad y disponibilidad.
¿Qué pasa si la IA genera una respuesta incorrecta?
El contrato debe conectar responsabilidad con causa, alcance y controles. No es igual un error por implementación defectuosa que un uso fuera del alcance o una decisión humana tomada contra advertencias del sistema.
¿Esta guía reemplaza la revisión de un abogado?
No. Esta guía es una referencia técnica y de producto. Un abogado debe revisar el contrato final, adaptar las cláusulas a la jurisdicción aplicable y validar obligaciones legales, regulatorias y comerciales.
¿Querés implementar esto en tu negocio?
En solu30 diseñamos e implementamos sistemas con IA aplicada: agentes, automatización, plataformas internas y software a medida. Si el tema de este artículo resuena con un problema real de tu operación, podemos ayudarte a pasar del concepto a algo que funcione en producción.
Contactanos en solu30.com y contamos el problema concreto.