Copyright de IA: qué auditar en tu producto antes de que te auditen a ti

28 de Julio del 202613 minIA, Legal, SaaS, Riesgo, Copyright

Respuesta corta (60 segundos): el 9 de julio del 2026 el New York Times + 16 medios pidieron a un juez federal sancionar a OpenAI por supuestamente haber mentido durante ~2 años sobre su capacidad técnica de buscar pruebas de uso de material con copyright en sus sistemas. El 22 de julio, el Treasury de EE.UU. dejó sanciones "sobre la mesa" contra Moonshot AI por alleged destilación de Anthropic Fable. El 24 de julio, el Delhi High Court falló en favor de OpenAI en India (interino). Tres jurisdicciones, tres señales distintas. Si tu SaaS tiene feature de IA — aunque sea un wrapper de API — estás expuesto al mismo argumento. Lo que tenés que auditar esta semana: (1) tu ToS y cláusula de indemnidad, (2) data lineage de tu feature, (3) la policy de training data de tu proveedor, (4) tu póliza E&O con rider de IP/AI. Checklist al final.

Cuando un comité ejecutivo me llama por un proyecto de IA en 2026, el riesgo legal ya no es hipotético. Lo que cambió esta semana es que el riesgo dejó de ser "teórico y futuro" para volverse "concreto y esta semana". Esto no es un post alarmista. Es un post operativo: cuatro auditorías que un founder SaaS puede hacer solo, sin abogado, en 1-2 tardes. La auditoría legal formal la hace tu abogado; este post te da el framework para saber qué preguntarle.

Por qué importa esta semana

Tres casos en 15 días, tres jurisdicciones, tres señales distintas. Vale la pena entenderlos en concreto porque juntos dibujan el mapa de riesgo:

Caso 1 — NYT + medios vs OpenAI (EE.UU., 9 jul 2026)

El New York Times, NY Daily News y otros 15 medios presentaron una moción ante un juez federal pidiendo que sancione a OpenAI. Lo que alegan: OpenAI ocultó deliberadamente su capacidad de buscar en sus datos de entrenamiento y logs de output evidencia de uso de artículos con copyright, durante aproximadamente dos años. La frase clave en las presentaciones judiciales es que OpenAI habría desplegado un "deliberate and systemic effort to obstruct discovery".

Esto importa por el precedente, no por el caso específico. Si el juez falla a favor de los publishers, cualquier otro publisher puede usar el mismo argumento (y la misma queja de discovery obstruido) contra cualquier SaaS con feature de IA entrenada con contenido scraped. No necesitás ser OpenAI. Necesitás tener un feature que use un modelo entrenado con contenido con copyright y no poder demostrar de dónde vino ese contenido.

Fuentes: NYT, AP News, Bloomberg Law.

Caso 2 — Treasury vs Moonshot AI (EE.UU.–China, 22-23 jul 2026)

El 22 de julio, TechCrunch reportó que el Asesor de Ciencia de la Casa Blanca (Michael Kratsios) acusó a Moonshot AI — creadores del modelo chino Kimi K3 — de haber construido su modelo destilando el "Fable" LLM de Anthropic, usando chips no autorizados para exportación a China. El Secretario del Treasury (Scott Bessent) dijo que sanciones quedan "on the table". El 23 de julio, un follow-up de TechCrunch recoge que varios expertos técnicos disputan la narrativa: argumentan que explotar Fable no explicaría el rendimiento de Kimi K3.

¿Qué tiene que ver esto con tu SaaS? Dos cosas. Primero: si EE.UU. empieza a sancionar a empresas por uso cross-border de modelos occidentales, tu cadena de suministro de IA (proveedor + sub-proveedor + país de hosting) se vuelve un riesgo legal real. Segundo: la cosa se mueve rápido. Pasó de "acusación pública" a "amenaza de sanciones" en 48 horas.

Fuentes: TechCrunch 22 jul, TechCrunch 23 jul.

Caso 3 — Delhi High Court vs OpenAI (India, 24 jul 2026)

El 24 de julio, el Delhi High Court rechazó el pedido de ANI Media de dictar una injunction contra OpenAI. Razón: el entrenamiento de ChatGPT con contenido de noticias cae prima facie bajo la Sección 52 de la Indian Copyright Act (fair dealing). El juez razonó además que restringir el entrenamiento sería detrimental al crecimiento de la IA y al interés público.

Cuidado: esto es un fallo interino sobre injunctive relief, no una decisión final sobre si hubo infringement. El caso de fondo sigue abierto. Y solo aplica a India. Si tu SaaS sirve clientes en EE.UU., EU, UK o Latam, no te protege. Pero sí te dice algo importante: no hay regla global. Cada jurisdicción decide distinto, y eso significa que la auditoría legal que hagas tiene que asumir el peor caso, no el mejor.

