DeepSeek arrived in three forms in one week, and each needed a different control

The week

Few technology stories move from the trade press to the evening news in a single week. DeepSeek did, and it did so with a jolt that reached trading floors, government offices and the phones of ordinary employees almost at once.

The story had started a month earlier. On December 26, 2024, DeepSeek released V3, a large general-purpose model, with a technical report. The report said the final training run used about 2.8 million hours on Nvidia H800 chips, a version Nvidia had built for the Chinese market under U.S. export rules. At an assumed rental rate of $2 an hour, that came to roughly $5.6 million. The report noted that the figure excluded earlier research and experiments. That caveat was often lost in the retelling.

On January 20, 2025, the Chinese company released R1, a reasoning model it said performed comparably to leading U.S. models on many benchmarks. A reasoning model is an AI system designed to work through problems step by step before answering, rather than replying instantly. Benchmarks are standardized tests that researchers use to compare models, a little like exam scores.

R1 was built on V3. According to its model card, it has 671 billion parameters in total, of which about 37 billion are active for any given piece of text. That design, known as mixture of experts, makes a model cheaper to run than its size suggests.

DeepSeek published the model’s weights under the permissive MIT license. The weights are, in effect, the model itself: the enormous set of numbers, learned during training, that determine how it responds. Publishing them under that license meant anyone could download the model, run it on their own computers and adapt it, with very few restrictions.

It also released six smaller “distilled” models, from 1.5 billion to 70 billion parameters. These were existing Qwen and Llama models trained on R1’s outputs, and they kept their base models’ licenses. The smallest could run on an ordinary laptop.

Its consumer app rose to the top of Apple’s U.S. App Store rankings, overtaking ChatGPT on January 27. That evening, DeepSeek temporarily limited new registrations, citing large-scale malicious attacks on its services. By then the market had noticed. On the same day, U.S. technology stocks fell sharply as investors questioned assumptions about the cost of advanced AI. Nvidia, whose chips power much of the AI industry, lost close to $600 billion in market value, which Reuters reported as the largest one-day loss for any U.S. company.

The security and privacy questions followed fast. On January 29, the security firm Wiz reported that it had found a DeepSeek database reachable from the internet without any authentication. It held more than a million lines of logs, including chat histories, API secrets and backend details. DeepSeek secured it promptly once Wiz disclosed the problem.

On January 30, Italy’s data protection authority ordered an urgent limitation on the processing of Italian users’ data by the two companies behind the chatbot, which in effect blocked the service there. The authority acted after the companies replied that they did not operate in Italy and that European law did not apply to them. U.S. bodies including the Navy and the state of Texas restricted its use. Around the turn of the month, Cisco researchers reported that an automated jailbreaking method had defeated R1’s safeguards on every one of 50 harmful test prompts.

And yet, at the same moment, the model was becoming more available, not less. On January 29, Microsoft added R1 to its Azure AI Foundry platform and GitHub. It said the model had gone through red teaming and safety evaluations, kept its content filtering on by default, and said distilled versions would run locally on Copilot+ PCs. On January 30, AWS offered R1 through Amazon Bedrock Marketplace and SageMaker JumpStart, and the distilled versions through other services, including import into Bedrock and EC2 instances running Amazon’s own Trainium and Inferentia chips. Both companies offered the model under customers’ existing cloud agreements. AWS recommended pairing deployments with its Bedrock Guardrails filtering service.

That contradiction, a model being banned in one form while being welcomed in another, was what the week taught anyone running technology in a bank, a hospital or an agency.

The DeepSeek week was covered as a market story and a national security story. In banks, health systems and agencies, it also served as an architecture lesson delivered at speed.

The same model reached them in three forms within about ten days. There was a consumer app operated by the developer, a developer API also operated by the developer, and open weights that anyone could run on their own hardware or on a U.S. cloud provider’s platform.

Many organizations responded with a single rule: block DeepSeek. That handled one risk and mislabeled the others. The three forms differ in who operates the model and where data goes, and so they carry different risks. The consumer app is a shadow-use risk, managed through endpoints and the workforce. The developer API is a data-jurisdiction risk, managed through approval and contracts. The open weights are a model-behavior risk, managed through evaluation.

