A small church AI policy should answer a volunteer’s next practical question: may I use this tool for this task, and who checks the result? Start with a one-page agreement that staff can actually explain. The checklist below is an editorial recommendation for everyday ministry work, not a claim that one template fits every church.

The NIST AI Risk Management Framework is a voluntary resource for thinking about trustworthy AI. Its companion NIST AI RMF Playbook offers adaptable actions under Govern, Map, Measure and Manage. A church can borrow that habit of assigning responsibility without pretending it has completed a formal certification or adopted every suggested control.

Name an owner before naming a tool. Assign a pastor or ministry leader to approve the policy, and identify a backup reviewer. Keep the current version somewhere volunteers can find it. Include an effective date, the approved tools and the person to ask when a proposed task falls outside the agreement.

Divide work into three lanes: permitted drafts, permission-first tasks and excluded material. Possible permitted drafts include a public event description based on confirmed details or alternative wording for an existing announcement. Keep pastoral judgment, final theological interpretation and public publishing decisions with people. Do not describe AI output as a pastor’s reviewed words until that review happens.

Make the data boundary concrete. As a recommended default, keep counseling notes, prayer requests with identifying details, children’s information, donor records, personnel matters and passwords out of general-purpose tools. A volunteer who is unsure should stop and ask the owner instead of experimenting with real information.

Use a short intake note for each public-facing draft: task, approved source material, tool used, intended audience and reviewer. An announcement about a meal might start with the organizer’s confirmed date, location and registration instructions. It should not begin with an invented testimonial, attendance figure or quotation.

The reviewer should compare names, dates and links against the original sources, read Scripture references in context, and check whether the wording fits the church’s beliefs and voice. Ask whether the draft makes an unsupported promise or sounds like personal pastoral advice. Rewrite unclear passages rather than simply adding a disclaimer.

Check permissions and presentation separately. Confirm that photographs, quotations and music have suitable permission for the intended use. Label an illustrative image when readers could mistake it for your congregation or an actual event. Look for readable text, useful captions and clear next steps before approving publication.

Keep a simple approval record beside the finished content: reviewer, approval date and final version. The volunteer who schedules a post should use that version rather than an earlier draft. A last-minute change to the service time should trigger another check, even if the original copy was approved yesterday.

If a mistake slips through, correct the public content promptly and tell the policy owner what happened. Preserve enough context to understand the failure without circulating sensitive details. Decide whether the source check, reviewer assignment or tool permission needs changing before the next similar task.

Our church automation guide explores broader administrative workflows. Use it alongside this policy, so time-saving systems still have a responsible owner. Our introduction to AI in the church provides the wider mission discussion; this checklist concentrates on the handoff between a volunteer’s draft and a leader’s approval.

Pilot the agreement with one low-risk announcement, then review it after thirty days. Ask volunteers which instruction was confusing and which check caught a real problem. Keep the policy brief enough to use, specific enough to enforce, and dated so the next volunteer inherits a working process rather than a forgotten document.