Navigating AI Compliance Across Multiple Jurisdictions: Building Compliance Before Laws Pass

By Patrick Dasoberi, CISA, CDPSE, MSc IT | Former CTO, CarePoint | Founder, AI Cybersecurity & Compliance Hub

Most organizations wait for laws to pass before addressing compliance. They watch regulatory developments, maybe track bills in parliament, and then—when legislation is enacted—they scramble to retrofit compliance into existing systems.

This reactive approach is expensive, disruptive, and risky.

As CTO of CarePoint, managing healthcare systems across Ghana, Nigeria, Kenya, and Egypt, I took a different approach: building compliance infrastructure ahead of legislative enactment.

While Nigeria's NDPR, Egypt's PDPL, and Kenya's DPA were all under parliamentary review during my tenure, we worked with legal counsel to interpret proposed requirements and built compliance into our systems proactively.

Ghana's Data Protection Act (2012) was the only fully enacted law we operated under. For the other three countries, we were preparing for regulations before they became legally binding.
This forward-thinking approach meant that when these laws eventually passed, we were ready—while competitors scrambled to retrofit compliance.

Here's what I learned: Regulatory compliance for AI isn't just about following enacted laws. It's about understanding regulatory intent, anticipating requirements, and building systems that respect fundamental rights even before legal obligations crystallise.

Traditional Software vs. AI Compliance

I hold the CISA certification with a focus on compliance and control frameworks. I understand traditional IT compliance. But AI introduces compliance challenges that existing regulations weren't designed to address.

AI System Compliance:

When we deployed AI models across our healthcare platforms, regulators in multiple countries asked: "Can you explain how the AI makes decisions?"

For traditional software, I could point to the code and logic flow. For AI models—especially complex neural networks—explainability wasn't that simple. We had to develop new approaches to demonstrating compliance with transparency requirements that weren't written with AI in mind.

This is why AI regulatory compliance requires specialised knowledge beyond traditional IT compliance expertise.

Operating Under Different Regulatory 

Maturity Levels

Managing compliance across four countries meant navigating vastly different regulatory environments:

Nigeria, Kenya, Egypt (Proposed/Developing Regulations):

This created a unique challenge: How do you build compliant AI systems when half your operating jurisdictions have established laws and the other half have proposed-but-not-enacted regulations?

When Regulatory Requirements Directly Conflict
One of the most significant challenges I faced was reconciling fundamentally different approaches to cross-border data transfers:
Nigeria & Ghana: Flexible Approach

Egypt: Strict Restrictions (Proposed PDPL)

The Proactive Approach
While most organizations waited for laws to pass, we built compliance infrastructure proactively for Nigeria, Egypt, and Kenya.

Why This Approach:

A) Avoid Expensive Retrofits

1. 1. Compliance built into system design is cheaper than post-deployment compliance bolting
2. 2. Architectural changes after deployment are exponentially more expensive
3. 3. Proactive compliance prevents technical debt

B) Reduce Deployment Risk

1. 1. When laws pass, we're ready to operate legally immediately
2. 2. No scramble to achieve compliance under regulatory deadlines
3. 3. Competitive advantage over unprepared competitors

C) Demonstrate Good Faith

1. 1. Regulators notice organisations preparing proactively
2. 2.  Shows commitment to compliance beyond legal minimums
3. 3. Builds trust with regulatory authorities

D) Future-Proof Systems

1. 1. Even if specific requirements change, compliance-by-design principles remain valuable
2. 2. Easier to adapt to the final enacted requirements from a strong foundation
3. 3. Privacy and security improvements benefit systems regardless of regulatory outcomes

How We Did It:
Step 1: Track Legislative Developments

1. 1. Monitored parliamentary proceedings in Nigeria, Kenya, Egypt
2. 2. Reviewed draft legislation and proposed amendments
3. 3. Tracked international regulatory trends (GDPR, EU AI Act)
4. 4. Participated in industry working groups discussing regulatory implications

Step 2: Interpret Proposed Requirements with Legal Counsel

