Choosing an AI deployment posture. Residency, retention and isolation are three different questions.
The safest posture is the one whose risks you can actually run.
Organizations often choose how to deploy a model by instinct. "It is personal data, so we must self-host." Or: "The provider is large, so the API is fine." Both skip the analysis. A deployment posture is a bundle of separate choices: who processes the data, where, under which retention terms, over which network path, and operated by whom. Each choice moves a specific risk. None removes risk altogether.
The useful question is not which posture is safest in general. It is which bundle leaves you with risks you can see, measure and control with the people and contracts you actually have.
Five patterns, five control boundaries.
From least to most operated by you: a standard API under the provider's standard terms; an enterprise API with a data processing agreement and administrative controls; private connectivity, where the model service is reached over a private link from your cloud; a dedicated environment, with compute reserved for you or a managed model deployed into your own cloud account; and a self-hosted model, an open-weight model on infrastructure you run.
Deployment postures · Control boundary
Five patterns, five different boundaries.
Scroll the diagram sideways to see all of it.
Read the diagram as text
- Standard API: your application calls a shared provider service over the public internet with TLS, under standard terms. You control only the application.
- Enterprise API: same path and shared service, under negotiated or enterprise terms that can cover retention, processing location and audit features.
- Private connectivity: the call travels over a private link from your cloud, so the network path is inside your boundary. The model compute is still shared.
- Dedicated environment: a private link to compute reserved for you, operated by the provider or deployed into your own cloud account.
- Self-hosted model: model servers on your network, operated by your team, including patching, scaling, monitoring and updates.
Residency, retention, isolation: ask each one separately.
Residency is where data is stored and where it is processed. The two can differ. A service may keep stored data in the EU while running inference in another region, or offer EU inference only for some models. Logs, abuse-monitoring copies and support access can each have their own location. Ask the question per model and per feature, and keep the dated answer.
Retention is what the provider keeps, for how long, who can access it, and whether it may be used to train models. It is set by contract, it differs between consumer, standard and enterprise terms, and it changes. Reduced or zero retention options exist for some services, often with eligibility conditions. Your own application logs are part of the answer too: a perfectly configured provider does not help if your logs keep every prompt indefinitely.
Network isolation is the path the traffic takes. A private endpoint keeps it off the public internet and lets your network policy apply. It says nothing about who else shares the compute, or what is retained at the other end. A posture can score well on one of these questions and poorly on another, which is why a single "secure or not" label is not useful.
Self-hosting does not shrink the work. It moves it to you.
| Task | Enterprise API | Self-hosted model |
|---|---|---|
| Patching and hardening the model service | Provider | Your team |
| Capacity, scaling, hardware supply | Provider | Your team |
| Model updates and re-evaluation | Provider updates; you re-evaluate | Your team, both |
| Monitoring and incident response | Shared | Your team, around the clock if the process is |
| Access control and application logging | Your team | Your team |
| Contract, data processing agreement, sub-processor review | Your team | Mostly removed for the model; still needed for hosting |
Two rows never move: access control and your own logging remain yours in every posture. Most incidents in practice come from those rows, not from the model provider.
Choose criterion by criterion, per data flow.
- Data class and human consequence. What is the most sensitive data in the flow, and what happens to a person if the output is wrong?
- Contractual and policy restrictions. What your contracts, sector rules and internal policies actually say about processors and locations, read rather than assumed.
- Required model capability. Test candidate models on your own evaluation set. A smaller open model that fails the task is not a safe choice; it is an unusable one.
- Operating capacity, measured honestly. Who patches the server on a Friday night, and how quickly? If the answer is nobody, that is the answer.
- Cost at expected volume. Per-call pricing against fixed capacity, including the people who run it.
- Exit. How you would switch. Prompts, evaluation sets and a thin abstraction layer keep that option open whatever you choose first.
The Deployment Explorer applies the first, second and fourth criteria as a screening exercise.
When self-hosting is not the safest realistic choice.
Illustrative
Consider a 40-person firm with no infrastructure team that wants staff to query internal HR procedures, some of which refer to individual cases. Wary of sending personal data to a provider, it rents a GPU server and has a contractor install an open-weight model. The contractor leaves. Six months later the server runs an unpatched operating system, an administration port is open to the internet, application logs hold every question in plain text, and nobody monitors any of it.
The alternative was an enterprise API under a data processing agreement, with retention controls, single sign-on, processing in a region the firm accepts, and inputs minimized so that case details are not sent at all. That option leaves residual risks too, but they are contractual, documented and visible. The self-hosted option left technical risks that no one was in a position to see.
Self-hosting is the right answer for some organizations: those with restricted data that cannot leave their control, and the team to run infrastructure properly. It is not a default for personal data.
One synthetic SME, three postures.
Illustrative
A fictional 60-person engineering consultancy wants AI help with three kinds of material: office documents (proposals, templates, internal procedures); personal information (CVs and staff records used to assemble bid teams); and restricted records (a client's technical drawings under a non-disclosure agreement that forbids third-party processing). It has an IT manager and a managed-service partner, but no infrastructure team.
| Material | Class and constraint | Posture screened | Key controls |
|---|---|---|---|
| Proposals, templates, procedures | Internal. No restriction beyond due diligence. | Enterprise API, or standard API if its terms exclude training on inputs and set acceptable retention. | Single sign-on, access by team, no training on inputs, retention reviewed. |
| CVs and staff records | Personal. Data processing agreement required; EU processing preferred by policy. | Enterprise API with EU inference confirmed for the chosen model, or private connectivity in the existing cloud tenancy. | Minimization: send skills and project history, not addresses or dates of birth. Impact screening with the data protection lead. |
| Client drawings under NDA | Restricted. Contract forbids third-party processing. | None until the contractual question is settled with the client. If processing is later allowed only on controlled infrastructure: a tenant-deployed or self-hosted model run by the partner. | Excluded from scope by default. Written client consent before any change. |
One organization, three postures. The decision is made per data flow, not per company. The most useful outcome here is the third row: recognizing that the right deployment for the drawings is, for now, none at all.
What this guide does not do.
- It does not give legal advice. Whether an obligation under data protection law or the EU AI Act applies to your use is for your counsel or data protection officer to determine.
- Provider terms, regional availability and retention options change. Anything in a contract must be checked at the date you sign it.
- The four data classes are a design heuristic. They do not map one-to-one onto legal categories.
- Costs are not quantified because they vary widely with volume, model and region.
- CNILIntelligence artificielle : le guide. The French data protection authority's guidance on personal data in AI systems, including minimization and data protection impact assessment.
- NISTAI Risk Management Framework, AI RMF 1.0, released 26 January 2023, and the Generative AI Profile, NIST AI 600-1, released 26 July 2024.
- European CommissionAI Act: regulatory framework for AI. Consulted 22 October 2026 for the application timeline.
Engineer with a doctorate in IT and systems from Sorbonne University. Leads the Applied AI practice. Full profile.