Conservar una obra que depende de un modelo de IA

Entre el 3 de febrero y el 19 de mayo de 2024, el Whitney Museum mostró dos versiones de AARON, el programa que Harold Cohen empezó a concebir a finales de los años sesenta. La exposición reunió obras de la colección, versiones del software en pantalla y plóteres activos trazando imágenes de distintas etapas. Esos plóteres no eran las máquinas originales. El museo los describe como recreaciones modernizadas, fabricadas para la exposición y ajustadas a los tamaños de papel y anchos de línea que Cohen había utilizado.

AARON pudo volver a ejecutarse porque sobrevivían versiones del programa y era posible reconstruir las máquinas que interpretaban sus órdenes. La página del Whitney no publica el protocolo técnico completo seguido para poner el código en funcionamiento. Aun así, el caso deja ver una diferencia crucial. Una institución que adquiere una obra conectada a un modelo de inteligencia artificial alojado por una empresa no adquiere necesariamente el modelo. Conserva un programa que formula peticiones a una infraestructura ajena. Si el proveedor retira el modelo, cambia los filtros o cierra la API, puede quedar intacto el código de la obra y haber desaparecido aquello que respondía.

No es la obsolescencia habitual de una máquina. Es dependencia sin custodia.

La obra está repartida

Una obra basada en inteligencia artificial puede distribuirse entre varias capas que pertenecen a responsables distintos:

El código de la obra, sus instrucciones, parámetros y reglas de interacción.
El entorno local que ejecuta ese código.
La API, el sistema de autenticación y las bibliotecas que conectan con el proveedor.
El modelo, sus pesos, su versión, sus filtros y su configuración de inferencia.
La infraestructura remota que decide cómo se ejecuta, cuánto cuesta y qué registra.
Los servicios auxiliares: almacenamiento, moderación, síntesis de voz, búsqueda, bases vectoriales, colas y analítica.

El artista o el museo quizá controle las dos primeras. Las demás pueden depender de varias empresas. Una actualización en cualquiera de ellas altera el resultado sin tocar el archivo adquirido por la colección. El mismo identificador comercial puede incluso acabar enrutando a una versión posterior. Desde fuera, la llamada funciona; la obra ya no se comporta igual.

«Antes del prompt» reconstruye una historia de interfaces que median entre intención y resultado. El problema de conservación aparece después. La interfaz visible puede permanecer mientras cambia el sistema que interpreta las instrucciones. Preservar la pantalla y el código cliente no garantiza haber preservado la obra.

La dependencia tampoco se limita al modelo. Una pieza puede conservar el acceso al modelo y perder el servicio de moderación que rechazaba determinadas respuestas, la biblioteca que ordenaba las herramientas, el motor de voz que daba cuerpo al resultado o la base remota que almacenaba la memoria de cada visitante. El expediente debe describir la cadena completa, no solo la marca más conocida.

Los modelos caducan

Las políticas de las empresas están pensadas para que clientes y desarrolladores migren aplicaciones. No ofrecen una garantía de continuidad artística.

Proveedor	Aviso documentado	Tras la retirada	Custodia de pesos
OpenAI	Como regla, al menos seis meses para modelos de disponibilidad general y tres para variantes especializadas. Los modelos preview pueden retirarse con plazos mucho menores, como dos semanas. Las razones de seguridad o cumplimiento pueden acortar los avisos.	En la fecha de cierre, el modelo o endpoint deja de estar accesible. En determinados casos puede ofrecerse capacidad dedicada, sin garantía general.	La política de retirada no promete entregar ni publicar los pesos.
Anthropic	Al menos 60 días para modelos públicos retirados de plataformas operadas por Anthropic. Las plataformas gestionadas por socios tienen calendarios propios.	Las peticiones a un modelo retirado fallan, salvo excepciones declaradas.	La empresa se compromete a preservar los pesos de modelos publicados y de uso interno significativo durante, como mínimo, la vida de la empresa. Preservar no equivale a proporcionar acceso.
Google, Gemini API	Publica fechas de cierre y las presenta como primeras fechas posibles. No fija en esa página un plazo mínimo único para todos los modelos.	El endpoint puede cerrarse o, en determinados casos, enrutar automáticamente las peticiones a un reemplazo.	La página de retiradas no ofrece una entrega general de pesos.
Midjourney	Documenta versiones y funciones anteriores, sin una garantía general de acceso indefinido.	La documentación de una versión no acredita que siga disponible para ejecución.	Es un servicio alojado y no publica sus pesos.
Stability AI	El ciclo depende del modelo y de la forma de distribución. Algunos modelos pueden descargarse y alojarse localmente.	Una copia local permite conservar una versión mientras sobrevivan entorno, hardware y licencia compatibles.	Determinados modelos distribuyen pesos bajo licencia.

