Almost all of the real value in AI for your business comes from connecting it to your own data, and almost all of the real risk comes from the same connection. Generic AI gives general answers. Wire it into your contracts, customer records and policies, and it starts doing work specific to you. Done carelessly, the same wire is how customer data ends up in a public tool and how a junior clerk gets to read the CEO’s salary.
So this post is about the connection itself: the three ways companies put data in front of an AI, the gate that makes the safe ones safe, a worked example, the traps, and what PDPL requires.
Three ways to put your data in front of an AI
In our experience every setup is one of three patterns, and only two belong in a business.
flowchart TD A(["How your data reaches the AI"]) --> B(["1. Staff paste it into a public tool"]) A --> C(["2. A private assistant reads it through a gate"]) A --> D(["3. A model trained on it, under your control"]) B --> B2(["No gate, no record, no way back"]) C --> C2(["The default for most companies"]) D --> D2(["For a few high-volume jobs"])
- Copy and paste. Someone opens a public chatbot and pastes in a customer list or a contract. It is fast, free, and how most companies use AI on their data today. No gate, no audit trail, no way to pull the data back, and under PDPL a real compliance problem. Breaches are not cheap here: across a Saudi and UAE sample, the average data breach now runs about $8.75M, the second-highest of any region in the world (IBM via The National, 2024). This is the data side of why handing the team ChatGPT is not a strategy.
- A private assistant that reads your documents. The AI holds nothing. When a user asks a question, a search layer pulls only the documents that user is allowed to see, and the model answers from those. Engineers call this retrieval. It fits most Saudi businesses because the data stays where it lives and every access can be logged.
- A model trained on your data. For a narrow, high-volume job (classifying thousands of claims a day) it can be worth teaching a model your patterns. It is the most powerful option and needs the most care: once knowledge is inside the model you cannot switch it off per user.
The second pattern is the default. The third is a deliberate upgrade for one job. The first should be banned in writing.
The gate: what “safe” actually means
Every safe setup has the same shape: data reaches the AI through a gate you control, and what should stay private never leaves the building.
flowchart LR
A(["Your documents and records"]) --> B{"Access control gate"}
B -->|Allowed for this user| C(["Private AI on your data"])
B -->|Blocked| D(["Stays private"])
C --> E(["Answers for the right people"])
C -.->|logged| F(["Audit trail"])
The gate is four decisions. Check each against any vendor proposal.
- Where the data lives. Your documents stay in your systems (SharePoint, your ERP, your own cloud tenancy) and the AI reads from them. Nothing is uploaded to a tool you do not control, and the contract says plainly that your data does not train anyone else’s model.
- Who can reach what. The AI inherits your existing permissions instead of getting its own. If the finance folder is restricted to six people, the assistant answers finance questions for those six and nobody else. Without this it will happily surface the acquisition memo to the receptionist, because it has no idea who is asking.
- What gets logged. Every question, document consulted, and answer is recorded. PDPL expects you to show how personal data was processed, and NCA ECC already expects access logging on sensitive systems. An AI with no log cannot be defended in an audit.
- What the AI must refuse. Written rules: never reveal national ID numbers, never answer salary questions, never summarise a document the user cannot open. Tested before launch, not discovered after.
A worked example: the policy and contract assistant
Say you are a 400-person contracting company. Staff ask HR and legal the same questions all day: what is the leave policy for a new hire, what does clause 14 in the Etimad framework contract mean for us, which supplier agreements expire this quarter. You hold roughly 3,000 policy and contract documents, and answering them eats, say, 25 hours a week. The numbers are made up to show the shape.
You build a private assistant using the second pattern. The documents stay in SharePoint. It reads them through your existing permissions, so a site engineer can ask about leave and safety but cannot see supplier pricing, while procurement can. Every question and source document is logged. Personal data in HR files is masked before the model sees it, so the assistant explains the leave policy without knowing anyone’s national ID or salary.
Month one, the assistant answers the routine questions and routes the rest to a person with the document attached. Those 25 hours drop to something like 8, and the 8 genuinely needed a human. When SDAIA asks what you did with employee data, the log is the answer.
What made it safe was not the model. It was the gate, the masking, and the log.
Where this goes wrong
The patterns we see in setups that are already running.
- The “just for now” upload. Someone exports the customer database and uploads it to a public tool “to test.” The test works, the file stays, and nobody knows where it is now. Personal data has left the Kingdom and Article 29 of PDPL has been breached without anyone deciding to.
- One big index with no permissions. A vendor indexes every document into one pool because the demo looks better. It also means the assistant will answer anything for anyone. If a proposal does not explain how the AI inherits your permissions, it does not.
- The vendor’s terms. “We do not train on your data” sits on a marketing page, not in the contract, or applies to the paid tier while half your staff are on the free one. Read the data-processing terms and check where the provider stores data; that decides whether you have a data residency problem before an AI one.
- Training on raw personal data. A model trained on customer records with the names still in them can regurgitate them, and you cannot delete a person from a trained model the way you delete a row. Mask first, train second.
- A policy nobody enforces. A one-page AI usage policy is essential, but with no approved tool and no blocked tool it is a document, not a control. Give staff an approved private assistant and the pasting mostly stops on its own.
PDPL: build it in from day one
None of this is new or optional. PDPL took effect on 14 September 2023, full compliance was required by 14 September 2024, and SDAIA is the regulator. If your data ever moves outside the Kingdom, Article 29 and SDAIA’s transfer rules govern that too (Morgan Lewis, 2024). An AI project is data processing like any other: it needs a lawful basis, a stated purpose, a retention rule, and an answer for the data subject who asks what you hold on them.
Treat the AI project as a PDPL exercise from the first workshop rather than sending it to legal at the end. Map which data sets the assistant will read, mark which contain personal data, decide what gets masked, and write down where the processing happens. We cover the engineering side in our practical guide to PDPL compliance; the short version is that compliance built into the design costs days, and compliance bolted on after an incident costs the project.
How to start
The reliable pattern is boring. Pick one set of documents that is valuable and not the most sensitive: policies, product manuals, supplier contracts. Measure how many hours a week people spend hunting through them today. Build a small private assistant on that set alone, with permissions inherited, personal data masked, and logging on from day one. Run it with a real team for a month and check two things: did the hours drop, and did the log show any answer that should not have been given.
If both are good, extend to the next data set. If the log shows a leak, you found it on policy documents instead of your customer database, which is the point of starting there. Done this way, you never have to choose between safe and useful.
Want AI that knows your business without putting your data at risk? SDCG connects AI to your company’s own data the safe way: private, access-controlled, and PDPL-compliant by design. We’re independent, so we build it around your business, not a product we’re quietly trying to sell. See our responsible AI and AI strategy services, or Book a free 30-minute review.