Which of your business data is safe to feed an AI tool?
The previous lesson covered where AI helps: when its inputs are text and data you already own. But that opens a question just as important as usefulness: which of your data is safe to put into an external tool, and which could expose you to legal liability? This lesson gives you a practical way to classify your data before it touches any tool.
The rule: what leaves your device leaves your control
When you paste text into an external AI tool, that text leaves your device for a server you neither own nor govern. The safe rule is to treat every input as if it might be stored and read. The right question isn't "is the tool trustworthy?" but "am I comfortable with this specific text leaving my company's walls?"
Don't ask about the tool's intentions — ask about the sensitivity of what you hand it. You are responsible for the data, not it.
Sort your data into three tiers
Before entering any data, place it in one of three buckets. This simple classification prevents most mistakes before they happen:
| Tier | Examples | Verdict |
|---|---|---|
| Public | Marketing copy, published prices, public product descriptions | Safe to use |
| Internal | Draft processes, reports with no personal data | With caution — strip any identifying detail |
| Sensitive & personal | Customer names, phone numbers, IDs, financial and health records | Not into an external tool without a legal basis and safeguards |
Personal data is governed by law
In Saudi Arabia, personal data is governed by the Personal Data Protection Law (PDPL), supervised by the Saudi Data and AI Authority (SDAIA). The law governs how personal data is collected, processed and shared with third parties, including transfer outside the Kingdom. Sharing your customers' data with an external tool is "processing" and "sharing" in the legal sense, and it carries requirements that don't disappear because the intermediary is an AI tool.
A concrete example: summarising customer complaints
A clinic wants AI to summarise its weekly patient complaints to find the recurring problem. The idea passes the usefulness test from the previous lesson: repetitive, its input is text you hold, and an employee reviews it. But the complaint text contains the patient's name, file number and phone — sensitive health data.
The fix doesn't kill the idea, it adjusts it: strip the identity before entering the text. Replace the name with "patient," delete the number and phone. The resulting summary — repeated complaints about long waits at the second branch — is just as useful without carrying anyone's identity. The benefit is kept; the risk is gone.
Four practical steps that reduce the risk
- Anonymise before you send. Remove names, numbers and identifiers, or replace them with neutral placeholders.
- Prefer tools with a clear data policy that states whether they use your inputs to train their models.
- Never paste secrets. Passwords, system keys, terms under a confidentiality clause — these don't leave, whatever the benefit.
- Keep a human boundary. A sensitive decision is never built on a tool's output alone, nor does it leave the business on the tool's authority without review.
Quick checklist
- You classified the data before entering it: public, internal or sensitive?
- You stripped any personal data of its identity before sending.
- You confirmed a lawful basis before processing personal data with an external tool.
- No secret, key or confidential contract left the building.
- You checked the tool's policy: does it train on your inputs?
This lesson is introductory and does not replace the Personal Data Protection Law or advice from a specialist for your specific case.