Why Your Strategy Data Cannot Go Into an Open AI Chat

There is a conversation happening in most large organisations right now that does not resolve. On one side: teams who have discovered that a general-purpose AI assistant makes them meaningfully faster. On the other: legal, works council, and the CISO, who have concluded that the most valuable use cases are exactly the ones they cannot approve.

Both sides are right, and the disagreement usually gets framed as a data protection problem. That framing is too narrow, and because it is too narrow, the conversation goes in circles.

It is rarely only GDPR

Data protection law is the reflex answer, and it does apply. But strategy documents, M&A models, restructuring plans and pricing analyses frequently contain little or no personal data. If GDPR were the only constraint, a great deal of the most sensitive work would be cleared.

It is not cleared. Two other levers are usually the binding ones, and they are seldom thought about together.

Lever one: co-determination

In Germany and much of Europe, introducing a system capable of monitoring employee performance or behaviour is subject to co-determination. In practice this means a works council agreement is required before rollout — not as a courtesy, but as a legal precondition.

A general-purpose AI assistant used across the organisation falls squarely into this category, and the agreement is not a formality. It covers what may be logged, what may be processed, what may be inferred, and under what conditions. Organisations that deploy first and negotiate later tend to discover that the negotiation is significantly harder once the system is already running.

Lever two: trade secret law

This is the lever that surprises people, and it is the more consequential one for strategy work.

Legal protection for a trade secret is not automatic. It is conditional on the holder taking reasonable steps to keep it secret. That is the mechanism: protection follows from protective conduct.

Now consider what happens when a strategist pastes an unreleased business case into a consumer AI chat. The question is not only whether that data leaks. It is whether the organisation can still claim it took reasonable protective steps. A secret shared with an uncontrolled third-party system may cease to qualify as a secret — and the loss is not recoverable by deleting the chat history afterwards.

This is why the constraint bites hardest exactly where the value is highest. Routine text? Fine. The unreleased strategy? That is the asset whose protected status you would be putting at risk.

The evidence in the market

This is not theoretical caution. The pattern across the last few years has been consistent: organisations enthusiastically adopt open AI chats, a real leak occurs, and access is restricted or banned outright. Several large enterprises took exactly that path publicly, and many more did it quietly.

The lesson those organisations drew was not “AI is unsafe.” It was more specific: this class of data cannot go into a system we do not control.

Where the pain actually sits

Here is the point that changes how the problem should be approached.

The constraint is a property of the data, not of the hosting arrangement. Moving a general-purpose model into your own tenancy helps with some concerns and leaves others untouched. If the interaction pattern is still “paste sensitive material into an open prompt and see what comes back,” the co-determination question and the trade-secret question do not disappear.

What changes the picture is a different interaction model altogether: controlled retrieval over a validated corpus, running on infrastructure you control, where the inputs are structured rather than pasted, the operations are specified rather than open-ended, and every human decision is recorded.

That is a different architecture, not a different deployment option.

The pain sits in the kind of data — not in where the model is hosted.

What a defensible setup looks like

Four properties, in our experience, are what actually get a system approved for strategy-grade data:

• On your infrastructure. Data does not leave the boundary you control. This is table stakes and it is not sufficient on its own.
• Deterministic core. The operations applied to your data are specified and reproducible, not open-ended generation. This is what makes the system describable to a works council in concrete terms.
• No US provider in the deterministic core. For organisations with sovereignty requirements, the jurisdiction of the components doing the actual reasoning is a separate question from where the servers sit.
• Recorded decisions. Every human approval documented — which turns “the AI suggested it” into an auditable chain with a person at the end of it.

The practical route through

For teams stuck in the circular conversation, the productive move is to stop arguing about AI in general and separate the question by data class.

Most organisations can approve a broad assistant for low-sensitivity work quickly. The strategy-grade work needs a different answer, and the answer is architectural. Trying to solve both with one procurement decision is why the conversation does not resolve.

The organisations getting this right are not the most cautious ones and they are not the fastest movers. They are the ones that recognised early that “can we use AI” is the wrong question, and replaced it with: for this class of data, what architecture can we actually defend?