Any model, from any developer, can reach an organization in one or more of these forms, so the same three controls apply long after DeepSeek’s week in the headlines.

The distinction matters because each control is owned, funded and evidenced by a different part of the organization. A ban signed by the CISO can be enforced on managed phones within hours. It cannot rewrite a vendor contract. It also says nothing about whether a model hosted in the bank’s own cloud account answers customers accurately. The sections below take each form in turn. They then show how the three play out on a single day, what architecture makes them cheaper, and what exposure each leaves with leaders.

One model, three routes in

The three forms work like a famous restaurant’s signature dish, available in three ways.

The consumer app is eating at the restaurant. You walk in, order and eat. The restaurant controls the kitchen, the ingredients and what happens to anything you leave behind. For an AI app, “anything you leave behind” is whatever you typed into it, which the operator may store, read or use under its own terms.

The developer API is ordering takeout for your own customers. An API, or application programming interface, is a way for one piece of software to send requests to another automatically. A developer building a product can send text to the model provider’s servers and get answers back, then show those answers inside their own app. Your data still travels to the provider’s kitchen, and the provider’s rules and laws govern what happens there.

Open weights are getting the recipe. You cook the dish yourself, in your own kitchen or in a kitchen you rent from a trusted landlord, such as a large U.S. cloud provider. Your ingredients never leave your control. But the recipe is still the recipe: whatever quirks and habits the original chef built into it come with it.

Each form raises a different question. For the app, it is whether staff are using it with work material. For the API, it is where the data goes and under whose law. For the weights, it is whether the model behaves as needed wherever it runs. Those questions have different owners inside an organization, which is why one blanket rule could not answer all three.

Three tests that sort any arrival

The analogy turns into three practical tests. A security architect can apply them to any new model in a few minutes, before anyone debates whether the model is good or bad.

• Who runs the computation. If the developer’s servers process each request, the organization faces form one or two. If its own hardware or its cloud account does the work, it faces form three.
• Where prompts and outputs are stored. In forms one and two, logs live on the developer’s infrastructure under its retention rules. In form three, logs live wherever the organization’s own systems put them.
• Whose terms govern. The consumer app runs under consumer terms accepted by an individual. The API runs under developer terms, sometimes accepted by an engineer with a credit card. Hosted weights run under the cloud provider’s enterprise agreement plus the model license.

Those three answers decide which team picks up the problem. They also sort the hybrid cases. A software vendor that calls a model API on the customer’s behalf puts the customer in form two, even though staff only ever see the vendor’s screen. A vendor that hosts open weights in its own data center is also form two from the customer’s side, because the customer’s data still leaves for someone else’s infrastructure.

Small copies of a large model

DeepSeek added a wrinkle that later releases repeated. Alongside the full model, it published six distilled versions, built by training existing Qwen and Llama models on R1’s outputs. Microsoft said distilled versions would run locally on its Copilot+ PCs.

Distilled models belong to form three, but they move the control point. A 671-billion-parameter model needs a server full of high-end GPUs, so only a data science team can stand it up. A model of a few billion parameters can be downloaded by any engineer and run on a workstation with free desktop tools. Approval then has to reach the endpoint as well as the cloud account. Software inventory rules that flag multi-gigabyte model files and known local-model runtimes belong in the toolkit.

Distillation also complicates licensing. The R1 weights carried the MIT license. The distilled versions carried the licenses of their base models: Apache 2.0 for the Qwen-based ones and Meta’s Llama license for the others. Legal review that cleared “DeepSeek, MIT” had cleared only some of the files.

Form one, the consumer app: shadow use on staff devices

The app was free, fast and briefly the most downloaded in the country. Staff installed it on personal and work phones, and some pasted work material into it. Security teams call this “shadow” use: technology adopted by staff without the organization’s approval or knowledge.

Its privacy policy described storing data on servers in China, and the exposed database showed weaknesses in how data was protected. For any regulated data, such as customer financial information, protected health information or controlled unclassified information, that was disqualifying. Controlled unclassified information is the federal category for sensitive government data that is not classified but still must be protected by law or policy.