OpenAI distingue entre retirada anunciada, cierre y estado heredado. Tras el anuncio, el modelo sigue funcionando hasta la fecha fijada; después deja de estar accesible. La documentación permite consultar ciertos cierres mediante el campo shutdown_date de la API de modelos. Esa mejora facilita la vigilancia, pero no convierte la fecha en garantía de conservación. Un sistema de producción debería registrar el identificador exacto y comprobar periódicamente ese campo, sin suponer que una ausencia de fecha equivale a disponibilidad indefinida.

Anthropic asumió en noviembre de 2025 un compromiso diferente: conservar los pesos de todos los modelos publicados y de aquellos con uso interno significativo durante, al menos, la existencia de la empresa. La preservación empresarial puede facilitar una investigación futura. La colección no recibe por ello una copia ni adquiere capacidad jurídica o material para ejecutar el modelo. Claude Opus 3 muestra el carácter excepcional de algunas salidas. La empresa lo retiró el 5 de enero de 2026 y después mantuvo acceso para usuarios de pago y, previa solicitud, mediante API. La continuidad dependió de una decisión del proveedor.

Google añade un problema más difícil de percibir. Algunas versiones dejan de ser seleccionables, pero el endpoint no se cierra: las solicitudes se redirigen a un modelo posterior. Para una aplicación convencional, el cambio puede ser útil. Para una obra, conservar el nombre de la ruta mientras cambia el comportamiento puede producir una pérdida silenciosa.

Disponibilidad no es identidad

Comprobar que una API devuelve 200 solo demuestra que existe una respuesta. La obra puede seguir «viva» mientras cambian:

La distribución estadística de las salidas.
Los filtros de seguridad y sus umbrales.
La interpretación de instrucciones.
La longitud y gestión del contexto.
La aleatoriedad, las semillas y la reproducibilidad.
Los precios, cuotas y límites de uso.
Los formatos de entrada y salida.
Las políticas sobre registro, retención o uso de los datos enviados.
Las herramientas que el modelo puede invocar.
La latencia, que puede formar parte de la experiencia temporal.

Una migración automática puede conservar una función práctica y destruir una propiedad artística. Si una pieza dependía de respuestas abruptas, errores concretos o una forma reconocible de asociar imágenes y lenguaje, la mejora técnica puede corregir precisamente aquello que la obra hacía visible.

Por eso hay que conservar resultados de referencia, no solo el nombre del modelo. El conjunto de pruebas debería incluir entradas representativas, salidas archivadas, tiempos de respuesta, errores esperados, métricas pertinentes y una descripción cualitativa del comportamiento. No reconstruirá el modelo. Permitirá decidir si una ejecución posterior sigue siendo una instancia aceptable de la obra.

La prueba debe distinguir tres estados:

Disponibilidad: el proveedor acepta la llamada.
Integridad técnica: las entradas, salidas y herramientas mantienen el formato esperado.
Fidelidad de comportamiento: la experiencia conserva las propiedades que el artista y la institución declararon significativas.

El tercer estado no puede reducirse siempre a una cifra. Puede exigir comparación visual, escucha, ensayo curatorial y participación del artista. Una tolerancia formulada antes del cambio evita decidir bajo presión cuando el modelo ya ha desaparecido.

El museo ya sabe conservar software, pero no el servidor ajeno

La Variable Media Initiative del Guggenheim, iniciada en 1999, propuso describir las obras por sus comportamientos y por los cambios que admiten. Sus cuatro estrategias son almacenamiento, emulación, migración y reinterpretación. La obra se define con cierta independencia del soporte para determinar qué puede cambiar cuando ese soporte queda obsoleto.

Tate utiliza una separación técnica complementaria: artefacto digital, entorno de ejecución y entorno de hardware. Su proyecto de conservación de arte basado en software crea imágenes forenses de discos, documenta sistemas y prepara máquinas emuladas cuando las herramientas lo permiten. La emulación reduce la dependencia de un hardware físico efímero al conservar un entorno ejecutable.

Rhizome conserva más de dos mil obras en ArtBase y ha desarrollado instrumentos para capturar sitios y recrear navegadores antiguos. EaaSI, surgida de Yale University Library y Software Preservation Network, facilita el uso y el intercambio institucional de entornos emulados.

Estas estrategias presuponen que existe un artefacto o entorno que puede adquirirse, copiarse o describirse con suficiente detalle. Un modelo remoto introduce una capa inaccesible. La institución puede archivar el cliente, la biblioteca y los registros de ejecución; no puede crear una imagen forense del servidor del proveedor.

