DeepSeek and High-Risk AI Vendor Assessment Guide

Staff and developers adopted DeepSeek faster than most organisations could assess it, and the same pattern will repeat with the next low-cost AI model from a supplier in a high-risk jurisdiction. Since January 2025 DeepSeek has been the subject of a public database exposure, data protection orders in Italy and South Korea, government device bans in Australia and Czechia, and a US government evaluation of its models' security behaviour. This guide uses DeepSeek as a worked example to build a repeatable assessment for any AI supplier whose data handling, jurisdiction or model behaviour is uncertain. It separates the hosted service from the open-weight models, because the risks and the right decisions are different. It is written for security architects, third-party risk teams, AI governance leads and the engineers who are asked to "just block it" or "just approve it".

Key takeaways

Assess the deployment, not the brand. The DeepSeek consumer app and API send prompts to servers in the People's Republic of China; the open-weight R1 models run locally under an MIT licence. They need different decisions.
Government actions are evidence, not policy for you. Australia's PSPF Direction 001-2025 and Czechia's NÚKIB warning are useful inputs, but each has a specific scope and exclusions that private organisations should read before copying.
Model behaviour is a security property. NIST's CAISI found DeepSeek R1-0528 agents were 12 times more likely than US frontier models to follow hijacking instructions, which matters most where a model can call tools or hold credentials.
Basic hygiene failures are a leading indicator. An unauthenticated ClickHouse database exposing chat logs and API secrets says more about a supplier's control environment than any questionnaire answer.
Decide, enforce and monitor in one cycle. A policy without network, endpoint and API-key controls is ignored; controls without an approved alternative push users to personal devices.

What makes an AI vendor high risk

Most AI supplier reviews reuse the SaaS questionnaire. That misses the factors that drove every public action against DeepSeek. Treat a supplier as high risk when two or more of the following apply, and run the full assessment in this guide rather than the standard one.

Risk factor	What to look for	DeepSeek example (sourced)
Jurisdiction and state access	Where data is stored and which laws can compel disclosure to authorities	The privacy policy (last updated 10 February 2026) states personal data is collected, processed and stored in the PRC; NÚKIB cites the PRC legal and political environment as a reason for its warning
Undisclosed onward transfers	Sub-processors and affiliates receiving prompts or telemetry	South Korea's PIPC found transfers of Korean users' data to companies in China and the US without consent, including prompts sent to a ByteDance-affiliated company, as reported by The Korea Times
Refusal to accept local law	Supplier position on GDPR, UK GDPR or sector rules	The Italian Garante reported that the companies said they did not operate in Italy and European law did not apply, which it found entirely unsatisfactory
Weak operational security	Exposed services, secrets in logs, missing authentication	Wiz found an unauthenticated ClickHouse database on ports 8123 and 9000 with over a million log lines including chat history and API secrets
Unsafe model behaviour	Jailbreak resistance, agent hijacking, biased or manipulated output	CAISI measured a 94% response rate to overtly malicious requests under a common jailbreak for R1-0528, against 8% for US reference models
Rapid uncontrolled adoption	Shadow use ahead of any review	CAISI reports downloads of DeepSeek models on model-sharing platforms rose nearly 1,000% from January 2025

None of these factors is unique to one company or one country. The same table applies to a start-up hosting models in a jurisdiction with weak privacy law, or to a supplier with a poor breach history anywhere. See the Third-Party AI Risk Guide for the baseline AI supplier review this guide extends.

Government bans, warnings and orders: what they actually say

Many internal policies cite "government bans" loosely. Read the primary text, because scope, exclusions and status differ. The table below records what each primary source stated when checked on 24 October 2026; check the source again before relying on it, because directions can be amended or withdrawn.