Fuente: Economic Times, Bar and Bench.

Auditoría 1 · ToS y cláusula de indemnidad

La pregunta que tenés que responder hoy: ¿qué pasa si un cliente o un tercero te demanda porque tu feature de IA reprodujo material con copyright? ¿Te cubre tu contrato con tu proveedor de modelo (OpenAI, Anthropic, Google) o te cubre tu propia póliza?

Qué mirar concretamente:

• Abrí el ToS de tu proveedor de modelo. Buscá las palabras "indemnify", "indemnification", "defend", "hold harmless". ¿Tu proveedor te defiende ante reclamos de terceros por uso del modelo? ¿O esa defensa está limitada a sus propios actos (no a los tuyos)?
• Buscá "training data", "outputs", "intellectual property". ¿El proveedor reclama propiedad sobre los outputs? ¿Te transfiere los derechos? ¿O te da una licencia?
• Buscá cláusulas de "warranty disclaimer". Casi todos los proveedores disclaimany warranty sobre no-infringement de los outputs. Si lo hacen, sabé que tu riesgo no lo cubre nadie.
• Si tu proveedor es OpenAI o Anthropic vía API, ellos históricamente ofrecen indemnidad limitada a casos donde el output infringe y vos no modificaste el prompt de manera que produjera la infracción. Verificá los términos exactos vigentes — cambian seguido.

Lo que vi en proyectos LATAM: el 70% de los SaaS con feature de IA no leyó la sección de IP de su ToS con el proveedor de modelo. El 30% que la leyó tiene una falsa sensación de seguridad porque leyó la cláusula de indemnidad sin leer los carve-outs (excepciones que la anulan).

Auditoría 2 · Data lineage

La pregunta: si un juez te pide que demuestres qué datos usó tu feature de IA, ¿podés hacerlo en 48 horas?

Qué significa "data lineage" en práctica para tu feature:

• RAG corpus: ¿qué documentos indexaste? ¿De dónde vienen? ¿Tenés registro (con timestamp) de cuándo se indexó cada uno? Si mañana te piden listar los 10.000 documentos que forman tu knowledge base, ¿podés?
• Fine-tuning data: si hiciste fine-tuning de un modelo base, ¿con qué datos lo entrenaste? ¿Dónde están almacenados? ¿Quién tuvo acceso?
• Embeddings: los embeddings técnicamente codifican fragmentos del texto original. Si te demandan por el corpus del RAG y pedís que preserven los embeddings, ¿los tenés identificados por documento de origen?
• System prompt y few-shot examples: ¿están documentados y versionados? ¿O viven solo en el código de producción sin changelog?

Caso anonimizado: SaaS B2B de documentos legales (~30 personas) construyó un copilot de IA para resumir contratos. RAG sobre su base de conocimiento interna (todo propio, licenciados o públicos). Cumplía con la auditoría de origen. Pero cuando les pedí el log de qué embeddings correspondían a qué documento, no lo tenían. Les tomó 3 semanas reconstruirlo con su proveedor de vector DB. Si un juez les hubiera pedido esa info en 48 horas, no la tenían. Eso es data lineage insuficiente.

Lo mínimo que tiene que existir: una tabla (puede ser un CSV simple) que mapee cada chunk en tu vector DB → documento original → fecha de ingesta → fuente (URL, upload del cliente, feed, etc.). Si tu proveedor de vector DB te lo da en una query, perfecto. Si no, montá un script que lo genere. Es trabajo de 1 día.

Auditoría 3 · Policy de training data del proveedor

La pregunta: ¿tu proveedor de modelo declara abiertamente qué tipo de datos usó para entrenar? ¿Y podés conseguir esa declaración por escrito?

El problema: la mayoría de los proveedores de frontera (OpenAI, Anthropic, Google, Meta con Llama) tienen políticas de training data que son ambiguas por diseño. Dicen cosas como "we use a mix of public data, licensed data, and human-generated data" sin especificar proporciones, fuentes ni mecanismos de opt-out.

Qué pedir concretamente a tu proveedor (por email, no por chat):

1. Declaración jurada de origen de training data para el modelo específico que usás (no para "nuestra familia de modelos"). Distintos modelos en la misma familia pueden tener políticas distintas.
2. Confirmación de derecho a sublicenciar outputs — ¿podés dar a tus clientes una licencia sobre los outputs sin que el proveedor pueda reclamar?
3. Mecanismo de opt-out para publishers — ¿hay un proceso formal para que un publisher pida que su contenido sea excluido del training? Si sí, ¿hay publishers conocidos que hayan usado ese proceso contra este modelo?
4. Historial de cambios — si el modelo fue re-entrenado o actualizado, ¿la policy nueva aplica retroactivamente a outputs previos?

