A significant modification can change the provider

Model supply chains encourage inherited assurance. A downstream organization receives documentation, evaluations, limitations, and usage conditions from an upstream provider, then fine-tunes, merges, distills, quantizes, retrains, or wraps the model for a new purpose. At some point the inherited record may no longer describe the artifact being placed on the market.

The Commission's GPAI guidelines say that actors making significant modifications may need to comply as providers while minor changes do not automatically produce the same result. The official Q&A emphasizes case-specific assessment. An operating program therefore needs a modification record and an explicit role decision.

Commercial labels are not enough. Calling work customization, adaptation, optimization, or hosting does not settle its effect. Record the starting model, methods, compute, changed capabilities, altered limitations, new distribution, and intended uses. The role assessment can then rely on technical facts instead of a product team's preferred vocabulary.

Put a role gate in the model pipeline

Before release, compare the derivative against the upstream evidence. Which evaluations remain relevant? Which documentation is now incomplete? Did the modification introduce new modalities, capabilities, languages, risk pathways, or integration assumptions? Did the actor change the model itself or only the surrounding system? Preserve the answers and the current interpretation source.

The gate should produce more than provider or not provider. It can identify obligations clearly inherited, obligations newly owned, evidence requiring refresh, questions for counsel or the AI Office, and interim limits while the assessment remains open. A binary field encourages teams to force uncertainty into the less burdensome category.

Inherited documentation stops at the point where the inherited artifact stops describing what you released.

Cumulative modifications matter. Ten changes that appear minor in isolation can produce a derivative whose behavior and market role differ substantially from the base. Maintain a lineage graph with ordered modifications and review the accumulated state at release, not only the latest patch.

Upstream change notices can reopen the downstream assessment too. A provider may update limitations, licensing, training-content information, or systemic-risk status without changing the endpoint name. Pin upstream evidence to the derivative release and define which notices require reevaluation or a new customer disclosure.

Contracts should support role transitions. Obtain usable upstream documentation, notice of material changes, lineage identifiers, and cooperation for questions. Define what the downstream actor must contribute after modification. The goal is not to transfer every obligation by contract; it is to ensure the technical and documentary handoff supports whichever role the facts create.

Make the obligation operational

Begin with the base model, cumulative modifications, changed capabilities and limitations, distribution decision, upstream evidence, and role interpretation for each derivative release. Express it as a control object rather than a policy summary: scope, triggering condition, applicable system or model version, permitted exception, effective time, evidence source, and the consequence when the control cannot establish compliance. This lets engineering, product, legal, and operations examine the same boundary without pretending their responsibilities are interchangeable.

The minimum receipt should retain lineage identifiers, methods and compute, capability and risk deltas, inherited-document review, role decision, open questions, interim limits, and effective date. Keep the record proportionate and protect confidential information, but make it possible to determine which rule, artifact, system version, and accountable decision governed the event. A folder of undated screenshots may show that work occurred; it rarely proves that the operative control held for the affected release.

Test the implementation by evaluating isolated and cumulative fine-tuning, merging, distillation, quantization, modality extension, and system-only changes against the role gate. Include ordinary cases, boundary cases, degraded dependencies, and known exceptions. Preserve the starting state, observed output, machine-readable evidence, user-visible result, and any human intervention. Re-run the test after changing a model, content pipeline, interface, standard, provider, or policy interpretation.

The derivative-model release owner with legal and assurance owners should decide whether the evidence supports continued operation, a narrower scope, a compensating control, or a hold. The owner needs authority over the affected release and access to the evidence. Record unresolved interpretation separately from a technical defect so an engineering patch does not masquerade as a legal conclusion.

Monitor both presence and effectiveness. A marker can exist but be stripped downstream. A disclosure can render but arrive after exposure. A document can be submitted but refer to an obsolete model. Pair a control-presence measure with a consequence or comprehension test, give the claim a review date, and reopen it when a dependency changes.

Maintain a dependency register for the control. Model endpoints, editing pipelines, content formats, user interfaces, identity services, submission portals, vendors, and external standards can change the evidence without changing the policy text. Name which changes invalidate the last test and which monitoring signal proves that the dependency remains inside the reviewed state.

Exercise the exception path as carefully as the ordinary path. Record who can invoke it, which facts they must supply, how long it lasts, what capability or distribution is reduced, and which compensating evidence remains. An exception without expiry and re-entry criteria becomes a second operating model that can silently outlive the reason it was approved.

Keep public and executive claims no broader than the tested boundary. Say which systems, releases, formats, routes, and dates the evidence covers, and identify material exclusions. When a control fails or a dependency moves, update the claim and the remediation record together. A transparent limitation protects more credibility than a universal statement built from a narrow passing test.

— Dispatches · Summit Cognitive