Contratos con proveedores de IA: cláusulas de no retención, portabilidad, auditoría y salida

Un contrato estándar de proveedor de IA está redactado para el proveedor. Renegociarlo cuesta menos que salir después.

El Data Processing Addendum estándar de OpenAI para clientes de API tiene 14 páginas. El de Anthropic para el plan Enterprise ronda las 18. El de Google Cloud Vertex AI, incluyendo los anexos de subprocesadores, pasa de 40. Ninguno de los tres, en su versión por defecto, cubre las cuatro cláusulas que un director jurídico razonable pediría antes de firmar: retención cero verificable, portabilidad de embeddings y fine-tunes, derecho de auditoría con acceso a evidencias concretas, y salida ordenada con periodo de transición y devolución de artefactos.

Las tres empresas ofrecen esas cláusulas. No en el borrador que te mandan. Hay que pedirlas.

El coste medio de renegociar un contrato de proveedor SaaS con revisión legal externa en España está entre 3.000 y 8.000 euros según Vertebra Gestión. El coste medio de migrar un stack de IA en producción con embeddings acumulados, fine-tunes y pipelines dependientes, cuando el proveedor original no coopera, supera los 40.000 euros y meses de trabajo. La aritmética es clara.

Aquí empieza el lío.

La cláusula de no retención: qué significa técnicamente y cómo verificarla

Los tres grandes proveedores (OpenAI, Anthropic, Google) tienen políticas de retención distintas según el producto y el plan contratado. En la API pura, sin plan enterprise, los prompts y las respuestas se guardan por defecto entre 30 y 90 días para monitorización de abuso. En los planes enterprise, la retención puede reducirse a cero, pero hay que pactarlo por escrito y activarlo en la consola.

Cero retención significa tres cosas concretas:

• Cero almacenamiento en disco. El prompt entra al modelo, se procesa en memoria, se devuelve la respuesta, y no se persiste en ningún sistema del proveedor. Ni en logs, ni en bases de datos, ni en buckets de análisis.
• Cero uso para entrenamiento. El contenido del prompt y la respuesta no se usan para entrenar futuros modelos, fine-tunear modelos base, o alimentar sistemas de evaluación interna.
• Cero acceso humano. Ningún empleado del proveedor, incluido el equipo de seguridad, puede leer el contenido salvo orden judicial expresa notificada al cliente.

Los tres puntos deben aparecer explícitamente en el DPA. El primero suele estar en la sección de "Data Retention". El segundo en "Model Training" o "Improvement of Services". El tercero en "Confidentiality" y "Access Controls".

Traducción: si el DPA solo dice "we do not use your data to train our models" pero no dice nada sobre retención en disco o acceso humano, faltan dos de las tres patas.

Cómo verificarla sin depender de la palabra del proveedor

El proveedor firma el papel. La verificación técnica es tu responsabilidad. Hay cuatro mecanismos que se pueden pedir en el contrato como evidencias periódicas.

• Certificación SOC 2 Type II con alcance explícito sobre los controles de retención. No vale el SOC 2 genérico. Hay que pedir que el informe incluya el control específico de "zero data retention for API traffic tagged as enterprise". OpenAI y Anthropic lo publican bajo NDA. Google Cloud lo tiene en el portal de Trust.
• Logs de auditoría propios accesibles por API. Los tres proveedores ofrecen endpoints de audit log en los planes enterprise. Con esos logs puedes verificar que las peticiones se procesan bajo el flag de zero retention y que no aparecen en ningún backup o snapshot.
• Cabeceras de respuesta HTTP con el flag activo. OpenAI devuelve openai-organization y en enterprise openai-processing-mode: zero-retention. Anthropic devuelve anthropic-organization y campos similares. Se pueden loggear y auditar internamente.
• Cláusula de derecho a inspección de sistemas o auditoría por tercero. Sobre esto va toda la sección tres de este post.

Regla: si el proveedor no te da al menos dos de esos cuatro mecanismos, la cláusula de no retención es marketing.

Lo que NO es cero retención

Una lista corta con los eufemismos más frecuentes en borradores estándar.

