Respuesta corta: el contrato de un proyecto de software a medida o de IA debe dejar por escrito de quién es el código y los datos, qué se entrega en cada fase y cómo se acepta, qué cuesta de forma fija y qué varía con el uso (con un tope), y cómo salís si cambiáis de proveedor. En los proyectos con IA hay que añadir tres cosas que un contrato de software clásico no trae: que no se entrene ningún modelo con vuestros datos, qué pasa cuando el proveedor de IA retira o encarece un modelo, y el contrato de encargado del tratamiento del artículo 28 del RGPD.
Por qué un contrato de IA tiene riesgos que no tiene uno de software clásico
Un programa a medida clásico hace lo mismo hoy que dentro de tres años. Un proyecto con IA no, por tres motivos:
- El modelo no es vuestro ni del proveedor. Casi siempre es de un tercero (OpenAI, Anthropic, Google…), que publica versiones nuevas y retira las antiguas con su calendario. La siguiente versión puede responder distinto.
- Parte del coste depende del uso. Cada consulta al modelo se paga. Sin separar ese consumo y ponerle tope, la factura mensual es una incógnita.
- Vuestros datos viajan. Documentos y fichas de clientes pasan por el proveedor del proyecto, el del alojamiento y el del modelo. Cada eslabón debe estar cubierto por escrito.
Y algo que pasa también en el software clásico: pagar el desarrollo no os hace dueños del código si el contrato no lo dice bien.
Las 12 cláusulas imprescindibles
Para cada una, qué debe decir y una frase de ejemplo orientativa.
1. Propiedad del código y de los desarrollos
Según la Ley de Propiedad Intelectual (art. 43), una cesión de derechos queda limitada a lo que el contrato prevé expresamente: si no fija plazo, se limita a cinco años, y si no fija territorio, al país donde se firma. Por eso no basta con «el software será del cliente»: debe ceder en exclusiva los derechos de explotación (reproducción, transformación, distribución) del código hecho para vosotros, sin límite de tiempo y para todo el mundo. Lo que el proveedor ya tenía (sus librerías, su plataforma) puede seguir siendo suyo, con una licencia a vuestro favor perpetua, gratuita e irrevocable.
Ejemplo: «El proveedor cede al cliente, en exclusiva, con carácter mundial y por todo el plazo de protección legal, los derechos de explotación sobre el código fuente y objeto desarrollado en el marco de este contrato. Los componentes previos del proveedor, enumerados en el anexo II, se licencian al cliente de forma perpetua, no exclusiva, irrevocable y sin coste adicional».
2. Propiedad y ubicación de los datos
Los datos que metéis y los que genera el sistema (registros, conversaciones) son vuestros. El contrato debe decir dónde se guardan (mejor en la UE), quién accede, cada cuánto se copian y en qué formato podéis descargarlos.
Ejemplo: «Todos los datos aportados por el cliente o generados por el sistema son propiedad del cliente. Se alojarán en centros de datos situados en la Unión Europea, y el cliente podrá exportarlos en cualquier momento en formato CSV o JSON».
3. Prohibición de usar vuestros datos para entrenar modelos
Las condiciones de empresa de los grandes proveedores de modelos ya dicen que no entrenan con lo que reciben por su API. Pero el contrato con quien os hace el proyecto debe cerrar dos puertas: que no use vuestros datos para entrenar ni ajustar modelos, y que no los reutilice en proyectos de otros clientes.
Ejemplo: «El proveedor no utilizará los datos del cliente, ni los resultados generados con ellos, para entrenar, ajustar o evaluar modelos de IA ajenos a este proyecto, y solo contratará servicios de IA cuyas condiciones excluyan dicho uso».
4. Nivel de servicio y tiempos de respuesta
No es lo mismo una caída que un botón mal alineado. El contrato debe clasificar las incidencias por gravedad, con un tiempo de respuesta y un objetivo de resolución para cada una, un horario y un canal para avisar.
Ejemplo: «Incidencias críticas (el sistema no funciona): respuesta en 4 horas laborables. Graves (una función principal falla): 1 día laborable. Leves: 5 días laborables. Horario de atención: de lunes a viernes, de 9:00 a 18:00».
5. Qué pasa cuando cambia o se retira un modelo de IA, o sube su precio
Es la cláusula más propia de la IA y la que con más facilidad se olvida. Debe decir quién vigila los avisos de retirada, con cuánta antelación os avisan, quién paga la migración y cómo se comprueba que todo sigue respondiendo bien (con un juego de preguntas de prueba acordado al principio). Si el modelo sube de precio, debéis poder elegir entre asumirlo o cambiar a otro equivalente.
Ejemplo: «Si el proveedor del modelo anuncia su retirada o un cambio de precio superior al 20 %, el proveedor lo comunicará al cliente en un plazo de 10 días y propondrá una alternativa. La migración a una versión equivalente, incluida la repetición de las pruebas de aceptación, está incluida en el mantenimiento».
6. Precio cerrado y partidas variables, con su tope
Lo sensato es precio cerrado por fase para el desarrollo (lo explicamos en precio cerrado o por horas) y, aparte, lo que depende del uso: consumo de IA, alojamiento y licencias. Cada partida variable, con estimación para vuestro volumen, tope mensual y aviso antes de llegar a él. Mejor con las cuentas a vuestro nombre; si os las repercute el proveedor, que diga si cobra margen.
Ejemplo: «El consumo de servicios de IA se estima en 40 euros al mes para el volumen descrito en el anexo I. El proveedor avisará al cliente cuando se alcance el 80 % del tope mensual de 80 euros, y no se superará sin autorización por escrito».
7. Criterios de aceptación de cada entrega
Cada fase se paga cuando se acepta, y se acepta si cumple criterios escritos antes de empezar: las funciones que deben hacer lo que dicen y, en IA, un porcentaje de acierto sobre casos reales vuestros. Debe fijar cuántos días tenéis para probar y qué pasa si algo no cumple.
Ejemplo: «La fase 2 se considerará aceptada cuando el sistema clasifique correctamente al menos el 90 % de los 200 documentos del juego de pruebas del anexo III. El cliente dispondrá de 10 días hábiles para comunicar las incidencias, que el proveedor corregirá sin coste antes de una nueva revisión».
8. Documentación y formación
Sin documentación, el sistema depende de la memoria de alguien del proveedor. Pedid documentación técnica (cómo está montado y qué servicios usa), un manual de uso y horas de formación incluidas.
Ejemplo: «Con la entrega final, el proveedor facilitará la documentación técnica de arquitectura, instalación y dependencias, un manual de usuario y 4 horas de formación para hasta 10 personas del cliente».
9. Mantenimiento tras la entrega
Separad la garantía (un periodo tras la entrega en el que los errores se corrigen gratis) del mantenimiento (un servicio aparte, opcional, con su precio y su forma de baja). Qué debe entrar y cuánto suele costar lo contamos en mantenimiento de un software a medida o de un proyecto de IA.
Ejemplo: «El proveedor corregirá sin coste los defectos que aparezcan durante los 3 meses siguientes a la aceptación final. El mantenimiento posterior es opcional, se regula en el anexo IV y puede darse de baja con 30 días de preaviso».
10. Salida y portabilidad
La prueba de un buen contrato es cuánto cuesta iros. Debe obligar a entregar en plazo corto el código, las credenciales, los datos en formato estándar y la documentación, y a ayudar en el traspaso a precio conocido. Mejor aún: repositorio y cuentas a vuestro nombre desde el primer día.
Ejemplo: «A la terminación del contrato, por cualquier causa, el proveedor entregará en 15 días el código fuente, la documentación, los datos y todas las credenciales de acceso, y prestará hasta 10 horas de asistencia al nuevo proveedor a la tarifa del anexo V».
11. Confidencialidad y contrato de encargado del tratamiento
Si el proveedor va a tratar datos personales por vuestra cuenta (de clientes, de empleados, de pacientes), el artículo 28 del RGPD exige un contrato que, entre otras cosas, le obligue a tratar los datos solo siguiendo vuestras instrucciones documentadas, a que su personal guarde confidencialidad, a aplicar medidas de seguridad, a no subcontratar sin vuestra autorización por escrito, a ayudaros a atender los derechos de las personas, a borrar o devolver los datos al terminar y a permitir auditorías. Los subencargados (el alojamiento, el proveedor del modelo de IA) deben aparecer en una lista. La AEPD publica unas directrices para redactar estos contratos. El resto de la parte de datos la tenéis en IA y RGPD.
Ejemplo: «Las partes suscriben como anexo VI el contrato de encargo del tratamiento conforme al artículo 28 del RGPD. El cliente autoriza los subencargados relacionados en dicho anexo; cualquier cambio se comunicará con 30 días de antelación para que pueda oponerse».
12. Limitación de responsabilidad
Es razonable que el proveedor limite lo que paga si algo sale mal, normalmente al importe del contrato. No lo es un límite ridículo (lo pagado el último mes) ni que cubra también las fugas de datos o la confidencialidad. Tened en cuenta además que el Código Civil (art. 1102) no permite renunciar a la responsabilidad por dolo. En IA, el proveedor responde de que el sistema funcione como se aceptó, no de cada respuesta: por eso las decisiones importantes llevan revisión humana.
Ejemplo: «La responsabilidad total del proveedor se limita al importe total del contrato, salvo en los casos de dolo, culpa grave, incumplimiento de la confidencialidad o de la normativa de protección de datos, que quedan excluidos de este límite».
Las 12 cláusulas de un vistazo
| Cláusula | Riesgo si falta | Qué pedir |
|---|---|---|
| Propiedad del código | Cesión limitada a lo indispensable o a cinco años; dependéis del proveedor para cualquier cambio | Cesión exclusiva, mundial y sin plazo; licencia perpetua de lo previo |
| Propiedad y ubicación de los datos | No saber dónde están ni poder sacarlos | Datos vuestros, en la UE, exportables en formato estándar |
| No entrenar con vuestros datos | Vuestros documentos acaban mejorando modelos o proyectos ajenos | Prohibición expresa al proveedor y a los servicios que contrate |
| Nivel de servicio | Una caída que nadie atiende hasta la semana siguiente | Gravedades, tiempos de respuesta y horario por escrito |
| Cambio o retirada del modelo | Sistema que deja de funcionar o factura que se dispara de golpe | Aviso, migración incluida y pruebas de nuevo |
| Partidas variables con tope | Consumo de IA sin límite ni control | Estimación, tope mensual y aviso previo |
| Criterios de aceptación | Discutir si «está terminado» cuando ya está pagado | Criterios medibles antes de empezar y plazo para probar |
| Documentación y formación | Sistema que solo entiende quien lo hizo | Documentación técnica, manual y horas de formación |
| Mantenimiento | Pagar por arreglar errores del propio desarrollo | Garantía gratuita y mantenimiento aparte, opcional y con baja |
| Salida y portabilidad | Quedar atrapados: cambiar sale más caro que seguir | Entrega de código, accesos y datos en plazo, y ayuda en el traspaso |
| Encargado del tratamiento | Incumplir el RGPD aunque el fallo sea del proveedor | Contrato del art. 28 con lista de subencargados |
| Limitación de responsabilidad | Límite simbólico que deja sin cubrir una fuga de datos | Tope razonable con excepciones para datos y confidencialidad |
Cláusulas que deberían haceros sospechar
- «El proveedor conserva la propiedad intelectual del software y concede al cliente una licencia de uso.» Aceptable para un producto estándar; no para algo hecho y pagado a medida.
- Precio cerrado sin alcance detallado, o por horas sin estimación ni tope por fase.
- «Los costes de terceros se facturarán según consumo», sin estimación ni tope.
- Aceptación tácita a los pocos días de la entrega, sin criterios escritos: si no protestáis a tiempo, está aceptado.
- Permanencia larga en el mantenimiento (dos o tres años) o penalizaciones por darlo de baja.
- Nada sobre la salida, o la entrega del código condicionada a pagar una «cuota de liberación».
- Permiso para usar datos del cliente «para mejorar el servicio» sin más precisión.
- Promesas de resultados de la IA sin haberla probado con vuestros datos.
Cómo negociar el contrato sin ser abogado
- Pedid el contrato junto con la propuesta, no el día de la firma, y comparadlo como el precio. Con el encargo bien preparado (cómo preparar el encargo de un proyecto) tendrá menos huecos.
- Pasad este checklist y marcad lo que falta o es ambiguo. No hace falta entender cada palabra, sino saber qué debería estar.
- Ordenad por importancia. Código, datos y salida no se negocian a la baja; plazos de respuesta u horas de formación, sí.
- Pedid los cambios por escrito, con la redacción que queréis; las frases de esta guía sirven de punto de partida.
- Preguntad «¿y si…?». ¿Y si os cerráis? ¿Y si el modelo desaparece? ¿Y si queremos irnos dentro de dos años? Las respuestas dicen mucho del proveedor.
- Dejad la revisión final a vuestro abogado, con vuestras notas: será más corta y más útil.
Un proveedor serio no se ofende por estas peticiones. Si se resiste a ceder el código o a escribir cómo salís, esa es la respuesta. Para elegir con quién trabajar, tenéis también cómo elegir socio tecnológico.
Ejemplo: un contrato por fases con pagos por hitos
Un proyecto tipo: una empresa de unas 40 personas que quiere una herramienta con IA para procesar los pedidos que llegan por correo. Los porcentajes son orientativos.
| Fase | Qué se entrega | Cuándo se paga |
|---|---|---|
| 0. Definición | Análisis del proceso, datos de partida, juego de pruebas y alcance cerrado de las fases siguientes | Precio propio, a la entrega del documento |
| 1. Prototipo | La parte clave funcionando con datos reales y el porcentaje de acierto medido | 30 % del desarrollo, al firmar las fases 1 a 3 |
| 2. Primera versión | Herramienta conectada al ERP, en uso por un equipo piloto | 40 % al aceptar esta fase con los criterios del anexo |
| 3. Puesta en marcha | Uso por toda la empresa, documentación y formación | 30 % a la aceptación final; empieza la garantía |
| Después | Mantenimiento opcional y consumo de IA con tope | Cuota mensual y consumo real, aparte |
Lo importante: nunca hay mucho dinero adelantado sin algo funcionando, cada pago va ligado a una entrega comprobable y, tras la fase 0, podéis no seguir y quedaros con el análisis. Los cambios se presupuestan antes de hacerlos y entran en la fase siguiente.
¿Y el AI Act? Depende de vuestro papel
El Reglamento europeo de IA reparte las obligaciones según el papel. Hay un detalle que afecta a los proyectos a medida: según su artículo 3, es proveedor no solo quien desarrolla un sistema de IA, sino también quien se lo hace desarrollar y lo pone en servicio con su propio nombre. Si os hacen un asistente que atiende a vuestros clientes con vuestra marca, el proveedor podéis ser vosotros; si usáis la herramienta de otro, sois responsables del despliegue.
En la mayoría de proyectos de una pyme (clasificar documentos, responder consultas) el riesgo es bajo: formar al equipo que usa la IA y, si el sistema habla con personas, que diga que es una IA (artículo 50, desde el 2 de agosto de 2026). Pedid que el contrato diga que se entrega preparado para cumplirlo. Si el uso es de alto riesgo, como seleccionar personal, las obligaciones llegan el 2 de diciembre de 2027 tras el aplazamiento de 2026, y el artículo 25.4 pide un acuerdo escrito sobre la información y el acceso técnico que debe dar quien suministra componentes o servicios. El calendario completo está en AI Act: qué es y qué cambia.
Cómo lo hacemos nosotros
Trabajamos con precio cerrado por fases y pago por hitos, y el código y los datos son del cliente: es lo que pedimos que exijáis a cualquiera, nosotros incluidos. Si todavía no tenéis claro el alcance, el primer paso suele ser una Auditoría IA (de 690 a 1.750 €, que se descuenta entera si después hacemos el proyecto), que hace el papel de la fase 0 del ejemplo. Y si ya sabéis lo que necesitáis, en software a medida explicamos cómo trabajamos; una primera versión útil parte de unos 7.000 €.
Si es lo que queréis resolverSoftware a medidaPlataformas, CRM, ERP y portales hechos sobre cómo trabajáis, con el código a vuestro nombre.→Preguntas frecuentes
¿Qué debe incluir un contrato de desarrollo de software a medida?
Como mínimo: cesión de la propiedad del código, propiedad y ubicación de los datos, alcance y precio por fases, criterios de aceptación de cada entrega, garantía y mantenimiento, salida con entrega de código y accesos, confidencialidad, contrato de encargado del tratamiento si hay datos personales y limitación de responsabilidad. Si el proyecto usa IA, añadid la prohibición de entrenar con vuestros datos, qué pasa si el modelo se retira o sube de precio y un tope para el consumo.
¿De quién es el código de un software hecho a medida?
De quien diga el contrato. La Ley de Propiedad Intelectual limita la cesión a lo que se pacta expresamente: si no se fija plazo, la cesión dura cinco años, y si no se concretan los usos, se limita a lo indispensable para el contrato. Por eso conviene pedir una cesión exclusiva, mundial y por todo el plazo legal, y una licencia perpetua de lo que el proveedor ya tenía antes.
¿Hace falta un contrato de encargado del tratamiento con la empresa que desarrolla el proyecto?
Sí, si va a tratar datos personales por cuenta de vuestra empresa, por ejemplo datos de clientes o empleados durante el desarrollo o el mantenimiento. Lo exige el artículo 28 del RGPD, que fija su contenido mínimo: instrucciones documentadas, confidencialidad, seguridad, subencargados autorizados, borrado o devolución al terminar y auditorías.
¿Cómo se controla en el contrato el coste del consumo de IA?
Separándolo del precio del desarrollo, con una estimación para vuestro volumen, un tope mensual que no se supera sin autorización por escrito y un aviso antes de llegar a él. Mejor si la cuenta del proveedor del modelo está a nombre de vuestra empresa; si la paga el desarrollador y os la repercute, el contrato debe decir si lleva margen.
¿Qué pasa si el proveedor de IA retira el modelo que usa nuestra aplicación?
Hay que migrar a otra versión, y el sistema puede responder distinto. El contrato debe decir quién vigila esos avisos, quién paga la migración y cómo se comprueba con las mismas pruebas de aceptación que todo sigue funcionando. Lo razonable es que la migración entre en el mantenimiento.
¿Necesito un abogado para revisar el contrato de un proyecto de IA?
Para la revisión final, es recomendable, sobre todo si hay datos sensibles o un importe alto. Pero podéis hacer antes la mayor parte del trabajo con un checklist: comprobar que están las cláusulas clave, marcar las ambiguas y pedir los cambios por escrito. Así la revisión del abogado es más corta y se centra en lo importante.
¿Tenéis un contrato o una propuesta encima de la mesa y queréis una segunda opinión técnica? En una reunión gratuita por videollamada lo repasamos con vosotros y os decimos qué falta.