I was watching the Samsung story break in real time. I remember the specific detail that stuck with me: it wasn't one engineer. It was multiple engineers, on separate occasions, across different teams. Each one thought they were solving a work problem. They were. They were also handing Samsung's proprietary source code to a third-party model under retention terms nobody had read.
Samsung's response was a company-wide ban on generative AI tools. Swift, decisive, and completely backwards. The data was already gone. The ban was a reaction to an absence of architecture, and banning the tools didn't build the architecture.
I spent years in U.S. Army cyber operations before my doctorate. The pattern I saw there is the same one I see in enterprise AI now: the failure almost never comes from a sophisticated attacker. It comes from a capable person using a powerful tool inside a policy vacuum. Samsung's engineers didn't breach anything. They logged in. That's the terrain we're operating in.
The Castle Is the Wrong Model
Stop thinking about AI security as a perimeter problem. The castle model assumes the threat is external: build the wall high enough and you're protected. That model has never been fully right, and for AI it's completely wrong.
Think about zoning laws instead. A city isn't secured by walls. It's governed by rules about what can go where, enforced by systems that work even when no one is watching. Residential districts don't have steel barriers. They have ordinances. Violation is visible. Accountability exists.
Your organization's AI exposure isn't coming from outside the walls. It's coming from employees with valid credentials, doing real work, inside tools that have no idea what your proprietary data is worth or where it's allowed to travel. The exposure doesn't look like an intrusion. It looks like productivity.
What the Zoning Code Actually Requires
In every security review I've run, the data classification framework exists on paper. What almost none of them have is operationalization: employees who can tell you in thirty seconds whether a specific document is confidential, restricted, or fair game for a third-party tool. That's the gap where Samsung happened. Nobody told the engineers that source code was restricted. Nobody defined what restricted even meant for an AI context. The employees filled the policy vacuum the way employees always do: with efficiency.
A real security posture has three layers, and the order is non-negotiable.
First, classification: what you're protecting, labeled in a way that travels with the data and means something to the person handling it. Not a document on the intranet. A lived taxonomy that engineers and analysts actually apply.
Second, constraint: a policy that governs which tools can touch which data categories, under what conditions, with what audit trail. This is the ordinance layer. It doesn't prohibit tools. It defines the rules of use.
Third, response: a defined protocol for when the rules get violated, because they will. Not a general incident response plan repurposed for AI. A process built specifically for data exposure through AI tools, which is a different problem with a different clock. Who assesses the exposure. Who communicates. What the vendor terms say about deletion. All of that has to exist before the exposure, or it's useless.
Before the Board Meeting Asks
The organizations I've watched navigate this well built their posture in parallel with adoption. They didn't wait for an incident to define the zoning code. Trying to rezone after the city has grown is expensive, disruptive, and usually incomplete. The companies running reactive security audits eighteen months into AI deployment are spending multiples of what a parallel build would have cost.
The forcing function is already in motion. EU AI Act compliance deadlines are rewriting what "AI policy" means for cross-jurisdictional operations. NIST's AI Risk Management Framework is the most operationally useful public document available for teams building from scratch: not light reading, but the closest thing to a zoning ordinance the industry has published.
The window to build ahead of the incident is still open. It won't be indefinitely.
Five Questions to Ask Before Your Next AI Rollout
1. Can you name every AI tool your employees are actively using today, including tools adopted individually without IT approval?
2. Does your data classification framework explicitly address what can and cannot be shared with a third-party AI model?
3. If a proprietary data exposure incident happened this week, who owns the response, and what are the first three steps?
4. Who in your organization holds accountability for AI security governance, not IT security generally, but AI specifically?
5. When your AI vendor updates their data retention and training policies, does your security team find out before or after your employees do?
MBL Partners · mblpartners.com · [email protected]