Notifications
Clear all
Topic starter
15/08/2026 8:29 pm
TL;DR: DeepSeek’s hosted and self-hosted paths create different enterprise risks because data location, jailbreak susceptibility, and shadow AI usage all change the control profile, according to WitnessAI. The practical lesson is that AI governance must cover discovery, routing, and runtime guardrails before model use begins, not after.
NHIMG editorial — based on content published by WitnessAI: DeepSeek safety, hosted use, self-hosting, and shadow AI governance
By the numbers:
- In January 2025, Wiz Research found a publicly accessible DeepSeek database exposing more than a million audit trail entries.
- Italy’s data protection authority ordered DeepSeek blocked on January 30, 2025, and New York issued a government-device ban.
Questions worth separating out
Q: What breaks when an organisation blocks an AI model only at the proxy layer?
A: Proxy blocking misses personal accounts, mobile apps, IDE tools, and agent frameworks that can still reach the model outside the browser path.
Q: Why do self-hosted AI models still need strict governance?
A: Self-hosting changes where data is processed, but it does not remove risks built into the model’s weights, such as jailbreak susceptibility or embedded policy behaviour.
Q: How do security teams know if AI governance is working?
A: Look for evidence that access decisions are reviewable, permissions are revocable, and exceptions are not becoming permanent.
Practitioner guidance
- Define approved DeepSeek deployment paths Separate hosted, API, self-hosted, and embedded backend use cases into distinct approval classes with different data and logging requirements.
- Extend discovery beyond browser-only controls Inventory DeepSeek usage across personal accounts, IDE assistants, local agent frameworks, and vendor backends so shadow AI does not bypass identity policy and audit coverage.
- Require data-routing controls before model access Route sensitive prompts to approved internal models or redact them before they reach third-party systems, and block use cases that cannot tolerate external storage or training exposure.
What's in the full article
WitnessAI's full analysis covers the operational detail this post intentionally leaves for the source:
- How WitnessAI maps DeepSeek usage across employees, models, apps, and agents with network-level visibility
- The control logic behind intent-based routing, including allow, warn, block, and route decisions
- Runtime guardrail behaviour for prompt injection, jailbreak blocking, and sensitive-data redaction
- Enterprise proof points and deployment examples that show how the controls work in production
👉 Read WitnessAI’s analysis of DeepSeek safety and enterprise AI governance →
DeepSeek exposure: what it means for enterprise AI governance?
Explore further
15/08/2026 8:29 pm
Hosted AI becomes a governance boundary problem when data leaves the enterprise identity plane. DeepSeek’s hosted path shows that AI risk is often created by where prompts are processed, not by the model alone. Once prompts cross into a provider’s environment, the enterprise must account for storage location, provider access, retention, and legal exposure. For IAM and GRC teams, the conclusion is simple: approval must be tied to the data path, not the marketing label on the model.
A question worth separating out:
Q: Who should decide whether a high-risk AI model is allowed in enterprise use?
A: Approval should sit with a governance group that can weigh security, privacy, legal, and operational requirements together, not with a single team acting alone. For sensitive use cases, the decision needs explicit data boundaries, routing rules, runtime guardrails, and audit logging. Without that record, the risk is not governable.
👉 Read our full editorial: DeepSeek exposure shows why AI governance must start before deployment
