Preserving an artwork that relies on an AI model

Between 3 February and 19 May 2024, the Whitney Museum displayed two versions of AARON, the program Harold Cohen began conceiving in the late 1960s. The exhibition brought together works from the collection, on-screen versions of the software, and active plotters tracing images from various stages. These plotters were not the original machines. The museum describes them as modernised recreations, manufactured for the exhibition and adjusted to the paper sizes and line widths Cohen had used.

AARON could be run again because versions of the program survived and it was possible to reconstruct the machines that interpreted its commands. The Whitney website does not publish the complete technical protocol followed to bring the code into operation. Even so, the case reveals a crucial difference. An institution that acquires an artwork connected to an artificial intelligence model hosted by a company does not necessarily acquire the model. It preserves a program that formulates requests to an external infrastructure. If the provider retires the model, changes the filters or closes the API, the artwork's code may remain intact while that which provided the responses has vanished.

It is not the usual obsolescence of a machine. It is dependency without custody.

The artwork is distributed

An artwork based on artificial intelligence may be distributed across several layers belonging to different entities:

The artwork's code, its instructions, parameters and interaction rules.
The local environment that executes that code.
The API, the authentication system and the libraries that connect to the provider.
The model, its weights, its version, its filters and its inference configuration.
The remote infrastructure that determines how it executes, what it costs and what it logs.
Auxiliary services: storage, moderation, speech synthesis, search, vector databases, queues and analytics.

The artist or the museum may control the first two. The others may depend on several companies. An update to any of them alters the result without touching the file acquired by the collection. The same commercial identifier may even end up routing to a later version. From the outside, the call functions; the artwork no longer behaves the same.

‘Before the prompt’ reconstructs a history of interfaces that mediate between intention and result. The problem of conservation appears afterwards. The visible interface may remain while the system that interprets the instructions changes. Preserving the screen and the client code does not guarantee that the artwork has been preserved.

The dependency is not limited to the model either. A piece may retain access to the model while losing the moderation service that rejected certain responses, the library that ordered the tools, the voice engine that gave body to the result or the remote database that stored the memory of each visitor. The dossier must describe the entire chain, not just the most well-known brand.

Models expire

Company policies are designed for clients and developers to migrate applications. They do not offer a guarantee of artistic continuity.

Provider	Documented notice	After retirement	Custody of weights
OpenAI	As a rule, at least six months for generally available models and three for specialised variants. Preview models may be retired with much shorter timeframes, such as two weeks. Security or compliance reasons may shorten notice periods.	On the closure date, the model or endpoint ceases to be accessible. In certain cases, dedicated capacity may be offered, without a general guarantee.	The retirement policy does not promise to deliver or publish the weights.
Anthropic	At least 60 days for public models retired from platforms operated by Anthropic. Partner-managed platforms have their own schedules.	Requests to a retired model fail, with declared exceptions.	The company commits to preserving the weights of published models and those with significant internal use for at least the lifetime of the company. Preserving is not equivalent to providing access.
Google, Gemini API	Publishes closure dates and presents them as the earliest possible dates. It does not set a single minimum timeframe for all models on that page.	The endpoint may be closed or, in certain cases, automatically route requests to a replacement.	The retirement page does not offer general delivery of weights.
Midjourney	Documents previous versions and functions, without a general guarantee of indefinite access.	Documentation of a version does not certify that it remains available for execution.	It is a hosted service and does not publish its weights.
Stability AI	The cycle depends on the model and the form of distribution. Some models can be downloaded and hosted locally.	A local copy allows a version to be preserved as long as a compatible environment, hardware and licence survive.	Certain models distribute weights under licence.

OpenAI distinguishes between announced retirement, closure and legacy status. Following the announcement, the model remains operational until the specified date; thereafter, it becomes inaccessible. The documentation allows certain closures to be monitored via the shutdown_date field in the models API. This improvement facilitates oversight, yet it does not make the date a guarantee of preservation. A production system should record the exact identifier and periodically check this field, without assuming that the absence of a date equates to indefinite availability.

In November 2025, Anthropic made a different commitment: to preserve the weights of all published models and those with significant internal use for at least the lifetime of the company. Corporate preservation may facilitate future research. The collection does not receive a copy, nor does it acquire the legal or material capacity to run the model. Claude Opus 3 shows how exceptional some reprieves are. The company retired it on 5 January 2026, subsequently maintaining access for paid users and, upon request, via API. Continuity depended on a provider decision.

Google introduces a more elusive problem. Certain versions are no longer selectable, yet the endpoint does not close: requests are redirected to a subsequent model. For a conventional application, this change may be useful. For an artwork, preserving the route name while the behaviour changes can result in a silent loss.

Availability is not identity

Verifying that an API returns 200 only demonstrates that a response exists. The work may remain 'alive' while the following change:

The statistical distribution of the outputs.
The safety filters and their thresholds.
The interpretation of instructions.
The length and management of the context.
The randomness, the seeds, and the reproducibility.
The pricing, quotas, and usage limits.
The input and output formats.
The policies regarding logging, retention, or use of submitted data.
The tools the model may invoke.
The latency, which may form part of the temporal experience.

An automatic migration may preserve a practical function whilst destroying an artistic property. If a piece relied upon abrupt responses, specific errors, or a recognisable way of associating images and language, the technical improvement may correct precisely that which the work rendered visible.

For this reason, reference results must be preserved, not merely the model name. The test suite should include representative inputs, archived outputs, response times, expected errors, pertinent metrics, and a qualitative description of the behaviour. It will not reconstruct the model. It will allow one to decide whether a subsequent execution remains an acceptable instance of the work.

The test must distinguish between three states:

Availability: the provider accepts the call.
Technical integrity: the inputs, outputs, and tools maintain the expected format.
Behavioural fidelity: the experience retains the properties that the artist and the institution declared significant.

The third state cannot always be reduced to a figure. It may require visual comparison, listening, curatorial assessment, and the artist's participation. A tolerance formulated before the change avoids deciding under pressure when the model has already disappeared.

The museum already knows how to preserve software, but not the third-party server

The Guggenheim's Variable Media Initiative, launched in 1999, proposed describing works by their behaviours and the changes they permit. Its four strategies are storage, emulation, migration, and reinterpretation. The work is defined with a degree of independence from the medium to determine what may change when that medium becomes obsolete.

Tate employs a complementary technical separation: digital artefact, execution environment, and hardware environment. Its software-based art conservation project creates forensic disk images, documents systems, and prepares emulated machines when the tools permit. Emulation reduces dependence on ephemeral physical hardware by preserving an executable environment.

Rhizome preserves more than two thousand works in ArtBase and has developed instruments to capture sites and recreate legacy browsers. EaaSI, which emerged from Yale University Library and the Software Preservation Network, facilitates the institutional use and exchange of emulated environments.

These strategies presuppose the existence of an artefact or environment that can be acquired, copied, or described in sufficient detail. A remote model introduces an inaccessible layer. The institution may archive the client, the library, and the execution logs; it cannot create a forensic image of the provider's server.

The distinction links to ‘Archiving and preserving a work created with artificial intelligence’, where I propose recording materials, tools, versions, decisions and dependencies. It also extends the practical logic of ‘Master file: digital work and versions’: preserving editable files and exchange formats protects the work the author controls, but an API requires documenting what was never inside the master file.

The four strategies can be applied to an AI-based work, with clear limitations.

Storage. This is viable when downloadable weights exist and a licence authorises their custody and execution. The exact file, its checksum, the licence, the loading code, the dependencies, the environment, and a description of the hardware must be saved. The commercial name of the model does not identify an instance.

Emulation. This can preserve the operating system, the libraries, and the logical hardware that execute a local model. It does not emulate an unknown remote service. It could preserve the client that made the request; the server would remain absent.

Migration. This replaces the model with another. It is a curatorial and artistic decision, not routine maintenance. Equivalence requires prior criteria: essential properties, permissible deviations, and authority to approve the change.

Reinterpretation. This produces a new incarnation when the previous one can no longer be maintained. It may use another model or a different procedure if the work admits such variability and the new version is declared as a reinterpretation. Without such a mandate, the update may present a new work under the identity of the previous one.

There is a fifth possibility: concluding the work. Some pieces deliberately depend on a service, a community, or a set of circumstances. Their disappearance may form part of their history. Preserving documentation and declaring that the work is no longer executable may be more faithful than fabricating an unauthorised continuity.

Downloadable weights: greater control, not self-sufficiency

A model that can be run locally improves the situation because the institution can hold an instance in custody. It must still resolve the licence, the hardware, the inference code and the origin of the data.

The licence may limit uses, sectors, revenue, redistribution, or derivative versions. The SDXL 1.0 licence identifies the model via checkpoints, weights, and parameters, but excludes the training data from its scope. Subsequent Stability AI licences distinguish between community and commercial uses based on economic conditions. The exact version applicable on the day of acquisition must be preserved; linking to a mutable page is insufficient.

Hardware also ages. A model may depend on libraries, drivers, compilers, or GPU capabilities that are difficult to reproduce. Saving the weights without the inference code and the environment offers only nominal custody: the file remains readable, but the execution has vanished.

The model licence also does not replace the licences of its components. The dossier must separate, where appropriate, weights, code, libraries, fonts, databases, voices, input materials and archived outputs. Technical preservation does not grant rights that the acquisition contract or the licences did not concede.

