Documentation must cross the model boundary

A model provider can publish careful documentation and still leave the deployed system opaque. The document may describe training, evaluation, limitations, and intended uses. An application builder then adds retrieval, prompts, tools, memory, routing, and fallback behavior. A deployer inserts the application into a workflow with local thresholds and human review. By the time a decision reaches a person, the model document is necessary and insufficient.

The European Commission’s General-Purpose AI Code of Practice includes a model documentation form intended to help general-purpose model providers supply information required under the AI Act. The deeper institutional question is how that information remains attached to responsibility as the model moves through a value chain.

Documentation often fails at the boundary because each party describes a different object. The provider describes a model. The integrator describes a service. The deployer describes a workflow. The affected person experiences a decision. Assurance requires links among all four, with no party allowed to treat the others’ documentation as a substitute for its own.

The system inherits limits, not conclusions

A model’s evaluation can establish behavior under specified conditions. It cannot establish that every downstream system is fit for use. Tool access may turn a harmless text error into an executed action. Retrieval may introduce private or adversarial data. A local prompt may suppress warnings. A fallback may replace the documented model. The integrator must test the assembled system.

The deployer inherits another task. It must assess the intended purpose, affected population, human oversight, operating environment, and available remedy. A system suitable for drafting may be unsuitable for ranking. A model capable of multilingual conversation may not be reliable for a specific administrative distinction. Provider evidence should constrain the local claim, not inflate it.

Documentation travels well only when every recipient adds the facts created at its own layer.

That additive record should preserve provenance. Which provider document applies to which model version? Which system version incorporated it? Which local evaluation relied on it? Which risk treatment addressed a stated limitation? A PDF stored in a vendor folder is not connected assurance. The chain needs stable references that survive updates and audits.

Material changes should generate new links rather than overwrite old ones. If a provider changes a model behind a stable endpoint, downstream parties need notice, an effective date, and enough information to determine whether evaluations or impact assessments must reopen. If an integrator changes tools or prompts, the deployer needs the same. Silent improvement is still silent change.

Information rights must be usable

The Commission’s GPAI provider guidance distinguishes obligations and roles, including circumstances in which significant modification can make another actor a provider. That boundary cannot be governed by labels alone. Organizations need technical and contractual information sufficient to determine what changed and whether their role changed with it.

Confidentiality complicates the exchange but does not eliminate it. Providers may need to protect trade secrets, security-sensitive details, personal data, and licensed content. Downstream users may not need raw training data or proprietary weights. They do need decision-useful information: capabilities, tested conditions, known limitations, material changes, applicable controls, and incident contacts.

Tiered disclosure can serve different audiences. Public summaries support transparency. Customer documentation supports integration and risk management. Regulators and qualified auditors may receive protected detail. The important design is consistency among tiers, with a way to verify that the public layer is not contradicted by the protected one.

Machine-readable fields should accompany narrative. Version identifiers, dates, evaluation references, intended-use categories, prohibited uses, change notices, and contact routes can move through inventories and deployment pipelines. Narrative remains necessary for meaning, but structured data lets institutions detect that a deployed component has become stale or unsupported.

The last mile owns the decision

Supply-chain accountability can become a ritual of pointing upstream. The deployer blames the integrator, the integrator blames the model, and the model provider notes that the use was outside scope. Each statement may contain truth. None provides remedy to the person who encountered the decision. Responsibility must be allocated before harm, not negotiated afterward.

The European Commission’s broader AI Act implementation materials describe obligations for actors across the chain and continued provider responsibility through post-market monitoring. That structure should inspire an operational map: who monitors which layer, who receives incidents, who can correct or stop the system, and who communicates with affected people.

Contracts should require evidence exchange, but architecture must make it possible. A deployer cannot report the operative model version if the service exposes no identifier. A provider cannot investigate a pattern if local incidents carry no correlation data. A customer cannot retest after change if updates arrive without notice. Technical interfaces are part of the accountability bargain.

Inventories are the receiving side of that bargain. They should connect provider, model, system, deployment, purpose, owner, evidence, and affected workflow. Without those relations, a change notice reaches an organization that cannot identify what to retest. Documentation has arrived, yet the institution remains unable to act on it.

The document that crosses the model boundary should not promise certainty. It should carry bounded claims, unresolved risks, change history, and the conditions under which earlier evidence remains valid. Each downstream party should add its configuration, tests, purpose, controls, and observed incidents. The result is not one universal model card, but a connected account of the deployed system.

Models move quickly through markets. Responsibility must be able to travel at the same speed. Documentation earns its value when it reaches the people who build, deploy, oversee, and experience the system—and when each of them can tell which facts came from upstream, which were created locally, and which remain unknown.

— Dispatches · Summit Cognitive