Blocking the app on managed devices and at the network edge was the right first move, but not a sufficient one. Staff reach for consumer AI tools when the approved alternative is absent or clumsy. If the official route is slower, people find a faster one.

The durable control has three parts: an approved assistant that is at least as convenient, clear rules on what may be entered into any AI tool, and monitoring of uploads to unapproved AI domains. An organization that already offers an approved assistant gives staff a reason not to go around it; one that offers nothing invites the next free app.

The owners here are endpoint management, the team that configures and secures staff devices, along with the security team and whoever runs the approved assistant.

What blocking actually involves

Blocking an app sounds like a single switch. It is several, and each has gaps.

On corporate-owned phones enrolled in mobile device management, administrators can prevent installation or remove a listed app. On personal phones enrolled under a bring-your-own-device program, they usually cannot. The organization controls a work profile or a set of managed apps, not the whole handset. There, the workable control is an app protection policy that stops data being copied out of managed apps such as email and document tools.

At the network edge, a secure web gateway or DNS filter can block the web version and the API domains. That covers office networks and laptops that route traffic through the corporate agent. It does nothing for a personal phone on a home connection, which is where much shadow use happens.

Data loss prevention fills part of the gap. Current tools classify destinations into categories such as generative AI, and can warn, block or log when content matching sensitive patterns is pasted or uploaded. They work best when the organization has already labeled its sensitive data. Account numbers and medical record numbers are easy to detect. A paragraph from a confidential credit memo is not.

Who is exposed, and under which rules

The consequence of one employee pasting regulated data differs by type of organization. Precision matters, and organizations should check with counsel on their own facts.

• Banks and credit unions. Customer information is protected under the interagency information security guidelines for banks and NCUA’s Part 748 requirements for federally insured credit unions. Both expect controls over where customer data goes and a response program when it goes astray.
• Broker-dealers and investment advisers. Recordkeeping rules add a layer. The SEC’s multi-year sweep on business messages sent over unapproved channels showed regulators will penalize firms whose staff used convenient consumer tools instead of approved ones.
• Health systems and ambulatory networks. Protected health information entered into an app with no business associate agreement is an impermissible disclosure under HIPAA. It is presumed to be a breach unless a documented risk assessment shows a low probability that the data was compromised.
• Federal agencies. Controlled unclassified information on an unapproved foreign service breaks CUI handling rules and triggers incident reporting, before any question of national security policy arises.
• State and local governments. Criminal justice information under the FBI’s CJIS Security Policy, tax data and benefits records each carry their own handling rules, and several states moved to ban the app on government devices.

For a health system, that breach presumption changes the economics. One clinician pasting a discharge summary into a free chatbot can trigger a breach analysis, possible notice to the patient and an entry in the annual report of small breaches to HHS. The cheapest control is the one that stops the paste.

Evidence an examiner would ask for

When an examiner or auditor asks about generative AI use, a memo opens the file. The stronger file also contains the acceptable-use policy and the date staff attested to it, and the technical block configuration with a timestamp. It includes data loss prevention reports showing attempted uploads falling over time, and the register of approved exceptions. It shows the approved alternative and how widely staff use it. Low adoption of the approved tool alongside heavy blocked traffic is a finding waiting to be written.

The trade-off in monitoring

Monitoring uploads means inspecting what staff type. In unionized public agencies and in European offices, that raises labor and privacy questions that a U.S. bank’s headquarters may not face. Works councils in several European countries must be consulted before new employee monitoring is introduced. A notice explaining what is logged, who can see it and how long it is kept costs little and can prevent a dispute.

Form two, the developer API: where data is processed and under what law

Developers and vendors could call DeepSeek’s API directly, at prices well below many U.S. alternatives. The risk was not the model but the destination. Data sent to the API was processed by a company subject to Chinese law, under terms written by that company, without the contractual protections a regulated organization would require.

This is what “data jurisdiction” means: the question of which country’s laws apply to your data once it lands on someone else’s servers. Those laws decide who could be compelled to hand it over, or could access it.

This form also has a less visible route in than the consumer app: through vendors. A software provider can swap the model behind a feature without telling its customers. The feature looks the same on screen. The data behind it may now be going somewhere new.