• "We may retain data for up to 30 days for abuse monitoring." Retención con etiqueta bonita.
• "Data is retained only in aggregated and anonymized form." No es cero retención. Es retención transformada, y la anonimización de embeddings o de patrones de uso es notoriamente débil.
• "We do not use your data for training, but may use it for service improvement." Puerta trasera. "Service improvement" incluye habitualmente evaluaciones de modelo, comparativas A/B y ajustes de safety.
• "Data is deleted upon request." No es cero retención. Es retención con derecho a borrado, que es una figura del RGPD, no una garantía contractual de no almacenamiento.

Si algo de esto aparece sin corrección en el DPA que firmas, no tienes cero retención. Tienes retención estándar con la palabra "cero" en el título.

Portabilidad: embeddings, fine-tunes y logs son tuyos o del proveedor

Un modelo de IA en producción genera tres tipos de activos que la empresa cliente considera intuitivamente suyos, pero que en el contrato por defecto pueden no serlo.

Los embeddings son representaciones vectoriales del contenido que has procesado. Una base vectorial con dos millones de embeddings de documentos internos, generada con text-embedding-3-large de OpenAI o con el modelo equivalente de Cohere, tiene un coste de reconstrucción entre 400 y 2.500 euros solo en llamadas a API, más el trabajo de pipeline. Y esa cifra asume que puedes volver a procesar todos los documentos originales. Si algunos se han borrado, perdido o modificado, la reconstrucción es imposible.

Los fine-tunes son versiones especializadas del modelo base entrenadas con tus datos. Un fine-tune completo con 50.000 ejemplos etiquetados puede costar entre 2.000 y 15.000 euros en compute, más el trabajo de curación del dataset. Si el proveedor conserva el fine-tune como suyo, no puedes exportarlo ni ejecutarlo en otro sitio.

Los logs de uso son el histórico de interacciones. Contienen patrones de consulta, errores, latencias y feedback humano. Son la materia prima para mejorar el sistema y para auditar decisiones.

Qué pedir por cada tipo de activo

• Embeddings. Derecho de exportación en formato estándar (JSON, Parquet o CSV con la matriz numérica y los metadatos) sin coste adicional, en cualquier momento durante la vigencia del contrato y durante el periodo de transición posterior. Formato máquina, no PDF ni interfaz web.
• Fine-tunes. Aquí hay tres niveles según proveedor. OpenAI y Anthropic no exportan los pesos del fine-tune. Puedes ejecutarlos vía API mientras seas cliente, y punto. Los proveedores open source como Mistral (en su oferta comercial) o Cohere permiten en algunos planes exportar los deltas del fine-tune. Google Cloud Vertex AI permite exportar los adapters (LoRA) cuando el fine-tune se hace sobre un modelo abierto. Solución: si la portabilidad del fine-tune es crítica, negocia desde el principio con un proveedor que la ofrezca, o haz el fine-tune sobre un modelo open weights que puedas ejecutar en tu propia infraestructura. Ver el análisis en IA local vs API.
• Logs. Derecho de exportación completa vía API o dump periódico, incluyendo timestamps, prompts, respuestas, metadatos de sesión, feedback de usuario y anotaciones de calidad. Formato estructurado, no capturas de pantalla del dashboard.

Tabla de portabilidad por activo y proveedor

La tabla es una foto de arquitectura, no un ranking. Un proveedor con menor portabilidad puede compensar con precio, calidad de modelo o SLA. Pero necesitas saber exactamente qué te llevas si el día uno te toca migrar.

La cláusula que evita el lock-in silencioso

Un patrón que aparece con frecuencia en los borradores es la siguiente: "Customer grants Provider a perpetual license to use Customer Data for internal purposes including model evaluation and improvement". Suena inocuo. No lo es.

Traducción: si aceptas esa cláusula, incluso después de salir del contrato el proveedor puede seguir usando tus datos indefinidamente para evaluar sus modelos. Y los datos que le has entregado (documentos, prompts, transcripciones de clientes) siguen en sus sistemas. El problema ya no es portabilidad. Es que el proveedor se queda con una copia perpetua.

