Most Sri Lankan executives I talk to fall into one of two camps.
Camp 1: "PDPA? We'll deal with it when it's enforced." Camp 2: "We use Microsoft/OpenAI — surely they handle compliance?"
Both camps are wrong. And both are going to have a very expensive problem in the coming months.
Let me explain why — without the legal jargon.
What PDPA Actually Says
Sri Lanka's Personal Data Protection Act (No. 9 of 2022) was passed by Parliament and signed into law. The gazette bringing its key provisions into force is at the Government Printer. Once published, full enforcement begins 12 months later.
Here's what the Act requires, stripped to its core:
1. You are responsible for personal data — even if a third party processes it.
This is the part most people miss. If you send customer data to Microsoft's servers in the US for Copilot to process, you are still the data controller. Microsoft is just the processor. If something goes wrong — a breach, unauthorized access, a cross-border transfer without proper safeguards — the liability lands on you, not on Microsoft.
Read that again.
Your company. Your fine. Your board meeting.
2. Cross-border data transfers need legal justification.
PDPA restricts transferring personal data outside Sri Lanka unless the receiving country has adequate data protection, or you have specific legal mechanisms in place (like standard contractual clauses or explicit consent).
Here's the problem: most cloud AI tools — Microsoft Copilot, OpenAI's ChatGPT, Google's Gemini — process data on servers in the United States, Europe, or other jurisdictions. Every time your employee pastes a customer record, a financial report, or patient data into these tools, that data leaves Sri Lanka.
Is the US an "adequate" jurisdiction under PDPA? That's a question the regulator hasn't fully answered yet. But here's what we know: the US does not have a federal data protection law equivalent to PDPA or GDPR. US companies can be compelled to share data with government agencies under laws like the CLOUD Act.
That's not a theoretical risk. That's a structural one.
3. You need audit trails and accountability.
PDPA requires organizations to demonstrate compliance — not just claim it. That means you need to know:
- What personal data was processed?
- Where did it go?
- Who accessed it?
- Was consent obtained?
- How long was it retained?
Now ask yourself: if your marketing team is using ChatGPT to draft customer emails, and your finance team is using Copilot to analyze client financials — do you have an audit trail for any of that?
Can you prove to a regulator what data was sent where?
If the answer is no, you have a compliance gap. And PDPA doesn't accept "we didn't know" as a defense.
The AI Tools Problem Nobody's Talking About
Here's what's actually happening inside Sri Lankan enterprises right now:
Scenario 1: The Bank
A mid-level analyst at a Sri Lankan bank uses Microsoft Copilot to summarize customer transaction data. The data includes names, account numbers, and transaction patterns. It's processed on Microsoft's Azure servers — likely in a US or Singapore data center.
The bank's compliance officer has no visibility into this. There's no audit log. No consent was obtained from the customers whose data was processed. The analyst was just trying to be more productive.
Under PDPA, this is a data protection violation. The bank — not Microsoft, not the analyst — is liable.
Scenario 2: The Insurance Company
An actuarial team uses ChatGPT to draft policy language and analyze claims data. The claims data includes policyholder names, medical histories, and settlement amounts.
ChatGPT's training data policies are complex. Even with enterprise agreements, the data travels to OpenAI's servers. The insurance company cannot guarantee that the data won't be used for model training, retained beyond the session, or accessed by unauthorized parties.
Under PDPA, the insurance company must be able to demonstrate that personal data was processed lawfully, with appropriate safeguards. Can they?
Scenario 3: The Exporter
An apparel manufacturer uses AI to generate compliance documentation for EU buyers. The documents include worker data — names, wages, working hours — required for supply chain transparency.
The AI tool processes this data on foreign servers. The EU buyer's audit team asks: "Where is this data processed? Can you guarantee it hasn't been shared?"
The manufacturer can't answer. The deal stalls.
These aren't hypothetical scenarios. These are conversations I've had with real Sri Lankan executives in the past few months. The pattern is the same every time:
"We adopted AI to be more productive. We didn't realize we were creating a compliance liability."
The Three Mistakes Sri Lankan Companies Are Making
Mistake 1: Assuming the vendor handles compliance.
Microsoft, OpenAI, and Google all offer enterprise agreements with data processing terms. But these agreements are designed for GDPR — European regulation. They don't automatically satisfy Sri Lanka's PDPA, which has its own requirements for cross-border transfers, consent, and local accountability.
Your vendor's compliance framework is not your compliance framework. You need your own.
Mistake 2: No internal AI usage policy.
Most Sri Lankan enterprises have no policy governing how employees use AI tools. There's no approved list of tools, no data classification guidelines, no training on what can and can't be entered into a cloud AI system.
This means every employee is making their own judgment call about data security. Some are pasting sensitive customer data into ChatGPT. Some aren't. Nobody knows who's doing what.
Mistake 3: Waiting for enforcement to start preparing.
PDPA's enforcement timeline is clear: the gazette is being published, and full enforcement follows 12 months later. That clock is ticking.
Enterprise compliance projects — especially ones involving AI infrastructure — don't happen overnight. Vendor evaluation, procurement, deployment, testing, training — you need 3-6 months minimum.
If you start when enforcement begins, you're already late.
What "Compliant AI" Actually Looks Like
Let me describe what a PDPA-compliant AI setup looks like in practice. Not in theory. In practice.
- Data stays in Sri Lanka. The AI model runs on infrastructure that's physically located in Sri Lanka, or on your own premises. Customer data never leaves the country. Cross-border transfer risk? Eliminated.
- You control the model. You choose which AI model to use — and you can switch. You're not locked into one vendor's pricing, one vendor's policies, or one vendor's geopolitical risks. If Microsoft raises prices or restricts access, you have alternatives.
- Every interaction is logged. Every query, every response, every piece of data processed — it's all logged. Audit-ready. If a regulator asks "what data was processed and when?", you have the answer.
- Role-based access. Not everyone in your organization should have access to the same data. A PDPA-compliant system lets you control who sees what — so the marketing intern can't accidentally access customer financial records through an AI query.
- Consent and purpose limitation. The system respects the purpose for which data was collected. Customer data collected for insurance claims processing isn't used for marketing analysis. Purpose limitation is a core PDPA principle, and your AI system needs to enforce it.
The Cost Argument (Because Someone Will Ask)
"But on-premise AI is expensive."
Is it?
Microsoft Copilot costs around US$360 per user per year — and your data goes to Microsoft's servers. You have no model flexibility. And you're exposed on PDPA.
An on-premise or locally-hosted sovereign AI platform — one that keeps data in Sri Lanka, offers multi-model flexibility, and includes audit logging — can cost significantly less. We've seen enterprises save 50–70% compared to Copilot while gaining compliance.
The question isn't "can we afford sovereign AI?"
The question is "can we afford the PDPA liability of not having it?"
What To Do This Week
I'm not going to tell you to overhaul your entire IT infrastructure by Friday. That's not realistic.
But here are three things you can do this week:
- Audit your AI usage. Send a simple survey to your department heads: "What AI tools are you using? What data are you entering into them?" You'll be surprised by the answers.
- Talk to your legal team. Ask them one question: "Are our current AI tools PDPA-compliant?" If they hesitate, you have your answer.
- Evaluate your options. There are alternatives to sending your data overseas. Sovereign AI platforms — built for Sri Lankan compliance requirements — exist. Some of us have been building them for over a year, specifically for this moment.
The Bottom Line
PDPA isn't a suggestion. It's law. The enforcement timeline is set. The gazette is being published.
Every Sri Lankan enterprise that handles personal data — banks, insurers, exporters, telecoms, government agencies — needs to answer one question:
"Where does our data go when we use AI?"
If the answer is "overseas," you have work to do.
The good news: the tools to solve this problem exist. They're built here. They keep your data here. And they cost less than what you're probably paying now.
The window to prepare is open. It won't stay open forever.
Want to know if your current AI setup is PDPA-compliant? Take our five-minute PDPA AI risk check and find out where you stand.
