Decision guide · 8 min
Private or public AI:
how should you choose?
A simple framework for deciding use case by use case, based on data, integrations, volume and the level of control needed.
Key takeaways.
- 01
“Private” describes a level of isolation and control: by itself, it does not guarantee security.
- 02
A public service may suit low-sensitivity, exploratory uses with limited integration.
- 03
The right architecture is often hybrid: a different environment according to the workflow's risk and value.
Three architectures, rather than two camps.
A public AI service is generally used within a provider's shared environment. Hosted private AI reserves an application layer and controlled resources for your organisation. On-premise deployment installs all or part of the system within your infrastructure.
These categories do not tell the whole story. The contract, location, query retention, subprocessors, identity management and logging matter as much as the commercial label.
- Public SaaS: quick setup, outsourced operations, control dependent on the provider and contract.
- Private hosted: an isolated environment operated for you, with more configuration options and visibility.
- On-premise: maximum control over the foundation, with responsibility for operations and hardware capacity.
Six criteria are enough for an initial decision.
Start with the workflow, not the model. An assistant summarising public content has different needs from an agent connected to CRM, contracts and email.
- Sensitivity: what data enters, leaves or is generated?
- Access: must each user's document permissions be applied?
- Integration: does the system act within a business tool or simply answer a question?
- Load: how many users, concurrent requests and documents?
- Traceability: do you need to explain, audit or reproduce an answer?
- Reversibility: can you export data and logs, and change models?
A hybrid approach is often the most rational.
Applying the heaviest architecture to every use slows adoption. Conversely, letting every team choose its own tool scatters data and responsibilities. The solution is to define a few clear usage zones.
For example: experimentation with public data in an approved tool, an internal document assistant in a private workspace, and tightly constrained data processing on dedicated or on-site infrastructure.
DECISION POINTThe right level of control is the one that fits the actual workflow, rather than the one that looks most reassuring in a presentation.
Questions to resolve before signing.
This one-page checklist helps you compare two offers without getting lost in model names.
- 01
Is the data used to train or improve the provider's model?
✓ - 02
Where are queries, attachments, indexes and backups stored?
✓ - 03
What retention period applies, and who can change it?
✓ - 04
Are enterprise authentication and roles supported?
✓ - 05
Are source permissions respected during document retrieval?
✓ - 06
Are actions, answers and configuration changes logged?
✓ - 07
Which subprocessors are involved and in which geographical areas?
✓ - 08
What can be exported at the end of the contract?
✓ - 09
What is the cost at actual load, beyond the per-user price?
✓ - 10
Who resolves an incident, and within what timeframe?
✓
Check and explore further.
We prioritise official texts and reference frameworks. This guide's recommendations are our practical interpretation of those sources, to adapt to your context.
- 01ANSSI — Security of generative AI systems ↗
Architecture and information-system integration recommendations.
- 02CNIL — Practical AI guidance ↗
Points to watch concerning personal data and rights.
- 03NIST — AI Risk Management Framework ↗
Voluntary framework for governing, mapping, measuring and managing risks.