---
title: "Which data must never leave the building, and how to decide"
url: "https://hurukan.com/blog/which-data-must-never-leave-the-building"
description: "Treating every record as secret makes the rule unworkable, and treating none as secret makes it pointless. A practical way to classify data before any model touches it."
---

# Which data must never leave the building, and how to decide

July 10, 2026·3 min read·Editorial team

A person in a grey suit seen from behind closing the heavy steel door of a records room lined with labelled grey boxes, a small blue-lit access panel on the wall, cool even light

One company forbids sending any internal data to external AI services. People keep using them anyway, on personal accounts, because the rule blocks a summary of a public press release as firmly as it blocks the payroll file. Another company allows everything, and someone pastes a customer contract, prices included, into a consumer chatbot to tidy up the wording.

Both policies fail for the same reason. They were written about tools, not about data. “Can we use model X?” has no good answer. “Can this kind of data go to a processor outside our control, under these terms?” does, and it can be answered once per kind of data rather than once per request.

“The building” here is shorthand for infrastructure the company controls: its own servers, or hardware it rents where nobody else holds the keys.

## Where data policies fail

**One rule for everything.** Too strict, and people route around it. Too loose, and the damage is done before anyone notices. Either way the policy stops describing what happens.

**A classification nobody can apply.** Five confidentiality levels are defined in a PDF. Nobody in the warehouse or in the sales team knows which level a delivery note is, so everything is treated as the level that is most convenient that day.

**Ignoring derived data.** Prompts, logs, summaries, search indexes and embeddings all carry the content they were made from. A search index of contracts should be treated as the contracts.

**Assuming the terms.** Whether a provider may retain what it receives, and whether it may use it for training, depends on the product and the contract you have, not on the brand. Read them.

**Treating personal data as one more category.** Under GDPR, using an outside processor for personal data requires a processing agreement, and moving that data outside the European Economic Area requires a transfer mechanism, such as an adequacy decision or standard contractual clauses. That has to be settled before the first request is sent, not after.

**Forgetting what secrecy protects.** Under EU rules on trade secrets, information is protected partly because its holder took reasonable steps to keep it secret. Pasting it into a service nobody controls can weaken that argument when it is needed most.

## A rule people can apply

Define the classes by what disclosure would cost, not by labels, and keep them few.

1.  **Public, or meant to be.** Published material, marketing copy, public filings. Any model.
2.  **Internal.** Routine operational information: procedures, general correspondence, internal notes without customer or personal detail. External models under a business contract that excludes training on your data and sets retention.
3.  **Confidential.** Contracts, prices, margins, customer lists, personal data, unreleased plans, source code. Only processors whose contract meets your legal obligations (for personal data, proper processing and transfer terms), or models you run yourself.
4.  **Never leaves.** Data whose disclosure would be serious and irreversible: specific trade secrets, credentials and keys, special categories of personal data you have no need to share, details of your own security. Processed only on infrastructure you control, by models you run, with every access logged.

Then attach the class to the _kind of object_, not to individual files. If the company’s model knows that something is a salary, a contract price or a customer complaint, the routing decision can be made automatically every time an agent touches it, instead of relying on each person to remember the policy.

That is how Hurukan is designed. The [Super Intelligence layer](https://hurukan.com/system/super-intelligence) routes each task to a model permitted for the data involved, including local models where data must not leave. The [Security and Sovereignty layer](https://hurukan.com/system/security-and-sovereignty) enforces permissions on the server and logs every access. Both are in build. The wider argument for designing control in rather than buying it is in [sovereignty is an architecture decision](https://hurukan.com/blog/sovereignty-is-an-architecture-decision), and the practical side of running models yourself is in [small models on your own hardware](https://hurukan.com/blog/small-models-on-your-own-hardware).

## A test you can run today

List the twenty kinds of object your business handles most: customer, order, invoice, price list, employee, contract, drawing, support ticket and so on. Next to each, write its class from one to four and a one-sentence reason.

Then find out which AI tools people actually use. Ask them, and do not guess. For each tool, note which classes of data reach it and under which contract terms.

Two lists come out of this. Every class three or four object reaching a tool without matching terms is your priority list for this month. Every class one object blocked from a useful tool is the reason people are working around your policy, and fixing that is what makes the rest of the policy believable.

-   data classification
-   GDPR
-   trade secrets
-   local models

## Keep reading

-   [One identity for people and agents: who may do what](https://hurukan.com/blog/one-identity-for-people-and-agents)
-   [The live state and the record: two memories of a company operating system](https://hurukan.com/blog/the-live-state-and-the-record-two-memories-of-a-company-operating-system)