How does model openness change the governance of marketing AI?

Artifact access, adaptation rights and the allocation of operational responsibility

This retrospective review considers source versions available by 13 February 2026. The cutoff defines the evidence included; preparation and source checking took place on 21 October 2026.

Keywords: open weights; model governance; transparency; adaptation; deployment

1. A release decision and a deployment decision

Descriptions of an AI model as open or closed combine several decisions that can be made separately. A developer may distribute weights while withholding training data. A company may run those weights on its own infrastructure or purchase access to someone else's hosted service. A model may be technically modifiable while its licence restricts some uses. A comparison that uses one label for all these properties cannot identify what the organisation gains or which responsibilities it assumes.

The research question is how model openness changes the governance of AI used in marketing. The relevant comparison concerns control over versions, adaptation, inspection, monitoring and operational access. It does not ask which current vendor wins a capability leaderboard. Nor does it treat openness as a moral or technical guarantee. The literature includes benefits that arise from inspection and modification, risks associated with wider distribution and substantial uncertainty about the marginal effects of releasing weights.

2. Review method

Targeted primary-source searches and retrieval were conducted on 21 October 2026 using open foundation models, model governance, transparency, model cards, fine-tuning safety and weight release. 18 references were selected to connect definitions and policy analysis with empirical work on adaptation, attacks and privacy. This is a focused narrative synthesis. No comprehensive database search, independent duplicate screening or formal meta-analysis was undertaken.

Research claims are restricted to the consulted author abstracts and publication records. The OSI definition was inspected directly. The NTIA report was located through its official report record and summary; no claim of complete report appraisal is made. NIST's publication record is used for architectural context. These materials differ in evidential function: a definition establishes a convention, a position paper develops an argument, a benchmark measures a specified system and a policy report evaluates a decision context. The synthesis preserves those differences.

3. What is actually open?

3.1 Weights and the preferred form for modification

The Open Source Initiative's AI definition specifies freedoms to use, study, modify and share an AI system, together with access to the preferred form for modification [1]. That formulation goes beyond whether a checkpoint can be downloaded. The definition is a normative specification of openness. It does not measure the safety, accuracy or commercial suitability of a model that meets it. A model can satisfy a release definition while remaining unsuitable for a particular task.

Weights are learned numerical parameters. Access to them enables forms of execution and adaptation that an inference-only interface may not expose. It does not make the model's behaviour immediately intelligible to a reader. Understanding how a particular answer arises still involves empirical and interpretability questions. Similarly, access to training code does not reconstruct a training run when the data, filtering, dependencies and configuration are missing. The components of reproducibility must therefore be named individually.

3.2 Openness is multidimensional

The Foundation Model Transparency Index specifies 100 indicators spanning upstream resources, the model and downstream use. Its original assessment covered ten major developers [4]. The breadth of the index demonstrates that transparency concerns more than checkpoint access. An organisation can disclose model architecture while giving little information about training-data composition or downstream impacts. Conversely, a hosted supplier can publish evaluation material without distributing weights. The index is an assessment framework, not a causal estimate that transparency improves task performance.

For marketing applications, these distinctions alter which questions can be answered internally. A reproducible checkpoint permits a team to hold the model version fixed during an evaluation. A sufficiently documented hosted version may also support controlled comparison, depending on the interface. Neither arrangement automatically provides information about every item of training data. Procurement language that treats transparent, open-source, open-weight and locally hosted as synonyms loses the properties on which the actual comparison depends.

4. Benefits and uncertainty in the release literature

Kapoor and colleagues define open foundation models through broadly available weights and examine their societal implications. Their position paper identifies properties such as customisability and limited monitoring, connecting them to benefits and risks. It argues that existing research is insufficient to characterise some marginal misuse risks relative to pre-existing technologies [2]. The conclusion is a statement about the available evidence, not a finding that every release is harmless or that every restriction is justified.

The NTIA's 2024 report considers dual-use foundation models with widely available weights and evaluates both benefits and risks [3]. Its official summary supports continued monitoring rather than an assumption that the question has been settled permanently. This historical policy assessment should not be represented as a current licence determination or as a forecast of every future model release. Model capabilities, deployment tools and available safeguards can change the comparison that a later assessment must make.

Marginal-risk reasoning asks what changes because weights are released, compared with a specified alternative. The alternative might be no access, API access, access to another open model or an already available non-AI technology. These comparators can yield different answers. An experiment demonstrating an undesirable capability establishes less about the release decision if the same capability is already cheaply available through another route. Conversely, easier modification or wider distribution may matter even when base-model behaviour appears similar.