The controls start with an approval process for any external AI service. Contract terms should require vendors to disclose which models and processing locations they use, and to notify changes. Egress rules, the network settings that control what traffic may leave the organization, should block unapproved AI endpoints from servers as well as laptops. Procurement and third-party risk own this form, with legal input on jurisdiction.

Why jurisdiction is also a technical question

The legal concern was concrete. China’s National Intelligence Law, in force since 2017, requires organizations and citizens to support and cooperate with state intelligence work. Western security agencies have cited that provision when assessing Chinese technology providers. A company subject to it cannot give a foreign customer a reliable promise to refuse a government request.

The Wiz finding added a technical layer. The exposed database held log streams with chat history and API secrets. Logs are where data sent to an API ends up, often in plain text and often for longer than anyone intended. A regulated organization evaluating any API provider should ask what is logged, how long it is kept, who can reach it and whether it is used for training. The DeepSeek episode showed in public what a bad answer looks like.

Contract terms that do the work

Many vendor contracts signed before generative AI took off said nothing about models. The clauses that close the gap are short.

• Disclosure. The vendor names each model provider and hosting region used for the customer’s data, as part of its subprocessor list.
• Change notice. The vendor gives advance notice before changing model provider or region, with a right to object or exit.
• Use limits. Customer data is not used to train or improve models, and prompts and outputs are kept only as long as stated.
• Flow-down. The same terms bind the vendor’s own model provider.
• Evidence. The vendor supplies attestation or audit reports that cover the AI processing as well as the core application.

These clauses fit existing frameworks. Under the federal banking agencies’ 2023 interagency guidance on third-party relationships, banks are already expected to understand subcontractors and data flows. HIPAA requires business associates to bind their own subcontractors that handle protected health information. Federal agencies buying cloud services expect FedRAMP authorization, which a model API operated from China would not hold.

Credit unions face a quirk. NCUA lacks the authority to examine third-party vendors directly, unlike the bank regulators under the Bank Service Company Act. Contract terms therefore carry more of the weight, because the regulator cannot look behind the vendor on the credit union’s behalf.

Finding the AI already inside vendor products

Contracts fix the future. Finding current exposure takes an inventory. A practical approach sends a short questionnaire to vendors whose products show AI features, asks which models and regions they use, and records the answers alongside the existing subprocessor register. The questions can be tiered by data sensitivity. A vendor that drafts marketing copy needs less scrutiny than one that summarizes loan files or clinical notes.

Network data helps confirm the answers. Traffic from a vendor’s on-premises appliance or agent to an unexpected AI endpoint is visible at the egress proxy. For software-as-a-service vendors, the customer cannot see the vendor’s outbound traffic and must rely on disclosure and audit evidence.

Your own developers count too

Developers inside the organization need the same rules. An engineer prototyping on a personal API key, with test data copied from production, creates the same exposure as a vendor. “Production” is the live system holding real customer or patient data, as opposed to a test environment.

Approved developer sandboxes with sanctioned model endpoints, and secret scanning that flags unapproved AI API keys in code repositories, close that path without slowing legitimate experiments. A sandbox is a safe space for experimenting; secret scanning is an automated check that looks for passwords and keys accidentally left in code.

Server egress deserves the same discipline. Many organizations filter staff browsing tightly but let servers and build pipelines reach the internet freely. A default-deny rule for outbound traffic from production and build systems, with an allowlist of approved AI endpoints, turns an unapproved API call into a visible, blocked event.

The case for allowing the API, and its limits

The strongest argument for the API was price. For non-sensitive work, such as summarizing public filings or drafting marketing copy, the jurisdiction concern weakens. Some firms reasonably asked why public data should not go to the cheapest capable service.

Two problems remained. Data classification is hard to enforce at the moment a developer writes code, and a pipeline approved for public data tends to acquire private inputs over time. For many public-sector and regulated buyers, provenance policy also settled the matter regardless of data type. The same capability became available days later through U.S. cloud platforms, which met the price argument another way.

Form three, the open weights: what the model does, wherever it runs

Running open weights on infrastructure the organization controls, or on a U.S. cloud platform under an existing agreement, removes the data-transfer risk. It does not remove all risk. A model carries behaviors from its training.