Por qué importa: el argumento legal "no sabía qué datos se usaron para entrenar" es atendible pero débil. El argumento "pregunté, me dieron una declaración escrita que decía X, actué en base a eso" es mucho más fuerte en discovery.

Auditoría 4 · Insurance: E&O + rider de IP/AI

La pregunta: ¿tu póliza de Errors & Omissions (E&O) cubre un reclamo de IP por contenido generado por tu feature de IA?

La realidad que veo: la mayoría de las pólizas E&O de startups SaaS cubren defectos en el servicio, negligencia profesional, breaches de datos. No cubren por default reclamos de propiedad intelectual sobre outputs. Y mucho menos si esos outputs fueron generados por un modelo de IA que el proveedor entrenó con scraped content.

Qué pedir a tu broker (o a uno nuevo, si el actual no sabe de AI):

• Confirmación por escrito de que la póliza cubre reclamos de IP/AI. Email o rider escrito, no verbal.
• Cobertura específica por "AI-generated content" o "generative AI outputs". Algunos brokers (Coalition, At-Bay, Vouch en EE.UU.) ya tienen riders específicos.
• Sublímite por incidente y agregado anual. Rango realista para una startup serie A-B: USD 1-5M por incidente.
• Exclusiones a chequear: ¿la póliza excluye reclamos basados en "datos de entrenamiento del proveedor"? ¿Excluye reclamos por copyright específicamente? Si la respuesta es sí a cualquiera, tenés un agujero.
• Costo esperado del rider: USD 5.000-15.000/año adicionales sobre la prima E&O existente para una startup de USD 5-20M raised. Es accesible. No es accesible es no tenerlo y enterarte cuando llegue el reclamo.

Lo que NO cubre este punto: advice legal sobre tu póliza específica. Esto es para que sepas qué preguntarle a tu broker, no para que decidas solo. Un broker serio especializado en tech debería poder responderte las 5 preguntas anteriores en una llamada de 30 min.

El ángulo cross-border: por qué importa aún si no operás en China o India

El caso Moonshot/Fable (22 jul) y el fallo Delhi HC (24 jul) son señales de que el riesgo de copyright de IA no es solo "EE.UU. vs OpenAI". Es un problema que se está jugando en múltiples jurisdicciones con señales contradictorias.

Lo que esto significa para tu SaaS:

• Si servís clientes en EE.UU., tu peor caso es el escenario NYT (sanciones, discovery agresivo, posibles daños).
• Si servís clientes en India, el fallo Delhi HC te favorece por ahora, pero el caso de fondo sigue abierto.
• Si usás un proveedor con infraestructura en Asia (incluso como sub-proveedor), el ángulo de sanciones y exportación aplica.
• Si tu feature permite a usuarios generar contenido que luego se distribuye globalmente, técnicamente estás expuesto a todas las jurisdicciones donde ese contenido se consume.

Implicación operativa: no asumas que por estar en Latam estás a salvo. La cadena de suministro de tu IA importa. Tu proveedor de modelo importa. Tu ToS con tus clientes importa. La auditoría legal completa requiere asumir el peor caso, no el mejor.

Checklist accionable para esta semana

Priorizado. Si solo podés hacer cinco cosas, hacé las primeras cinco. El resto podés delegarlo.

• Alta prioridad · día 1-2: Leé el ToS de tu proveedor de modelo (OpenAI, Anthropic, Google, etc.). Buscá "indemnification", "IP", "training data". Documentá qué encontraste en una nota interna.
• Alta prioridad · día 1-2: Listá todos los proveedores de tu cadena de IA (modelo, embeddings, vector DB, hosting, GPU provider). ¿Alguno está en una jurisdicción con riesgo de sanciones?
• Alta prioridad · día 2-3: Confirmá con tu proveedor de modelo, por email, su policy de training data específica para el modelo que usás. Guardá el email.
• Alta prioridad · día 3: Contactá a tu broker de seguros. Preguntá específicamente si tu E&O cubre IP/AI. Pedí confirmación por escrito.
• Alta prioridad · día 3-4: Mapeá tu data lineage. Tabla: cada chunk en vector DB → documento original → fecha → fuente. Si no la tenés, montá un script para generarla.
• Media prioridad · semana 2: Hablá con tu abogado sobre redacción de tu ToS hacia el cliente final. ¿Tu ToS te protege si el output infringe?
• Media prioridad · semana 2: Evaluá alternativas a tu proveedor actual. ¿Hay un modelo con training data explícitamente licenciado (por ejemplo, los modelos abiertos de AI2, Mistral con licencia enterprise) que podrías usar para flujos críticos?
• Media prioridad · semana 2: Si servís clientes enterprise, avisales que estás haciendo la auditoría. Una nota proactiva de "compliance in progress" puede ser la diferencia entre renovar contrato o no.
• Baja prioridad · mes 1: Considerá un segundo proveedor (Claude ↔ OpenAI suelen ser intercambiables con cambios menores) como fallback si el principal entra en litigio sistémico.
• Baja prioridad · mes 1: Si hacés fine-tuning, auditá el origen del fine-tuning data con el mismo rigor que el RAG.
• Baja prioridad · mes 1: Documentá quién en tu equipo tiene acceso a los datasets de entrenamiento y embeddings. Si no hay nadie con acceso formal, tenés un riesgo de seguridad además de legal.