La diferencia enlaza con «Archivo y conservación de una obra realizada con inteligencia artificial», donde propongo registrar materiales, herramientas, versiones, decisiones y dependencias. También prolonga la lógica práctica de «Archivo maestro: obra digital y versiones»: conservar editables y formatos de intercambio protege el trabajo controlado por el autor, pero una API obliga a documentar aquello que nunca estuvo dentro del archivo maestro.

Las cuatro estrategias pueden aplicarse a una obra con IA, con límites claros.

Almacenamiento. Resulta viable cuando existen pesos descargables y una licencia que autoriza su custodia y ejecución. Deben guardarse el archivo exacto, su suma de comprobación, la licencia, el código de carga, las dependencias, el entorno y una descripción del hardware. El nombre comercial del modelo no identifica una instancia.

Emulación. Puede conservar el sistema operativo, las bibliotecas y el hardware lógico que ejecutan un modelo local. No emula un servicio remoto desconocido. Podría conservar el cliente que hacía la petición; el servidor seguiría ausente.

Migración. Sustituye el modelo por otro. Es una decisión curatorial y artística, no mantenimiento rutinario. La equivalencia requiere criterios previos: propiedades esenciales, desviaciones admisibles y autoridad para aprobar el cambio.

Reinterpretación. Produce una nueva encarnación cuando ya no puede mantenerse la anterior. Puede usar otro modelo o un procedimiento distinto si la obra admite esa variabilidad y la nueva versión se declara como reinterpretación. Sin ese mandato, la actualización puede presentar una obra nueva bajo la identidad de la anterior.

Hay una quinta posibilidad: concluir la obra. Algunas piezas dependen deliberadamente de un servicio, una comunidad o una coyuntura. Su desaparición puede formar parte de su historia. Conservar documentación y declarar que la obra ya no es ejecutable puede ser más fiel que fabricar una continuidad no autorizada.

Pesos descargables: más control, no autosuficiencia

Un modelo ejecutable localmente mejora la situación porque la institución puede custodiar una instancia. Todavía debe resolver la licencia, el hardware, el código de inferencia y el origen de los datos.

La licencia puede limitar usos, sectores, ingresos, redistribución o versiones derivadas. La licencia de SDXL 1.0 identifica el modelo mediante checkpoints, pesos y parámetros, pero excluye los datos de entrenamiento de su objeto. Las licencias posteriores de Stability AI distinguen usos comunitarios y empresariales según condiciones económicas. Hay que conservar la versión exacta aplicable el día de la adquisición; enlazar a una página mutable no basta.

El hardware también envejece. Un modelo puede depender de bibliotecas, controladores, compiladores o capacidades de GPU difíciles de reproducir. Guardar los pesos sin el código de inferencia y el entorno ofrece una custodia nominal: el archivo sigue legible y la ejecución ha desaparecido.

La licencia del modelo tampoco sustituye a las licencias de sus componentes. El expediente debe separar, cuando proceda, pesos, código, bibliotecas, tipografías, bases de datos, voces, materiales de entrada y salidas archivadas. Conservar técnicamente no otorga derechos que el contrato de adquisición o las licencias no concedieron.

El origen de los datos plantea otra cuestión. Custodiar un modelo no resuelve la licitud de su entrenamiento ni amplía los permisos de exhibición, acceso o redistribución. La capacidad técnica de ejecutar debe distinguirse de la autorización jurídica para hacerlo.

El precedente de una API perdida

Schwitters on Twitter, de David Sullivan, es un bot de 2009 incorporado a ArtBase. La descripción aportada por el artista explica que un programa escrito en Processing, mediante la biblioteca Java Twitter4J, publicaba en la cuenta @kschwitters.

El Net Art Extinction Timeline de ZKM relaciona su degradación con el cierre del acceso gratuito a la API de Twitter anunciado en 2023. La ficha afirma que, sin credenciales válidas y acceso de pago, fallan la publicación y la recuperación. Está marcada como investigada mediante inteligencia artificial, por lo que no equivale a un informe de conservación. Rhizome confirma la obra, la técnica y la dependencia original; no he localizado una declaración de Rhizome o del artista que documente el estado actual ni una migración, emulación, restauración o reinterpretación.

El caso permite sostener una afirmación limitada: una obra puede depender de una API externa y perder una función esencial cuando cambia el acceso. No demuestra que la obra haya desaparecido por completo ni documenta su tratamiento posterior. Tampoco es un caso de retirada de un modelo de IA.

No he localizado en las fuentes revisadas una obra cuya avería por retirada de un modelo de IA esté documentada por la institución conservadora junto con el tratamiento aplicado. Esa ausencia impide presentar como precedente lo que todavía es una proyección fundada en políticas técnicas.

