Appearance
Data Handling v3.9
Last updated: September 30, 2026
Bounded Retention
AI4Love holds one working Airtable base per organization in AI4Love's account as a service provider. The base is isolated per organization. It exists only while service is active plus a 90-day exit window, then it is deleted. Full export is available on request. The client organization remains the institution responsible for the personal information under FIPPA. An organization-held mirror (Owned Copy) is designed but not running in production and is described only as planned.
| 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 (planned — Google Sheets or comparable, your workspace) | People, activity, and insight records — records only, no formulas, automations, or analysis machinery | Your organization | Indefinite — would survive cancellation permanently |
Being direct about the current state: the nightly publisher job that would sync people, activity, and insight records — write-only — from the working base to your organization's mirror file has not shipped yet. It is designed and available to be built as part of your onboarding, and this page will describe it in the present tense only once it is actually running. Until your mirror is provisioned, you can request a full export of the working base at any time. Once provisioned, you would be able to 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 these stores entirely — read-only, never modified, unaffected by anything described on this page.
On cancellation:
- If a mirror has been provisioned for your organization, it is untouched — it 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.
A full export is available on request at any time, and our working store is bounded — active while you're a customer, deleted 90 days after you're not. Once the mirror ships for your organization, you will also hold a continuously updated copy of your own.
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 campaign workflow metadata from the dashboard. The MCP server writes nothing. 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.
Suppression and Source Deletion
AI4Love mirrors the client's system of record. Do-not-contact and no-solicitation codes carry over on the nightly sync, halt insight generation for the person, and close open insights. Source-system deletions and merges are removed from the AI4Love base; during pilot phase this is a removal request completed within 5 business days with written confirmation, with automatic propagation on the roadmap. Erasure requests received directly by AI4Love are routed to the client as data controller.
Every removal, merge, and suppression close is recorded in an operations log in the working base (type, record, source identifier, date, who confirmed it). The log never holds the person's name or email.
Identity
Identity follows the source systems. For CRM sources the source constituent/record ID is the primary matching key, email secondary for email-only sources. Email changes update the existing record in place. Duplicates are merged with suppression flags preserved and merges logged.
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. For MCP, removing an organization API key stops access at the next request; an assistant signed in with OAuth holds a 30-minute access token, so removing a staff member's access key stops it at its next token refresh, within 30 minutes. Effectiveness ultimately depends on the provider invalidating the token on their end. - Session behaviour on revocation: Both MCP transports check the credential on every request. The older SSE transport keeps a short-lived in-memory session that only pins the organization; it never authenticates on its own. An OAuth access token stays valid until its 30-minute expiry, and the refresh that would replace it is refused once the staff member's access key is removed.
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.
When a mirror is provisioned for your organization, access to it will use a service account with editor rights on that one file only — nothing else in your workspace. You will be able to 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 from the trash for 7 days and deleted bases for 30 days, then permanently removed. Base snapshots are restore-only backups retained for up to 1 year on the Team plan; AI4Love never queries them, and logged deletions are re-applied before any restored base returns to service. Both are administered by AI4Love. A provisioned mirror file's version history and recovery would run entirely on your own workspace's native controls (e.g., Google Sheets version history), independent of AI4Love.
Data Residency
All infrastructure is US-hosted. Canadian data residency is not currently available.
- Airtable working bases and Pinecone (sector research index and client vault) are hosted in AWS
us-east-1. AI4Love's Airtable workspace uses the Team plan. Pinecone holds no supporter records. - Vercel backend API and MCP functions run in
iad1(Washington, D.C.), pinned in each project'svercel.json. - Make.com uses the US
us2data center. Axiom stores application audit events and runtime logs in AWSus-east-1. - Anthropic and OpenAI API-tier processing used by AI4Love is in the US. A staff member's own assistant connected through MCP is governed separately by that workspace's terms and settings.
- Nango (OAuth credential vault) is hosted in the US. AI4Love does not offer a Canadian or self-hosted Nango deployment.
- Organization mirror (planned. Google Sheets or comparable) would reside in your organization's own workspace and follow that workspace’s hosting location, outside AI4Love's control. It does not change the US hosting of AI4Love's working base or processing.
See Sub-Processors for each provider's region and role.
Data Retention
| Layer | What | Retention |
|---|---|---|
| Organization-held mirror (when provisioned) | 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 |
| Airtable base trash | Deleted records and deleted bases | Records recoverable for 7 days, bases for 30 days, then permanently removed |
| Airtable base snapshots | Restore-only backups of the working base | Retained up to 1 year on our Team plan (Airtable snapshot policy). Never queried by AI4Love. Logged deletions are re-applied before any restored base returns to service |
| Pinecone (sector research index and client vault) | Published sector research and client-provided organizational documents. No supporter data | AWS us-east-1 (Virginia). Client vault purged at end of service |
| Device-level artifact caches | Live Artifacts rendered in a staff member's assistant client may be cached on that device by the client application | Controlled by the staff member's device and client application, not by AI4Love, which holds no copy. Cleared by the client's cache policy or by the staff member |
| Application memory | Transient request data | Request-scoped; not used as a durable data store |
| Vercel runtime logs | Application audit events and request metadata, including staff email as actor identifier, caller IP, and user agent. No supporter data | One day; audit events also streamed to Axiom, retained 30 days |
| Axiom | Application audit events and Vercel runtime logs from ai4love-backend and stilltide-mcp only; no supporter data | 30 days on the Personal plan; Log Drain added September 14, 2026. See Axiom |
| Per-organization Access Log (planned — ships before first client go-live) | Supporter record views, exports, and integration changes: staff identifier, event, record IDs, timestamp | Planned in the working base; follows active service + 90-day exit window, then deletion |
| 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, once provisioned — 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.
- A provisioned organization mirror would live in your own workspace and be 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 platform-native mechanisms.
- Recovery of the working base is handled through Airtable's platform capabilities, administered by AI4Love. Recovery of a provisioned organization mirror would be handled entirely by your organization, through your own workspace.