The origin of the data poses another question. Custody of a model does not resolve the legality of its training nor does it extend the permissions for exhibition, access, or redistribution. The technical capacity to execute must be distinguished from the legal authorisation to do so.

The precedent of a lost API

Schwitters on Twitter, by David Sullivan, is a 2009 bot incorporated into ArtBase. The description provided by the artist explains that a program written in Processing, using the Java Twitter4J library, published to the @kschwitters account.

The ZKM Net Art Extinction Timeline links its degradation to the closure of free access to the Twitter API announced in 2023. The entry states that, without valid credentials and paid access, publication and retrieval fail. It is marked as investigated via artificial intelligence, so it does not equate to a conservation report. Rhizome confirms the work, the technique, and the original dependency; I have not located a statement from Rhizome or the artist documenting the current state, nor a migration, emulation, restoration, or reinterpretation.

The case allows for a limited assertion: a work may depend on an external API and lose an essential function when access changes. It does not demonstrate that the work has disappeared entirely, nor does it document its subsequent treatment. Nor is it a case of the retirement of an AI model.

I have not located in the reviewed sources a work whose failure due to the retirement of an AI model is documented by the conserving institution alongside the treatment applied. That absence prevents presenting as a precedent what is still a projection based on technical policies.

The lack of public cases also says something about institutional practice. It may signify that these acquisitions remain recent, that treatments are not published, or that the dependency was not documented with sufficient precision to identify the loss. In any of the three scenarios, the collection needs to formulate now the questions that will be impossible to answer later.

Acquiring a dependency

Receiving files and an API key is not enough. The acquisition dossier should include:

Exact identifier of the model, endpoint, and version.
Provider and effective platform, because associated services may apply different schedules.
Client source code and dependencies locked by version.
Instructions, system messages, tools, parameters, and seeds where they exist.
Reference inputs and outputs, with authorisation to preserve them.
Record of observable filters, limits and security configuration.
Credentials kept separate from the dossier and a procedure for renewing them.
Forecast cost, quotas, usage limits, and the party responsible for payment.
Terms of service, licences and retirement policies archived with a date.
Data that the work sends to the provider and the retention regime.
Essential behaviours and tolerances regarding changes.
Authorised decision in the event of retirement: migrate, reinterpret, document or conclude.
Persons empowered to approve a new version after the death or incapacity of the artist.

The acquisition contract should also resolve who assumes future migrations, who pays for the infrastructure, what happens if the provider unilaterally changes its conditions, and what the institution can do without new authorisation from the artist. A clause that promises to "keep the work operational" without defining costs, tolerances, and authority transfers the conflict to the future.

The conditions for preserving layered files and changing programs remain necessary for the editable parts. In a connected piece, contracts, technical identity and behaviour tests must be added.

Privacy is part of conservation when the work receives data from the public. It must be documented what is sent to the provider, whether personal data exists, where it is stored, for how long, and on what legal basis. It is not prudent to archive all interactions indiscriminately to preserve behaviour: a collection may require an anonymised or synthetic sample and a retention policy separate from the artistic archive.

Testing before retirement

The plan must be put into practice while the system is working. Retirement is not the moment to begin documenting.

A periodic review can record the version declared by the provider, check the published shutdown dates, run the test suite and compare the results with earlier references. The frequency depends on the risk: a preview model with only a few weeks' notice requires more frequent monitoring than a stable model with six months' notice. Monitoring must generate a useful alert, not an accumulation of reports that nobody reads.

Should deviations emerge, the dossier must distinguish between expected variation and material alteration. The decision cannot be left to a single metric. A work may depend on perceptual or conceptual properties that require human assessment and, where possible, the artist's participation.

It is also worthwhile to prepare degraded states. The interface may operate using archived responses, display a recording of an execution, or exhibit the protocol and the absence of the service. No option automatically replaces the active work. These are distinct documentary states and must be designated as such. The wall label and catalogue should not present a recording as if the work were still executing.

A collection does not control the continuity of a company, but it does control the clarity of its acquisition. If the contract does not specify what occurs when the model changes, the institution will inherit a technical and authorial dispute. If it does, the retirement may still bring the original execution to an end, though it will not erase the possibility of understanding what the work was or why it ceased to function.

On the open conversation

This text separates verified policies, institutional precedents and interpretation. If you work in conservation, digital collections, software-based art or artificial intelligence infrastructure and can provide a documented case of retirement, migration or reactivation, you may contact me.

The author’s relationship to the cases

I am developing a generative work that depends on third-party network infrastructure, meaning the problem analysed affects me directly. I use artificial intelligence tools from several of the companies cited. There is no financial or professional relationship with the Whitney, Guggenheim, Tate, Rhizome, ZKM, or the providers mentioned.

When the model disappears: preserving an artwork that relies on artificial intelligence