Start with problems, not demos

Write the top three administrative problems you intend to solve and the data classes involved. Vendors should map capabilities to those problems. A dazzling demo on public text proves little about your confidential workloads. If a salesperson cannot answer residency and retention in plain language, treat that as signal, not style.

Minimum diligence pack

  • Security and privacy documentation, DPA, subprocessors
  • Data residency and training-use commitments
  • Admin controls, SSO, logging, key revocation
  • Export and deletion procedures
  • Support access model (who can read customer content, and when)
  • Pricing for real seat and usage patterns
  • References from comparable institutions when available

Cross-check sovereignty with data sovereignty in church software and run an ethical AI vendor assessment before signature.

Pilot contract shape

Time-box pilots, define success metrics, forbid production confidential data until controls pass, and require an exit plan. Prefer paper that lets you stop without hostage data. Involve legal early for transfers and special-category data. A “free pilot” that trains on your content is not free.

After purchase

Procurement is not finished at signature. Schedule quarterly reviews of usage, incidents, subprocessor changes and whether the tool still matches purpose. Unused AI seats with broad access are a risk, not an asset. Document why a vendor was refused—future staff need that memory.

Who must sit at the table

At minimum: IT (or a trusted technical adviser), a privacy or compliance contact, a mission representative when the tool will touch people-facing work, and a budget owner. Leaving any one of them out is how you get a clever pilot that cannot be signed, funded or defended later.

Write a one-page decision memo after shortlist: problem, data classes, scores, residual risks, pilot plan. File it where the next finance officer can find it in three years.