Explaining AI in the service to your congregation

Say it before you use it, say it in one sentence, and say who is responsible. That is almost the whole answer. The congregation that hears "from today you can listen to the sermon in your own language — scan the code on the seat in front of you, and yes, this is done by a computer, and yes, Markus is the one who checks it" does not have a problem. The congregation that finds out afterwards does.

We learned which sentence to use by getting it wrong. The first Sunday we switched the translation on, I announced it as a feature. The second Sunday I announced it as a service to the people who needed it and named the person who would be watching the quality, and that was the Sunday nobody asked me about it afterwards.

What do you actually say from the front?

Thirty seconds, before the sermon, not after. This assumes the mechanics are already sorted — a code on the card, the listener's own phone, no app to install, which is how live sermon translation actually runs. The announcement is the part people get wrong.

"If German is not your first language, there is a QR code on the card in your row. Scan it and you can hear this message in your own language, live, on your phone. A computer does the translating. Sara and I check what it does with names and Bible references, and if it gets something wrong I would rather you tell me than not come back."

That last clause does more work than the rest put together. You have told them there is a human owner, you have told them it is fallible, and you have invited the correction instead of waiting for the complaint.

The three objections, and honest answers

You will hear the same three. None of them is unreasonable and none of them needs a defensive answer.

"Is it listening to us?" The honest answer is about scope, not reassurance. What is picked up is what comes off the desk — the microphone at the front. The conversation in row nine is not in it, because row nine is not plugged into the mixer. Then point at where your retention and data handling are actually written down rather than paraphrasing them from the platform; ours sit on our data and GDPR page, and the elder who asks deserves the written version, not my summary of it.

"Will it replace the people who do this?" Where you have a human interpreter who knows the family, it should not, and we say so plainly: there is a real case for keeping your interpreter — for the pastoral conversation afterwards, for the funeral, for the person who needs a face and not a phone. What the machine does well is the Sunday where nobody was available, and the fourth language nobody in the building speaks.

"Will it put words in the preacher's mouth?" This is the serious one, and the answer is procedural. Somebody approves the vocabulary. Names, place names, the way your church says "elder" or "home group", the Bible book abbreviations — these are where every system slips, and they are also the only part a human can fix in advance. A glossary a person has approved, entry by entry, is the difference between a translation that sounds like your church and one that sounds like a machine that has never been there. Ours is the church memory, and it is not clever: it is a list someone on the team said yes to.

Who on your team approves what

Write this down once and it stops being a debate:

• Vocabulary — one person, usually whoever knows the congregation's names best. Not the tech volunteer.
• The recording and what comes from it — the transcript, the summary, the full message, the small-group guide, the drafts for the newsletter. Someone reads them before they go out. They are drafts, not posts.
• What gets published at all — the same person who signs off a bulletin today. AI does not change who owns the communications.
• Corrections — a named route. "Tell me" is a route. "Submit feedback" is not.

The split that works is roughly the one a communications manager described to me as ten-eighty-ten: the human sets the brief and supplies the facts, the machine does the middle, and the human edits and publishes. The temptation is to skip the last ten per cent because the middle came back looking finished. That is the whole risk, and it is a discipline problem rather than a technology problem.

The thing that actually goes wrong

Not the translation. The unattended draft. The story that gets told in every church tech room is some version of a volunteer who let a tool generate event descriptions and images unsupervised, and something strange went out under the church's name. Nobody was malicious and nobody was incompetent; there was simply no second pair of eyes between the machine and the public.

So the policy you need is shorter than the policy you are imagining. Something generated is a draft until a person has read it. A person is named for each kind of draft. The congregation is told, from the front, in one sentence, before anything is switched on. Three lines, and you have covered more ground than most.

Try it on one Sunday

Pick the Sunday you already know a guest is coming who does not have your language. Announce it in the thirty seconds before the sermon, exactly as above. Afterwards, ask two people — one who used it and one who did not — what they thought you had just told them. If their answer matches what you meant, your sentence works. If it does not, fix the sentence, not the technology.

If you want to see what the whole Sunday looks like when it is set up this way — the translation in the room, the after-service screen, and the transcript, summary and drafts that arrive within the hour — that is what a tool like this actually does on a Sunday.