AI tools process personal data more often than teams admit
Even a “simple” drafting assistant may receive names, contact details, case notes, or employment context. Under the GDPR, that is personal data. If the tool stores prompts, trains on them, or routes them outside your documented processors, you have expanded your processing without updating your records of processing activities — and possibly without a lawful basis assessment.
Dioceses already manage baptisms, schools, tribunals, safeguarding, and payroll through specialised systems with defined roles. AI should not become the unmanaged side door next to those systems. The risk is cultural as much as technical: generative tools feel informal, so staff treat them like a private notepad rather than a processor sitting on the network path of confidential text.
Assume any free-form prompt box can become a personal-data store. Design policy and tooling on that assumption.
Legal bases and purpose limitation still apply
Useful internal questions for any AI pilot in a diocesan setting:
- What is the purpose of this processing (drafting circulars, answering facilities emails, summarising non-confidential reports)?
- What legal basis covers it, and is the data minimised to what the task needs?
- Are special-category data involved — including, in some contexts, data revealing religious belief — and if so, which extra conditions apply under Articles 9 and related national law?
- Have data subjects been informed through privacy notices where required?
- How long are prompts and outputs retained, and who can access historical chats?
If staff paste safeguarding material, tribunal correspondence, or raw HR files into a public chatbot, you are not “being innovative.” You are creating an incident pathway and a documentation problem at the same time.
Purpose limitation also means resisting feature creep: a tool approved for website copywriting is not automatically approved for pastoral case notes.
Controllers, processors, and joint arrangements
When a diocese buys organisational AI, it is usually appointing a processor (or, in edge cases, entering a more complex controller relationship — take legal advice for those). Your contracts and diligence should make roles explicit. Ask whether the vendor trains models on customer content, which subprocessors touch prompts, and how support staff access tenant data under break-glass procedures.
Keep AI tools in the same mental model as email hosting or parish management software: if personal data flows through it, it belongs in your processor inventory and risk assessment cycle.
Processors, transfers, and realistic vendor questions
Practical diligence questions for any vendor shortlist:
- Subprocessor lists and how you are notified of material changes
- Data location for primary storage, backups, logs, and inference
- Transfer mechanisms if data leaves the EEA
- Retention defaults for conversations, embeddings, and tickets
- Whether customer content is used for model training (default expectation: no, unless you explicitly agree)
- Support for erasure, export, and account closure aligned with your policies
- Authentication options, key revocation, and admin audit logs
Pair this page with data sovereignty in European church software when contracts and hosting regions are on the table. For model boundary choices, see private AI versus public LLMs.
A safer diocesan adoption pattern
Start with low-risk workloads: public website copy, generic facilities FAQs, non-confidential internal templates, published policy summaries. Keep high-risk categories out of early pilots. Prefer systems with organisational accounts, key revocation, European hosting options, and clear retention settings.
Train staff the way you train them on email and removable media: concrete examples of what must never leave approved systems. Appoint an owner for the pilot, write a one-page purpose statement, and schedule a review date before expanding scope. Measure usefulness (time saved, quality of drafts) and incidents (near-misses, policy violations) with equal seriousness.
When the pilot succeeds, scale by policy and architecture — not by unofficial browser bookmarks.
Records, DPIAs, and when to slow down
Update records of processing when AI tools become systematic, not only when a contract is signed. Consider a data protection impact assessment when large-scale profiling, special-category data, or novel high-risk automation is in scope. Slowing a pilot is cheaper than explaining an unmanaged processor after a complaint.
Coordinate with your DPO or privacy contact early. Bring them a one-page description of purpose, data categories, users, retention, and vendor — not a surprise after launch. Keep that one-pager with the pilot approval so future staff understand the original intent.
Working with parishes and agencies
Diocesan AI policy must travel. Parishes and agencies often have less IT support and more volunteer turnover. Provide simple rules, approved tools, and a contact for exceptions. Otherwise local freelancers and free chatbots will fill the gap with uncontrolled processing. Offer short training that uses parish-realistic examples rather than abstract legal language alone.
Incident readiness
Decide in advance who investigates if prompts containing personal data were sent to an unapproved tool. Include AI channels in your incident playbooks. Practice once; do not invent the process during a real complaint.