Researchers testing R1 reported that it deflected politically sensitive topics in line with Chinese content rules and was easier to manipulate into harmful output than several alternatives. Manipulation here means techniques sometimes called “jailbreaking,” in which a user crafts prompts that trick a model into ignoring its safeguards.

The published tests were specific. Cisco researchers ran an automated jailbreaking method against 50 prompts sampled from HarmBench, a standard set of harmful requests. R1 blocked none of them. Every comparison model they tested blocked at least some.

What self-hosting removes and what it keeps

Self-hosting changes the threat model in three ways. Prompts and outputs stay inside infrastructure the organization controls. The model cannot change underneath the organization, because the weights are a fixed file. And no outside party sees usage patterns.

It keeps three things. The model’s trained behaviors come with it, including topic deflection and susceptibility to manipulation. The model files themselves are software supply chain artifacts. And the organization now carries the operating burden that the developer previously carried.

The supply chain point is easy to miss. Model files can be tampered with between publisher and user, and some older file formats can execute code when loaded. Downloading from the publisher’s official repository, checking file hashes, preferring formats that store only numbers and scanning files before loading are routine controls borrowed from software packaging.

What the cloud platforms added

Microsoft and AWS each wrapped the model in their own controls. Microsoft said R1 had gone through red teaming and safety evaluations before listing, with content filtering on by default. AWS recommended pairing R1 deployments with Bedrock Guardrails, which screens inputs and outputs separately from the model.

Those layers help, and a model risk team should record them as compensating controls. They do not change the model’s underlying tendencies. A filter that catches harmful output will not detect a model that silently leaves part of an answer out. That subtler failure is the one that matters for a bank or agency publishing information to the public.

Reasoning traces are data too

R1 writes out its reasoning before its answer. That trace can repeat sensitive details from the prompt, speculate about a customer or state wrong intermediate conclusions. Organizations deploying reasoning models had to decide whether to log traces, how long to keep them and who may see them. Showing a raw trace to a customer invites confusion and complaints.

Testing for the intended use

The control is evaluation for the intended use, the same as for any model: accuracy on the organization’s tasks, resistance to manipulation, handling of sensitive content and consistency of outputs. A model used to summarize internal policies needs different tests from one that drafts letters to customers.

Evaluation does not need to be elaborate to be useful. A sensible starting point has three parts. One is a set of realistic sample tasks drawn from the intended use. Another is a set of known tricky prompts that test whether the model can be pushed off course. The third is a comparison with the model the organization already uses. The results tell decision-makers whether the new model is good enough, safe enough and consistent enough for that particular job.

Which framework applies

Banks already had a model risk framework in the Federal Reserve and OCC’s 2011 supervisory guidance, SR 11-7, which covers development, validation and ongoing monitoring. Applying it to a general-purpose language model takes interpretation, but the habits transfer: document the intended use, test against it, set limits and monitor. Credit unions and smaller institutions often adopt a lighter version of the same approach.

Federal agencies were operating under OMB memorandum M-24-10, issued in March 2024. It required inventories of AI use cases and minimum risk practices for uses that affect rights or safety. Health systems had narrower triggers. Software that drives clinical decisions may fall under FDA oversight, and HHS’s HTI-1 rule had begun requiring developers of certified health IT to disclose information about predictive tools in their products. Administrative uses such as summarizing policy documents fall outside those regimes but still need evaluation.

Provenance, meaning where a model came from, is a separate policy question. Federal agencies and some contractors may face restrictions on models from certain countries however they are hosted, and organizations should check with counsel.

Evaluation results should be recorded with the model version, because a later release of the same open model can behave differently. A usable record names the model, its exact version and file hash, the test date, the test sets, the scores, the known weaknesses, the compensating controls and the approver. When a new version arrives, the same tests run again and the results are compared line by line. The owner is the AI or model risk function.

The cost of running it yourself

Self-hosting the full model is expensive. A model with 671 billion parameters needs a server with several high-end GPUs, even though only a fraction of the parameters are active for each word. Managed endpoints on cloud platforms bill by instance-hour whether or not the model is busy. Distilled versions cost far less but perform worse. For intermittent use, a hosted model from an already approved provider can cost less than an idle private deployment.

