Appearance
Data Handling v3.2
Last updated: July 22, 2026
Data Custody
AI4Love maintains two separate stores for your data — one bounded, one you own outright.
| Store | What It Holds | Who Controls It | Retention |
|---|---|---|---|
| Working base (Airtable, AI4Love's account) | Normalized supporter, activity, insight, and workflow records the nightly analysis agents require | AI4Love, with per-organization isolation | Active service, plus a 90-day exit window after cancellation, then deleted |
| Organization mirror (Google Sheets or comparable, your workspace) | People, activities, and insights — records only, no formulas, automations, or analysis machinery | Your organization | Indefinite — survives cancellation permanently |
A nightly publisher job syncs people, activity, and insight records — write-only — from the working base to your organization's mirror file after each analysis run. You can revoke AI4Love's write access to that file at any time from your own workspace; the file, and everything already written to it, stays yours regardless.
Source systems (Blackbaud, Mailchimp, Environics) sit outside both stores entirely — read-only, never modified, unaffected by anything described on this page.
On cancellation:
- Your organization mirror is untouched — it already lives in your workspace and stays there permanently.
- The working base enters a 90-day exit window. During that window, you can request reactivation, a full export, or immediate deletion. After 90 days — or immediately, on request — it is deleted.
- Source systems were never modified and need no cleanup.
You always hold a complete, permanent copy of your own. Our working store is bounded — active while you're a customer, deleted 90 days after you're not.
What We Read vs. What We Never Touch
| Blackbaud RE NXT | Mailchimp | Environics | |
|---|---|---|---|
| We read | Constituent profiles, gift history, actions, event registrations | Contact lists, campaign sends, open/click activity | Postal-code-level demographic segments |
| We never read | Payment details, credit card numbers, bank accounts, passwords | Payment info, billing details, API account settings | Individual-level personal data |
| We never write back | No creates, modifies, or deletes in your RE NXT | No changes to contacts, lists, or campaigns | N/A — enrichment is one-way |
What we write to the working base: AI4Love writes to fields it owns — AI-generated insight records (headline, pattern, domain), Environics enrichment fields (PRIZM segment, giving propensity), and, through the mark_campaign_refined MCP tool, organization-scoped Generated Campaign metadata. We do not write to source-of-record fields (donation amounts, contact details, engagement history). This restriction is enforced through application-level logic, not an Airtable-native permission tier, so it is a code-review and audit-log control rather than a platform guarantee.
Encryption Standards
All communication between AI4Love, your platforms, and infrastructure providers is encrypted.
| Layer | Standard | Details |
|---|---|---|
| Data in transit | TLS 1.2+ | All API calls, webhook payloads, OAuth flows, and MCP queries. No plaintext connections accepted. |
| Data at rest — Airtable | AES-256 | All stored data encrypted at rest. SOC 2 Type II certified. |
| Data at rest — Nango | AES-256 | OAuth tokens encrypted at rest. SOC 2 Type II certified. |
| Data at rest — Doppler | AES-256 | API keys and secrets encrypted at rest. SOC 2 Type II certified. |
| Data at rest — Vercel | AES-256 | Build artifacts and environment variables encrypted at rest. SOC 2 Type II certified. |
Credential Storage and Revocation
- OAuth tokens are stored and encrypted by Nango (SOC 2 Type II), a dedicated credential vault. AI4Love application servers never persist tokens to disk.
- API keys (e.g., Mailchimp) and the Airtable Service Account Access Token are stored in Doppler (SOC 2 Type II). The Service Account Access Token receives the same SOC 2-compliant storage and rotation procedures as all other integration credentials. Keys are never committed to code or logs.
- Revocation: Staff can disconnect any platform from the Integrations dashboard. This calls Nango's
deleteConnectionendpoint, which destroys all stored tokens. For API-key integrations, removing the key disables access immediately. Effectiveness ultimately depends on the provider invalidating the token on their end. - Session behaviour on revocation: MCP has two transports with different session behavior. Streamable HTTP (used by ChatGPT and most connectors) is stateless — every request revalidates the credential, so revocation takes effect on the very next call. SSE connections (used by some clients) hold a short-lived, in-memory session; that session ends when the client disconnects or its underlying OAuth access token expires (maximum TTL 60 minutes) — a currently-open SSE session isn't force-closed mid-stream by a revocation elsewhere.
Permission Scoping
Working bases are provisioned and operated entirely by AI4Love, with per-organization isolation — each organization's working base is a separate Airtable base under AI4Love's own account, credentialed separately from every other organization's. Your organization does not need an Airtable account or login of its own to use AI4Love.
What actually limits AI4Love's writes day-to-day is application code: record operations run through scoped service functions that target specific tables and fields (insights, enrichment, campaign-workflow metadata). Schema changes — adding fields, altering tables — are handled as a separate, explicitly approved step, not something application code does autonomously.
Access to your organization mirror uses a service account with editor rights on that one file only — nothing else in your workspace. You can revoke that access at any time from your own Google Sheets (or equivalent) sharing settings; doing so stops future syncs immediately without affecting anything already written to the file.
Safety net: Airtable's native Trash and Base Snapshots provide recovery independent of application code for the working base — deleted records are recoverable for a limited window, and base snapshots can restore prior states, both administered by AI4Love. Your mirror file's version history and recovery run entirely on your own workspace's native controls (e.g., Google Sheets version history), independent of AI4Love.
Data Residency
Default regions across the stack are US-based.
- Working base (Airtable) is hosted under AI4Love's own Airtable plan. Canadian residency for the working base depends on the plan tier and configuration in place at the time — confirm current availability during procurement.
- Organization mirror (Google Sheets or comparable) resides in your organization's own workspace and follows whatever residency configuration your organization has set there — entirely outside AI4Love's control.
- Nango (OAuth credential vault) can be self-hosted in Canada for organizations where credential residency is a compliance requirement.
Confirm exact requirements and configuration during procurement — residency posture should be documented in your organization's Data Processing Agreement before onboarding begins, not assumed from this page.
Data Retention
| Layer | What | Retention |
|---|---|---|
| Organization-owned mirror | People, activities, insights | Indefinite — owned and controlled by your organization |
| AI4Love working base | Supporter, activity, insight, and workflow records | Active service + 90-day exit window, then deleted |
| Application memory | Transient request data | Request-scoped; not used as a durable data store |
| Vercel runtime logs | Request metadata (no supporter PII) | Plan-dependent — Pro retains one day by default; longer retention available through Observability Plus or Log Drains to an external destination |
| LLM providers | API inputs/outputs | Up to 30 days for trust & safety, then deleted, subject to endpoint, account controls, and contract terms |
| Nango | OAuth tokens | Until revoked |
| Doppler | API keys | Until rotated or removed |
Beyond the working base and your organization mirror, AI4Love does not retain supporter data. Processing in between is transient only.
Backup and Recovery
- Airtable provides platform-level redundancy and automatic backups for the working base, administered by AI4Love.
- Your organization mirror lives in your own workspace and is backed up and recoverable through that platform's native version history — entirely under your control, independent of AI4Love.
- AI4Love does not maintain a separate backup system beyond these two platform-native mechanisms.
- Recovery of the working base is handled through Airtable's platform capabilities, administered by AI4Love. Recovery of your organization mirror is handled entirely by your organization, through your own workspace.