The broad foundation-model literature also draws attention to inherited dependencies: downstream applications can share weaknesses of the underlying model [13]. That observation concerns a supply chain of capabilities and limitations. A marketing application built around one checkpoint does not cease to depend on upstream choices because the checkpoint runs locally. Local control changes who can intervene in the deployment, but it does not retrospectively alter the origin or quality of the training corpus.

5. Adaptation creates control and a new evaluation target

5.1 The ability to modify

LoRA freezes a pretrained model while introducing trainable low-rank adaptation matrices, substantially reducing the parameters that must be trained for downstream adaptation [10]. For governance, its relevance is that modification need not involve a complete retraining of the original model. A deployer can change behaviour through a relatively small additional artifact. This makes version identity more detailed than the name of the base model: the adapter, its training data and its configuration become part of the evaluated system.

The capability to adapt a model can support task-specific investigation. It also means that results for the base checkpoint may no longer describe the deployed version. A company that adds a writing-style adapter has created a new configuration even if the change appears modest. Accuracy, refusal behaviour and data exposure should be assessed for that configuration. The present literature review does not claim that adaptation necessarily worsens these outcomes; it establishes that they cannot be inferred solely from the original model's report.

5.2 Safety after fine-tuning

Qi and colleagues report that both adversarial fine-tuning and some benign fine-tuning procedures can reduce the safety alignment of the tested models [7]. Their experiments include an API-based model as well as an openly available model. The finding therefore concerns adaptation privileges, not a clean division in which only open models can change safety behaviour. The abstract establishes the possibility under tested conditions; it does not provide a universal rate of safety loss for arbitrary company datasets.

A governance comparison must ask which party can modify which layer. In an API arrangement, the provider may control the base weights while allowing customer fine-tuning. In a self-managed arrangement, the operator may control the checkpoint, adapter, runtime and tool layer. These differences affect accountability and the opportunity to test or reverse changes. They do not decide in advance which arrangement produces better safeguards. That is a question about the complete system and the resources devoted to operating it.

6. Openness does not map cleanly onto security

Zou and colleagues show that adversarial inputs can transfer across aligned models in the configurations studied [8]. Their attack research is relevant to governance because behavioural safeguards require evaluation against deliberate attempts to circumvent them. It does not establish that withholding weights prevents all such attempts. Access affects what an attacker can inspect or optimise, while black-box interaction can still expose a system to attacks. These are different attacker capabilities, not a single open-versus-closed security variable.

AgentDojo evaluates agents executing tools over untrusted content [11]. Its relevance lies in the application layer: model release terms do not determine which email folders, customer systems or publishing tools an agent can reach. An openly distributed model can run behind narrow permissions. A hosted model can be connected to an excessively broad credential. The permissions and external effects must be measured alongside model-level resistance if the claim concerns a marketing workflow rather than a standalone text generator.

NIST's Zero Trust Architecture provides established context for resource-specific authorisation [12]. Applying the concept does not require that the model be proprietary or open. It requires identifying the principal and resource at the access boundary. A locally hosted model inside a corporate network can still be used by an application that exposes information to the wrong user. The network location of inference and the correctness of authorisation are separate properties of the deployment.

7. Privacy and the distribution of visibility

Nasr and colleagues report extraction from several classes of language model, including models accessed through production interfaces [9]. The existence of leakage across those categories makes a simple privacy ranking by release label untenable. The study concerns extractable training information under specialised attacks. It does not compare all dimensions of customer-data handling, and it does not show that every inference request is incorporated into shared weights.

Local execution may keep a prompt away from an external inference endpoint, provided the complete data path remains local. It can also place more responsibility on the operator for access, logging, retention and incident response. A hosted system shifts some operational visibility to the provider and can supply different administrative controls. Neither configuration eliminates the need to examine what happens before and after inference. Retrieval, analytics and collaboration tools may transmit information independently of the model endpoint.

Monitoring is similarly distributed. A developer releasing weights may have limited visibility into later deployments. An API provider may observe service interactions but not the customer's full business context. A local operator may observe its own use but lack upstream training information. These are different information gaps. Governance that depends on a party detecting an event must specify whether that party can actually observe the event and whether the relevant signals survive the system's privacy and retention settings.

8. Documentation and reproducibility

Model Cards proposes structured documentation of intended use and performance under relevant conditions [5]. Datasheets for Datasets proposes documentation of dataset motivation, composition, collection and recommended uses [6]. Both are documentation frameworks. Their presence improves the information available for scrutiny but does not establish that the documented system is accurate or safe. The content, specificity and evidential basis of the documentation remain objects of assessment.

A model card for a general-language benchmark is not a validation study for consumer-insight analysis. The downstream task may involve different languages, sensitive information or unusual product categories. The point of documenting intended use is to expose that mismatch. A deployment record can then connect the model version to the actual evaluation set and the changes made for the application. This makes a later result interpretable without requiring an unsupported claim that the original benchmark transfers intact.