Regla: cualquier licencia sobre tus datos debe terminar en el mismo momento en que termina el contrato, más un periodo de transición pactado, y siempre con obligación explícita de eliminación certificada al final.

Auditoría: qué evidencias pedir y cada cuánto

El derecho de auditoría en un contrato SaaS estándar suele ser un párrafo genérico que dice algo como "Customer may audit Provider's compliance with this Agreement once per year upon 30 days written notice, subject to Provider's reasonable security requirements". Ese párrafo, en la práctica, no permite auditar casi nada.

Un derecho de auditoría útil especifica cuatro cosas: qué se puede auditar, cómo, con qué periodicidad y por quién.

Los cuatro niveles de auditoría posibles

• Nivel 1: acceso a informes de terceros. El proveedor entrega los informes SOC 2 Type II, ISO 27001, ISO 42001 (específico para sistemas de IA) e informes de penetración vigentes. Es lo mínimo. Los tres grandes lo dan bajo NDA.
• Nivel 2: cuestionario de seguridad respondido. El cliente envía un cuestionario propio (SIG, CAIQ) y el proveedor responde por escrito, firmado. Útil para compliance interno.
• Nivel 3: auditoría remota por tercero acreditado. Un auditor externo, contratado por el cliente pero acordado con el proveedor, revisa evidencias específicas: configuraciones, logs, procesos de gestión de incidentes. Sin acceso físico ni al código.
• Nivel 4: auditoría in situ. El auditor va físicamente a las instalaciones del proveedor o a su equipo de seguridad. Este nivel prácticamente ningún proveedor de IA lo da salvo a clientes muy grandes (banca, defensa, sanidad crítica). No lo pidas si no lo necesitas.

Para la mayoría de empresas, el nivel 3 es el techo razonable y realista.

Qué evidencias pedir en concreto

Una lista genérica de "cumplimiento con las leyes aplicables" no sirve. La auditoría útil pide evidencias concretas y ligadas a los otros compromisos del contrato.

• Evidencia de zero retention. Muestras de logs del sistema de procesamiento demostrando que las peticiones marcadas como zero-retention no aparecen en almacenamiento persistente.
• Evidencia de acceso restringido. Registro de qué empleados del proveedor tienen acceso a qué sistemas, con qué credenciales y qué controles de MFA.
• Evidencia de gestión de incidentes. Últimos 12 meses de incidentes que hayan afectado potencialmente a datos del cliente, con detalle de causa raíz y remediación.
• Evidencia de subprocesadores. Lista actualizada de terceros que procesan datos (cloud providers, servicios de moderación, herramientas internas) con localización geográfica y garantías contractuales.
• Evidencia de eliminación. Cuando se solicita borrado de datos, evidencia técnica de que se ha ejecutado en todos los sistemas, incluidos backups.

Regla: la cláusula de auditoría debe listar las evidencias específicas que se pueden pedir. Sin lista, es un derecho vago que el proveedor puede recortar a discreción.

Periodicidad y coste

Un compromiso razonable para la mayoría de empresas es una auditoría documental anual (nivel 1 y 2) sin coste adicional, y derecho a una auditoría por tercero (nivel 3) cada 24 meses, con costes compartidos si el resultado no encuentra incumplimientos materiales, y a cargo del proveedor si sí los encuentra.

El detalle importante es el reparto de coste condicional. Sin él, el proveedor tiende a resistir cualquier auditoría porque le supone gasto puro. Con él, tiene incentivo para cooperar y para no dar problemas en la revisión.

La cláusula de salida: transición ordenada, no cortada de cuajo

Salir de un proveedor de IA no es como salir de un CRM. En el CRM te llevas un CSV con los contactos y en dos semanas tienes el nuevo sistema poblado. En IA te llevas embeddings, fine-tunes, prompts calibrados, benchmarks internos y pipelines que dependen de la latencia y el comportamiento exacto del modelo saliente. Reproducir todo eso en otro proveedor lleva entre 4 y 16 semanas dependiendo de la complejidad, según los datos que recogen consultoras como Davisa para migraciones cloud análogas.

