redwitch

📄 Red Witch – External Design Input: “Digital Colonialism” & AI Data Sovereignty

Document Name: “Digital colonialism: how AI companies are following the playbook of empire” Source / Link: The Conversation, Nov 25, 2025 — Jessica Russ-Smith (ACU), Michelle D. Lazarus (Monash University) https://theconversation.com/digital-colonialism-how-ai-companies-are-following-the-playbook-of-empire-269285
Document Type: External Design Input / Regulatory, Ethical & Societal Context Purpose: Provide evidence of systemic risks in large-scale data collection, bundled consent, and “digital terra nullius” practices by AI companies. Used to inform privacy-preserving design requirements, governance controls, and risk management for the Red Witch project.

1. Summary of Key Findings

2. Implications for Red Witch Design

Based on the article, Red Witch shall implement the following design inputs / requirements to avoid digital-colonial practices and align with Indigenous data sovereignty principles:

Requirement / Design Input Description Linked RMF Risk
DI-101: Reject digital terra nullius Treat all user data as owned and revocable; never assume implicit or bundled consent R-Ext-101
DI-102: Continuity of consent App must request explicit consent for each category of data usage; no all-or-nothing bundles R-Ext-101, R-Ext-102
DI-103: Community/local data storage All data stored locally on device or within a community-controlled environment; no cloud scraping R-Ext-101, R-Ext-103
DI-104: Revocable permissions Users can revoke consent at any time; data must be deletable without retention R-Ext-101
DI-105: No data scraping or silent collection App must never collect data the user did not intentionally enter or authorize R-Ext-101, R-Ext-102
DI-106: Transparency of access events Log and expose any instance of data access or processing; provide “why, what, when” visibility R-Ext-102
DI-107: Legal alignment for data sovereignty Design aligned to GDPR, UNDRIP Indigenous Data Sovereignty Guidelines, and relevant privacy standards R-Ext-103
DI-108: Anti-coercive UX Essential functionality cannot be gated behind bundled consent agreements R-Ext-102

External risks identified from the “Digital Colonialism” article are added to the RMF:

RMF Risk ID Source Risk Description Mitigation / Control
R-Ext-101 “Digital Colonialism” (2025) Treating user data as “ownerless,” leading to unauthorized, unethical, or unlawful data extraction Local-only storage, revocable consent, granular permissions, no scraping, explicit data ownership
R-Ext-102 “Digital Colonialism” (2025) Bundled/coercive consent creating loss of agency, privacy violations, and digital exclusion Anti-coercive UX, continuity-of-consent, transparency logs
R-Ext-103 “Digital Colonialism” (2025) Failure to meet emerging data sovereignty expectations (legal + cultural), leading to litigation and trust failure Alignment with GDPR/UNDRIP, community-controlled storage, no secondary use

4. Usage

This external design input informs:

1) Conceptual overview — what data sovereignty is (short)

Data sovereignty (general) — the principle that data is subject to the laws, rights, and governance of the place, people, or community to which it pertains; it covers legal jurisdiction (national/state), ownership, and governance choices about collection, storage, access and reuse. (IBM)

Two distinct but overlapping meanings you’ll see in practice

Why it matters to your app / QMS

2) Current landscape — key trends (brief, evidence-linked)

  1. Litigation & market pressure pushing companies to change behaviour. High-profile lawsuits and settlements (e.g., Anthropic $1.5B settlement; platform suits against scrapers like Reddit vs Perplexity) demonstrate legal exposure for large-scale scraping and opaque reuse. This raises liability for any app that depends on third-party training data or shares user data. (The Verge)

  2. Stronger Indigenous / community governance frameworks are being adopted and promoted. CARE principles (GIDA), OCAP (First Nations), and regional collectives (Maiam nayri Wingara in Australia) are now referenced by governments, funders and research institutions — meaning community consent and governance expectations are becoming normative. (RDA)

  3. Regulatory and technical emphasis on locality + control. Governments and cloud providers differentiate “residency” vs “sovereign” cloud offerings; organizations are expected to show where data lives, how it crosses borders, and who can access it. (IBM)

  4. Shifting definitions of consent & transparency. The “bundled consent” model is under fire: continuous, revocable, and purpose-specific consent models are being proposed as alternatives (this is central to Indigenous data sovereignty arguments and to civil-society privacy proposals). (RDA)

  5. Academic and policy discourse reframes data extraction as a form of ‘digital colonialism’ — useful for risk analysis and stakeholder engagement because it highlights power asymmetries and historical analogues. (See the Conversation piece you shared and supporting scholarship.) (Vishal Ravate)

3) Immediate, practical follow-up for your app and QMS (prioritized checklist)

Use this as a runnable checklist; each item maps to QMS artifacts (SRS, RMF, DHF, audit evidence).

A. Governance & legal (high priority)

B. Consent & UX (high priority)

C. Technical controls & data lifecycle (high priority)

D. Community engagement & ethical alignment (high impact)

E. Monitoring & continuing compliance (medium priority)

4) Suggested QMS/RMF artefacts to produce