1. 1. The legal team analyzed draft legislation
2. 2. Identified likely compliance obligations even if specific language might change
3. 3. Assessed risk of different interpretations
4. 4. Made conservative assumptions where requirements were ambiguous

Step 3: Design Compliance Into Architecture

1. 1. Built data isolation capabilities before they were legally required
2. 2. Implemented consent management systems anticipating stricter consent requirements
3. 3. Developed documentation frameworks for demonstrating compliance
4. 4. Created audit trails and logging infrastructure

Step 4: Conduct Internal Audits

1. 1. Assessed systems against proposed regulatory requirements
2. 2. Identified gaps between the current state and anticipated obligations
3. 3. Prioritised compliance improvements
4. 4. Documented compliance readiness

Step 5: Iterate as Legislation Evolved

1. 1. Adjusted compliance infrastructure as proposed laws were amended
2. 2. Refined interpretations as regulatory guidance emerged
3. 3. Maintained flexibility to adapt to final enacted requirements

For Nigeria, where the NDPR was under development during my tenure, we conducted structured internal audits aligned with proposed NDPR requirements.
Focus Areas:

1. Vendor Compliance

• Which vendors processed Nigerian patient data?
• Did vendor contracts include appropriate data protection clauses?
• How did vendors demonstrate their own compliance capabilities?
• What happened to data when vendor relationships ended?

Real Challenge:
Many AI vendors—especially international vendors—didn't understand Nigerian regulatory requirements or proposed NDPR provisions. We had to educate vendors about anticipated obligations and, in some cases, reject vendors who couldn't demonstrate readiness for Nigerian compliance.
2. Access Control

• Who could access Nigerian patient data?
• Were access permissions based on legitimate business need?
• How were privileged access accounts managed?
• What audit trails documented access to sensitive data?

3. Cross-Border Transfers

• What Nigerian data left Nigeria?
• For what purposes?
• With what safeguards?
• Under what legal mechanisms?

The proposed NDPR had provisions about cross-border transfers. We proactively implemented transfer impact assessments and documentation even before they were legally required.
4. Data Minimisation

• Were we collecting only data actually needed for specified purposes?
• How long were we retaining Nigerian patient data?
• What processes governed data deletion?

The Value of Proactive Internal Audits:
These internal audits—conducted before NDPR enactment—significantly reduced our exposure to external regulatory scrutiny after the law passed. We had already identified and addressed compliance gaps.
Organisations that waited for enactment faced:

• Regulatory audits shortly after laws are passed
• Limited time to remediate identified issues
• Higher risk of enforcement actions
• Reputational damage from publicised compliance failures

Ministry of Communications & Digitalisation, Ghana & UN Global Pulse

March–May 2022
One of the most significant recognitions of my AI compliance and governance expertise was being selected as a national and international expert resource person for the development of

Ghana's Ethical AI Framework and

Data Exchanges Roadmap.
Selection Process:
This wasn't open participation. I was specifically invited based on my operational experience managing AI systems in healthcare and my demonstrated expertise at the intersection of AI technology, security, and regulatory compliance.

My Contributions:
1. Expert Testimony at High-Level Workshop
I participated in an invitation-only workshop involving:

1. Government agency representatives
2. UN Global Pulse technical experts
3. Academic researchers
4. Private sector technology leaders

The workshop focused on:

• Ethical considerations for AI deployment in Ghana
• Data governance frameworks for responsible AI
• Mechanisms for data sharing that respect privacy and sovereignty
• Ghana's readiness for safe AI adoption

My role was providing:

• Practical insights from operating AI healthcare systems
• Technical expertise on AI capabilities and limitations
• Compliance perspectives from managing multi-jurisdictional regulatory requirements
• Real-world examples of AI governance challenges

2. Expert Interview and Strategic Document Review
Before the workshop, I participated in:

• Dedicated expert interview with framework development team
• Pre-workshop analysis of confidential strategic documents
• Technical review of proposed framework components

This preparatory work helped shape the workshop agenda and focus discussions on areas where Ghana needed the strongest guidance.

3. Critical Terminology Shift: "Data Markets" → "Data Exchanges"
One of my most impactful contributions was guiding the terminology shift from "data markets" to "data exchanges."
Why This Mattered:
"Data Markets" Implied:

