BLUF: govern the deployable supplier tuple, not a brand name. A production AI system depends on a specific model or fine-tune, serving endpoint and region, retrieval component, policy configuration and change process. Put those dependencies behind an approved-model registry and an inference gateway that can deny an unapproved tuple, retain evidence, and force re-review when the supplier changes something material.
This is an engineering control, not a legal classification. Article 53 of the EU AI Act places documentation, information and copyright-policy obligations on providers of general-purpose AI models; Annex XI specifies information intended for downstream providers. Whether your organisation is a provider, deployer, importer or another actor depends on the factual arrangement. Have counsel assess that question where consequences matter; build traceability regardless.
Why a supplier register alone fails
A procurement record often captures supplier, contract and model family. It usually does not answer which endpoint served a request, which region received data, whether a hosted alias moved, which embedding model built the index, or whether a fine-tune and base model remain compatible. Those gaps turn an ordinary vendor release into an uninvestigable production change.
The Commission explains that GPAI provider obligations include giving information to downstream AI-system providers and maintaining a copyright policy; its GPAI guidance is interpretative rather than legally binding. Engineering teams should therefore use supplier documentation as evidence input, not as a substitute for their own workload evaluation, data-boundary decision or accountable release approval.
Reference architecture: the supplier control plane
The control plane has five separable services. First, an approved-model registry records a model-component tuple: supplier, immutable version or artefact digest, hosting type, permitted regions, data class, allowed capabilities, owner, expiry and rollback target. Second, an inference gateway resolves only approved registry entries and enforces endpoint and region policy before credentials are used. Third, a model and component bill of materials links base model, adapter, tokenizer, system prompt, tool schema, embedding model, retrieval-index snapshot and safety configuration. Fourth, an evidence vault stores supplier documents, evaluation runs, contracts or notices, approvals and observed gateway events. Fifth, a change detector compares supplier notices and runtime metadata with the approved tuple and opens re-review rather than silently accepting drift.
Diagram — control path: product request → policy lookup → approved-model registry → region/endpoint gate → inference gateway → hosted API or self-hosted runtime. Evidence path: supplier notice + model documentation + evaluation run + gateway trace → component bill of materials → evidence vault → owner review. A changed version, region, capability or component state routes to quarantine or an explicit re-approval gate.
The release-side pattern should connect to an immutable LLM release bundle: production traffic must carry a release ID that resolves to a frozen component set. For the procurement side, model choice as a change-control decision provides the companion evidence question: evaluate the workload and data path, not a vendor announcement.
Decision table: control by supply mode
| Supply mode | Minimum enforced control | Failure to expect | Accountable owner |
|---|---|---|---|
| Hosted API | Pin provider model revision, endpoint and permitted region; capture retention and subprocessor evidence | Alias moves or regional failover changes the effective service | Vendor manager + platform owner |
| Open-weight base model | Verify licence, source digest, model card, runtime image and patch owner | A mutable repository tag or unsafe runtime image enters production | Platform security + model owner |
| Fine-tune or adapter | Link base revision, adapter digest, training-data approval and evaluation segments | Adapter is compatible syntactically but regresses German or critical cases | ML owner + business owner |
| Retrieval component | Pin embedding model, index snapshot, corpus policy and access-control version | Model is unchanged but retrieval answers drift after a re-index | Knowledge owner + platform owner |
Data flow and evidence fields that matter
At request time, the application submits a workload class and requested capability, not a raw supplier endpoint. The gateway retrieves the approved tuple, validates data classification and region, injects the resolved release ID, and emits a trace with decision ID, registry version and policy result. Do not log prompts or personal data merely to make the trace useful; retain a minimised correlation record and hold sensitive evidence under a separate access policy.
For each tuple, retain: intended purpose; actor and technical owner; supplier and contract reference; model/base/adaptor digests; endpoint and region; data categories; capability and tool permissions; retrieval dependencies; evaluation suite and segment thresholds; evidence freshness date; change-notice channel; approval and expiry; and rollback or disable action. This maps naturally to the NIST AI RMF practice of making governance and measurement activities operational rather than treating risk as a one-time document.
Four failure modes to test before rollout
1. Silent hosted-model drift. A provider updates an alias or safety layer while latency and quality change. Mitigation: block floating aliases where a pin is available; poll runtime metadata; attach a change notice to an affected tuple; rerun the frozen evaluation segments before promotion.
2. Region-policy bypass. A developer uses a direct SDK endpoint to solve an outage. Mitigation: network egress allow-lists and workload identities that can call only the gateway; alert on unsigned direct calls; test a controlled fail-closed response.
3. Fine-tune lineage break. An adapter is deployed without the exact base revision, dataset approval or tokenizer record. Mitigation: require component digests in the bill of materials and reject deployment when any mandatory relationship is absent.
4. Retrieval drift disguised as model stability. A re-index, embedding change or permission filter changes answers while the chat model is unchanged. Mitigation: treat retrieval artifacts as supplier components, version the index, and run access-controlled retrieval evaluations. The operational basis is the existing guidance on proving retrieval decisions.
Legal question for counsel; engineering recommendation
Legal question for counsel: determine the organisation’s role and applicable obligations for the intended system, contract chain and sector. Article 53 and Annex XI concern GPAI-provider transparency/documentation, but they do not replace case-specific advice on the downstream system.
Engineering recommendation: make every production call resolvable to an approved supplier tuple and evidence record. This reduces change ambiguity whether or not a particular legal duty applies, but it does not itself establish compliance, lawful data processing, copyright compliance, functional suitability or supplier accountability.
A practical 30-day implementation sequence
Week 1: inventory the endpoints, weights, adapters, embeddings and retrieval indexes that actually receive production traffic; remove unknown direct paths. Week 2: introduce the tuple schema and gateway allow-list for one workload. Week 3: attach frozen evaluation segments, owner and expiry to that tuple. Week 4: simulate a vendor version and region change, prove that the change reaches the right owner, and rehearse disablement or rollback. Start with visibility; strict deny rules should follow after you know the dependency graph.
Sources
Regulation (EU) 2024/1689, Article 53 and Annex XI (EUR-Lex)
European Commission: GPAI Code of Practice
European Commission: Guidelines for providers of GPAI models
NIST AI Risk Management Framework
Make supplier evidence usable in production
I help B2B teams turn AI supplier inventories into enforceable gateway, release and evidence controls. A focused architecture review can identify the direct paths, missing owners and re-review triggers before the next model change becomes an incident.