Lo que este post NO cubre

Para que quede claro:

• No es advice legal. Si necesitás advice legal específico sobre tu contrato con tu proveedor de modelo o sobre cómo redactar tu ToS hacia tus clientes, contratá un abogado de IP/AI. En Latam hay firmas especializadas; en EE.UU., abogados con experiencia en generative AI litigations.
• No cubre ML clásico pre-LLM. El riesgo de copyright sobre modelos entrenados con datasets propietarios es distinto y más manejable. Este post asume que usás LLMs frontera o modelos abiertos recientes.
• No cubre el lado del proveedor. Si estás construyendo un modelo desde cero y entrenando con scraped data, este post no es para vos — necesitás advice legal específico mucho antes de entrenar.
• No cubre deepfakes o generación de imágenes. El caso NYT/Moonshot/Delhi es sobre texto. La jurisprudencia sobre imágenes generadas por IA tiene sus propios precedentes.

Si te interesa trabajar esto con apoyo

Si tu SaaS tiene feature de IA y querés ayuda para hacer esta auditoría operativa (las 4 que cubrí arriba), o querés que revise tu caso específico con tu proveedor de modelo, agendá una llamada de 30 minutos gratis. Hago este tipo de auditoría para founders SaaS LATAM y suele destaparse algo que el cliente no había visto.

Preguntas frecuentes

¿Esto aplica a mi SaaS si solo uso RAG con mis propios documentos?

Aplica menos que si usás un modelo fine-tuneado o scraped, pero no es cero. Si tu proveedor de embeddings o LLM fue entrenado con material con copyright y vos no podés demostrar que tu output es lo suficientemente transformativo, estás expuesto al mismo argumento que los publishers le están haciendo a OpenAI. La auditoría mínima sigue siendo necesaria.

¿Cuánto cuesta agregar cobertura IP/AI a mi póliza de E&O?

Para una startup SaaS serie A-B (USD 5-20M raised), un rider de IP/AI sobre una póliza E&O existente típicamente cuesta USD 5.000-15.000/año adicionales, dependiendo de cobertura (USD 1-5M por incidente) y deducible. Brokers especializados en tech (Coalition, At-Bay, Vouch) tienen productos específicos. Si tu E&O actual no menciona 'AI' o 'generative', casi seguro no te cubre.

¿Qué hago si mi proveedor de modelo no me da detalles de training data?

Documentá la negativa por escrito (email basta). Eso te protege en discovery si algún día te demandan: mostrás que intentaste actuar con diligencia. Mientras tanto, asumí el peor caso en tu evaluación interna de riesgo: que el modelo fue entrenado con scraped content con copyright. Si eso cambia tu decisión de usarlo (ej. reemplazable por modelo abiertamente licenciado), considerá migrar.

¿El fallo de Delhi HC a favor de OpenAI significa que el riesgo es bajo?

No. Es un fallo interino sobre injunctive relief (no una decisión final sobre infringement). Además solo aplica a India bajo la Indian Copyright Act. Si tu SaaS sirve clientes en US, EU, UK o Latam, ese fallo no te protege. Lo que sí te dice es que no hay regla global todavía — y eso es parte del problema: cada jurisdicción decide distinto.

¿Audito yo mismo o contrato un abogado?

Las 4 auditorías de este post las podés hacer vos o tu CTO esta semana (son operativas: leer ToS, listar proveedores, pedir declaraciones, hablar con tu broker). Lo que NO podés hacer solo es el consejo legal sobre tu contrato específico con el proveedor de modelo ni la redacción de tu ToS hacia tus clientes. Eso es abogado, no este post.