• Commercial transactions as primary model
• Monetisation of personal data
• Market-driven data flows
• Private sector profits from public data

"Data Exchanges" Better Represented:

• Non-commercial data sharing models
• Social and humanitarian purposes
• Controlled, ethical data sharing
• Public benefit focus

Ghana's Intent:
The government wasn't trying to create commercial data markets. They wanted frameworks for responsible data sharing that served public good—healthcare research, agricultural development, and educational improvement—while protecting individual rights and national sovereignty.
The "data markets" framing didn't represent this intent and could have led to unintended consequences.

Impact of the Shift:
My input directly influenced the conceptual foundations of Ghana's ethical AI and data governance efforts. The framework now:

• Emphasises responsible data stewardship over data commodification
• Aligns with Ghana's development priorities
• Balances innovation with protection of individual and collective rights
• Positions Ghana as a leader in ethical AI governance in Africa

What This Demonstrates:
This appointment demonstrates credibility as an AI regulatory and governance expert with influence at both national and international levels. It's one thing to manage compliance within a company. It's another to shape national AI governance frameworks.a 

This experience directly informs how I approach AI regulatory compliance—not just as technical implementation of legal requirements, but as participation in ongoing societal conversations about how AI should be governed.

The Regulatory Requirement:

Most data protection laws require transparency about automated decision-making. Data subjects have rights to understand how decisions affecting them are made.

The AI Challenge:

For complex AI models—especially deep neural networks—explaining specific decisions isn't straightforward. The model itself is a black box processing millions of parameters.
How We Addressed It:
1. Layered Explanations

High-level explanation: "The AI analyzes patient symptoms, medical history, and clinical indicators to assess disease risk."
Model-level explanation: "The model was trained on 50,000 patient cases and uses pattern recognition across 200 clinical features."
Instance-level explanation: "For this specific patient, the elevated risk score is primarily driven by [top 5 contributing factors]."

1. 1. What data was the model trained on
2. 2. What the model is designed to predict
3. 3. Known limitations and biases
4. 4. Performance metrics across different populations
5. 5. Validation methodology

• 1. AI provides recommendations, not final decisions
• 2. Clinical experts review and approve AI outputs
• 3. Patients interact with human clinicians who can explain the reasoning
• 4. Clear communication that AI assists but doesn't replace human judgment

The Lesson:
Perfect explainability isn't always achievable with current AI technology. But you can still meet transparency requirements through documentation, layered explanations, and appropriate human oversight.

The Regulatory Requirement:
Data protection laws (GDPR, Ghana DPA, proposed NDPR, proposed Kenya DPA) grant data subjects the right to erasure—the "right to be forgotten."
The AI Challenge:
Once patient data is used to train an AI model, the model has "learned" from that data. The data itself might be deleted from databases, but the learned patterns remain in model weights.

Can you truly erase someone's data from a trained model?
How We Addressed It:
1. Data Minimization During Training

• Don't train on more data than necessary
• Use aggregated or de-identified data where possible
• Document exactly what patient-level data contributed to each model

2. Model Retraining Protocols

• When erasure requests are received, document the data subject
• If the individual's data materially contributed to model training, flag the model
• For high-stakes models, consider retraining without the individual's data
• For lower-stakes models, document the limitation and assess ongoing model validity

3. Honest Communication with Regulators

• Acknowledge that perfect erasure from trained models is technically complex
• Demonstrate good faith efforts (retraining when appropriate)
• Document processes and technical limitations
• Prioritize transparency over claiming capabilities we don't have

3. Honest Communication with Regulators

• Acknowledge that perfect erasure from trained models is technically complex
• Demonstrate good faith efforts (retraining when appropriate)
• Document processes and technical limitations
• Prioritize transparency over claiming capabilities we don't have

The Lesson:
This remains an unsolved challenge in AI compliance. Regulators are still developing guidance. The key is demonstrating good faith effort, technical understanding, and honest communication about limitations.

The Regulatory Requirement:

Data protection laws require that data be collected for specified, explicit, and legitimate purposes. Using data for new purposes requires new legal basis.

