Sovereignty is more than an EU flag on the homepage
A vendor can market European values while still routing inference through third countries, sharing support access broadly, retaining prompts indefinitely, or embedding third-party AI APIs that reintroduce transfer risk. Sovereignty requires readable architecture: regions, subprocessors, admin access, encryption, logging, and exit — written down and testable.
Church management systems (membership, donations, sacraments administration, schools, facilities) already concentrate sensitive personal data. Adding “AI assistants” inside those products multiplies the number of places text can land. Treat AI features as new processing activities, not cosmetic UI.
Questions for church-management and AI vendors
- In which countries are primary and backup data stored?
- Where does AI inference execute, and is prompt content logged?
- Which subprocessors receive content for AI, email, analytics, or support?
- Who among vendor staff can read customer content, and under what break-glass process?
- Can we export all records and AI conversation histories in usable formats?
- What happens to embeddings, caches, tickets, and backups after contract end?
- Can training on customer content be contractually excluded?
Align answers with your GDPR records and with diocesan or organisational IT policy. See also GDPR-compliant AI for dioceses.
Contracts, DPAs, and change management
A data processing agreement is necessary but not sufficient. Watch for unilateral change clauses, opaque subprocessor updates, and AI features enabled by default. Require notification before new AI subprocessors are added. Document who inside your organisation may approve such changes. Sovereignty erodes most often through slow product evolution, not a single dramatic outage.
Avoiding lock-in while staying practical
Perfect sovereignty with zero vendors is rarely realistic for modern institutions. Aim for clear contracts, minimised personal data in AI prompts, regional controls, portable exports, and a documented alternative if a supplier fails. Sovereignty is a programme of choices reviewed over time, not a single product checkbox at purchase.
When evaluating hosting isolation further, read on-premise versus cloud AI.
A working definition you can put in a policy
Consider adopting language such as: “We require that personal data processed for core pastoral, educational, employment, and donor operations remain in documented EU/EEA locations unless a named exception is approved in writing, with transfer safeguards and a review date. AI features are in scope for this rule.” Adapt with counsel to your jurisdiction and structure.
AI features inside existing platforms
Your membership or donor platform may ship an “AI helper” that sends fields to a third-party model. Inventory those toggles. Disable what you have not reviewed. Ask whether the helper is covered by the same DPA and region commitments as the core database.
Feature flags change. Re-check after major version upgrades and after any “smart search” or “auto summarise” marketing update from the vendor.
Multi-country Catholic networks
Orders and federations spanning multiple countries need clearer maps: which entity is controller, where data of members in each country resides, and which AI tools are approved centrally versus locally. Sovereignty is organisational as well as geographic. Central convenience must not silently re-home parish data without local awareness.
Evidence you can show a board
Keep a short pack: data map, approved AI list, DPAs, region attestations, last access review, and last export/deletion test. Boards do not need model benchmarks first; they need proof that institutional duties are still under control while technology changes.
Minimum viable data map
List systems that hold personal data, the categories they hold, the region of storage, the vendor, and whether AI features are enabled. One spreadsheet is enough to start. Update it when systems are added or AI toggles change. Without a map, sovereignty is a speech, not a practice.
Share a simplified version with leadership annually. Visibility creates accountability.
Exit drills
Once a year, practice exporting a sample of critical records and confirming deletion workflows with a vendor. An untested exit clause is theatre. Boards should ask when the last export drill happened, not only whether the contract mentions portability.
Sovereignty work is continuous: new AI features will keep appearing inside software you already own. Schedule a twice-yearly review of AI toggles, subprocessors, and region settings so quiet product changes do not undo careful procurement. Treat that review as ordinary governance, not a special project.