What “public LLM” usually means
A public large language model product typically offers a shared multi-tenant service: many customers, standard terms, and a product roadmap you do not control. Some vendors offer enterprise tiers with stronger contractual promises, regional options, and admin controls; others remain consumer-grade with aggressive retention or training language.
The security question is not primarily “is the model smart?” It is “what happens to my prompts and documents under ordinary use, under support access, and under a future change of terms?” Public tools can be appropriate for public content. They become problematic when they are the default for internal work without classification.
What “private AI” can mean (and what it does not)
Private is an overloaded word. In procurement conversations it can mean any of the following:
- A dedicated organisational deployment with isolated storage and customer-managed access
- A private cloud or VPC-style instance in a chosen region, still vendor-operated
- An on-premise or air-gapped deployment for the highest sensitivity and offline requirements
- A vendor-hosted model that contractually excludes training on your data and limits retention, even if multi-tenant
Private does not automatically mean “perfectly secure.” A poorly patched on-premise box can be worse than a well-run European private cloud. Public does not automatically mean “unsafe for every task.” Match the deployment model to data classification, IT maturity, and the cost of getting it wrong.
Security properties to compare side by side
When you evaluate options, build a simple matrix rather than relying on brand reputation:
- Tenancy — shared vs dedicated infrastructure for storage and inference
- Training use — whether prompts can improve the provider’s general models
- Retention — defaults for chats, files, embeddings, and logs
- Admin visibility — can your organisation see who used the system and revoke access quickly?
- Integration surface — browser only, API, SSO, network restrictions
- Exit — export and deletion at contract end
Write answers from vendor documentation and contracts, not from sales slides alone.
Decision criteria for Catholic organisations
- Data classes in scope — public communications versus HR, donor care, or pastoral systems
- Residency — EU processing requirements from policy, insurers, or law
- Integration needs — API into existing tools versus stand-alone chat for staff
- Auditability — logs for who asked what, when, with privacy-appropriate limits
- Operational burden — who patches, monitors, and supports the system day to day
- Exit plan — can you export or delete organisational content cleanly?
For hosting topology trade-offs in more detail, continue with on-premise AI for Catholic institutions. For communication hygiene, see faith-based data privacy.
A practical recommendation pattern
Many institutions land on a hybrid: approved organisational AI for everyday internal work under contract and regional controls; stricter environments or bans for high-confidentiality content; and a short allow-list so staff are not forced into shadow IT. Publish that pattern. Ambiguity is what drives people back to personal free accounts.
Enterprise tiers are not automatically private
Paying more can buy SSO, admin consoles, and better contractual language without changing the fundamental multi-tenant boundary. Always ask whether inference and storage are dedicated, what the retention defaults are, and whether support can read content. Price is a weak proxy for isolation.
Conversely, a smaller vendor with clear EU hosting and no training on customer data may fit better than a famous consumer brand with an enterprise sticker. Read the architecture, not only the logo. Require answers in writing and store them with the procurement file.
Shadow AI is a private-versus-public problem too
If official tools are blocked without an approved alternative, staff will use personal accounts on public models. That outcome is worse than a governed organisational deployment. Pair restrictions with usable approved options and training. Measure whether unofficial tools disappear after you launch an official path — if they do not, fix usability before adding more bans.
Testing before trust
Before putting internal data into any system, test with synthetic or public content. Verify export, deletion, admin revocation, and logging behaviour. Trust should follow evidence, not a marketing claim that the model is “enterprise ready.”
Questions to bring to every vendor call
Where is inference executed? Where are prompts stored? Who can read them? Is customer content used for training? What is deleted on contract end? Can we force EU-only processing? How are API keys rotated? What happens during a subprocessor change? Write the answers into your procurement file the same day — memory is not a control.
If a vendor cannot answer clearly, treat that as a signal. Ambiguity at sales time rarely becomes clarity after go-live.