5) Who / what to consult next (resources & contacts)

Organisations & frameworks

Legal / policy watchers

6) Quick, pragmatic timeline you can adopt now (two-week sprint)

Days 1–3: create Data Map + gap list; schedule legal consult. Days 4–7: draft SRS changes: continuity of consent, local storage default, revocation API. Add to DHF. Days 8–10: stakeholder outreach plan (identify communities, legal counsel, suppliers). Draft MOUs. Days 11–14: implement logging and a minimal consent prototype; add to RMF and arrange a QMS internal audit entry.

7) Example language you can paste into SRS / QMS to link this work to external context

“External Context: ‘Digital colonialism — how AI companies are following the playbook of empire’ (The Conversation, Nov 25, 2025) and related Indigenous Data Sovereignty principles (OCAP, CARE) were reviewed. Controls implemented include continuity of consent, local-default storage, community governance mapping, and contractual prohibitions against scraping; see RMF entries R-Ext-101..103.” (Vishal Ravate)

✅ What is CANChat (and what’s real vs. rumor)

So: yes, Canada is building a public / sovereign-AI capability, of which CANChat is a visible example. It is not (in public documents) a consumer-facing or commercial LLM yet — but it shows that the government is investing in having “AI under Canadian jurisdiction.”

🌐 Broader Canadian “Sovereign AI” Landscape (2025)

CANChat is part of a broader movement in Canada toward data sovereignty and “sovereign AI.” Key developments:

Conclusion of landscape: there is a concerted push — from public and private sectors — to build “sovereign AI” capacity in Canada. The goal is to let Canadians (or Canadian organizations) use powerful AI while keeping data, governance, and legal jurisdiction within Canada.

🔎 How CANChat / Sovereign AI affects “Data Sovereignty” for your app

Given your interest in data sovereignty and embedding it into your QMS / RMF for your app, CANChat and the broader sovereign-AI trend are relevant in a few important ways:

Positive signals / opportunities:

But: caveats & limitations — sovereignty is not yet perfect:

🎯 What this means for your app — and what you should do (next steps)

Because of this evolving landscape, I recommend you treat the rise of sovereign-AI + CANChat as strategic context input for your QMS / design — and use it to strengthen your data-sovereignty posture. Here’s how:

  1. Explore using Canadian-hosted AI infrastructure (e.g., a “sovereign AI factory”, or a private-cloud Canadian LLM) if your app uses AI or large-language models. This helps align with sovereignty, privacy, and compliance goals.
  2. Monitor legal/regulatory developments — e.g. the evolving definition of “data sovereignty” in Canada (the 2025 white paper warns about limits). Use this as part of your external context and risk-watch list in the RMF.
  3. Integrate governance and consent controls regardless of where the AI lives — sovereignty does not remove the need for explicit user consent, transparency, auditability, and data minimization.
  4. Include “sovereign-AI / Canadian infrastructure” as a design / business requirement — e.g. in your SRS, note that any AI backend must be hosted in Canada, on Canadian infrastructure, with Canadian or appropriately aligned legal controls.
  5. Engage with emerging Canadian AI ecosystem & providers (government, private, academic) — possibly as suppliers or partners, to stay ahead of compliance and take advantage of local infrastructure.

https://aiatsis.gov.au/publication/116530

📚 What is that 2019 document — and why does it matter

So — yes, data-sovereignty thinking predates the explosion of generative-AI tools by several years. Importantly, that means concerns about data extraction, representation, colonization via data, and governance — which seem very contemporary given AI — have been under discussion for a long time within Indigenous, academic, and policy circles.

🔎 What this long history implies / why it resonates now (and for you)

Several implications of that early origin are relevant, especially to a project like yours that aims to embed data-sovereignty and ethical design:

✅ What this means for your app / QMS — and how to build on it

Because “data sovereignty thinking” is not new but has deep roots — you have an advantage. Use that history to ground your design and governance:

✅ Key Canadian / Indigenous Data Sovereignty Frameworks

First Nations Information Governance Centre (FNIGC) + OCAPÂź Principles

Thus OCAPÂź is perhaps the best-known Indigenous data-sovereignty framework in Canada for First Nations data.

Broader / Pan-Indigenous or Cross-Community Principles & Emerging Models (MĂ©tis, Inuit, Multi-Nation, research contexts)

Because Canada includes multiple Indigenous peoples (First Nations, Inuit, MĂ©tis), and because different communities have distinct cultures, protocols, and governance traditions — many data-governance frameworks emphasize distinctions-based approaches (i.e. recognizing that what works for one community may not for another). (CIHI)

Some of the broader governance models include:

Thus there isn’t a single monolithic “Canadian Indigenous data sovereignty framework” that covers all Indigenous peoples — but a suite of recognized frameworks and principles, many of which are internationally aligned, and adaptable depending on which community is involved.

🎯 Why these frameworks matter (and how they work in practice)

🧰 What this means if you build an app / data-driven product in Canada

Since you are designing an app and a QMS with data-sovereignty concerns — knowing that these frameworks exist gives you a real, formal reference point:

This site is open source. Improve this page.