Most mainstream AI tools are built on top of large datasets and are constantly being improved using user input: the prompts, text, code, and files people paste into them.
Depending on the provider and how they’re configured, that data may:
- Be retained for a period of time
- Be used to improve models
- Be accessible internally to some staff
- Be exposed if the provider has a security incident
Now combine that with how people are actually working today:
- Teams paste PII, client details, legal content, and code into AI tools for help.
- AI systems become a concentration point for data from many organizations at once.
Instead of each company being its own isolated point of failure, we’re creating large, attractive targets where a single compromise could expose data from many businesses and individuals at the same time.
The Other Risk: Over-Reliance and Blind Trust
The second issue is reliance.
AI is quietly becoming part of people’s daily workflow: writing emails, generating code, summarizing documents, drafting policies, and more. When that happens:
- Sensitive information gets pasted “just this once” (then again, and again).
- People start trusting outputs without checking where the information came from or whether it should be shared.
- Security teams often aren’t looped in at all.
The danger isn’t just, “What if the model leaks something?” but also, “What if we’re feeding it information that should never have left our environment in the first place?”
Two Directions for Safer AI Use
So what can we do about it? A couple of approaches come to mind.
1. Treat AI like any other high-risk data system
If you’re using cloud-based AI tools:
- Push for strong data retention and privacy controls (no long-term storage of prompts by default).
- Limit what staff can paste into AI: no PII, credentials, or sensitive client data unless there are clear rules and technical controls to match.
- Treat AI systems like other critical third-party services: vendor risk reviews, access controls, logs, and monitoring.
At a minimum, organizations should be asking:
“What happens to the data we put into this model, and who can see it?”
2. Use local models when data really matters
For businesses that care deeply about where their code, designs, or client information end up, local models are often a better fit.
The basic idea is:
- Run the AI model on infrastructure you control (on-prem or in a private cloud).
- Keep prompts and outputs inside your own network and logging systems.
- Apply your existing security controls: access controls, backups, encryption, etc.
For example, you might:
- Stand up a small Linux server or VM dedicated to running one or two curated models
- Restrict access to only your team
- Use it for code review, documentation help, or internal Q&A—without sending that data to a third-party AI provider
There’s still security work to do (patching, monitoring, hardening), but the risk moves back into your court, instead of handing everything over to a black box you don’t control.
I think one of the next big waves in AI will be making local models easier to deploy and secure, so businesses don’t need huge hardware or a full ML team just to get value from them.
Final Thoughts
AI is a powerful tool, and I use it myself. The danger isn’t the model sitting on a server somewhere—it’s how we handle data, how much we trust the outputs, and how little we sometimes think about where everything is going.
In the rush to stay innovative, a lot of organizations are quietly creating single points of failure: centralized AI systems full of sensitive data, connected to many parts of the business, with limited visibility into how that data is stored or used.
I’m currently working on security strategies for using local models in realistic environments—balancing ease of access with strong security controls.
If you’re interested in talking through how AI fits into your security picture—cloud models, local models, or a mix of both—you can email me at ryan@cenegi.com or reach out at https://cenegi.com/contact.