La cláusula de salida debe cubrir cuatro elementos: preaviso, periodo de transición, entregables y coste.

Preaviso

El preaviso mínimo razonable es de 90 días por cualquiera de las dos partes. Si el proveedor puede terminarte con 30 días de aviso y tú tienes un sistema en producción con 500.000 llamadas al mes, estás en una posición imposible. Y si tú necesitas 60 días para migrar y solo puedes preavisar con 30, pagas dos meses de proveedor doble.

El preaviso también debe cubrir cambios materiales de servicio: si el proveedor va a deprecar un modelo, retirar una feature o cambiar la política de precios de forma sustancial, 90 días es el mínimo razonable para reaccionar.

Periodo de transición

Al final del contrato, debe haber un periodo de transición pactado durante el cual el servicio sigue operativo con las mismas condiciones económicas y técnicas. Rango habitual: 60 a 180 días.

Durante ese periodo, el cliente puede seguir usando el sistema en producción, exportar todos los activos, entrenar al equipo en el nuevo proveedor y ejecutar pruebas comparativas. El proveedor se compromete a mantener SLA y a facilitar la migración con soporte técnico razonable.

Traducción: el día en que expira el contrato no es el día en que se apaga el servicio. Es el día en que empieza la transición pactada.

Entregables al final

Al terminar la transición, el proveedor debe entregar:

• Exportación completa de embeddings. Formato estándar, todas las colecciones, con metadatos.
• Exportación completa de logs. Últimos 24 meses como mínimo, o el periodo completo si es menor.
• Exportación de fine-tunes. Pesos si el modelo es open, o al menos el dataset de entrenamiento y los hiperparámetros usados si el modelo es cerrado.
• Documentación de configuración. Prompts sistema, parámetros, plantillas, catálogos de intents.
• Certificado de eliminación. Documento firmado por un responsable con nombre, cargo y fecha, indicando que todos los datos del cliente se han eliminado de sistemas productivos, staging, backups y logs internos, en la fecha X.

El certificado de eliminación es el más olvidado y el más importante. Sin él, tienes una promesa oral de que tus datos se han borrado. Con él, tienes una evidencia contractual que sirve ante auditoría propia y ante la Agencia Española de Protección de Datos si algún día hay una brecha en el proveedor y aparecen tus datos.

Coste de la salida

El coste de la salida debe estar tasado en el contrato. Tres modelos comunes:

• Salida sin coste. El proveedor no cobra por la migración ni por los entregables. Es lo ideal desde el punto de vista del cliente.
• Salida a coste de servicio. El proveedor cobra las horas de soporte a una tarifa pactada en anexo, con tope máximo. Habitual en enterprise medio.
• Salida a mercado. El proveedor cobra "según tarifa vigente". Es la más peligrosa. En el momento de la salida el proveedor puede aplicar cualquier precio, y no tienes referencia previa. Solución: rechazar esta cláusula o pactar tope máximo en euros.

Datos sensibles y RGPD: cláusulas adicionales que no son opcionales

Si tu empresa procesa datos personales de ciudadanos europeos, o datos categorizados como sensibles (salud, biometría, opinión política, orientación sexual, condena penal), el DPA general no basta. Hacen falta cláusulas específicas.

El RGPD en su artículo 28 exige que el contrato entre responsable (tu empresa) y encargado (el proveedor de IA) incluya al menos ocho elementos. Los ocho aparecen en los DPA estándar de los grandes proveedores. El problema no es que falten. Están redactados de forma genérica.

Los seis puntos que hay que endurecer en el DPA