One bank, three conversations by lunchtime

Suppose a regional bank on the Monday the market fell. By lunchtime, three separate conversations are under way.

The security team notices that a number of staff phones have the DeepSeek app installed, and that a few web uploads went to its domain the previous week. They block the app on managed devices and the domain at the network edge. The head of operations then asks why staff were using it at all. The answer is that the bank’s approved assistant is slow to request and limited in what it can do. Improving that becomes a priority.

The procurement team receives a question from a business line. A vendor providing a document-processing tool has mentioned it is “exploring cheaper models.” The bank’s contract does not require the vendor to say which models it uses. Third-party risk sends a letter asking for disclosure of models and processing locations, and adds the clause to the renewal template.

The data science team, meanwhile, wants to try the open-weight model on the bank’s existing cloud platform for an internal research task. The model risk function agrees to an evaluation first, testing accuracy on the bank’s documents and resistance to manipulation, and asks legal whether any provenance restrictions apply to the bank’s government business.

By Friday, the picture is clearer. The app is blocked and the approved assistant has a project to make it easier to use. The vendor has replied, naming the models it uses and confirming where data is processed, and the bank now knows to ask the same question of its other AI-enabled suppliers. The evaluation of the open-weight model is under way, with results to be recorded against the specific version tested. None of the three teams needed to wait for the others, because none of their tasks depended on the others’ answers.

Three conversations, three owners, three different controls. A single “block DeepSeek” memo would have stopped the data scientists, done nothing about the vendor and left the underlying reason for shadow use untouched.

The same Monday in a hospital, a county and a federal agency

The pattern looks different outside banking, which is why ownership has to be set locally. The cases below are hypothetical illustrations.

A health system’s first concern would be clinicians. Phones in clinical areas are often personal, so an app block reaches only some of them. The privacy officer needs to know whether any protected health information was entered, which means reviewing data loss prevention logs and asking staff directly. A separate question comes from the vendor side. Documentation and coding tools that already process patient data with AI need business associate agreements that say which models sit behind them.

A county government faces a different mix. It may have no data science team, so form three barely arises. Its exposure is the app on staff phones and AI features inside the case management or permitting software it licenses. A sheriff’s office handling criminal justice information must hold any vendor touching that data to CJIS requirements. The county’s most effective steps could be a single procurement clause and adoption of its state’s device policy.

A federal agency would probably ban all three forms, because provenance policy applies however the model is hosted. That is a legitimate result of the same analysis. The difference is that the agency reaches it deliberately, with the reason recorded, instead of assuming one memo covers everything.

A switchboard between applications and models

One architectural choice makes all three controls cheaper. If applications call models through an internal routing layer, an organization can approve, evaluate, log, cost-control and remove models by configuration.

A routing layer is a kind of switchboard. Instead of each application connecting directly to a particular model, every application connects to the switchboard, and the switchboard decides which approved model handles the request. Changing models becomes a setting, not a software project.

The switchboard also gives leaders something they rarely have with AI: a single place to see what is being used. Every request passes through it, so the organization can log which models are called, by which applications, for what volume and at what cost. That record is useful for budgets, for audits and for spotting an application that has started relying on a model nobody approved.

When a new model appears, cheaper or better, it can be tested and offered through the same route. When a risk emerges, it can be withdrawn the same day. The DeepSeek week exercised both needs within a few days.

What the layer does

• Identity. Every call carries the calling application’s identity, so usage can be traced and revoked.
• Policy. Rules tie data classifications to approved models. Restricted data may reach only models hosted in the organization’s own cloud account.
• Inspection. Prompts can be screened for sensitive patterns, and outputs for policy violations, before they pass.
• Logging. Requests and responses are recorded, with retention set by policy.
• Cost control. Budgets and rate limits per application stop a runaway process from producing a surprise bill.
• Fallback. If one model fails or is withdrawn, traffic can shift to an approved alternative.

What it costs and what it breaks

The layer is not free. It adds a network hop and some latency. It becomes a dependency for every AI feature, so it needs the same availability engineering as any core service. A central team that owns it can become a bottleneck if approvals are slow.

