Can we put our documents into AI? What Israeli privacy law actually requires

The question, asked plainly

Somewhere around the second or third meeting, someone in the room, usually the CFO or the general counsel, asks the question that actually decides the deal: can we put our contracts, our client files, our HR records into this thing, or are we handing a vendor something we're not allowed to hand anyone. It's a fair question, and it deserves a real answer, not a slide that says enterprise-grade security and moves on.

This post is that answer. Not legal advice, and not a substitute for a lawyer reading your own contracts, but a straight account of what Israeli law actually asks of you, what an enterprise AI agreement actually changes, and what stays on your desk no matter which vendor you pick.

What Israeli law actually asks

Israel's Privacy Protection Law treats a company that holds personal data, an employee's file or a customer's record, as the party responsible for what happens to that data, even after it leaves the building. Handing information to an outside processor, an AI vendor included, doesn't hand off the responsibility with it. The organization that collected the data stays accountable for how it's protected and what it's used for.

In practice, a few things stay true no matter which AI tool you use. You need to know, and be able to say, what personal data goes where. You need some form of written commitment from anyone processing that data on your behalf, an AI vendor is a processor like any other, spelling out what they can and can't do with it. And the purpose has to match: data collected to run payroll doesn't get repurposed to train a model just because the tool touching it happens to also do that.

If any of the people whose data you handle are in the EU, customers, job applicants, employees of an EU subsidiary, GDPR sits alongside Israeli law, not instead of it. GDPR reaches further than most people expect. It can apply because of who the data is about, not where your company is registered. That's a second set of obligations to check, not a replacement for the first.

None of this is exotic. It's the same discipline you already apply to a payroll vendor or an outsourced call center. AI tools don't get a pass because they're new.

What "doesn't train on your data" actually means, and what it doesn't

Most major AI vendors' enterprise or API tiers will tell you, correctly, that they don't use your inputs to train their models. That's a real commitment. It's also narrower than it sounds.

It means the specific promise written into that contract: your prompts and files aren't fed back into model training. It does not mean the vendor has no access to your data, that nothing is logged or retained for any period, that it's automatically compliant with Israeli or EU law, or that the free version of the same product makes the same promise. A consumer account and a business or API account, even on the exact same product, are frequently two different agreements sitting behind one login screen.

This is a contractual boundary, not a technical one. The model doesn't know or care which account is typing into it. What changes is the paper behind the account: retention windows, who can access logs, whether a data processing agreement is signed, what happens when someone asks for deletion. None of that is visible from the chat window. It's visible in the agreement your organization actually signed, or didn't. Read your own vendor's current terms before relying on any of this. The details differ by vendor and change over time.

The mistake most teams make

Here's the one we see most often, and it's the one that actually creates risk: treating "our documents" as a single bucket. It isn't. Three different things live in that folder, and each carries a different obligation.

Personal data is anything that identifies a real person: a customer's name and phone number, an employee's salary, a candidate's résumé. This is what privacy law is actually about, and it's the category that needs the most care before it goes anywhere near a consumer-tier tool.

Commercially sensitive data is different: a pricing strategy, an unreleased product plan, a client list, a board deck. It usually doesn't identify a person, so privacy law isn't the main concern, but a leak here can cost a company a deal or a competitive edge. It's often covered by an NDA or a confidentiality clause that has nothing to do with privacy regulation.

Public data is what you've already published: a blog post, a press release, your own marketing copy. There's almost nothing to protect here, and most of the anxiety in the room evaporates once people see how small the genuinely risky pile actually is.

Here's why the distinction matters. A team that treats all three the same makes one of two mistakes. It locks down everything, including the harmless material, and the AI project quietly dies from friction. Or it protects nothing, because nobody wants to be the one slowing things down. A team that sorts documents into these three piles can move fast on two of them and be careful about the one that actually needs it.

A policy you can actually use

Six lines, written down, are worth more than a page nobody reads.

1. If a document names a real person outside your own team, a customer, a patient, a candidate, strip the identifying details before it goes into a personal AI account, or use your organization's approved business account instead.
2. Anything under an NDA or marked confidential goes through the approved business or API account only, never a personal or free-tier login.
3. Before uploading, ask one question: would this document need to sit in the NDA drawer? If yes, it needs the business agreement, not a personal chat window.
4. Use one approved account per team, not five personal logins, so one real agreement actually covers all of it.
5. If you can't find a straight answer in the vendor's terms about what happens to a file after you delete it, ask before you upload, not after.
6. When someone isn't sure, the answer is to ask whoever owns the compliance call in your organization, not to guess and move fast.

Where this fits into the workshop

We built a full session around exactly this question inside Safe AI at Work: where the real line sits, how permission tiers work day to day, and what needs to be written down before a team's use of AI widens. If your organization is close to rolling this out and wants the six-line version turned into something specific to your own documents, that's worth talking through before the rollout, not after. Get in touch about a workshop.

FAQ

Can we legally upload client contracts to an AI tool?

That depends on what's in them and which account you're using, not on the tool's brand name. A contract with a client's personal details needs the same care you'd give any processor handling that data: an appropriate agreement in place, and a business-tier account rather than a personal login. Check your own agreement with the vendor, and if there's real doubt, ask someone qualified to look at your specific contracts.

Is Claude's enterprise tier GDPR compliant?

An enterprise agreement can be built to support GDPR compliance, but compliance isn't something a product ships with on its own. It depends on the actual terms in your agreement, the data processing addendum you've signed, and how your organization uses the tool. Read the current agreement rather than assuming the tier name settles the question.

Do we need a signed data processing agreement with our AI vendor?

If the vendor processes personal data on your behalf, which is what happens the moment personal data goes into the tool, some form of written agreement covering that processing is generally expected under Israeli and EU privacy frameworks. Whether your current vendor relationship has one, and whether it covers what you actually need, is worth confirming directly rather than assuming.

What's the real risk of using a personal ChatGPT or Claude account for work?

The tool working well isn't the risk. The risk is that a personal account usually carries different terms, and often less clarity about retention and access, than a business account on the same product. For anything that isn't already public, that gap is exactly where the six-line policy above earns its place.