Reproducibility also has levels. Having the same weights and prompt can support an attempt to repeat inference. Reproducing training requires far more information and resources. Reproducing a business outcome adds the workflow, people, data and external environment. A claim that an open checkpoint makes results reproducible should identify which level is intended. A locked model artifact cannot by itself reproduce a campaign exposed to a different audience or a different media allocation.

Documentation can become stale even while the model file remains unchanged. An application may change its retrieval corpus, prompt template, access rights or post-processing rules. Those changes alter the system being assessed. Version control at the model layer is therefore necessary for some comparisons but insufficient for end-to-end reproducibility. A useful research record names the complete configuration that produced the reported result rather than relying on a family name that spans many variants.

9. Interpreting the trade-offs for marketing

A marketing team comparing deployment options needs a task-specific unit of analysis. Classifying a large volume of short, non-sensitive product descriptions differs from synthesising confidential customer interviews or generating public claims. The ability to inspect and adapt weights may be valuable in one case and operationally unnecessary in another. This review provides no empirical basis for assuming that a single release model is optimal across those tasks.

Control has practical requirements. The right to modify a model does not supply the skills, hardware or evaluation data needed to exercise that right well. The ability to hold a version fixed is useful only when the version and its dependencies are actually retained and testable. Conversely, outsourcing inference does not outsource the marketing organisation's choice of input data or interpretation of the result. Those remain part of the application even when the underlying model is operated by a third party.

The literature supports a more precise comparison than a broad trust judgement. It is possible to compare access to artifacts, permitted modifications, monitoring responsibilities and evidence for the actual task. It is also possible to identify unresolved questions rather than assign them an arbitrary score. Combining these dimensions into a single model ranking would require explicit weights and a decision objective. The reviewed sources do not supply those weights for marketing organisations.

9.1 Reversibility and retained evidence

Holding a checkpoint fixed can support a rollback, but a rollback is a system operation rather than a property of the licence. It requires the old artifact, compatible runtime and relevant application configuration. If the retrieval corpus or tool permissions have changed, restoring the weights alone does not recreate the earlier behaviour. A hosted version can likewise offer a rollback mechanism only within the controls and versions the service actually exposes. The comparison concerns demonstrated recovery of a tested configuration, not a general promise attached to the word open.

Retained evaluation results are valuable because they identify which questions were answered before a change. They also expose unanswered questions. A test set designed for one language, audience or output format cannot establish performance in another without additional evidence. Openness may make investigation easier, while the validity of the resulting inference still depends on the task and design. This separates the availability of a research opportunity from the outcome of the research itself.

Membership-inference research concerns determining whether a record was used in training, a different privacy claim from reconstructing its contents. [14] Differentially private learning makes a formal privacy mechanism part of training; access to weights alone does not establish such a guarantee. [15] HELM evaluates multiple dimensions of model behaviour rather than interpreting openness as a performance measure. [16]

CheckList adds targeted behavioural tests to aggregate model evaluation. [17] Technical-debt research locates operational obligations in the surrounding system. Governance of an open-weight deployment therefore also depends on its data, interfaces, permissions and maintenance arrangements. [18]

10. Limitations and conclusion

This synthesis combines empirical security reports, documentation proposals, definitions and policy analysis. Their coexistence should not be mistaken for a homogeneous evidence base. Most research sources were accessed at abstract level, and the review does not audit licences, replicate attacks or assess a specific deployment. The historical transparency and policy findings are dated observations. They cannot establish the current conduct of every model developer or predict the marginal risks of a future release.

Open weights change what recipients can execute, inspect and modify. Hosted services change where inference and some operational controls reside. Neither choice determines security, privacy or suitability on its own. The research supports evaluating the released artifact, adaptation privileges, application permissions and available documentation separately. A defensible governance account identifies who controls each layer, what evidence is available and which claims remain untested for the intended marketing task.

Source access and appraisal register

The additional comparative sources in references 14–18 are used for the specific distinctions cited in the discussion. Access is limited to previously inspected primary-source abstracts, publication records or manuscripts. Their inclusion does not imply a fresh full-text risk-of-bias appraisal or direct validation in the application discussed here.

The OSI definition [1] was consulted directly. Research sources [2,4,5,6,7,8,9,10,11,13] were consulted through author abstracts and publication records; no full empirical replication or detailed supplementary appraisal was undertaken. The NTIA report [3] was located through its official report and summary; claims are limited to its broad scope and monitoring stance. Source [12] was consulted at official publication-record level. Licence interpretation and current supplier compliance were not assessed.

References