A supervisory authority asks about one system. On a shared platform the answer comes from the same five or six pieces of code every time: the training job that produced the artefact, the registry entry that describes it, the gateway that logged the request.
That asymmetry cuts both ways. Emit the right records once and thirty teams are evidenced together; emit nothing and thirty teams fail the same audit on the same Tuesday. The duties are written about systems. They are discharged by the platform.
An obligation is satisfiable only where something in the pipeline produces the artefact that would demonstrate it. These three are the emissions most often missing, and each has a single right place to live.
Article 12 asks for automatic recording over a system's lifetime. One schema covering request identifier, artefact version, tenant, timestamp, routing decision and outcome, with a retention window chosen deliberately rather than inherited from a bucket rule. Put it in the gateway and no team can opt out, and no team has to implement it twice.
Article 11 technical documentation is assembled from lineage most registries never hold. Make the training job write the entry and fail the run when the dataset snapshot, code commit, image digest, evaluation artefact or named approver is absent. Documentation then falls out of training for every team on the platform at once, rather than being written from memory two years later.
A modification can reopen the conformity question, and on a platform the change often comes from no release at all. A provider moves a checkpoint beneath a hosted endpoint, a base model is superseded, a runtime quantises differently after an upgrade. Pin the upstream version, record the pin in the registry, and treat a movement as a change event that reaches every tenant it touches.
Request identifier, artefact version, tenant, timestamp, routing decision and outcome, with a retention period chosen deliberately and applied to every served model rather than left to whatever each bucket does.
Dataset snapshot, code commit, image digest, hyperparameters, evaluation artefact and approver, with the publish step failing when a field is missing. Hand-written entries decay and cannot be audited.
Canary splits, shadow traffic and automatic fallback mean the registry entry is not the answer to what served. Write the artefact that actually ran, and the reason it was chosen, at request time.
A provider-side change reaches every tenant at once. The pin, the recorded version and a change event that notifies each affected system are what stand between you and a silent modification.
No. A provider hosts weights and runs infrastructure. It does not write your registry entries, choose your retention window or record which artefact answered a given request. Those emissions are yours, and on a shared platform they are the platform team's rather than each product team's.
No, and nobody should sell you one. The duties are written about systems and their providers and deployers. What this paper argues is operational rather than legal: on a platform serving thirty teams, the code that satisfies those system-level duties is the same code every time, so it belongs in one place.
Measure 2 December 2027 against how long it takes to change a logging schema across thirty teams and retrain everything that depends on it. Article 50 transparency applied on 2 August 2026 and binds now, and Annex I obligations follow on 2 August 2028. The logging and registry work is the long pole.
Article 99 sets the ceiling for most operator obligations at the higher of EUR 15M or 3% of worldwide annual turnover, with SMEs, start-ups and small mid-caps paying the lower of the two.
The more likely cost is simpler: one missing emission puts every system on the platform in the same position at once.
That catalogue scores one system. This paper maps the legal duties onto the shared pipeline underneath thirty of them. MLOps and Model Serving: An Engineering Reference numbers the twenty-eight platform controls across seven families and names the artefact that proves each one.
Use this one to decide what must exist, and that one to decide who builds it.
VPs of platform engineering and heads of risk who own the shared path every model takes to production. It assumes you already run a platform, since 90% of organisations do, and that your question is no longer whether to have one but what it has to emit.
Drop your details and we'll send MLOps and Model Serving Under Regulation straight to your inbox - no spam, unsubscribe anytime.
Bring your serving path and your model registry to a working session with our platform engineers. We will find out whether either can name the artefact that answered a request last March. SECTION 7 - FAQ - 5 to 8 questions
Book a platform review