A server in the EU does not automatically make an AI system compliant. Compliance is a property of the entire product: what data enters the system, what model and licence are used, how outputs are controlled and how every deployable artefact can be traced.
Architecture before paperwork
The most effective compliance work starts with architecture. Separate the model runtime from application data, define access boundaries, minimise stored prompts and establish a clear owner for each component. These choices reduce later documentation work because the system itself is easier to explain.
A model family has more than one licence
Weights, source code, tokenisers, datasets, evaluation sets and derivative artefacts can each have different terms. Record the exact version, upstream source, licence, checksum and intended use for every artefact. A model name alone is not sufficient provenance.
Turn a checkpoint into a product
Treat the deployment as a chain of signed or hashed artefacts:
- verify the source checkpoint and licence;
- record conversion and quantisation parameters;
- build a reproducible runtime image or binary;
- test the deployment against a defined evaluation set;
- ship the approved artefact with its configuration and release record.
This makes a production result reproducible rather than merely repeatable by memory.
More than data residency
EU deployment also requires purpose limitation, access control, retention rules, incident handling and clear information for users. Email, logs, monitoring and third-party APIs belong to the same review as the model endpoint.
Before go-live
Answer four questions: Which data is processed? Which artefacts and licences are in use? Which controls prevent misuse or unintended disclosure? Can the organisation reproduce the exact deployed system? When those answers are documented, compliance supports delivery rather than slowing it down.