I still remember the cold sweat. It was 2 AM, and I was staring at a server log at RemoteTeam. We had just pushed a new feature that used a third-party AI service to help with HR compliance. Everything looked fine in testing, but now, in production, we were seeing something… odd. The AI was flagging things that made no sense, and I had this sinking feeling that our customer data was being exposed in a way we hadn't anticipated.
We eventually figured it out—a misconfiguration in an API call, a classic rookie mistake. But that night taught me a lesson I’ll never forget: when you build on top of someone else’s AI, you’re not just inheriting their cool tech, you’re inheriting their security posture. And let me tell you, that’s not always a good thing.
People get so excited about the power of large language models that they forget to ask the hard questions. We’re all standing on the shoulders of giants like OpenAI, Anthropic, and Google, but that doesn’t mean we can afford to be naive. Their security is not your security. Not completely.
The Shared Responsibility Lie
Every cloud provider talks about a “shared responsibility model.” It’s a neat little diagram that shows what they’re responsible for (the security of the cloud) and what you’re responsible for (the security in the cloud). It’s a useful starting point, but in the world of AI, it’s a dangerous oversimplification.
When you’re just renting a virtual machine, the line is pretty clear. But when you’re sending your most sensitive customer data to a black-box API, that line gets blurry. Really blurry. You’re trusting that the platform is handling your data correctly, that it’s not being used to train their models without your consent, and that it’s being stored and transmitted securely. That’s a lot of trust to place in a vendor.
I’ve seen founders get burned by this. They assume that because they’re using a major AI platform, they’re automatically compliant with GDPR or HIPAA. That’s just not true. The platform might give you the tools to be compliant, but it’s up to you to use them correctly. And if you mess it up, it’s your company on the hook, not theirs.
Data Privacy is Your Problem
Let’s talk about data privacy. When you’re building an AI product, data is your lifeblood. It’s also your biggest liability. You have a responsibility to protect your users’ data, and that responsibility doesn’t go away just because you’re using a third-party AI service.
At one of my startups, we were building a tool that analyzed customer feedback. We wanted to use a powerful new sentiment analysis model, but we were worried about sending raw, identifiable customer feedback to a third-party API. We ended up building our own data anonymization layer that stripped out all personally identifiable information before it ever left our servers. It was a pain to build, but it was the only way we could sleep at night.
Here’s the thing: you need to be paranoid about data privacy. You need to ask your AI vendors the tough questions:
- Where is my data being stored?
- Who has access to it?
- Is it being used to train your models?
- How is it being encrypted, both in transit and at rest?
- What happens to my data when I delete it?
If they can’t give you clear, straight answers to these questions, run away. Fast.
The Black Box Problem: Model Explainability
Another huge issue is model explainability. Or the lack thereof. Many of the most powerful AI models are complete black boxes. You send them some data, they spit out an answer, and you have no idea how they got there.
This is a huge problem, especially in regulated industries like finance and healthcare. If you’re using an AI model to make decisions about people’s lives—like whether or not to approve a loan or recommend a medical treatment—you need to be able to explain how that decision was made. If you can’t, you’re opening yourself up to all sorts of legal and ethical risks.
I was an early investor in a company that was using AI to diagnose skin cancer. The model was incredibly accurate, but they couldn’t get it approved by the FDA because they couldn’t explain how it worked. They ended up having to go back to the drawing board and build a simpler, more interpretable model. It was a huge setback, but it was the only way forward.
Don’t be afraid to sacrifice a little bit of accuracy for a lot more explainability. A model that you can understand and trust is far more valuable than a black box that you can’t.
My Advice to Founders
So, what’s a founder to do? It’s a complex world out there, but it’s not impossible to navigate. Here’s my advice:
- Be a Skeptic. Don’t just take your AI vendor’s word for it. Do your own due diligence. Read their security documentation. Ask the hard questions. And if you don’t like the answers you’re getting, walk away.
- Own Your Security. Don’t assume that your AI platform has you covered. You are ultimately responsible for the security of your application and your users’ data. Build security into your product from day one.
- Think in Layers. Don’t rely on a single security control. Build a layered defense, with multiple controls at different levels of your application. That way, if one control fails, you have others to back it up.
- Invest in Expertise. If you don’t have security expertise on your team, hire it. Or bring in a consultant. This is not an area where you can afford to cut corners.
Building on top of cloud AI platforms can be a huge accelerator for your business. But it’s not a free lunch. You need to go into it with your eyes wide open, and you need to be prepared to do the hard work of securing your application and your users’ data. The future of your company may depend on it.
Frequently Asked Questions
How has this view evolved over time?
My thinking on most topics has changed significantly over the years. Early in my career, I held many conventional views that experience proved wrong. I try to update my beliefs when the evidence changes.
Do all experts agree with this view?
No, and that's fine. The best ideas in business are often contrarian. I share my perspective based on my experience and data, but I encourage you to seek out opposing viewpoints and form your own conclusions.
How can I apply this thinking to my own situation?
Start by identifying the core principle behind the opinion, not the specific example. Then ask yourself: does this principle apply to my context? If yes, test it in a small, low-risk way before going all in.
What's the most common pushback you get on this?
People often push back by citing exceptions or edge cases. And they're usually right that exceptions exist. But building a strategy around exceptions rather than patterns is a losing game for most founders.