Authority	Instrument and date	Scope	Notable detail
Italy, Garante per la protezione dei dati personali	Urgent limitation order, 30 January 2025	Processing of Italian users' data by Hangzhou DeepSeek and Beijing DeepSeek	Immediate effect, investigation opened
Australia, Department of Home Affairs	PSPF Direction 001-2025, 4 February 2025	All Australian Government systems and devices	Prevent access, use or installation of DeepSeek products, applications and web services and remove existing instances; still listed among PSPF directions
South Korea, PIPC	New downloads suspended 15 February 2025, resumed 28 April 2025	Domestic app distribution	Resumed after a Korean-language revised policy; corrective recommendations included destroying transferred prompts (news report)
Germany, Berlin Data Protection Commissioner	Digital Services Act notice to Apple and Google, 27 June 2025	DeepSeek apps in German app stores	Reported as unlawful content over transfers of personal data to China; app stores asked to decide on blocking
Czechia, NÚKIB and Government	Warning under the Act on Cyber Security, 10 July 2025; government resolution 9 July 2025	Obligated entities' risk analyses; ban on state-owned devices of central authorities within 30 days	Threat rated High; excludes security testing and locally run open-source DeepSeek LLMs that cannot communicate with DeepSeek servers
United States, NIST CAISI	Evaluation of DeepSeek models, 30 September 2025 (updated 20 November 2025)	Technical evaluation, not a ban	Compared R1, R1-0528 and V3.1 with US reference models on performance, cost, security and narrative bias

Read the exclusions: the Czech text explicitly carves out security research and locally hosted open-source models. A private policy that bans "anything DeepSeek" is broader than the government instrument it cites, which may be the right choice, but should be a conscious one.
Separate privacy and security findings: the Italian, Korean and Berlin actions are data protection findings about transfers and transparency. The Australian and Czech actions are security risk decisions. CAISI is a technical evaluation. Each feeds a different part of your assessment.
Record your source and date: store the URL and check date in the risk register entry so the decision can be revisited when an instrument changes.

Hosted service, API or open weights: three different risk profiles

The most common assessment error is treating DeepSeek as a single thing. The same model family can reach your organisation in at least four ways.

Deployment path	Where prompts go	Main risks	Typical decision
Consumer web or mobile app	Supplier servers (PRC per privacy policy)	Data transfer, no enterprise contract, device telemetry, no admin controls	Block on managed devices and networks
Supplier API from your code	Supplier servers	Same as above plus API keys in code and CI, data sent at volume	Block unless a documented exception with no personal or confidential data
Model hosted by a third-party cloud or inference provider	That provider's region and contract	Model behaviour risks remain; data risk depends on the host's terms and region	Assess the host as the supplier, then assess the model separately
Open weights run on your infrastructure	Nowhere outside your boundary if egress is blocked	Unsafe behaviour, embedded bias, model file supply chain, licence inheritance	Allow for defined use cases after model evaluation and supply chain checks

Licence inheritance: the DeepSeek-R1 repository states that code and weights are under the MIT licence, but the distilled models are derived from Qwen 2.5 (Apache 2.0) and Llama 3.1 and 3.3 (Llama licences). Legal review must cover the base model's licence, not only DeepSeek's. OWASP LLM03:2025 Supply Chain lists licensing risk explicitly.
Model files are code-adjacent: pull weights only from the publisher's verified organisation on the model hub, prefer the safetensors format over pickle-based files, and refuse repositories that require remote code execution at load time unless the code has been reviewed. See the Open-Weight Model Security Guide.
Egress is the control that makes "local" true: the Czech exclusion depends on the model having no ability to communicate with DeepSeek servers. Run self-hosted models in a segment with default-deny egress (NIST SP 800-53 SC-7) and log any outbound attempt.

Running the assessment

Use the following sequence for any supplier that meets the high-risk threshold. It fits inside an existing third-party risk process (CSF 2.0 GV.SC-06 due diligence before the relationship, GV.SC-07 monitoring during it) and should take days, not months, because shadow use starts immediately.

Triage within 48 hours: confirm whether the service is already in use from proxy, DNS, CASB and expense data, and apply a temporary block or warn page on managed devices while the review runs. Record the business owners who asked for it.
Collect primary evidence: privacy policy and terms (note the "last updated" date), data location, controller entity, sub-processors, security attestations (ISO/IEC 27001 certificate, SOC 2 report), and any regulator or government action from the primary source.
Test the model: for any deployment path where the model will be used, run your own jailbreak, prompt-injection and agent-hijacking test set (MITRE ATLAS AML.T0051 LLM Prompt Injection and AML.T0054 LLM Jailbreak) and compare against the model you already approve. CAISI's published method is a useful structure. See the AI Red Teaming Guide.
Classify the data in scope: decide which data classes may never reach the supplier. For personal data, run or update a DPIA and check the transfer mechanism for the destination country. See the DPIA Guide.
Decide per deployment path: approve, approve with conditions, or prohibit, using the decision table below. Write the decision as one paragraph a user can understand.
Enforce: implement the network, endpoint, identity and code controls in the next section. Test the block from a managed laptop, a managed phone and a CI runner.
Monitor and revisit: set a review date (90 days for a prohibited supplier with strong demand, 12 months otherwise) and a trigger list: new regulator action, new model release, change of privacy policy, breach report.
Roll back cleanly: if a block breaks an approved tool that embeds the model through a third-party host, have a documented exception path with an owner and expiry rather than removing the block.

