The EU’s cybersecurity agency and scientific research service are testing Chinese open-weight AI models that can be downloaded and run on local infrastructure.
The European Union Agency for Cybersecurity (ENISA) and the European Commission’s Joint Research Centre (JRC) confirmed the evaluations to Politico. The JRC’s study also includes American and European models, and it runs the systems on its own secure computing infrastructure, according to The Next Web.
For organizations considering similar deployments, the security question extends beyond which model performs best to what data and systems it can access.
What the EU is testing, and what remains unknown
Commission spokesperson Maciej Berestecki told Politico that the JRC runs these models on its own secure computing infrastructure and that the Commission does not intend to use them in its day-to-day work. However, neither the specific models under evaluation nor the test results have been disclosed.
A second Commission official told Politico that safety and security are not the main focus of the JRC’s study. The available reporting does not establish whether its findings will inform procurement or deployment decisions.
Open-weight AI shifts security controls to the deployer
Unlike hosted AI services, where the provider controls the infrastructure and can enforce safeguards at the service level, open-weight models can be downloaded, modified, and run on an organization's own systems. This means the original developer cannot centrally control how each copy is configured, what restrictions users remove, or which systems the model connects to.
Organizations running models on their own infrastructure take on responsibility for securing that deployment. They must secure the environment in which the model runs, restrict its access to sensitive data and external tools, and test whether its safeguards hold under real operating conditions.
The evaluations may improve understanding of the models’ capabilities and limitations. The available reporting does not identify them as an approval process for government or enterprise use.
Even so, how secure these models remain in practice also depends on how organizations configure, modify, and integrate them into their operations. Changes to the model, its permissions, or its connected tools can alter the deployed system’s risk profile.
What security teams should check before deployment
For organizations considering open-weight AI, local deployment offers control over where the model runs. That control does not automatically establish that the resulting system is secure. Teams still need to assess the model, its supporting software, and its access to business resources.
Start with the intended workload. Identify what information the system will process, whether it needs access to confidential records, and whether it can call external tools or execute commands. A system that summarizes documents requires a different assessment from an agent authorized to modify files or interact with production systems.
Test those permissions in an isolated environment before granting live access. Use representative, nonsensitive data to check whether malicious instructions in documents or tool responses can redirect the system, expose information, or trigger unauthorized code execution. Restrict access to what the workload requires and require human approval for consequential actions.
Treat changes as a reason to reassess the deployment. Fine-tuning, replacing a model, adding a connector, or expanding permissions can change how the system behaves. Teams should document the tested configuration, monitor its operation, and maintain a way to disable access if problems emerge.
The EU evaluations are relevant context, but their reported existence does not establish that any particular model is suitable for a business deployment. Until methods and findings are available, organizations cannot determine what security conclusions the tests support. The practical takeaway is to assess the complete system under its intended operating conditions before connecting it to sensitive data or business tools.
Read more: Learn how prompt injection in Azure DevOps can manipulate AI coding agents into accessing sensitive data through a developer’s existing permissions.