It also tends to expose a lowest-common-denominator interface. Providers implement features such as structured outputs or tool use in different ways. A gateway that hides those differences can hide useful capability too. One workable compromise allows a direct path for specific, approved cases and keeps the gateway as the default.

The logs deserve the most care. A gateway that records every prompt builds the kind of store Wiz found exposed at DeepSeek: chat history, keys and metadata in one place. It needs access controls, encryption, retention limits and monitoring matched to the most sensitive data that passes through it.

Flexibility in the contract

The week also showed why multi-year, fixed-price commitments to a single model aged badly, while the price of capability was falling this fast. Leaders negotiating AI contracts should think about flexibility as carefully as price.

Flexibility can be written in. Useful terms include committed spending that can be applied across several models from the same provider, price review rights when the provider releases a cheaper model, and short terms for anything priced per model. Cloud marketplaces helped, because a newly listed model could be bought under an existing agreement.

Five exposures from one week of DeepSeek

DeepSeek arrived in three forms, an app, an API and downloadable weights, and each form creates exposure that a board or an agency head will be asked to account for.

Regulatory exposure. A single employee pasting customer records, patient details or sensitive government information into an unapproved app can create a reportable incident. Regulators will ask what the organization did to prevent it, and “we sent a memo” is a weak answer if no approved alternative existed. Notification clocks differ by sector. HIPAA allows up to 60 days from discovery to notify affected individuals. The banking agencies’ incident notification rule requires notice to the regulator within 36 hours, though only for incidents that seriously disrupt operations. A single paste would rarely meet that bar, but the analysis has to be done and documented.

Third-party risk. Vendors swapping the model behind a feature without notice is a new version of an old problem: not knowing who your suppliers’ suppliers are. Leaders who already oversee outsourcing will recognize the pattern, and the same contractual tools apply. Concentration is the second-order question. If several critical vendors depend on the same model provider, an outage, a sanction or a security failure at that provider reaches all of them at once.

Reputation. A model that deflects certain topics or can be manipulated into harmful output reflects on whoever puts it in front of customers or the public. The organization, not the model developer, will be the name in the story. Public agencies carry an extra burden. Information they publish must be accurate and impartial, and a model that shades answers on sensitive subjects is unsuitable for public-facing use without heavy controls.

Cost and opportunity. The week showed how quickly the price of AI capability can move. Organizations that can test and adopt a cheaper or better model safely, within days, gain an advantage. Those locked into rigid arrangements, or with no way to evaluate new models, pay more and move slower. Budget processes were tested too. Finance teams that treated AI as a fixed annual software license had no way to capture a sudden drop in unit price.

Clarity of ownership. Perhaps most important, each form has a different natural owner: security and endpoint teams for the app, procurement and third-party risk for the API, model risk for the weights. A leader who makes those assignments explicit turns a confusing week into three manageable tasks. The usual failure is handing the whole topic to the CISO. Security can own the app and part of the API control, but model evaluation needs data science, and contracts need procurement and legal.

How the prepared organizations differed

A well-prepared organization can answer, for any model, which of the three forms it might arrive in, and who owns the control for each. It offers staff an approved assistant good enough that they do not need a free alternative. Its contracts require vendors to disclose and notify model and location changes. It evaluates models for its intended uses before approving them, and records results by version. And its applications reach models through a routing layer, so change is a configuration decision.

The organizations that struggled tended to make the opposite choices:

• One rule for three risks. A blanket ban treats a recipe like a restaurant.
• Blocking without replacing. Staff move to the next free tool.
• Forgetting vendors. The model behind a familiar feature can change silently.
• Assuming self-hosting means safe. It solves where data goes, not how the model behaves.
• Locking in. Long, rigid commitments to one model in a market where capability is getting cheaper fast.

The strongest case for one rule

A single rule has real advantages. It is fast, easy to communicate and easy to audit. A small credit union or a rural hospital with no data science team may never face forms two and three in-house. For such an organization, a blanket ban on DeepSeek in every form costs nothing it would have used.

The argument holds for that organization only on the surface. Its vendors still face the form-two question, and a ban on its own staff does nothing about the model behind a vendor’s feature. Even the smallest organization needs the contract clause. And when the next model arrives, a rule written around one company’s name will not cover it.

