Selecting the “right AI tool” is no longer the real problem for companies. The real problem is this: your employees are already using AI - but not the AI you approved. While leadership is still discussing governance, legal is still checking GDPR clauses, and IT is still comparing vendors, people in marketing, HR, finance and engineering are pasting company data into free, consumer-grade chatbots. That phenomenon has a name: Shadow AI. And until you give people a safe, governed alternative, Shadow AI will keep winning.

This text lays out a concrete, four-path framework for deploying large language models (LLMs) in a way that is secure, compliant and realistic for a modern enterprise. It’s based on one simple observation: not every AI option is equally safe, and not every business needs the most expensive, self-hosted setup. The right choice depends on what you’re trying to do (use AI vs. build with AI), how sensitive your data is, and what level of control you actually need.

We will walk through four models:

1. Consumer Gemini on a personal account
   
   
   

2. Gemini inside Google Workspace
   
   
   

3. Programmatic access via API (Vertex AI / Gemini API)
   
   
   

4. Self-hosted / open-source LLMs on your own infrastructure
   
   
   

…and we’ll connect them to governance, GDPR, TCO and actual business scenarios.

Why this matters right now: Shadow AI is a today problem

Generative AI entered enterprises incredibly fast - faster than most technologies before it - because it solved a real, everyday pain: drafting, summarizing, explaining, refactoring. That’s exactly why employees reached for the easiest tools: free, public chatbots.

And that’s where the breach starts.

• Marketing uploads customer lists to “get insights”.
  
  

• Developers paste proprietary code to “find bugs”.
  
  

• HR uploads performance reviews to “summarize feedback”.
  
  

All of that often goes into tools that:

• are tied to private accounts, not the company domain,
  
  

• are governed by consumer privacy policies, not enterprise DPAs,
  
  

• can use the submitted data to improve their models,
  
  

• and can expose the data to human reviewers.
  
  

So, while management is discussing “AI risks”, the real leak is already happening - from inside. That’s why the very first business move is not “build an AI platform”, but stop the uncontrolled channel and replace it with an approved one.

The 4-path framework (enterprise view)

The core insight from your original text is very important: the risk is not in AI as such - the risk is in the deployment model. The same vendor can offer:

• a consumer product (risky),
  
  

• a corporate product (safe),
  
  

• an API (very strong privacy),
  
  

• or a self-hosted option (maximum control, maximum cost).
  
  

So let’s go through them, in order of how much control you have - and how much it will cost you to get it.

1. Consumer Gemini on a personal account - why this is a business no-go

This is the tool most employees will reach for first, because it’s:

• free,
  
  

• in the browser,
  
  

• no procurement,
  
  

• no admin,
  
  

• no friction.
  
  

But it’s also the worst possible option for company data.

Purpose and scope. This service is designed for individuals, not organizations. It’s governed by broad consumer privacy policies that say, in essence: we collect information to provide, maintain, and improve our services, and to develop new ones. That is a perfectly valid model for a consumer product - but it’s a fundamental mismatch for a company that wants to keep its own data out of someone else’s training pipeline.

Human review. The documentation is very explicit: conversations may be reviewed by human raters to improve quality. Even if the data is de-identified, from a corporate standpoint you have already broken confidentiality: an external party, outside your DPA, has seen the content.

Retention. Even if the user turns off activity history, the provider may retain data temporarily (e.g. 72h) for abuse detection and safety. Some reviewed data may be stored longer. From a GDPR perspective, this is where things start to break:

• you can’t fully enforce purpose limitation,
  
  

• you can’t fully guarantee erasure on request,
  
  

• you can’t transparently prove where the data actually lives now.
  
  

Lack of enterprise controls. There is no:

• admin console,
  
  

• central audit trail,
  
  

• DLP integration,
  
  

• mapping to company roles/OU,
  
  

• visibility for the security team.
  
  

So even if the employee did something wrong, you, as the controller, don’t even see it.

Conclusion for model 1: this is not a “cheaper business option”. It’s a liability. The right policy for this path is: block, ban, explain. Block access from corporate devices and networks, ban usage for business data, and explain why - including that the exact same vendor offers a corporate, governed alternative.

2. Gemini in Google Workspace - the fastest safe path for most companies

This is the path your source text calls, in practice, “the one 90% of you should be on”.

Contractual shift. When you move from a consumer account to Gemini inside Google Workspace, the business model flips. You are no longer the product - the service is. Your prompts, emails, Docs, Sheets are treated as Customer Data under your existing enterprise agreement and Google’s Cloud Data Processing Addendum. In legal terms: Google is the processor, you are the controller. That’s the opposite of the consumer model.

Key guarantees (the ones leaders always ask about):

• “Your data is not reviewed by humans.”
  
  

• “Your data is not used to train models.”
  
  

• “Your data is processed within your domain and according to your policies.”
  
  

This is what makes this path compatible with GDPR: you can point to a contract, to a DPA, to a processor role, to defined purposes.

Inherited security. The second huge advantage is that you don’t have to build new security just for AI. Gemini inherits what you already have in Workspace:

• your DLP rules (e.g. credit cards, national IDs),
  
  

• your file permissions (if a user can’t see the CEO’s salary sheet, Gemini won’t summarize it for them),
  
  

• your audit logs (the same console, same SIEM destination),
  
  

• your Client-Side Encryption setup (if you encrypt client-side, Google can’t read, so Gemini can’t process),
  
  

• your IRM / sharing rules.
  
  

So, instead of inventing a new AI governance stack, you piggyback on the one your admins already know.

