When assessing the security of AI, where a model comes from can only tell you so much. Arturs Jaunosans, COO and technical lead of Ajelix, explains why organisations should be paying much closer attention to where their data goes and who controls the infrastructure beneath it.

European organisations often begin an AI security assessment with a seemingly straightforward question: who developed the model, and where is that company based?

When a Chinese-developed model enters a procurement discussion, rejection can be almost instinctive. Given legitimate concerns about national security, intellectual property, supply chains and government access to technology, that caution is understandable. But it is not a complete security assessment.

A model’s origin matters. It may affect the obligations placed on its developer, the transparency of its development process and the supply-chain risks that need investigation. The mistake is treating origin as a proxy for what happens to organisational data when the model is used.

A team could reject one model on geopolitical grounds while approving another that sends sensitive prompts to externally operated infrastructure, with little visibility over logging, retention, administrative access or subcontractors. Neither deployment is automatically safe. They create different risks.

The open-weight debate is also about who controls the switch

The debate over open-weight AI has recently moved beyond theoretical warnings. In July, Nvidia, Microsoft, Meta, Palantir, Mistral and dozens of other technology companies backed an industry letter urging US policymakers to support open-weight AI and avoid sweeping restrictions as Chinese open models become more capable and affordable. OpenAI and Google joined after the letter’s initial publication, while Anthropic remained the most prominent major AI company not to sign.

The divide is partly philosophical, but also commercial. Infrastructure companies benefit from a broad model ecosystem because each model creates demand for chips, cloud capacity and enterprise software. AI companies with proprietary models, meanwhile, generate revenue by charging customers for access. Their safety concerns may be valid, but commercial incentives are also part of the context in which the debate is taking place.

Anthropic CEO Dario Amodei has argued that highly capable open-weight models are difficult to control because, once their weights are released, developers cannot withdraw access, impose updates or restore safeguards centrally. That is a legitimate concern when discussing malicious use. Yet the lack of a central off switch can also benefit organisations seeking continuity and greater control over their infrastructure.

Anthropic’s recent Fable 5 and Mythos 5 episode illustrated the other side of this debate. Following a US government directive restricting access by foreign nationals, Anthropic temporarily suspended the models for all customers because it could not immediately verify users’ nationality. Access to Fable 5 was later restored globally after the restrictions were lifted, while Mythos 5 access was restored to a set of US organisations. The incident showed how access to a centrally operated model can change abruptly because of regulatory decisions outside the customer’s control.

For organisations building critical processes around AI, that dependency matters. A proprietary service can be modified, restricted or withdrawn by its provider or the authorities governing it. By contrast, an open-weight model deployed on infrastructure controlled by the organisation cannot be remotely switched off by its original developer in the same way.

That does not make open-weight models inherently secure. The operator assumes responsibility for patching, monitoring, access controls, dependencies and incident response. But openness should not itself be treated as evidence of insecurity. Nor are proprietary cloud services inherently unsafe: they may provide encryption, monitoring and security capabilities that smaller organisations would struggle to reproduce.

The more useful question is therefore not simply whether a model is open or proprietary, but who controls its deployment, how the underlying infrastructure is operated and where the organisation’s data travels.

Openness is not a security verdict

Enterprise AI security is created by the whole operating environment, not by the model source in isolation. The same model can present radically different data-exposure risks depending on whether it runs on an organisation’s servers, dedicated hosted infrastructure, a managed private environment or a shared cloud service.

The practical review should begin with the path followed by the data. Where does inference happen? Do prompts, files, outputs, embeddings or telemetry leave the organisation’s environment? What is logged or retained? Who has privileged access? Where do backups and metadata go?

A network-isolated system still needs to be assessed for software dependencies, remote-management tools and update mechanisms. A cloud provider may promise not to retain customer data and may offer strong security controls, but buyers should ask how these protections work in practice and how they can be verified.

Legal jurisdiction matters, but it should be examined alongside architecture rather than used as a substitute for it. Under the US CLOUD Act, American authorities can compel a US-based provider to hand over data within its possession, custody or control regardless of where that data is physically stored. In practice, this means that running a workload in a European data centre operated by a US hyperscaler does not, by itself, place the data beyond the reach of US legal process.

Control has an infrastructure threshold

Private deployment is often presented as the obvious answer for sensitive AI workloads. In practice, it is not a realistic default for every organisation.

Running models privately may require accelerators, servers, storage, networking, redundancy and security equipment. It may also require high-density rack space, power, cooling, connectivity, observability, maintenance and specialist staff. Capacity must be provisioned before demand is fully known, and expensive hardware may remain idle during periods of low demand.

Based on benchmarking, vendor discussions and research into private AI infrastructure, deployments can require hundreds of thousands of euros in investment. For organisations still testing whether a use case will deliver a return, that cost can be hard to justify.

European calls for greater technological sovereignty must confront the same reality. The EU’s Apply AI Strategy aims to strengthen technological sovereignty by linking infrastructure, data and testing facilities, but expanding regional compute capacity still requires capital, hardware, energy and skilled operators. Sovereignty cannot be created through procurement language alone.

Not every task deserves the largest model

Organisations sometimes apply large general-purpose models to predictable, deterministic tasks. A fixed-format report, for example, may be produced more reliably with a conventional script or workflow. Using a large model adds cost, latency and compute consumption without necessarily improving the result.

The opposite error also occurs: an organisation selects a model that is too small for a complex task, receives poor outputs and repeats the process until the apparent savings disappear.

Before purchasing infrastructure or committing to a provider, teams should define the process, desired outcome, acceptable error rate, latency, data sensitivity and expected volume. Only then should they decide whether the task requires generative reasoning, retrieval, a smaller specialised model, conventional automation or a combination of tools.

This is not merely a software-design issue. Model choice affects accelerator demand, energy consumption, cloud expenditure and data centre capacity. It also affects whether an AI project succeeds at all. Buying technology before processes and outcomes have been defined can result in an expensive pilot that cannot be scaled.

A better procurement question

European organisations should not ignore where a model comes from. Model provenance, supplier governance and geopolitical exposure remain legitimate parts of due diligence.

But the model’s passport should not end the discussion. A locally deployed model is not automatically secure. A cloud service is not automatically unsafe. An open-weight model is not automatically transparent or well maintained, and a proprietary one is not automatically better governed.

A credible assessment should show where inference takes place, how data moves, who controls the infrastructure, what is retained, which responsibilities remain with the buyer and whether the organisation can operate the chosen architecture securely and economically.