I spent eighteen months assuming that any AI we added to our content tools would reduce the load on our volunteer coordinators. The faster we generated lessons, the more time they would have for actual relationships with kids. That assumption cost us three coordinators in one quarter and left the rest of the team questioning whether the product still served the people who showed up every Sunday.
The real fracture was not about speed or even about quality. It was about who decided when the output was good enough to hand to a volunteer working on a Tuesday night with seven minutes and a printer. Once that decision moved to an external model and a dashboard no one on the ground could touch, the people closest to the work stopped trusting the system they were supposed to maintain.
This is the same pattern Jensen Huang has warned about with sovereign AI. When an organization gives up control over the model, the data, and the evaluation criteria, it ends up optimizing for someone else’s metrics. In ministry products the someone else is usually an LLM vendor whose success is measured in tokens, not in whether a volunteer finishes the lesson without rewriting it at 10 p.m.
The split showed up first in the curriculum workflow
The first visible break happened in the weekly curriculum handoff. We had built a generation step that turned a short prompt into a full lesson outline, complete with discussion questions and craft ideas. On paper it looked like a win for the 7-minute volunteer. In practice the outlines arrived with the wrong tone for our age group or referenced objects that did not exist in most church supply closets.
Coordinators began spending more time fixing the generated material than they had spent writing it from scratch. One of them printed a side-by-side comparison for the team: the original handwritten lesson took twenty-two minutes to produce and needed almost no changes; the AI version took four minutes to generate and then forty minutes to repair. The time savings had moved from the volunteer to the coordinator, exactly the opposite of the intended effect.
The team divided along a line no one had predicted. The product managers and engineers saw throughput numbers rising and assumed morale was improving. The coordinators saw their evenings disappear into revision cycles and stopped suggesting improvements. The product kept shipping, but the people who actually delivered it on Sunday had checked out.
Control over the model mattered more than speed
We tried the usual fixes first: better prompts, retrieval-augmented generation, even a small fine-tune on past approved lessons. None of them addressed the core issue. The model still sat outside the team’s direct influence. When it produced something off, the only options were to accept it or to open a ticket that might be resolved in the next sprint.
Huang’s point about sovereign control applies here in a practical way. A ministry product team needs the ability to freeze a model version, to define its own scoring rubric, and to override outputs without waiting for an upstream change. Without that, every improvement in generation speed simply increases the volume of work that must be manually corrected by the same small group of coordinators.
We eventually moved a smaller, locally hosted model behind a simple internal interface. Generation slowed by a factor of three, yet the coordinators stopped rewriting lessons. The difference was that they could now adjust the temperature, swap the reference set, and reject an output before it reached the print queue. The product became slower on the server and faster in the real workflow.
Sovereignty starts with who owns the eval loop
The decisive change came when we handed the evaluation criteria back to the people who would use the output. Instead of a shared dashboard with vendor-defined scores, each coordinator kept a personal frozen set of ten lessons they had already approved by hand. Any new generation had to be compared against that set before it moved forward. If it failed the comparison, the coordinator could veto it without further discussion.
This small shift restored ownership. The eval loop was no longer an abstract quality metric; it was a concrete personal benchmark that traveled with the person doing the work. Morale improved not because the model got smarter, but because the decision rights returned to the same individuals who carried the Sunday responsibility.
The pattern repeats across other ministry tools. When an AI feature is introduced without a corresponding transfer of control over its outputs, the people closest to the mission absorb the hidden cost. The line that split our team was never about technology preference. It was about whether the coordinators still recognized the product as something they could shape.
Your Turn: Apply This Today
- Choose one coordinator on your current project and give them explicit veto authority over any AI-generated content before it reaches volunteers; document the veto rule in the next sprint planning note.
- Have that same coordinator assemble a frozen personal benchmark of eight to ten past lessons they consider acceptable and store it as a simple shared folder they control.
- Replace the next automated quality score with a two-question checklist the coordinator answers against their benchmark before any output moves forward.
- Schedule a thirty-minute weekly review where the coordinator can adjust the reference set or reject a model version without needing engineering approval.
- Measure coordinator time spent on revision rather than generation for the next four weeks and share the delta with the product team in raw minutes, not percentages.
- If the revision time does not drop by at least half, pause the AI step for that workflow until the coordinator can describe what control they still lack.
The same ownership question appears in The Benchmark Number That Still Needed a Human Gate and The Bias I Let Shape Every Eval Until a Human Scored It.
I consult with ministry product leaders on AI tool ownership, volunteer workflow metrics, and eval loops that stay in human hands. Let’s talk.