A second objection is that the three-form analysis invites hair-splitting while the risk is live. The answer is sequencing. Block the app and the API domains on the first day, because both steps are cheap to reverse. Then let the procurement and model risk work run on their own timetables. Speed and precision do not conflict here, because they apply to different forms.

Where the next headline model will test the controls

DeepSeek will not be the last model to arrive this way. A written runbook turns the response into routine. A useful one covers the first 72 hours: who triages, which domains are blocked pending review, which vendors receive the disclosure question and who decides whether an evaluation is worth running. Five questions test whether that runbook exists.

1. When a new AI model makes headlines, who decides our response, and do they distinguish between the app, the API and the downloadable model?
2. Do our staff have an approved AI assistant that is at least as easy to use as the free alternatives?
3. Do our vendor contracts require disclosure of which AI models and processing locations sit behind their features, and notice of changes?
4. How do we evaluate a model before approving it, and do we record results by version?
5. Do our applications reach AI models through a single internal route, so we can switch or withdraw a model in a day?

The answers amount to the governance program. They are best tested before the next model makes headlines, through a tabletop exercise that walks the three forms with each owner in the room.

With hindsight

The market sell-off proved short-lived. AI infrastructure spending kept rising through 2025, and in July 2025 Nvidia became the first company valued at $4 trillion. By late October it had passed $5 trillion. Investors who had feared that cheaper AI would shrink demand for chips found that, at least for that year, it did not. Cheaper capability seemed to widen use faster than it cut spending per task.

The cost story also aged. DeepSeek’s own report had said its $5.6 million figure covered only the final training run. Analysts argued through 2025 that the company’s total spending on hardware and research was far higher. The headline number had compared one line of DeepSeek’s budget with the whole budgets of its rivals.

The architectural point held better than the financial one. Government restrictions on DeepSeek’s app spread in early 2025. Taiwan barred its use by government agencies, Australia banned it from government devices, and South Korea suspended new downloads while regulators reviewed its data handling. Several U.S. states also barred it from government devices. These were restrictions on the first form, the app, driven by concerns about where data went and how it was protected.

The concern about the third form was later tested formally. On September 30, 2025, NIST’s Center for AI Standards and Innovation published an evaluation of three DeepSeek models, R1, a May 2025 update of R1 and V3.1. It compared them with four U.S. models on 19 benchmarks. The best U.S. model outperformed the best DeepSeek model on nearly every benchmark, with the widest gaps in software engineering and cyber tasks. Agents built on DeepSeek’s models were far easier to hijack with malicious instructions. The models also echoed Chinese Communist Party narratives much more often than the U.S. models did.

Two details of that report mattered for governance. It tested each release separately, which is the version-by-version discipline the evaluation argument calls for. And it tested the models themselves, independent of where they were hosted, which confirmed that hosting location answers only the data question.

Meanwhile open-weight models from several developers and countries kept improving, and the cost of model capability kept falling. That trend made the third form steadily more important. In August 2025, OpenAI released open-weight models, gpt-oss, its first since GPT-2. U.S. policy moved the same way. The administration’s AI Action Plan, published in July 2025, encouraged open-source and open-weight AI from American developers. Organizations had more capable models they could run under their own control, which raised the value of good evaluation and lowered the value of any single long-term commitment.

Federal rules changed shape without dropping the core controls. In April 2025, OMB replaced its 2024 AI memoranda with M-25-21 on use and M-25-22 on acquisition. The new memos pushed agencies to adopt AI faster while keeping inventories and minimum risk practices for high-impact uses.

Enterprise AI platforms increasingly offered routing across multiple models as a standard feature. What had looked like an advanced design choice in January became, within the year, something many organizations could switch on rather than build.

The three forms recurred with later models, which made the distinction between shadow use, data jurisdiction and model behavior a lasting part of AI governance rather than a response to one company.

Asking whether to allow a model usually turned out to be the wrong framing. The useful version asked in which form, for which use and under whose control. Each answer points to a different owner and a different safeguard. Organizations that built their response that way in early 2025 found the next headline-grabbing model far easier to handle.