• Localización de datos. El DPA debe especificar en qué países se procesan los datos. Para el RGPD, procesamiento fuera del EEE requiere garantías adicionales (Cláusulas Contractuales Tipo desde 2021, con adenda si es EEUU). Anthropic ofrece región EU dedicada. OpenAI ofrece "Data residency" en Europa en enterprise. Google Vertex AI permite elegir región y jurisdicción exacta.
• Subprocesadores. Lista completa y actualizada, con notificación de cambios (mínimo 30 días de antelación) y derecho de objeción con derecho a rescisión si el nuevo subprocesador no cumple requisitos.
• Notificación de brecha. Plazo máximo de 48 horas desde detección, con contenido mínimo definido: naturaleza de la brecha, datos afectados, medidas tomadas, contacto de responsable. El RGPD te obliga a notificar a la AEPD en 72 horas desde que tú sabes, así que necesitas margen.
• Asistencia en solicitudes de titulares. El proveedor debe ayudar a responder solicitudes de acceso, rectificación, borrado y portabilidad de titulares. Con plazos y sin coste dentro de un volumen razonable pactado.
• Evaluaciones de impacto (EIPD). Si el uso del sistema de IA requiere EIPD según la Guía de la AEPD, el proveedor debe facilitar la información técnica necesaria para completarla.
• Compliance con AI Act. Desde febrero de 2025 aplica el artículo 4 sobre alfabetización, y desde agosto de 2026 aplican progresivamente las obligaciones sobre sistemas de alto riesgo (Anexo III). El DPA debe reflejar en qué categoría de riesgo se clasifica el uso del sistema y qué obligaciones asume el proveedor como suministrador de un modelo de propósito general (GPAI).

Datos sensibles: cláusulas adicionales

Para categorías especiales del artículo 9 del RGPD (salud, biometría, etc.):

• Prohibición explícita de uso para entrenamiento incluso en agregado.
• Cifrado en tránsito y en reposo con claves gestionadas por el cliente (BYOK) cuando sea técnicamente viable.
• Segregación lógica de tenants con evidencia técnica auditable.
• Restricción a personal específico con clearance documentado.
• Notificación de brecha en 24 horas, no 48.

Estas cinco no vienen en el DPA por defecto de ningún proveedor. Se añaden en anexo negociado.

Errores frecuentes en la revisión de contratos de proveedores de IA

Cinco errores que aparecen repetidamente cuando reviso contratos ya firmados por empresas que vienen con problemas.

Error 1: Firmar el DPA sin leer los anexos. Síntoma: el equipo jurídico revisa el master agreement y da OK al DPA "estándar" sin abrir los anexos técnicos. Los anexos suelen contener la lista de subprocesadores, la política de retención específica del producto y los flags técnicos. Solución: cada anexo se revisa como si fuera un contrato aparte. Si el proveedor no publica los anexos, no se firma el master.

Error 2: Aceptar "reasonable security measures" sin definir cuáles. Síntoma: la cláusula de seguridad dice que el proveedor implementará "medidas técnicas y organizativas razonables". Sin definición, "razonable" es lo que el proveedor decida. Solución: reemplazar por lista concreta con referencia a ISO 27001, ISO 42001, SOC 2 Type II y controles específicos (cifrado AES-256, MFA obligatorio para acceso administrativo, gestión de accesos con revisiones trimestrales).

Error 3: No pactar SLA con crédito. Síntoma: el contrato promete "99.9% uptime" pero no dice qué pasa si el proveedor incumple. En la práctica, no pasa nada. Solución: el SLA debe tener crédito automático (5% del importe mensual por cada 0.1% por debajo del compromiso, escalando), con derecho a rescisión sin penalización si el incumplimiento se repite tres meses consecutivos.

Error 4: Cláusula de limitación de responsabilidad tapando el resto. Síntoma: al final del contrato aparece "in no event shall Provider's aggregate liability exceed fees paid in the twelve months preceding the claim". Traducción: si te pierden datos sensibles y te cae una multa de 4 millones de la AEPD, el proveedor te devuelve lo que hayas pagado ese año, que puede ser 50.000 euros. Solución: excluir del cap de responsabilidad las brechas de datos personales, los incumplimientos del DPA y los casos de dolo o negligencia grave. Es negociable en enterprise.

Error 5: Renovación automática indefinida sin ventana de revisión. Síntoma: el contrato se renueva automáticamente por 12 meses cada año salvo denuncia con 60 días de antelación. En dos años, tienes tres años de compromiso acumulado. Solución: renovación automática por periodos iguales, pero con derecho a renegociar precio y condiciones en cada renovación, y con ventana de denuncia razonable (30 días es suficiente).

