AI and business data: the perimeter contracts cannot protect

Enterprise AI data security now has to answer a structural question. The market for artificial intelligence models has settled into two distinct levels, and the split is permanent. On one side sit closed models accessed through APIs: you send data, answers come back, you pay per use. On the other sit open-weight models, downloadable and installable on your own infrastructure: the model file is in-house, processing happens locally, data does not leave. Two different economies, two radically different models of control, two levels of risk that cannot be compared when confidential information is at stake.

Google's move with Gemma 4 — released in April 2026 under the Apache 2.0 licence, removing every constraint on commercial use — made the fork even clearer. For the first time, a leading lab offers open models with performance close to flagship proprietary products, on accessible hardware, without legal restrictions. The same dynamic involves Meta with Llama, Mistral from Europe and Alibaba with Qwen. The alternative to the cloud exists, is mature and works. The relevant question for a company changes accordingly: when is it reasonable to use one option or the other, and why does the answer almost always depend on the nature of the data involved.

Three distinct problems, often confused into one

The debate on data security with cloud AI models tends to focus on training: are the data used to improve the model? On this point, enterprise vendors — OpenAI, Anthropic, Google, Microsoft — offer explicit contractual guarantees. For business customers, training on transmitted data is excluded by default. On this specific point, the contracts work.

Training is only one of three layers of the problem. The other two are almost always ignored when a company evaluates adopting cloud AI tools.

The second layer is retention. Even excluding training, data transmitted through APIs is stored on the vendor's servers for abuse monitoring. The standard period for OpenAI is thirty days; at the end, inputs and outputs are removed from the logs, subject to overriding legal obligations. The clause matters: in May 2025 a US federal court ordered OpenAI to retain indefinitely all consumer conversations, including deleted ones, in a copyright dispute. The order was later scaled back and OpenAI restored its standard policies in September 2025, but the episode shows that retention can be changed unilaterally by third-party judicial obligations, regardless of the contractual terms with the customer. A Zero Data Retention (ZDR) mode exists that excludes any storage of inputs and outputs, but it is not automatic: it must be requested explicitly, is available only to customers with qualified use cases, requires direct negotiation with the sales team and is not accessible on every endpoint. For most small companies using standard APIs, ZDR is not a concretely available option.

The third layer — the most underestimated — is transmission itself. And it is structurally different from any other form of IT supply a company has ever handled.

Why cloud AI is different from any other IT supplier

With any traditional IT vendor — a housing provider, a backup operator, a document archiving system — data is transmitted and stored in opaque form. The vendor holds files, records, encrypted packages. It stores them, replicates them, protects them. But it does not understand them. A contract, an audit, an end-to-end encryption system can ensure that no operator accesses those files without explicit, case-by-case authorisation.

With a large language model the mechanism is radically different. When a prompt reaches an LLM through an API, the model processes it semantically: it understands the context, extracts relations between concepts, recognises entities, produces inferences. It does not store a file — it interprets content. A confidential contract sent to an LLM for a summary is no longer an opaque document held by a server: it is a text a machine has read, understood and drawn meaning from. That understanding, in aggregate or synthetic form, can then be accessible to the vendor's human operators as part of the contractually foreseen monitoring. OpenAI states this in its enterprise documentation: authorised employees can access stored data for engineering support, investigation of potential abuse and legal compliance; in some cases, third-party contractors bound by confidentiality may review conversations to identify improper use.

The difference from the past is therefore qualitative, not only quantitative. Before AI, the risk of a cloud vendor was unauthorised access to stored files, a problem manageable with encryption, contracts and access policies. With cloud AI, the data is handed to a system that understands it by function, not by error or intrusion. The human factor remains the most underestimated vector in security management, and the LayerX AI Security Report 2025 confirms it with precise figures: 77% of business users paste data directly into chatbots, often from unmanaged personal accounts, and Cyberhaven analysis shows that sensitive data makes up about 35% of everything employees paste into external AI platforms. These are not deviant behaviours: they are normal, daily use of tools perceived as productive.

Professional secrecy, proprietary know-how, information covered by confidentiality agreements with customers or suppliers: none of these can be adequately protected by a Data Processing Agreement if the workflow routes them through a system that processes them semantically on external infrastructure. GDPR compliance and the European AI Act, in force with progressive obligations since 2025, worsen this exposure: processing personal data on servers outside the EU requires specific guarantees that many standard contracts do not meet in operational practice.