The AI Challenge:
Is using patient data to improve AI models a "compatible purpose" with the original healthcare purpose, or is it a new purpose requiring new consent?
Real Scenario:

1. 1. Original purpose: "Process your health data to provide you with clinical care."
2. 2. AI model improvement: "Use your health data (along with thousands of other patients) to improve diagnostic accuracy for future patients."

Is that the same purpose or a different purpose?

1. 1. Don't assume original healthcare consent covers model training
   2. Include explicit consent provisions: "Your anonymised health data may be used to improve AI diagnostic models."
   3. Allow patients to opt out of model training while still receiving care
   4. Document consent separately for model training purposes

1. 1. Remove direct identifiers before using data for training
2. 2. Assess re-identification risks
3. 3. Apply anonymization techniques where appropriate
4. 4. Document de-identification methodology

a) Clearly document the purpose of each data processing activity
b) Distinguish between:

1. 1. Individual patient care (original purpose)
2. 2. Operational analytics (possibly compatible purpose)
3. 3. Model training/improvement (potentially new purpose)
4. 4. Research (typically requires separate consent)

The Lesson:
When in doubt about purpose compatibility, obtain explicit consent. Regulatory authorities and courts are still developing guidance on AI model training as a purpose. Conservative interpretation protects both patients and organisations.

The Regulatory Requirement:
Some jurisdictions require:

• Registration of automated decision-making systems
• Data Protection Impact Assessments (DPIAs) for high-risk processing
• Human oversight for certain automated decisions

Kenya's Proposed Provisions:
The Kenya DPA (before my CTO tenure ended) had explicit requirements for automated decision-making. Organizations using automated systems for decisions significantly affecting data subjects needed to:

• Register those systems with the Data Protection Commissioner
• Conduct impact assessments
• Implement safeguards including human review

How We Addressed It:
1. System Inventory

• Documented all AI systems across our platforms
• Classified by level of automated decision-making:

                 a) Fully automated with no human review
                 b) AI-assisted, with human approval required
                 c) Human decision with AI providing information only

2. Risk Classification

• Assessed each system for impact on data subjects
• High-risk: Diagnostic recommendations, treatment suggestions
• Medium-risk: Appointment scheduling, resource allocation
• Low-risk: General health information, wellness tips

3. Impact Assessments

• Conducted DPIAs for high-risk AI systems
  Documented:

     a) What data is processed
     b) How AI makes decisions
     c) Risks to data subjects
     d) Safeguards implemented
     e) Human oversight mechanisms

4. Registration Preparation

• Prepared documentation for registering AI systems with regulatory authorities
• Even in jurisdictions where registration wasn't yet required, we had documentation ready
• This preparation meant quick compliance when requirements were enacted

The Lesson: Proactive impact assessments serve multiple purposes:

• Regulatory compliance
• Risk identification and mitigation
• Stakeholder communication
• Documentation for audits and inspections

Don't wait for regulatory requirements—conduct impact assessments for high-risk AI systems as a matter of good governance.

Mistake 1: Initially Underestimating Documentation Requirements

What Happened: Early in my CTO tenure, I focused heavily on technical compliance—building the right security controls, implementing proper access management, and ensuring data isolation.

But I underestimated the importance of documentation.
Regulators don't just want you to be compliant—they want you to demonstrate and document compliance.
The Gap:

• 1. We had strong technical controls, but limited documentation of why we made specific design choices
• 2. We conducted internal reviews but didn't formally document them as audits
• 3. We had processes, but hadn't written them down as policies

When the Egypt inspection happened:

We scrambled to create documentation that should have existed from day one.
The Fix:Implemented a comprehensive documentation framework:

1. 1. Policies: Written policies for data protection, AI governance, vendor management
2. 2. Procedures: Step-by-step procedures for key compliance activities
3. 3. Records: Data processing records, consent logs, access logs
4. 4. Assessments: Documented DPIAs, risk assessments, vendor reviews
5. 5. Decisions: Document key compliance decisions and rationale