La falta de casos públicos también dice algo sobre la práctica institucional. Puede significar que estas adquisiciones siguen siendo recientes, que los tratamientos no se publican o que la dependencia no se documentó con suficiente precisión para identificar la pérdida. En cualquiera de los tres supuestos, la colección necesita formular ahora las preguntas que después serán imposibles de responder.

Adquirir una dependencia

Recibir archivos y una clave de API no basta. El expediente de adquisición debería incluir:

Identificador exacto del modelo, endpoint y versión.
Proveedor y plataforma efectiva, porque los servicios asociados pueden aplicar calendarios distintos.
Código fuente del cliente y dependencias bloqueadas por versión.
Instrucciones, mensajes de sistema, herramientas, parámetros y semillas cuando existan.
Entradas y salidas de referencia, con autorización para conservarlas.
Registro de filtros, límites y configuración de seguridad observables.
Credenciales separadas del expediente y procedimiento para renovarlas.
Coste previsto, cuotas, límites de uso y responsable del pago.
Condiciones del servicio, licencias y políticas de retirada archivadas con fecha.
Datos que la obra envía al proveedor y régimen de retención.
Comportamientos esenciales y tolerancias frente a cambios.
Decisión autorizada ante una retirada: migrar, reinterpretar, documentar o concluir.
Personas facultadas para aprobar una nueva versión después de la muerte o incapacidad del artista.

El contrato de adquisición debería resolver además quién asume futuras migraciones, quién paga la infraestructura, qué ocurre si el proveedor cambia unilateralmente sus condiciones y qué puede hacer la institución sin una nueva autorización del artista. Una cláusula que prometa «mantener la obra operativa» sin definir costes, tolerancias y autoridad traslada el conflicto al futuro.

Las condiciones para conservar archivos con capas y cambiar de programa siguen siendo necesarias para las partes editables. En una pieza conectada hay que añadir contratos, identidad técnica y pruebas de comportamiento.

La privacidad forma parte de la conservación cuando la obra recibe datos del público. Debe quedar documentado qué se envía al proveedor, si existen datos personales, dónde se almacenan, durante cuánto tiempo y con qué base jurídica. No es prudente archivar indiscriminadamente todas las interacciones para preservar el comportamiento: una colección puede necesitar una muestra anonimizada o sintética y una política de retención separada del archivo artístico.

Probar antes de la retirada

El plan debe ejecutarse mientras el sistema funciona. La retirada no es el momento de empezar a documentar.

Una revisión periódica puede registrar la versión declarada por el proveedor, consultar las fechas de cierre publicadas, ejecutar el conjunto de pruebas y comparar los resultados con referencias anteriores. La periodicidad depende del riesgo: un modelo preview con avisos de pocas semanas exige vigilancia más frecuente que un modelo estable con seis meses de preaviso. La supervisión debe generar una alerta útil, no una acumulación de informes que nadie revisa.

Si aparecen desviaciones, el expediente debe distinguir una variación esperada de una alteración material. La decisión no puede dejarse solo a una métrica. Una obra puede depender de propiedades perceptivas o conceptuales que requieren evaluación humana y, cuando sea posible, participación del artista.

También merece la pena preparar estados degradados. La interfaz puede operar con respuestas archivadas, mostrar una grabación de una ejecución o exponer el protocolo y la ausencia del servicio. Ninguna opción sustituye automáticamente a la obra activa. Son estados documentales distintos y deben nombrarse como tales. La cartela y el catálogo no deberían presentar una grabación como si la obra siguiera ejecutándose.

Una colección no controla la continuidad de una empresa, pero sí la claridad de su adquisición. Si el contrato no dice qué ocurre cuando el modelo cambia, la institución heredará una disputa técnica y autoral. Si lo dice, la retirada todavía puede terminar con la ejecución original, aunque no borrará la posibilidad de entender qué fue la obra ni por qué dejó de funcionar.

Sobre la conversación abierta

Este texto separa políticas verificadas, precedentes institucionales e interpretación. Si trabajas en conservación, colecciones digitales, arte basado en software o infraestructura de inteligencia artificial y puedes aportar un caso documentado de retirada, migración o reactivación, puedes escribirme.

Relación del autor con los casos

Desarrollo una obra generativa que depende de infraestructura de red de terceros, de modo que el problema analizado me afecta directamente. Utilizo herramientas de inteligencia artificial de varias empresas citadas. No existe relación económica ni profesional con Whitney, Guggenheim, Tate, Rhizome, ZKM ni los proveedores mencionados.

Cuando el modelo desaparece: conservar una obra que depende de la inteligencia artificial