A work made with artificial intelligence can keep its appearance and, at the same time, lose almost everything that made it possible to produce. The model changes, an account is closed, an API disappears, the provider alters its terms, or the intermediate files end up scattered across devices and services. The final result remains visible, but it can no longer be explained, verified or reproduced with rigour.
This guide organises the records needed to understand, display, pass on and preserve a work that uses AI. It does not presuppose that the result is protected by copyright. Documenting a process evidences facts and decisions; of itself it neither creates originality nor makes human a production that was not.
For the legal and communication questions, see also Authorship and works made with AI under Spanish law, How to disclose the use of artificial intelligence in an artwork, sale or open call, How to label content generated or modified with AI and the Master artwork record.
What the archive must make possible
A sufficient archive must answer five questions:
- What materials entered the process and under what rights or permissions.
- Which tools, models, and versions were involved.
- Which human decisions significantly altered the work.
- Which file or behaviour is considered the work.
- What needs to be kept in order to show the work again without replacing it with another.
Not every work requires the same level of detail. A still image exported as a TIFF has fewer dependencies than an installation that queries a remote model live. Documentation should be proportionate to the risk of loss, to complexity and to the commitments made to buyers, institutions and collaborators.
Open the dossier from the start
Do not reconstruct the process at the end. From the first session, create a folder or dossier with a stable naming convention. Record:
- Name of the tool and provider.
- Model or family of models.
- Version, when displayed, or date and time of access when the provider does not identify it.
- Type of account and features used.
- Device, operating system, and auxiliary applications.
- Use via web interface, local application or API.
- Date of each relevant change.
When a platform does not publish the exact version, do not invent one. Note what you know and what cannot be determined. An access date, screenshots of the interface and the account history can be more reliable than a name inferred afterwards.
Input materials and provenance
Keep separately the originals you contributed: images, sketches, texts, audio, video, code, datasets, fine-tuned models and your own references. Do not depend on the compressed copy left inside the platform.
For each material, record:
- Authorship and provenance.
- Date of creation or receipt.
- Licence, contract, consent or exception relied on.
- Changes made before incorporating it.
- Restrictions on reuse, publication, or training.
- Personal data or sensitive information it contains.
If you use third-party materials, keep the permission or legal basis that justified the use on the relevant date. The fact that a file was accessible on the internet does not mean it could be reused, added to a dataset or circulated within the work.
When you train or fine-tune a model on your own work, link this dossier to the documentation in Training an AI model on your own work. Keep the dataset used, its versions, the filters applied and the training parameters where technically and legally possible.
Instructions, versions, and decisions
It is not necessary to save every irrelevant interaction, but neither is it sufficient to retain only the final instruction. Select the milestones that explain how the work changed:
- Instructions that modified composition, content, or behaviour.
- Reference images or outputs chosen to continue.
- Discarded variants that allow an important decision to be understood.
- Masks, sketches, pose controls, seeds, and parameters where they exist.
- Subsequent edits in other applications.
- Selection and discard criteria.
Add a short note on why each milestone matters. A folder with hundreds of results and no context is a dumping ground for files, not process documentation.
The selection must be honest. Do not later reconstruct a sequence more coherent than the one that took place, and do not present as a conscious decision what was an automatic acceptance. The archive gains value when it distinguishes control, delegation, accident and uncertainty.
Master file and formats
Export a master file that is independent of the platform. Use an open or widely documented format, provided it does not destroy essential properties. Also keep, where appropriate:
- Editable project with layers and links.
- Lossless master file.
- Exhibition or distribution copy.
- Thumbnail or reference image.
- Checksums to detect changes.
- Colour profile, resolution, codec, sample rate, and other export parameters.
The master file does not replace the editable project, and the editable project does not replace the version shown. Keep both. If the work changes during an exhibition, keep the version actually exhibited and record the changes.
Keep at least two copies on different media and a third away from the main location. Check periodically that they can be opened. An untested backup merely expresses an intention.
Dependencies and behaviour
In a dynamic, interactive, or live-generated work, identity does not reside in a single file. Record:
- Model, API, and provider.
- Libraries and versions.
- Source code and execution environment.
- Hardware, sensors, controllers, and peripherals.
- Network connection and external services.
- Credentials required, without entering passwords in the general dossier.
- Usage limits, costs and quotas.
- Data generated during each execution.
Then describe the significant behaviour: what must happen for the work to remain recognisable as the same. Distinguish essential properties from variable elements. It may be essential that the system responds in real time, but not that it produces an identical image; or it may be essential to preserve a specific version because later variation would change the meaning.
Also document the acceptable failures. Latencies, errors or interruptions may form part of a work’s historical behaviour or be defects that should be corrected. That decision should not be left to the technician who reinstalls the work years later.
Emulation, migration and reinterpretation
Define a strategy before the technology fails:
- Emulation: reproducing the original environment through software or hardware that mimics its operation.
- Migration: transferring the work to a new system whilst attempting to preserve its significant properties.
- Reinterpretation: remaking the work by other means when the original device is no longer viable.
No strategy is neutral. Emulation may maintain behaviours whilst losing material qualities. Migration may improve performance whilst erasing a historically significant slowness. Reinterpretation may preserve the concept whilst transforming the experience.
Write down which changes you accept, which require authorisation and who may decide on them. The Variable Media Network questionnaires and the Matters in Media Art resources offer useful frameworks for formulating these decisions. If the work lives on the web, Conifer, developed by Rhizome, can record navigable sessions, although it does not by itself guarantee the preservation of external services or server-side processes.
Terms of use and technical provenance
Provider terms change. Keep a dated copy of the version that applied when you made the work, especially the clauses on:
- Ownership of, or licence to, outputs.
- Commercial use.
- Handling of materials you upload.
- Training or service improvement.
- Credits and restrictions.
- Account suspension.
- Data retention and deletion.
A contractual licence is distinct from copyright. A provider may allow commercial use of an output that does not reach the legal threshold for protection. It may also impose contractual conditions that say nothing about who is the author of the final work.
Content credentials based on C2PA can attach signed claims about provenance and transformations. They are useful for recording technical history and for verifying that certain declarations have not been altered. They do not prove that the signatory is the author, nor that every relevant step has been included. Also keep readable documentation separate from the file: metadata can be lost during export, capture or publication on a platform.
Collective work
When several people are involved, the archive also distributes power. Name the contributions without reducing them to a single lead credit:
- Concept.
- Input materials and data.
- Programming and integration.
- Selection and editing.
- Interaction design.
- Technical production.
- Preservation and reinstallation.
Agree in writing who decides on new versions, migrations, sales, loans and reinstallations. Settle credits and remuneration before exhibiting. Record what each person contributed and under what conditions it may be reused.
If images, voices or data of identifiable people are used, document the consent, its purpose and the means of withdrawing it. Organic Law 1/1982 provides that consent concerning privacy and one’s own image is revocable, without prejudice to any compensation due for damage caused. The processing of personal data must also comply with its own legal basis and information duties.
Name who will act as custodian of the archive, who will receive a copy and what will happen if the collective dissolves. Avoid having a single personal account hold essential materials.
Handover to an institution or buyer
Do not hand over only the visible file. Prepare a transfer package with:
- Master artwork record.
- Master file and exhibition copy.
- Register of input materials.
- Relevant version history.
- Dependencies and technical requirements.
- Installation and shutdown instructions.
- Description of significant behaviour.
- Preservation strategy.
- Credit and use conditions.
- Technical contacts and people responsible for authorisation.
Separate public documentation from confidential information. Keys, personal data, full contracts and materials without permission to disseminate must not be added without controls to the work’s publicly accessible archive.
Checklist
- ☐ I have recorded the tool, provider, model and date of access.
- ☐ I keep the input materials and their provenance.
- ☐ I have selected relevant instructions, versions and decisions.
- ☐ There is a master file independent of the platform.
- ☐ I keep the version that was actually shown.
- ☐ I have documented dependencies, code and hardware.
- ☐ I have described the significant behaviour.
- ☐ I have decided which changes are acceptable in a migration.
- ☐ I keep the terms of service that applied on the date of creation.
- ☐ The team's credits and contributions are documented.
- ☐ Someone is responsible for custody, and more than one copy has been checked.
- ☐ Handover to third parties distinguishes public from confidential documentation.
Itineraries
I need to document my work
Open the dossier in the first session. Do not try to preserve everything: identify input materials, milestones, decisions and master files. The record should allow another person to understand what happened without depending on your memory or on a platform account.
I am going to sell or exhibit
Hand over a stable version, technical requirements, installation instructions and preservation criteria. Make clear what may be modified and who may authorise a new version. If operation depends on a subscription or an API, allocate costs and responsibilities in advance.
An open conversation
The tools, models and terms of providers change quickly. If you preserve, produce or collect works made with AI and spot a dependency or procedure that should be added, you can write to me.