The Lesson:
In compliance, if it's not documented, it didn't happen. Build documentation discipline from day one, not after regulatory inquiry.

Mistake 2: Vendor Compliance Assumptions
What Happened:
We engaged AI vendors who made strong compliance claims:

1. 1. "Fully GDPR compliant"
2. 2. "Meets all healthcare data protection requirements"
3. 3. "Enterprise-grade security and privacy"

I initially took these claims at face value, especially from well-known vendors with impressive client lists.

The Problem:
When we conducted detailed vendor assessments for Nigerian NDPR preparation:

1. 1. Some vendors had never heard of Nigerian data protection requirements

• 2. "GDPR compliant" didn't mean they understood African regulatory frameworks
• 3. Some couldn't support data residency requirements
• 4. Some had data processing practices incompatible with the proposed Nigerian requirements

Real Incident:
One AI vendor processed data through servers in multiple countries without clear documentation of data flows. When asked about compliance with Egypt's anticipated data residency requirements, they had no mechanism to ensure Egyptian data stayed in Egypt.

We had to terminate the relationship and rebuild functionality with a compliant infrastructure.

The Fix: Implemented a rigorous vendor assessment process:

1. 1. Don't accept compliance claims without evidence
2. 2. Require documentation: certifications, audit reports, compliance attestations
3. 3. Test claims: Ask specific questions about regulatory requirements in YOUR jurisdictions
4. 4. Include compliance obligations in contracts: Explicit data residency, processing restrictions, audit rights
5. 5. Conduct periodic vendor audits: Verify ongoing compliance

The Lesson: Vendor compliance is your compliance. You can't outsource compliance responsibility even if you outsource technical operations. Assess vendors thoroughly before engagement and monitor them continuously.

Pre-Deployment Compliance Checklist
After managing compliance across four jurisdictions, I developed a systematic checklist used before any AI system deployment:

Effective AI compliance requires cross-functional collaboration:

Executive Leadership:

• Strategic compliance decisions
• Resource allocation
• Risk acceptance
• Stakeholder communication

Key Principle: No single function owns AI compliance. It requires collaboration across technical, legal, clinical, and business functions.

The Challenge
Managing compliance across four jurisdictions meant tracking regulatory developments in multiple countries simultaneously:

• Legislative amendments
• New regulations
• Regulatory guidance updates
• Enforcement actions and precedents
• International developments influencing local regulation

1. Direct Regulatory Monitoring

- Subscribed to official updates from:

• Ghana Data Protection Commission
• Nigeria's National Information Technology Development Agency
• Kenya Data Protection Commissioner
• Egyptian data protection authorities

- Monitored parliamentary proceedings for legislative changes
-Reviewed proposed bills and amendments

2. Legal Counsel Network

• In-house legal counsel tracked developments
• Local legal advisors in each country provided jurisdiction-specific updates
• Regular legal briefings on regulatory changes
• Legal counsel flagged significant developments requiring action

3. Industry Associations

• Participated in healthcare technology associations
• Attended regulatory compliance working groups
• Shared intelligence with peer organizations
• Industry associations often had direct engagement with regulators

4. International Developments

• Tracked GDPR developments (influenced African laws)
• Monitored EU AI Act progression
• Reviewed international AI governance frameworks
• Adapted international best practices to local context

5. Regulatory Relationship Building

• Maintained relationships with regulatory authorities
• Participated in consultations and public comment periods
• Attended regulatory workshops and conferences
• Direct engagement provided early insight into regulatory thinking

The System:

• Weekly: Review regulatory news and updates
• Monthly: Legal team briefing on significant developments
• Quarterly: Comprehensive compliance review assessing impact of regulatory changes
• Annually: External compliance assessment considering regulatory evolution

For Organizations New to AI Compliance

Start by clearly identifying:

• Which jurisdictions you operate in
• Which regulations apply to your AI systems
• What stage of regulatory maturity each jurisdiction is in (enacted law vs. proposed regulation)
• Which regulations are most stringent (your baseline)

Don't assume:

• General data protection laws fully address AI
• GDPR compliance equals compliance everywhere
• Vendor compliance means you're compliant

Document:

• What AI systems you have or plan to deploy
• What data each system processes
• What decisions or recommendations each system makes
• Who is affected by each system
• Where each system operates (geographic scope)

Classification:

• High-risk: Systems making significant decisions about individuals (healthcare diagnoses, credit decisions, employment)
• Medium-risk: Systems processing sensitive data or affecting user experience materially
• Low-risk: Systems with minimal impact on individuals

For each AI system, assess:

• Current compliance state
• Applicable regulatory requirements
• Gaps between the current state and requirements
• Resources needed to close gaps
• Timeline for remediation

Prioritize:

• High-risk systems first
• Jurisdictions with enacted laws before proposed regulations
• Quick wins (easy fixes with high compliance impact)

Build foundational compliance infrastructure:
Policies:

• AI governance policy
• Data protection policy
• Automated decision-making policy
• Vendor management policy

Processes:

• AI system approval process
• Data Protection Impact Assessment process
• Consent management process
• Data subject rights fulfillment process

Documentation:

• Data processing records
• Model documentation templates
• Compliance assessment templates
• Audit documentation standards

Technical controls:

• Data minimisation
• Anonymisation/pseudonymization
• Access controls
• Encryption
• Audit logging

Organisational controls:

• Training and awareness
• Defined responsibilities
• Approval workflows
• Compliance monitoring

Ongoing compliance activities:

• Regulatory monitoring
• Periodic compliance reviews
• Internal audits
• External assessments
• Continuous improvement

Don't try to do everything at once. Build systematically, starting with highest-risk systems and highest-priority requirements.

• Risk assessment methodology
• Control frameworks (though need AI-specific additions)
• Documentation discipline
• Audit and monitoring approaches
• Security controls (encryption, access management, etc.)

• AI-specific regulatory requirements (automated decision-making, explainability, model transparency)
• Technical challenges unique to AI (data deletion from models, purpose limitation for model training)
• Rapidly evolving regulatory landscape
• Need for deeper collaboration with legal function

• Learn AI fundamentals (Pillar 1: AI Cybersecurity Fundamentals)
• Understand AI-specific risks (Pillar 2: AI Risk Management)
• Master AI regulatory requirements (this pillar)
• Integrate AI compliance into existing security and compliance programs

• Regulatory interpretation for AI
• Impact assessment for AI systems
• AI vendor compliance evaluation
• Cross-functional collaboration (technical, legal, clinical)

• AI-specific regulatory requirements (automated decision-making, explainability, model transparency)
• Technical challenges unique to AI (data deletion from models, purpose limitation for model training)
• Rapidly evolving regulatory landscape
• Need for deeper collaboration with legal function

• Learn AI fundamentals (Pillar 1: AI Cybersecurity Fundamentals)
• Understand AI-specific risks (Pillar 2: AI Risk Management)
• Master AI regulatory requirements (this pillar)
• Integrate AI compliance into existing security and compliance programs

If you're coming from traditional compliance or privacy:

What Transfers:

• - Regulatory analysis skills
• - Documentation and record-keeping
• - Data subject rights processes
• - Vendor assessment
• - Audit and enforcement response

Recommended Path:

1. - Build technical literacy (Pillar 1: AI Cybersecurity Fundamentals)
2. - Understand data privacy implications (Pillar 4: Data Privacy & AI)
3. - Master AI-specific compliance requirements (this pillar)
4. - Learn risk management for AI (Pillar 2: AI Risk Management)

Recommended Path:

1. - Build technical literacy (Pillar 1: AI Cybersecurity Fundamentals)
2. - Understand data privacy implications (Pillar 4: Data Privacy & AI)
3. - Master AI-specific compliance requirements (this pillar)
4. - Learn risk management for AI (Pillar 2: AI Risk Management)

Recommended Path:

1. - Build technical literacy (Pillar 1: AI Cybersecurity Fundamentals)
2. - Understand data privacy implications (Pillar 4: Data Privacy & AI)
3. - Master AI-specific compliance requirements (this pillar)
4. - Learn risk management for AI (Pillar 2: AI Risk Management)

Key Skill Development:

• - Technical understanding of AI systems
• - AI-specific privacy impact assessment
• - Collaboration with technical teams
• - Interpreting AI regulatory provisions

If you're building or operating AI systems in Ghana, Nigeria, South Africa, Kenya, or elsewhere in Africa:

Pay Attention To:

1. Regulatory Maturity Stages

• - Some countries have enacted data protection laws
• - Some have proposed bills under review
• - Some have limited data protection frameworks
• - Regulatory landscape is rapidly evolving

Strategy: Build compliance infrastructure proactively, even before laws are enacted. This positions you ahead of competitors and reduces risk when regulations pass.

2. Multiple Jurisdictional Requirements

1. - If operating across multiple African countries, you face multiple regulatory frameworks
2. - Requirements often differ significantly
3. - Cross-border data transfers have varying restrictions

Strategy: Design for the most stringent requirements as baseline. Easier to have strong controls everywhere than to have different compliance levels in different markets.

4. Resource Constraints

1. - Compliance can be expensive
2. - Smaller organisations may have limited budgets
3. - Need to achieve compliance efficiently

Strategy: Use risk-based prioritisation, leverage free resources, focus on documentation, and build internal capability.

5. Infrastructure Realities

1. - Compliance solutions designed for Western infrastructure may not work
2. - Need approaches that work with intermittent connectivity, limited compute, variable bandwidth

Strategy: Design compliance controls that work within your infrastructure realities, not theoretical optimal conditions.

Recommended Path:

1. - Understand applicable regulations in your operating jurisdictions
2. - Build proactive compliance even before laws are enacted
3. - Focus on documentation and demonstrable compliance
4. - Engage with regulatory authorities
5. - Contribute to regulatory development where possible

Common Compliance Pitfalls to Avoid
Pitfall 1: Assuming GDPR Compliance = Global Compliance
The Mistake:
Many AI vendors claim "GDPR compliant" and assume this satisfies all data protection requirements globally.
The Reality:

• - Ghana DPA, Nigeria NDPR, Kenya DPA have different provisions than GDPR
• - AI-specific requirements vary (automated decision-making provisions differ)
• - Data residency requirements in some African countries are stricter than GDPR
• - Enforcement priorities and regulatory focus areas differ

What to Do Instead:

1. - Assess compliance against each applicable jurisdiction's requirements
2. - Don't assume GDPR compliance transfers directly
3. - Understand jurisdiction-specific provisions
4. - Build compliance for YOUR operating environment, not generic global compliance

Pitfall 2: Compliance as Final Gate Before Deployment
The Mistake:
Treating compliance as something to address after AI system development is complete, right before deployment.
Why This Fails:

• - Compliance considerations should influence system design
• - Retrofitting compliance into built systems is expensive and sometimes impossible
• - Late compliance assessment delays deployment
• - May discover fundamental incompatibility between system design and requirements

What to Do Instead:

1. - Integrate compliance into the development lifecycle from the design phase
2. - Conduct compliance assessments throughout development, not just at the end
3. - Include compliance timelines in project plans
4. - Design for compliance, don't bolt it on

Pitfall 3: Over-Reliance on Vendor Compliance Claims

The Mistake: Accepting vendor compliance representations without verification.

Why This Fails:

• - Vendors may not understand your specific regulatory requirements
• - "Compliant" in vendor's operating jurisdiction doesn't mean compliant in yours
• - Vendor compliance doesn't absolve you of compliance responsibility
• - Vendor capabilities may not match claims

What to Do Instead:

• - Verify vendor compliance claims with documentation
• - Assess vendors specifically against YOUR regulatory requirements
• - Include compliance obligations in contracts
• - Conduct ongoing vendor monitoring
• - Remember: vendor compliance is YOUR compliance responsibility

Pitfall 4: Ignoring Regulatory Developments Until Laws Pass

Why This Fails:

1. - Miss opportunity to build compliance proactively
2. - Face expensive retrofits when laws pass
3. - Competitors who prepared proactively have an advantage.
4. - May face early enforcement even during transition periods

What to Do Instead:

1. - Track proposed legislation in your operating jurisdictions
2. - Build compliance infrastructure ahead of enactment
3. - Interpret proposed requirements conservatively
4. - Engage in regulatory consultations
5. - Position for compliance leadership, not compliance scrambling

Pitfall 5: Insufficient Documentation

The Mistake: Focusing on technical compliance implementation without adequate documentation.

Why This Fails:

1. - Regulators require demonstrable compliance, not just actual compliance
2. - Audits and inspections focus heavily on documentation
3. - Can't prove compliance decisions were appropriate without documentation
4. - Organizational memory fades without written records

What to Do Instead:

1. - Document everything: policies, procedures, decisions, assessments
2. - Maintain records of processing activities
3. - Create audit trails for compliance activities
4. - Prepare documentation as if regulatory inspection is coming (because it might be)
5. - Build documentation discipline into compliance culture

AI regulatory compliance connects deeply with other pillars:

Start Your AI Compliance Journey
AI regulatory compliance is complex, rapidly evolving, and critically important. Organisations that master compliance gain a competitive advantage, reduce risk, and build trust with customers and regulators.
This isn't just about avoiding penalties. It's about building AI systems that respect individual rights, operate transparently, and contribute to responsible AI adoption.
The regulatory landscape will continue evolving. The organisations that thrive will be those that:

• 1. Understand compliance deeply across jurisdictions
• 2. Build compliance proactively, not reactively
• 3. Integrate compliance into AI development
• 4. Contribute to regulatory development
• 5. Balance innovation with responsible governance

Start building your AI compliance capabilities today. The regulatory future is coming—be ready for it.

CISA, CDPSE, MSc IT, BA Admin, AI/ML Engineer
Former CTO, CarePoint | Founder, AI Cybersecurity & Compliance Hub

Patrick Dasoberi brings executive healthcare technology leadership, regulatory expertise, and hands-on multi-jurisdictional compliance experience to AI regulatory education.
Executive Healthcare Technology Leadership
Until recently, Patrick served as Chief Technology Officer of CarePoint (formerly African Health Holding), responsible for healthcare systems across Ghana, Nigeria, Kenya, and Egypt. In this role, he navigated compliance across four different regulatory frameworks—including proactive compliance building for Nigeria's NDPR, Egypt's PDPL, and Kenya's DPA before these laws were fully enacted.

National AI Governance Expertise

Patrick was selected as Subject Matter Expert and Resource Person for Ghana's Ethical AI Framework and Data Exchanges Roadmap (Ministry of Communications & Digitalisation, Ghana & UN Global Pulse, March-May 2022). His contributions directly influenced the conceptual foundations of Ghana's national AI governance efforts, including guiding the critical terminology shift from "data markets" to "data exchanges" to better represent non-commercial, humanitarian data sharing models.

Technical Education Background
Before healthcare technology leadership, Patrick taught web development and Java programming in Ghana for seven years, developing deep expertise in making complex technical and regulatory concepts accessible.

Current Operations & Focus

Patrick currently operates AI-powered healthcare platforms (DiabetesCare.Today, MyClinicsOnline, BlackSkinAcne.com) across Ghana, Nigeria, and South Africa. Through AI Security Info and the AI Cybersecurity & Compliance Hub, he shares practical compliance insights from operating real-world AI systems under multiple regulatory frameworks.

Professional Certifications & Education:

• CISA (Certified Information Systems Auditor) – Compliance-focused
• CDPSE (Certified Data Privacy Solutions Engineer)
• MSc Information Technology, University of the West of England
• BA Administration
• Postgraduate AI/ML Training (RAG Systems)

Executive & Operational Experience:

• Former CTO: CarePoint (healthcare systems across Ghana, Nigeria, Kenya, Egypt)
• Regulatory Expert: Ghana Ethical AI Framework & Data Exchanges Roadmap (Government & UN)
• Teaching: 7 years teaching web development and Java programming in Ghana
• Current Founder: AI & Compliance Hub
• Current Operator: AI healthcare platforms across Ghana, Nigeria, South Africa
• Focus Areas: Multi-jurisdictional AI compliance, African regulatory frameworks, Proactive compliance