TL;DR: Three of the largest church management software vendors have shipped or announced AI features inside their ChMS in the last sixty days, and the way each handles congregational data is materially different. Before signing a renewal, we recommend five questions that every church leader should get direct, written answers to. The answers determine whether AI inside your ChMS becomes a stewardship asset or a stewardship liability.
Core Insights:
Vendor AI roadmaps are now part of the renewal cycle, not a separate decision, and most ChMS contracts auto-enable new AI features without granular opt-out.
83% of church leaders are very or somewhat concerned about AI data privacy, yet only 5% of churches have a formal AI policy in place (Barna/Pushpay State of Church Tech 2026).
Pushpay, ACST/MinistryPlatform, and Subsplash each represent a distinct data-governance posture, not a feature comparison.
Every “we don’t train models on your data” claim we have read in 2026 comes from vendor marketing or terms of service, never from an independent third-party audit.
The most important question is not what the AI does today, it is what the vendor’s roadmap will auto-enable at the next renewal and whether feature-by-feature opt-out is contractually available.
64% of church leaders believe their church should have an established AI use policy. Most of that policy work happens at the renewal table, where the leverage actually exists.
Five questions belong on every church leader’s desk before signing a church management software renewal in 2026: will our congregational data ever be used to train AI models, what happens to that data if we cancel, who on our staff sees what when the AI generates an answer, is the AI’s reasoning auditable, and which roadmap features will be auto-enabled at our next renewal. We walk through each below, grounded in the most current vendor disclosures and independent ministry research.
Why Vendor AI Decisions Are Now Renewal Decisions
AI features inside church management software are no longer optional add-ons that ministries evaluate separately, they are being shipped directly into the products churches already pay for, on the renewal cycle churches already signed. That changes what the renewal conversation needs to cover, and it maps onto the broader picture of what ChMS vendors are actually doing with AI in 2026.
Two recent vendor announcements illustrate the pace. Pushpay’s largest one-time investment ever in its Staq family, unveiled on June 2, 2026, introduced an AI involvement summary feature inside the ChMS and reshaped how giving, ChMS, and engagement data flow together. A month earlier, ACST launched MinistryPlatform AI as a layered integration over the existing ChMS, citing a thirty-minute setup that uses existing API credentials. The point is not the features themselves. The point is that these capabilities arrived on the vendor’s release calendar, and the church’s renewal contract is what governs them.
That is the question framework leaders are now wrestling with, and it is also the moment where contract leverage actually exists. Once the renewal is signed, the next opportunity to renegotiate scope is twelve months away. AI features ship in the meantime.
Key Point: AI features inside the ChMS arrive on the vendor’s renewal cycle, not on the church’s evaluation cycle. The renewal table is where the leverage exists, and the questions below are how we use it.
Question One: Will Our Congregational Data Ever Be Used to Train AI Models?
The first question on every renewal desk is whether the vendor or any of their partners will use member records, giving history, attendance, pastoral notes, or counseling data to train AI models. We look for a written contractual answer, not a marketing-page assurance.
The current vendor disclosures are close on language and important to read carefully. ACST states that data queried through MinistryPlatform AI is retrieved live, securely returned, and not stored or used to train AI models. Pushpay describes member data as staying within their secure partner ecosystem and not used to train external AI foundation models. Both statements answer the headline question. Neither statement answers the question of what happens inside the partner ecosystem, with which named subprocessors, under which exceptions.
That distinction matters because 83% of church leaders are very or somewhat concerned about AI data privacy according to the 2026 Barna and Pushpay State of Church Tech research. The concern is real, the contractual specificity is what addresses it. We ask for the language from the marketing page to be mirrored in the master services agreement, with named partners and named exceptions documented.
Key Point: Vendor marketing language about model training is consistent across the category. What matters is whether the same language appears in the contract we sign, in writing, with named exceptions and named partners.
Question Two: What Happens to Our Data If We Cancel?
Exit portability matters more after a year of AI features have been generating derived data, summaries, pastoral-care signals, and engagement scores. We ask what the vendor returns, what they retain, and what they delete, on what timeline, in what format. These are the four buyer questions the industry is now coalescing around, and exit terms are central to all four.
The complication is that most ChMS exit clauses were written before AI features shipped. A standard data export covers member records, giving history, group rosters, and the categories of data the church entered. It does not automatically cover the AI-generated layer: the summaries the assistant produced, the engagement scores it inferred, the pastoral-care flags it surfaced. Those derived artifacts are arguably the church’s data and arguably the vendor’s product. The contract is what resolves the ambiguity.
Vendor consolidation is creating new derived-data layers faster than exit clauses are being updated. The June 8 Pushpay and Nurture single point of entry release is one example: a new path that assigns people directly to Nurture Process Queues from inside the ChMS, which generates new categorical data the original 2024 contract probably did not anticipate.
This is also where the broader evaluation framework we use comes in. Exit terms are one input among several, but they are the one most often left underspecified at signing.
Key Point: Exit terms written before AI features shipped do not automatically cover derived AI outputs. We ask for the cancellation clause to name AI-generated artifacts explicitly.
Question Three: Who on Our Staff Sees What When the AI Generates an Answer?
AI assistants inside the ChMS need to respect the same access permissions a human staff member would, or they create a quiet permissions bypass. We look for role-based controls, audit trails, and table-level restrictions, not a single global permission to “use the AI.”
This is one area where the public vendor disclosures are unusually specific. ACST’s stated role-based permissions, audit trails, table-level controls, and data response inspection describe an architecture in which AI queries inherit the permissions of the staff member running them. That is the correct posture. It also needs to be verified against the actual configuration, because the existence of role-based controls does not guarantee they are configured to the church’s standard out of the box.
The denominational conversation reinforces the same principle. The Brentwood Statement on AI in Christian Ministry calls for human oversight in pastoral applications of AI, which in practice means clear access controls and clear audit trails for any AI-generated output that touches counseling, member care, or pastoral notes.
The vendor side of the work pairs with the staff-side policy work that complements the vendor-side controls. The two halves are not interchangeable. Vendor controls govern the technology, internal policy governs the people, and both are required.
Key Point: A ChMS AI assistant that ignores existing permission structures is a governance problem, not a productivity gain. Role-based access for humans must extend to role-based access for AI queries.
Question Four: Is the AI’s Reasoning Auditable, and Can We Document It?
When the AI surfaces a pastoral-care recommendation, a giving pattern flag, or an attendance trend, we need to see how it got there. Auditable reasoning chains and documented validation steps are the difference between a tool we can defend at an elder meeting and a tool we cannot.
Pushpay’s stated safety, accuracy, and transparency sequential check is one example of a vendor articulating the validation sequence in public. The sequence reads in order: safety first, then accuracy, then transparency. That ordering is defensible, and it is also worth pressing the vendor on the specifics of how each check is implemented and surfaced to the staff member receiving the AI output.
The congregational trust dimension is the other side of the same conversation. Lifeway Research data published alongside the Brentwood Statement indicates that 61% of churchgoers are concerned about AI’s influence on Christianity. That concern is not abstract. It shows up in the elder meeting where the staff is asked how the AI reached its conclusion. Auditable reasoning chains are how that question gets answered honestly.
The independent observation matters here too. Vendor-funded research and vendor-built tooling demand independent scrutiny, and the absence of a third-party audit regime in this category means the church’s own diligence is the only audit.
Key Point: Vendors that can show their work earn trust. Vendors that cannot show their work earn polite distance until they can.
Question Five: What’s in Your AI Roadmap That Will Be Auto-Enabled at Our Next Renewal?
Most churches discover new AI features the morning they appear in the product, not the moment the contract is signed. We ask for the roadmap in writing and for feature-by-feature opt-out, not a binary AI toggle.
The explicit AI involvement summary feature on the Pushpay roadmap is one example of a feature that arrives via release notes rather than via a separate purchasing decision. The roadmap path that will assign people directly to Nurture Process Queues from inside the ChMS is another. Both are reasonable product moves. Both are also material changes to how data flows inside the church’s stack, and both should be evaluated against the church’s own AI policy rather than auto-enabled by default.
The speed of arrival is a feature of the category. ACST’s stated thirty-minute setup using existing API credentials is one indicator of how quickly new AI capabilities can move from announcement to production inside a church’s ChMS. The renewal contract is what governs that speed, or fails to.
Key Point: The renewal we sign in 2026 is also the renewal that governs the AI features shipped in 2027. Granular opt-out, written in, is the only durable answer.
The Three Vendor Postures We Are Watching
Pushpay, ACST/MinistryPlatform, and Subsplash represent three different data-governance choices, not three flavors of the same product. We walk through how each one currently positions on the five questions above.
Pushpay’s Staq family brings ChMS, giving, and Nurture engagement under a centralized data flow, with AI features added directly to the renewal cycle. The acquisition-driven product breadth is part of the proposition, and it is also why the exit and roadmap questions carry extra weight: more data categories are flowing through one vendor’s infrastructure than before.
ACST and MinistryPlatform AI is a layered integration over the existing ChMS, built on the open Model Context Protocol. ACST sits under the Vanco parent and serves approximately 50,000 churches. Live retrieval, role-based permissions, and audit trails are part of the stated architecture. The open protocol is the most distinctive element, because it makes the data-query path inspectable rather than proprietary.
Subsplash, via the Pulpit AI integration, focuses on sermon-content AI rather than ChMS-data AI. The data path is different, the buyer questions are different, and we mention it briefly here because this post is focused on congregational data inside the ChMS, not on sermon and content workflows.
The independent observation that vendor product breadth is reshaping the church-tech decision applies to all three postures. The choice between them is a data-governance choice, and it pairs with the internal policy work that pairs with whichever vendor posture we choose.
Key Point: We are not picking a feature set, we are picking a data-governance posture. The three postures available in 2026 are meaningfully different.
What We Look for in the Written Answer, Not the Sales Call
Every claim that matters belongs in the contract, the data processing addendum, or the security documentation. Sales-call assurances are useful for context, they are not enforceable.
Five places we push for written specificity:
The data-training language belongs in the master services agreement, not the marketing page. The wording should name the partners, the exceptions, and the auditability of the claim.
The exit-portability clause should name AI-generated artifacts explicitly, including derived summaries, scores, and flags, with timelines for return and deletion.
The audit-trail and permissions architecture belongs in the security overview document, not described verbally on the sales call. Role-based controls and table-level restrictions should be configurable and inspectable.
The roadmap opt-out clause should be written before the next renewal arrives, with feature-by-feature opt-in for new AI capabilities as the default, not a binary toggle.
The gap worth naming: as of mid-2026, no independent third-party audit verifies vendor data-handling claims in this category. That makes contractual specificity the church’s only durable protection.
The question set the industry is converging on maps closely to the five above. The policy gap between concern and action across the sector is what makes the renewal conversation worth the time. The independent posture we recommend leaders bring to every vendor claim is to treat the contract as the source of truth, and the sales conversation as the helpful context around it.
Key Point: What is in the contract is what we have. What is on the sales call is what we hope for. We negotiate from the first, not the second.
Frequently Asked Questions
Does my ChMS vendor already use my church’s data to train AI?
The honest answer is that it depends on the vendor and on the contract you signed. Current vendor disclosures from Pushpay and ACST state that congregational data is not used to train models, but the specifics belong in the master services agreement, not in a marketing page. We recommend asking for the language in writing.
What is the most important AI question to ask at a ChMS renewal?
The roadmap opt-out question carries the most leverage. AI features arrive automatically on the vendor’s release cycle, and most contracts treat AI as a single toggle rather than a feature-by-feature opt-in. The renewal is the moment to negotiate granular control, because the next opportunity is twelve months away.
How does the Model Context Protocol matter for church management software?
ACST’s MinistryPlatform AI is built on the open Model Context Protocol, which standardizes how AI assistants query underlying data. For a church leader, the practical effect is that data is retrieved live rather than pre-indexed into a separate AI store, and the protocol is auditable. We expect more ChMS vendors to adopt similar architectures in 2026.
Are there independent audits of how ChMS vendors handle AI data?
Not yet. As of mid-2026, no independent third-party audit, certification body, or denominational watchdog has published a comparative review of how the major ChMS vendors handle congregational data inside their AI features. Vendor disclosures are the only public source. That makes contractual specificity the church’s primary protection.
What should a small church without a tech team prioritize in AI vendor evaluation?
Two things. First, get the data-training and cancellation language in writing, even if the rest of the contract feels boilerplate. Second, choose a vendor whose default settings are conservative rather than maximalist, so a small staff is not configuring AI controls they do not have the bandwidth to monitor. Default-off beats default-on for under-resourced teams.
How often should we revisit our ChMS AI terms?
We revisit at every renewal cycle, which for most ChMS contracts is annually. We also revisit any time the vendor announces a material AI feature or completes an acquisition that changes the data-flow path, regardless of the renewal calendar. The Pushpay and Nurture integration shipped in June 2026 is a recent example of a mid-cycle change worth a fresh look.
Does the Brentwood Statement require us to change vendors?
No. The Brentwood Statement is a denominational framework calling for human oversight and pastoral guardrails in AI use. It does not name vendors or prescribe vendor changes. It does inform the questions leaders bring to the renewal table, particularly around auditability, human-in-the-loop oversight, and the pastoral applications the AI is allowed to touch.
Key Takeaways
AI inside the ChMS is now a renewal decision, not a separate evaluation. Vendor roadmaps ship features automatically, and the renewal contract is where leverage lives.
Five questions cover the durable ground: data training, exit portability, staff access permissions, reasoning auditability, and roadmap opt-out.
Vendor marketing language is consistent across the category. Contractual language is not. We negotiate the contract.
No independent third-party audit currently verifies vendor data-handling claims for ChMS AI, which makes written specificity the church’s primary protection.
Three vendor postures are now distinct: Pushpay’s centralized Staq family, ACST/MinistryPlatform’s open-protocol layered integration, and Subsplash’s sermon-content focus. Each represents a different data-governance choice.
Most churches feel the AI policy gap. Sixty-four percent of leaders believe a formal AI policy matters, only five percent have one, and most of that policy work happens at the renewal table.
Where We Go From Here
The five questions above are the durable ground for evaluating AI inside any church management software, and they map onto the vendor landscape we mapped last Friday.
The next decision most leaders face is whether to raise these questions at the current renewal cycle or wait, and the answer usually depends on how soon the contract auto-renews and what AI features are already in flight.
If your ministry is working through a ChMS renewal with new AI features on the table, we would be glad to think it through with you. We offer no-pressure consultations where we listen first, then share what we have learned helping ministries navigate the same questions. Schedule a consultation.
Sources and References
ChurchTechToday, “AI Ethics And The Church’s Most Sensitive Data,” June 8, 2026. https://churchtechtoday.com/ai-ethics-and-the-churchs-most-sensitive-data/
Barna and Pushpay, State of Church Tech 2026, “Church Leaders’ AI Usage and Concerns,” 2026. https://www.barna.com/research/church-leaders-ai-usage-concerns/
ACST, “ACST Launches Ministry Platform AI: Bringing Secure, Ministry-Aware AI to Churches,” May 7, 2026. https://www.businesswire.com/news/home/20260507886746/en/ACST-Launches-Ministry-Platform-AI-Bringing-Secure-Ministry-Aware-AI-to-Churches
Pushpay, “Building for the Future: The Staq Transformation,” June 2, 2026. https://pushpay.com/blog/building-for-the-future/
Lifeway Newsroom, “Lifeway, SBC Leaders Respond to Research Findings with AI in Christian Ministry Statement” (Brentwood Statement), June 8, 2026. https://news.lifeway.com/2026/06/08/lifeway-sbc-leaders-respond-to-research-findings-with-ai-in-christian-ministry-statement/
MinistryWatch, “The New Church Tech Divide Is Missional, Not Digital,” March 30, 2026. https://ministrywatch.com/the-new-church-tech-divide-is-missional-not-digital/
Pushpay, “Pushpay Introduces a Streamlined Customer Experience Between Pushpay and Nurture.io Platforms,” June 8, 2026. https://www.globenewswire.com/news-release/2026/06/08/3308161/0/en/Pushpay-Introduces-a-Streamlined-Customer-Experience-Between-Pushpay-and-Nurture-io-Platforms.html