Red flags típicos en borradores estándar

Ocho frases que aparecen en borradores por defecto y que deben marcarse en rojo antes de firmar.

• "Provider may modify these terms at any time with notice on our website." Traducción: el proveedor puede cambiar el contrato unilateralmente. Rechazar. Los cambios deben pactarse por escrito.
• "Customer Data may be shared with affiliates for legitimate business purposes." Traducción: el proveedor puede pasar tus datos a filiales sin control. Restringir a subprocesadores listados y notificados.
• "Provider makes no warranty regarding accuracy of outputs." Traducción: si el modelo dice una barbaridad y actúas sobre ella, es tu problema. En parte es razonable (el modelo es probabilístico), pero debe matizarse con obligación del proveedor de mantener sistemas de safety y notificar degradaciones conocidas.
• "Governing law: State of California / Delaware / Ireland." Traducción: cualquier disputa se litiga en jurisdicción del proveedor. En Europa, negociar jurisdicción europea (habitualmente Irlanda si el proveedor tiene sede allí) o al menos arbitraje internacional con sede en jurisdicción neutral.
• "Provider may suspend service for suspected policy violations without prior notice." Traducción: si el sistema automático de moderación del proveedor considera que has violado sus políticas, te corta el servicio sin avisar. Añadir obligación de notificación y periodo de aclaración salvo casos de riesgo grave documentado.
• "Fees are subject to change with 30 days notice." Traducción: el proveedor puede subirte el precio con un mes de aviso. Fijar precio por periodo contractual (mínimo 12 meses) con incrementos capados (IPC + X%).
• "Customer grants Provider a perpetual, worldwide, royalty-free license to Feedback." Traducción: cualquier sugerencia, bug report o comentario que envíes se convierte en propiedad intelectual del proveedor. Aceptable en general para feedback genuino, pero excluir explícitamente cualquier dato del cliente incluido en el feedback.
• "This DPA supersedes any prior agreements regarding data protection." Traducción: cualquier cláusula de protección de datos que hayas negociado antes queda sin efecto. Verificar orden de prevalencia y añadir excepciones expresas si has negociado términos específicos.

Preguntas frecuentes

Qué cláusulas debe tener un contrato con un proveedor de IA

Cuatro esenciales: no retención verificable de datos, portabilidad de embeddings, fine-tunes y logs, derecho de auditoría con evidencias concretas, y cláusula de salida ordenada con periodo de transición y certificado de eliminación. A estas cuatro se suman las obligaciones RGPD del artículo 28 (localización, subprocesadores, notificación de brecha, asistencia a titulares) y las derivadas del AI Act para uso empresarial (categorización de riesgo, alfabetización del personal, obligaciones de suministrador GPAI).

Cómo se pacta la no retención de datos con OpenAI o Anthropic

En ambos casos, con plan Enterprise. En OpenAI, se firma el Enterprise Agreement (no basta con el TOS de API) y se activa "Zero Data Retention" en la consola de administración, con la organización marcada como tal. La configuración se refleja en las cabeceras de respuesta HTTP y en los logs de auditoría enterprise. En Anthropic, se firma el Enterprise Agreement equivalente y se activa "Zero Retention" a nivel de organización, con verificación por API. En ambos casos, hay que pedir explícitamente el DPA enterprise (no el estándar) y verificar que las cláusulas de "Data Retention", "Model Training" y "Confidentiality" reflejan retención cero, no uso para entrenamiento y acceso humano restringido.

Qué pedir para poder salir de un proveedor de IA sin perder datos

Cuatro cosas contractuales: preaviso mutuo de 90 días como mínimo, periodo de transición pactado de 60 a 180 días con SLA y precio mantenidos, entregables definidos (embeddings, logs, fine-tunes o dataset de entrenamiento, documentación de configuración, certificado de eliminación firmado), y coste de salida tasado en el contrato (idealmente sin coste, o con tope máximo en euros). A nivel técnico, mantener exportaciones periódicas propias de embeddings y logs desde el primer día, no esperar al momento de la salida.