Questions that separate high-risk AI suppliers from ordinary ones

Which legal entity is the controller, and where are prompts, files and outputs stored and processed?
Are prompts used to train or improve models, and can this be switched off contractually for every user?
Which affiliates and sub-processors receive prompts or telemetry, and in which countries?
What is the retention period for prompts and logs? (DeepSeek's policy gives no fixed periods.)
What independent security attestation exists, and does its scope cover the inference service?
How does the supplier respond to data protection authorities in your jurisdiction?
Has the supplier had an exposure of logs or secrets, and what changed afterwards?

See the Security Questionnaires Guide and the Vendor Security Assessment Template for the general question set.

Decision guidance

Situation	Recommended position	Conditions
Public sector body covered by a direction or warning	Follow the instrument exactly	Document scope, including any exclusions for research and local models
Regulated private organisation (finance, health, critical infrastructure)	Prohibit hosted app and API	Allow open weights only in an isolated environment after model testing and egress controls
General enterprise with an approved AI assistant	Prohibit hosted app and API, redirect users to the approved tool	Explain why in plain language; offer a request route for capabilities the approved tool lacks
Research or security team evaluating the model	Allow under exception	Isolated environment, no production data, named owner, expiry date
Small organisation without a TPRM function	Block the consumer app and API domains at DNS or secure web gateway; ban use with customer or personal data in the acceptable use policy	Revisit when a regulator in your country issues guidance
Product team wants a cheap model behind a customer-facing agent	High bar regardless of supplier	Agent hijacking results matter more than benchmark scores; require tool-permission limits and human approval for sensitive actions

Cost and capability arguments deserve a fair hearing, but check them: CAISI reported that one US reference model cost 35% less on average than the best DeepSeek model to reach similar performance across 13 benchmarks. Price per token is not the same as cost per completed task.

Enforcing the decision

Network: block the supplier's web, API and app domains on the secure web gateway and DNS resolver for managed devices, and alert rather than silently drop for the first two weeks so you can see who is affected (NIST SP 800-53 SC-7, CM-7).
Endpoint and mobile: add the mobile apps to the MDM blocklist for corporate and BYOD work profiles, and the desktop clients or browser extensions to application control. Personal devices remain a gap: cover them in policy and training (AC-20 Use of External Systems).
Code and CI: add the supplier's API base URLs and key formats to secret scanning and code search rules; review dependency manifests for the supplier's SDK; block egress to the API from build runners.
AI gateway: where an AI or LLM gateway fronts model access, remove the supplier from the provider list and route all model calls through it so a later change is one configuration edit. See the AI Gateway and LLM Gateway Guide.
Third-party embedding: ask existing SaaS suppliers whether they route any customer data to the model and through which host. Contract clauses on sub-processor change notification are the control here (SR-6 Supplier Assessments and Reviews, SA-9 External System Services).
Communication: publish the decision, the reason and the approved alternative. Blocks without an alternative are the main cause of shadow AI. See the Shadow AI Discovery Guide.

Where identity fits

API keys are the main way a prohibited AI supplier becomes embedded in production. A developer who tests a model with a personal API key in an environment variable, then commits it, creates both an unapproved data flow and a leaked credential. The DeepSeek exposure itself showed the other direction: secrets that customers or the supplier's own systems used appeared in the exposed log stream. Treat every AI provider key as a non-human identity with an owner, a scope, a rotation date and a revocation path, and inventory them across vaults, CI variables and developer machines. If you prohibit a supplier, revoke and delete its keys rather than relying on network blocks alone. See the LLMjacking Guide.

Detection and measurement

Log: DNS and proxy requests to the supplier's domains (by user and device), MDM inventory of the mobile app, secret scanning hits for the supplier's key format, egress attempts from self-hosted model segments, and exception approvals with expiry (AU-2 Event Logging).
Watch for drift: new subdomains and API endpoints, model hosting through new inference providers, and browser extensions that wrap the service.

Metric	Target	Why it matters
Time from public adoption spike to triage decision	Under 5 working days	Shadow use grows fastest before a decision exists
Blocked request volume per week after enforcement	Falling trend after week 2	A flat or rising trend means users lack an alternative
Managed devices with the prohibited app installed	Zero	Direct measure of endpoint enforcement
Supplier API keys found in code or CI	Zero live keys	Shows whether the decision reached engineering
Self-hosted model egress attempts	Zero allowed, all investigated	Confirms that "local" really is local
High-risk AI suppliers with a current assessment and review date	100%	Decisions decay as policies and models change

Framework mapping

Framework	Reference	How it applies
NIST CSF 2.0	GV.SC-04, GV.SC-06, GV.SC-07, GV.SC-10	Prioritise AI suppliers by criticality, perform due diligence before use, monitor during use, plan for exit
NIST SP 800-53 Rev. 5	SR-3, SR-5, SR-6, SR-11, SA-9, RA-3, AC-20, SC-7, CM-7	Supply chain controls, supplier review, external services, component authenticity for model files, boundary and least functionality enforcement
ISO/IEC 27001:2022 Annex A	5.19 to 5.23	Supplier relationships, agreements, ICT supply chain, monitoring and cloud service use
CIS Controls v8.1	Control 15 Service Provider Management	Inventory, classify and assess service providers, including AI providers
OWASP Top 10 for LLM Applications 2025	LLM02, LLM03, LLM06	Sensitive information disclosure to the provider, supply chain and licensing, excessive agency in agents built on the model
MITRE ATLAS	AML.T0010, AML.T0051, AML.T0054, AML.T0057	AI supply chain compromise, prompt injection, jailbreak and data leakage tests for model evaluation
MITRE ATT&CK	T1567 Exfiltration Over Web Service	Monitoring frame for data leaving through an unapproved AI web service

Common failure patterns

Banning the name, missing the path: the app is blocked but the same model arrives through a cloud marketplace, an inference provider or a SaaS feature, with no assessment of that host.
Trusting questionnaires over evidence: a supplier that answers "yes" to logging and access control can still expose an unauthenticated database. The DeepSeek Database Exposure 2025 leaked chat history and API secrets from a ClickHouse instance with no authentication; external attack surface checks would have been more informative than self-attestation.
Assuming open weights are safe by default: local hosting removes the data transfer, not the jailbreak and agent hijacking behaviour CAISI measured, and not the licence obligations of the base model.
Leaving keys behind: blocking domains but never revoking API keys, so a later network change silently re-enables the integration.
Copying a government ban without its scope: policies cite PSPF or NÚKIB but omit the research and local-model exclusions, which then blocks legitimate security testing.
One-off decisions: no review date, so the organisation never notices a resumed service, a revised privacy policy or a new model version.

Lessons from incidents

The DeepSeek exposure was found by an external research team within weeks of the service's surge in popularity, and the exposed log stream contained the very data a customer would most want protected: prompts and secrets. For assessors, the lesson is that a supplier's growth rate can outpace its security engineering, so the period of fastest adoption is when evidence is weakest. Treat external findings about exposed services and leaked secrets as supplier risk signals with the same weight as formal attestations, and re-run the assessment when one appears.

Practitioner checklist

Define the high-risk AI supplier criteria (jurisdiction, transfers, legal posture, operational security, model behaviour, adoption speed) and add them to TPRM intake.
Record each relevant government or regulator action with its primary source URL, scope, exclusions and check date.
Assess hosted app, API, third-party hosted model and open weights as separate decisions.
Run your own jailbreak and agent-hijacking tests before approving any model for agents or customer-facing use.
Block prohibited services at DNS, web gateway, MDM and application control, and test from laptop, phone and CI runner.
Revoke and delete API keys for prohibited suppliers and add their key formats to secret scanning.
Host approved open-weight models in a segment with default-deny egress and alert on any outbound attempt.
Ask existing SaaS suppliers which models and hosts process your data, and require sub-processor change notification.
Publish the decision with an approved alternative and an exception route.
Set a review date and triggers, and report the metrics above to the AI governance forum.

Standards and references

Related NHI Mgmt Group resources: Third-Party AI Risk Guide · Third-Party Risk Management Guide · Open-Weight Model Security Guide · EU AI Act Compliance Guide · Frontier AI Model Risk Frameworks Guide. This guide summarises public government and regulator actions and is not legal advice.

DeepSeek and High-Risk AI Vendor Assessment Guide: Evaluating AI Supplier Risk