The open-model exemption is not an assurance claim

An open model can be inspectable, modifiable, and widely shared while remaining entirely unevaluated for the decision an institution wants it to support. Openness changes who can study and improve the artifact. It does not answer whether the assembled system is reliable in this language, safe with these tools, appropriate for this population, or governed by an organization capable of correcting harm.

That distinction matters as regulatory frameworks recognize open development. The European Commission’s guidance for general-purpose AI providers explains that qualifying free and open-source models may be exempt from specified duties, including some technical documentation and representative requirements, when stated conditions are met. The guidance also identifies limits: systemic-risk models do not receive the same exemption, and copyright-policy and training-content-summary duties remain.

An exemption allocates legal obligations. It does not certify a technical property. Yet the language of exemption can drift in organizational conversation. ‘Open source’ becomes ‘transparent,’ transparent becomes ‘auditable,’ auditable becomes ‘safe,’ and safe becomes ‘approved.’ Each step adds a conclusion that the licensing condition did not establish.

Freedom is not fitness

The Open Source AI Definition centers freedoms to use, study, modify, and share a system, supported by access to the preferred form for modification. Those freedoms are substantial. They allow independent inquiry, adaptation, competition, and collaborative repair. They describe what recipients are permitted and equipped to do with an artifact. They do not promise what the artifact will do in a particular deployment.

Weights can be available while training data remains only partially characterized. Code can be inspectable while the deployed service adds undisclosed prompts, retrieval, routing, moderation, or tools. A community can reproduce a base model while an institution cannot reproduce the exact decision path of its application. Openness increases possible scrutiny; assurance still requires someone to perform the scrutiny and connect it to the operative system.

Open access creates the possibility of assurance. It does not perform the assurance work.

This is not a criticism of open development. Closed systems face the same gap, often with fewer opportunities for independent inspection. The point is to preserve the category boundary. Licensing terms govern freedoms and conditions of use. Assurance claims require evidence about performance, security, impact, oversight, and change under stated conditions. One can support the other without substituting for it.

The distinction also protects honest comparison. A proprietary provider may offer extensive evaluation evidence while withholding implementation details. An open provider may expose the artifact while offering little deployment evidence. A buyer should evaluate both the evidence available and the freedoms needed, rather than reducing a multidimensional choice to a contest between ‘open’ and ‘safe.’

The deployment creates new obligations

The AI Act’s text treats open-source status as conditional rather than universal relief. The regulation’s recitals distinguish transparency-related exceptions for qualifying general-purpose models from systemic-risk duties and preserve rules for open systems used in high-risk or otherwise regulated contexts. The legal details depend on role and use; the durable operational lesson is that a license does not erase the deployment.

A downstream builder chooses prompts, context, tools, memory, thresholds, and fallbacks. A deployer chooses purpose, population, workflow, human oversight, and remedy. These choices create risks that cannot be evaluated at the base-model repository. The party making them must add evidence at its own layer rather than pointing upstream to the availability of weights.

Modification sharpens responsibility. Fine-tuning may change behavior. Quantization may alter reliability. Added tools may convert a text error into an external action. A new intended purpose may move the system into a different risk class. The organization needs change control that asks what new role it has assumed and which earlier evidence no longer travels with the modification.

The same is true of community derivatives. A familiar model name may sit above different weights, templates, safety settings, and dependencies. Provenance must identify the exact artifact and configuration. ‘Based on an open model’ is not a version. Reviewers need to know which lineage produced the system they are assessing.

Open ecosystems can make this work stronger. Public test suites, signed releases, reproducible builds, documented derivatives, shared incident reports, and competing evaluations can distribute assurance across many observers. But those practices need governance, maintenance, and evidence quality. A crowded repository is not automatically a reliable assurance institution.

Exemptions need an evidence map

An organization using an exemption should record precisely which obligation does not apply, which conditions support that conclusion, who made the determination, and when it must be revisited. It should separately list the duties and risks that remain. This prevents a narrow regulatory conclusion from becoming a blanket internal status called ‘exempt.’

The Commission’s broader AI Act implementation guidance continues to assign monitoring, human oversight, incident response, and information duties according to the system’s role and use. Institutions should map those responsibilities across provider, modifier, integrator, and deployer. The open artifact may cross all four roles; accountability should not disappear between them.

Procurement should ask two separate sets of questions. What freedoms and materials does the license provide? What evidence supports safe and effective use in the intended context? The first reveals dependence and inspectability. The second reveals fitness and governability. Combining them into one score hides weaknesses that only become visible after deployment.

Public communication should preserve the same honesty. An organization may state that a model is released under qualifying open terms or that its components can be inspected. It should not imply that openness alone establishes compliance, safety, fairness, or suitability. Those claims require their own scope, method, date, and evidence.

Open models can support a healthier assurance market because more parties can test, challenge, and improve them. The regulatory recognition of open-source conditions can support that ecosystem. The institution’s task is to use the freedom without borrowing certainty from it. An exemption tells you which legal route applies. Assurance still has to tell you whether the deployed system deserves the authority you plan to give it.

— Dispatches · Summit Cognitive