TCO and rollout. This is a simple, per-seat subscription. No GPUs to buy, no MLOps to hire. You turn it on, test a few policies, roll it out org-wide. That’s why it’s the fastest way to kill Shadow AI: you give employees a tool that is actually better than the unofficial one - but safe.

Conclusion for model 2: if your goal is “let our people use AI at work - to write, summarize, analyze, create - and do it safely”, this is the answer.

3. Programmatic access via API (Vertex AI / Gemini API) - when you need to build, not just use

Not every company stops at “use AI”. Many want to put AI into their own products, automate parts of customer service, build internal copilots, or create data-analysis pipelines. For that, they need APIs, not just “AI in Docs”.

This path has a different security profile - in some ways even stronger than Workspace.

Zero Data Retention. The contract for generative AI in Google Cloud is very clear: data you send to the API is used only to generate the response and is not stored to train models. There is a small, technical exception: the platform may cache inputs for up to 24 hours to improve latency - but you can turn this off at project level. For banks, healthcare or public sector, this is critical.

But… shared responsibility. This is where many teams fail. The provider secures:

• the model,
  
  

• the API endpoint,
  
  

• the data center,
  
  

• the network.
  
  

You must secure:

• your application code,
  
  

• your authentication and authorization (IAM),
  
  

• your input sanitization (to prevent prompt injection),
  
  

• your encryption (before sending sensitive payloads),
  
  

• your logging and monitoring,
  
  

• your rate limiting and abuse detection.
  
  

In other words: a secured API does not make your app secure. If your app leaks data in logs, or lets users query documents they shouldn’t see, the fact that the LLM didn’t store the data doesn’t help you.

Cost pattern. APIs are great because they are cheap to start and scale with usage. But at very high volumes, you may need to start thinking about optimization, batching, or even model distillation. Still, for most mid-sized companies, the variable cost is acceptable compared to the CapEx of self-hosting.

Conclusion for model 3: choose this if you have a competent engineering team and you’re building AI into your products or internal tools. Accept the shared-responsibility model and document it.

4. Self-hosted / open-source LLMs - maximum control, maximum burden

This is the path everyone likes to talk about… and very few should actually take.

Why people want it: because it promises 100% data sovereignty. The model runs on your hardware, in your network, in your VPC, maybe even air-gapped. Data never leaves. For defense, intelligence, certain finance use cases, or R&D on highly sensitive IP - that’s exactly what’s needed.

But the costs are deferred and heavy.
Your original text calls it “a system with deferred costs” - and that’s exactly right.

You need to account for:

• CapEx: racks of high-end GPUs (A100/H100 class or equivalents), high-performance networking, storage, sometimes even building out a proper server room. That alone can run into hundreds of thousands.
  
  

• OpEx: power, cooling, space, maintenance, monitoring.
  
  

• People: this is the real cost. You cannot ask your current IT admin to “also run the LLM”. You need MLOps, SRE, people who can tune, quantize, monitor and upgrade models, and keep them available. These are some of the most expensive profiles on the market.
  
  

And after all that… the model you run locally will very often be weaker than what you can access via API for a fraction of the price. Plus, you own uptime, backups, scaling, DR.

When it makes sense: when your data cannot legally or operationally leave your environment, and you have both the budget and the talent to run it long-term. Then, and only then, self-hosting is a rational risk-mitigation strategy - not a cost-saving one.

A two-question decision tree

You don’t actually need a 30-page policy to decide. Your original framework collapses into two very simple questions:

1. What are we doing with AI?
   
   

   • If we are using AI for employee productivity → Path 2 (Workspace).
     
     

   • If we are building AI features/products → Path 3 (API).
     
     

2. Do we have extreme, non-negotiable data-sovereignty requirements?
   
   

   • If yes → consider Path 4 (self-hosting).
     
     

   • If no → stay with 2 or 3.
     
     

And Path 1 (consumer)?
You don’t use it. You block it, ban it, and explain why.

Governance: the part everyone wants to skip (but can’t)

Technology alone won’t keep you safe. All four models still need an internal AI governance layer. At minimum:

• Acceptable Use Policy (1 page).
  “We use Workspace AI for internal work.”
  “We block consumer AI on company devices.”
  “No ‘Confidential’ or ‘Client’ data goes into AI without approval.”
  “Engineering can use API for approved projects only.”
  
  
  

• Data classification + DLP.
  So that even if someone tries to paste sensitive data, the policy catches it.
  
  
  

• RBAC / IAM.
  AI should only “see” what the user is entitled to see.
  
  
  

• Audit and monitoring.
  So security can see usage patterns, anomalies, and potential misuse.
  
  
  

• Model/prompt registry.
  A central list of what’s approved - so people don’t reinvent unsafe patterns.
  
  
  

This is what makes AI repeatably safe, not just “we turned it on”.

Final takeaway

If you look at the four models side by side, the message is actually very clear:

• Consumer AI is convenient but unsafe → block.
  
  
  

• Workspace AI is the fastest way to give everyone safe AI → enable.
  
  
  

• API AI is the way to embed AI into your products → use, but secure your part.
  
  
  

• Self-hosted AI is for the few with extreme requirements → choose only if you really must.
  
  
  

The real risk is to spend months debating Path 4 while the entire company keeps leaking data through Path 1. The real win is speed: give people a governed, powerful tool now, wrap it in governance, and shut down the shadow channels. That’s how you get the benefits of AI without paying for them in reputation, compliance fines, or lost IP.