Where local inference solves the problem at the root

Local inference with open-weight models closes the question structurally. The model runs on a company server or on private infrastructure controlled by the company itself. Semantic processing happens inside the perimeter. Data does not leave, does not transit, does not reach any external system. Protection does not depend on contractual clauses or the provider's good faith: it depends on the architecture of the system, which by construction does not transmit.

For activities that do not handle confidential information — processing public texts, supporting external communication, analysing content already stripped of sensitive references — cloud APIs remain an efficient choice. The distinction between data that can leave the perimeter and data that must not is the same principle that governs correct management of company mobile devices: it depends on knowing what to classify and how, rather than blocking everything.

Pseudonymisation, minimisation and the limits of the hybrid approach

There is an intermediate level, architecturally more complex: a system that processes documents before they reach an external model, automatically replacing sensitive references with neutral tokens or aliases before the prompt leaves the company perimeter. The transformed document reaches the cloud model; the original identifiers stay inside.

This approach is correctly called pseudonymisation, not anonymisation. The distinction is technical and legally relevant. True anonymisation implies irreversibility: the data is altered so that linking it back to the original individual or entity is impossible even with additional resources. Pseudonymisation replaces identifiers with aliases while keeping a separate mapping that allows reconstruction, which makes it reversible and, under EDPB guidelines 01/2025, still within the scope of the GDPR. True anonymisation on context-rich texts is in practice almost impossible: a contract describing a specific negotiation remains recognisable even after names and dates are removed, because the context itself is identifying.

Alongside pseudonymisation sits minimisation: transmitting to the external model only the data strictly necessary for the task, excluding everything that does not contribute to the quality of the output. Minimisation works on context selection before transmission. It is a sound and applicable principle, with an important limit: language models produce output that is more precise and useful the richer and more coherent the context provided. An overly minimised query produces generic answers. Minimisation must therefore work on selecting relevant information, not on indiscriminately reducing it: it excludes what is not needed, not what might be needed.

The hybrid approach — local pseudonymisation as an intermediate layer before sending to a cloud model — is practicable and, in certain contexts, appropriate. It requires careful design: a badly calibrated pseudonymisation system lets identifying contexts through even without explicit personal data. Its correct implementation is part of the AI architecture, not an add-on module bolted on afterwards.

The market for open models in 2026: the raw material is there

The technical availability for local inference in companies is now concrete. Until two years ago, open models suffered a significant quality gap against the best proprietary models. That gap has substantially closed.

Google's Gemma 4 took third place in the Arena AI ranking with the 31-billion-parameter variant, beating systems with up to twenty times more parameters. The compact models of the same family — E2B and E4B — run directly on smartphones, with four times the speed of the previous generation and 60% less energy use. Mistral, developed in Europe with specific attention to data sovereignty needs, offers models optimised for inference on limited resources. Meta's Llama 4 has context windows of ten million tokens, useful for processing large document corpora in a single session. Alibaba's Qwen 3 dominates on coding and structured reasoning tasks.

Competition among these labs has compressed release cycles from semesters to weeks. For the first time, choosing local inference does not mean a significant sacrifice in performance. On the infrastructure side, industry estimates reported by Agenda Digitale put the cost of a dedicated server with two GPUs between 60,000 and 100,000 euros for high-end configurations. For smaller organisations, solutions on a European private cloud offer a practical balance between control and infrastructure costs.

The architectural question that comes first

When EBM Solution designs AI systems for clients that handle confidential information — professional practices, manufacturing companies with proprietary know-how, construction or real-estate firms with sensitive data on clients and suppliers, retail businesses with structured customer archives — the first question is not which model to use. It is where the inference runs.

This choice determines the architecture of the whole system: the document processing pipeline, authentication management, data classification before it enters the AI flow, and the design of pseudonymisation layers for cases where cloud components are still necessary. The risks of AI investments for small companies are not only economic: they include exposure to vulnerabilities that emerge months after implementation, when the architecture is already consolidated and expensive to change.

The AI model market now has the technical depth to support this choice concretely. The complexity lies in integration: hardware or private cloud, model, pipeline, perimeter security, user training and internal governance of use. These are choices that affect a company's security posture for years and that, made without careful assessment, produce exactly the kind of exposure they were meant to avoid.

The same perimeter question appears on every device, and protecting company data on mobile devices is where local processing starts to matter.