Qué red flags aparecen en los contratos estándar de proveedores IA

Los ocho más frecuentes: modificación unilateral de términos, compartición con filiales sin control, exención total de responsabilidad por outputs, jurisdicción del proveedor sin opción de negociación, suspensión sin notificación por violaciones automatizadas de política, subida de precio con solo 30 días de aviso, licencia perpetua sobre feedback que puede incluir datos del cliente, y DPA que anula acuerdos anteriores sin excepciones. Cada una tiene contramedida negociable en plan enterprise. En plan estándar, no son negociables, y esa es la razón principal por la que un uso empresarial serio requiere plan enterprise.

Se pueden auditar in situ los sistemas de OpenAI o Anthropic

En la práctica, no salvo excepciones muy grandes (grandes bancos, defensa, sanidad crítica). Lo que sí se puede pedir en enterprise es: acceso bajo NDA a los informes SOC 2 Type II, ISO 27001 e ISO 42001, respuesta escrita a cuestionarios de seguridad tipo SIG o CAIQ, y en algunos casos, auditoría remota por tercero acreditado (nivel 3) sobre evidencias específicas (logs de retención, gestión de accesos, lista de subprocesadores). Nivel 4 (auditoría in situ) suele quedar reservado a clientes con volumen contractual superior a los siete cifras anuales.

Qué diferencia hay entre no usar mis datos para entrenamiento y no retener mis datos

Muchísima. "No usar para entrenamiento" significa que el proveedor no incorpora tus datos al dataset de entrenamiento de futuros modelos. Pero puede seguir almacenándolos en disco (para logs de abuso, para servicio al cliente, para análisis interno) y sus empleados pueden acceder a ellos bajo procedimientos internos. "No retener" es más fuerte: el dato no se persiste en ningún sistema tras el procesamiento. Los tres pilares de retención cero son almacenamiento cero, uso para entrenamiento cero y acceso humano cero. Sin los tres, la cláusula está incompleta.

Cierre

Un contrato de proveedor de IA es un contrato de infraestructura crítica con encaje regulatorio complejo. No es un SaaS más. Los datos que le entregas, las representaciones vectoriales que genera y los fine-tunes que produce son activos estratégicos que definen la libertad futura de tu empresa para cambiar de proveedor, para migrar a modelo propio, o para responder ante una auditoría regulatoria.

Los proveedores serios (los tres grandes y varios europeos) tienen contratos enterprise que cubren las cuatro cláusulas críticas. No las cubren en el borrador por defecto porque el borrador por defecto está optimizado para su operativa, no para tu protección. Pedirlas no es agresivo. Es lo que hace cualquier equipo jurídico competente cuando revisa un contrato de encargado de tratamiento con perfil de riesgo alto.

Si estás revisando un contrato con un proveedor de IA y quieres una segunda opinión técnica sobre qué cláusulas endurecer, qué evidencias pedir en auditoría, o si tu caso de uso justifica plantearse IA local en lugar de API, puedes reservar una sesión de 30 minutos para revisar el contrato concreto y salir con una lista priorizada de puntos a renegociar. Sin coste.

Lecturas relacionadas

• IA local vs API: cuándo tiene sentido cada opción
• Alfabetización en IA y AI Act artículo 4: qué obliga desde febrero de 2025
• Coste real de un piloto de IA en empresa mediana

Fuentes y referencias

• Reglamento (UE) 2024/1689 sobre Inteligencia Artificial (AI Act)
• Reglamento (UE) 2016/679 sobre Protección de Datos (RGPD), artículo 28
• Agencia Española de Protección de Datos: Guía sobre encargados de tratamiento
• OpenAI Enterprise Privacy: documentación de Zero Data Retention
• Anthropic Trust Portal: informes SOC 2 y política de retención
• Google Cloud Vertex AI: documentación de residency y controles de datos
• Vertebra Gestión: rangos de coste de revisión legal SaaS
• Davisa: plazos y costes típicos de migración cloud