“I honestly don’t know what we’re allowed to put into AI.” I hear this a lot. The moment the conversation turns to where the data goes, executives get uneasy. I get it. For a while, “servers overseas sound risky” was my own reason for being nervous, without me ever examining what that actually meant.
This is not an article about AI being dangerous, and it’s not one about you worrying too much. It’s about breaking your unease into parts you can actually judge, and turning that into a rule your team can use.
“It’s made by a domestic vendor, so it’s safe” is not a standard
When AI and cloud come up, the reasons people give for feeling safe or unsafe cluster around origin and location. “A domestic vendor is safe.” “Overseas servers are risky.” “On-premise is secure.” And when I mention that we run our development out of Vietnam, some people say that makes them vaguely uneasy too. (Offshore development in Southeast Asia is common enough in Japan that this reaction is familiar to me.)
What strikes me is how this standard drifts over time. Companies that said “we can’t have our data off-premise” a few years ago now work in Google Docs without a second thought. Nothing about the architecture changed. They just got used to it.
My own “overseas servers sound risky” was the same. I understood no more than before. The unease simply wore off. Which means the “safety” we feel from origin and location isn’t a risk assessment at all. It’s familiarity.
The data says something similar. In the 2025 white paper from Japan’s Ministry of Internal Affairs and Communications, based on a FY2024 survey, 49.7% of Japanese companies had a defined policy for using generative AI, up from 42.7% the year before. Still only half. What the same white paper lists among the concerns companies raised: not knowing how to use it effectively, security risks such as internal information leaking, and running costs. My read: for the other half, what blocks progress sits earlier than security. It’s the absence of a yardstick for making the call.
The yardstick is already inside your company
So what do you judge against? Before inventing a new standard, I’d look at what you already do. Our email, our contracts, our client correspondence: all of it has been sitting in Google Workspace for years. Our confidential data was on someone else’s servers long before AI showed up.
There’s a reason we accept that without losing sleep. Google states publicly that Workspace data is not used to train generative AI models outside your domain without permission, and Workspace’s generative AI (Gemini) holds third-party certifications including ISO/IEC 42001. So we have already drawn a line — “with this level of contractual guarantee, we’re willing to hand over our confidential data” — and we live by it.
That gives you a standard you can actually use. If a new AI tool can offer the same level of guarantee, in contract, as the cloud you already trust, you can treat it the same way. Starting from “is AI safe?” gets you nowhere. Comparing against a line you have already accepted does. I don’t think you go out and find the yardstick. I think you find it by taking stock of what you already run on.
Two axes: is it online, and what kind of data is it?
With that line in place, the next step is sorting. I use two axes and nothing more. First, is the AI online — does your input leave for someone else’s server? Second, what class of data are you about to put in? I call them the send line and the data grade.
An example of the first. In February 2025, Japan’s data protection authority, the Personal Information Protection Commission, published a notice about the Chinese AI service DeepSeek: data including personal information collected through use is stored on servers in China, and Chinese law applies to it. The part that matters here is not stopping at “because it’s Chinese.”
Data you put into an online AI enters the legal jurisdiction of whoever runs that service. The structure is identical for US services. It looks like a question of origin. It’s really a question of whether the data leaves your building.
The same DeepSeek case shows the structure cleanly. Because the model itself is published openly, Amazon and Microsoft run their own hosted versions of it (Microsoft in January 2025, AWS in March 2025). Data you send to those does not travel to servers in China. A “Chinese, therefore risky” test cannot tell those two apart. Origin is not what’s doing the work here. What matters is where the service runs, and who is responsible for it.
There’s a fair objection here: “If we just use the enterprise plans from Microsoft, Google, or OpenAI, don’t we skip this sorting entirely?” There is a real core to choosing by vendor. Which jurisdiction your data falls under is a genuine risk factor, and the DeepSeek notice is exactly that. But that fits inside the two axes as “contract and data class.”
Even on an enterprise plan, the moment it goes online it has left your building. Which data you may send stays a separate question from the contract. Origin works fine as one input to a risk assessment. Where it stops working is as a source of comfort. I’ve written separately about why an offshore team still earns its place once AI writes the code.
Your first rule only needs three lines
The data grade doesn’t need fine-grained classes on day one. Here is where we actually draw the line. Two items.
- Real client data (database contents, end-user personal information) goes into no AI. Ever.
- Credentials (IDs, passwords, API keys) never go in, and AI never operates them either.
Add “public information has no restriction” and you have three lines. Three hard lines should make day-to-day calls a lot easier for your team. If you want the wider picture for distributed teams, I covered that in the piece on building a hybrid work security framework. What remains is the grey zone — how far to go with your own source code and internal documents — and you widen that with conditions attached, such as limiting it to business tools with an opt-out from training. Every company’s situation differs, so I wouldn’t try to cover everything in one pass.
It’s worth knowing how far that conditional path can go. Enterprise and API contracts from ChatGPT and Claude do not use your input for training. Beyond that, some providers will sign a zero data retention agreement, where nothing is kept once the request is processed. At that point you are fairly close to the standard of the cloud you already trust.
One case shows how much that contract difference matters. In the copyright case The New York Times brought against OpenAI, a US federal court ordered in May 2025 that ChatGPT output logs be preserved, including chats users had deleted. Conversations people believed were gone stayed alive as potential evidence. The forward-looking part of that duty was lifted in the autumn of 2025. But in January 2026, a judge affirmed an order to produce 20 million de-identified conversation logs from what had already been preserved.
Here’s the part that matters: enterprise contracts and customers with zero data retention agreements were carved out of the preservation order. Data that was never stored cannot be preserved, even by a court. Which contract you were using decided how you were protected when things got real.
To be clear about scope: what the contract level decides is how far you can widen the grey zone. The three hard lines do not move, no matter how strong the contract. Client data and credentials stay out, zero data retention or not. The yardstick from earlier is something you use inside those lines.
I should admit that we hadn’t written any of this down either. I’ve been telling clients that having rules matters, while our own boundaries lived only in my head. Before writing this article, I started by interviewing our own engineers. If a software company that works with AI every day was in that state, being behind here is normal. I figure starting today is enough.
“Rules go stale anyway” — true. That’s why you review them monthly
Rules you write today are outdated in a month. I hear that, and the pace of change is genuinely brutal (so brutal that keeping up with AI can quietly become the job itself, which I wrote about separately). Plenty of companies conclude that a sharp person making judgment calls in the moment beats maintaining a document.
They go stale. That part is completely true. My conclusion runs the other way: because they go stale, a rule is not something you write. It’s something you take stock of every month. Once a month, check whether new tools have appeared and whether anyone hit a case they weren’t sure about, then share the updated version.
No one can promise zero incidents. What you can have is a standard that’s still alive this month when someone needs to look something up. That is the actual substance of having rules.
A sharp person’s in-the-moment judgment is fast while that person is around. It just can’t stop a new hire from pasting a client list into ChatGPT on the day they’re out.
Over-restricting fails too — build freedom inside a frame
There’s a trap in the other direction: assuming that tighter rules always mean more safety. In practice, the harder you swing toward “nothing outside the approved tool list,” the more your team loses any chance to touch new tools at all. It happens most in companies with the strongest controls. That said, a blanket ban is sometimes the right call.
Right after a breach, or in a heavily regulated industry, stopping everything and resetting can be correct. But that’s an emergency measure with an end date and conditions attached. Make it the standing default and you lose more than you protect.
So the shape to aim for is freedom inside a frame. The hard lines (client data, credentials) don’t move. Inside them, trying new tools is encouraged rather than tolerated.
The point of drawing a line is to make it obvious where it’s safe to experiment. Don’t let it become a tool for taking freedom away — that’s the one thing we decided not to compromise on when we started.
What to do tomorrow
- If your reason for feeling safe or unsafe is “origin” or “location,” pause on it — that may be familiarity talking
- Check the guarantee level of the cloud you already trust with confidential data, and use that as your yardstick
- Draw three hard lines (real client data / credentials / public information). Widen the grey zone with conditions, such as business tools with a training opt-out
- Put a monthly review on the calendar — that part, not the writing, is the substance
Frequently asked questions
Our staff may already be putting internal information into ChatGPT. What should we do first?
Before issuing a ban, find out what is actually happening. Ask who uses which AI tools and what they put in, with no blame attached. Bans push usage underground, and losing visibility is the bigger risk. Once you know the real picture, sharing the three hard lines is the fastest next step.
Is there a safety difference between free and paid (business) AI plans?
Yes. With most services, free consumer plans default to using your input for training, while business plans and APIs default to a contract where it is not used. The same AI under a different contract changes which classes of data you can put in. Ending personal-account use for work is the first practical step of any rule.
How often should the rules be reviewed?
We designed ours around a monthly cycle and started running it this month. AI tools move fast enough that a quarterly cadence drifts too far from reality. A review does not mean rewriting everything: check whether new tools appeared and whether anyone hit an unclear case, then update only the delta.
Want to draw these lines for your own team?
Tell me what kinds of data you handle and which tools you use, and we can sketch your three hard lines and a monthly review rhythm in about half an hour.
Book 30 minutes → Message us instead →
Shogo Harada原田 祥吾
CEO · Linnoedge Inc. · LinkedIn↗
Operating IT offshore development and overseas expansion support businesses across two bases: Tokyo and Vietnam. A leader who believes in “Systems over Spirit,” structuring cross-border businesses that often tend to be opaque. Committed to providing “reproducible quality” to organizations and clients rather than relying solely on individual skills.