Privacy Policy & Data Security

Kindred Point ("KP", "we", "our") is built specifically for nonprofits, cultural venues, and mission-driven organizations. We understand that donor records, member rosters, and financial transactions represent a sacred trust between you and the people who support your mission. This policy explains what we collect, how we secure it, and how AI features interact with your data.

Account information: Organization name, billing contact, staff user names and email addresses.

Operational data you create in KP: Donor and customer records, donations, memberships, tickets, orders, events, grants, pledges, and the supporting fields you choose to capture (e.g. addresses, phone numbers, giving history, notes).

Payment data: Card numbers and bank details are never stored in KP. All payments are processed by Stripe (PCI-DSS Level 1 certified). KP stores only non-sensitive transaction references (e.g. Stripe charge IDs, last-4 digits, payment status).

Technical data: Log data, IP addresses, browser type, and usage telemetry needed to operate, secure, and improve the platform.

2. How We Use Your Information

• Provide, maintain, and improve the KP platform for your organization
• Process transactions and deliver receipts, acknowledgments, and statements
• Send technical notices, security alerts, and support communications
• Respond to your support requests and product questions
• Monitor usage to detect abuse, fraud, and reliability issues
• Generate aggregate, de-identified analytics about platform health

We do not sell your data. Ever. We do not rent it, share it for advertising, or use it to enrich any third-party data product.

Encryption at rest

All operational data is encrypted at rest using AES-256 in our managed cloud database. Backups are encrypted with the same standard and stored in geographically redundant locations.

Encryption in transit

All connections to KP — web app, mobile browsers, API calls, and webhooks — are protected with TLS 1.2 or higher. Insecure HTTP connections are automatically upgraded or rejected.

Tenant isolation

KP is a multi-tenant platform. Every record in the database carries a tenant_id, and every query — whether from the UI, an integration, or our AI features — is filtered to your tenant at the backend layer. There is no path by which one organization can read or modify another organization's data, even by accident.

Access control

Access to your KP workspace requires authentication. Staff users are assigned roles (admin, manager, development, POS, front-gate) and only see the pages and actions their role permits. Point-of-sale stations can be locked with staff PINs that re-prompt on idle. Sensitive operations (refunds, voids, tenant data wipes) are gated behind role checks and audit logging.

Payment security

KP never sees, transmits, or stores raw card numbers, CVVs, or bank account credentials. Stripe Elements collect payment details directly from the customer's browser to Stripe's servers. KP receives only tokenized references. This means our scope under PCI-DSS is minimized to the lowest applicable level.

Third-party integrations

When you connect QuickBooks, Constant Contact, Printful, EasyPost, or Twilio, OAuth tokens are stored encrypted at rest and used only to perform the actions you've configured. You can disconnect any integration at any time, which immediately revokes the stored credentials.

Audit trail

Sensitive write operations — refunds, voids, role changes, manual billing overrides, AI queries — are recorded with the acting user's email and timestamp. Administrators can review activity logs within their tenant.

KP Assistant and other AI-powered helpers (grant narrative drafting, outcome summaries, policy drafting) use large language models from established providers (OpenAI, Anthropic, Google) accessed exclusively through their enterprise APIs via Base44's InvokeLLM integration. KP never sends your data to consumer chatbot products (ChatGPT, Claude.ai, Gemini consumer) — only to enterprise API endpoints with the stronger commercial terms described below.

Your data is never used to train AI models

All AI calls are made under enterprise / commercial API terms that contractually prohibit the provider from using submitted inputs or generated outputs to train, fine-tune, or improve their models. This is fundamentally different from consumer AI products, where conversations may be used for training. Specifically:

• OpenAI API: Data submitted via the API is not used to train OpenAI models by default. Inputs may be retained for up to 30 days for abuse and misuse monitoring only, then deleted.
• Anthropic API: Customer API data is not used to train Anthropic's models. Inputs and outputs are not retained beyond the immediate request.
• Google (Vertex AI / Gemini API): Customer data submitted through the API is not used to train Google's foundation models.

These commitments are part of each provider's published commercial API terms — not internal promises — and any change would require advance notice.

How an AI request actually flows

When a staff user asks KP Assistant a question, the data path is:

1. The user types a prompt inside KP.
2. KP's backend runs scoped database queries filtered to your tenant_id.
3. The user's question plus only the resulting rows (not your full database) are sent to the AI provider over TLS via Base44's InvokeLLM integration.
4. The provider returns a response, which is shown to the user and logged with their email.
5. The provider discards the input and output — nothing is retained for training.

Tenant isolation extends to AI

Every AI query runs through the same tenant-scoping that protects the rest of the platform. KP Assistant cannot read records belonging to another organization, even if asked. It executes pre-defined backend tools that always filter by your tenant_id before returning results. Two organizations' data is never mixed in the same request.

Minimum-necessary data

KP Assistant does not transmit your entire database to the AI provider. It runs scoped queries (e.g. "top 10 donors this quarter") and includes only the resulting rows needed to answer the question — typically a few dozen records, not your full constituent list. Sensitive fields that are not stored in KP (full SSNs, raw card numbers, bank account credentials, CVVs) cannot be sent because they do not exist in our database to begin with.

Read-mostly access and bounded actions

KP Assistant cannot refund payments, charge cards, modify donation amounts, or delete records. The only "write" actions available to it are logging touchpoints, creating donor tasks, and drafting content for staff review — all of which are audit-trailed with the requesting user's email. The blast radius of any AI action is bounded by design.

Tenant controls

Each organization can disable AI features entirely through a per-tenant kill switch (ai_assistant_enabled) and choose a model tier (economy / standard / premium). Daily usage caps prevent runaway costs and unusual activity. All AI invocations are recorded in a per-tenant usage log (TenantAiUsageLog) capturing the requesting user, timestamp, and token count, which administrators can audit at any time.

Transparency and grounding

KP Assistant cites which records it drew from when answering a question. If you cannot see the source data, the assistant did not either. We do not use AI features to generate financial figures, donor counts, or other reportable numbers without underlying records to back them.

What we do not claim

We want to be candid about the limits of what any AI vendor can guarantee. We cannot promise that a model provider will never suffer a security incident, and we cannot inspect the internal operations of OpenAI, Anthropic, or Google. What we can promise is the architecture above: enterprise API terms, tenant isolation enforced before the AI ever sees data, minimum-necessary payloads, bounded write actions, full audit logging, and a per-tenant kill switch that disables AI features instantly. If a provider ever materially changed its training or retention terms, our integration is provider-agnostic and we would route around them.

Retention: We retain your operational data for as long as your KP account is active. If you cancel, your data remains accessible for 90 days, after which it can be exported on request and then permanently deleted from production systems. Encrypted backups roll off according to a documented schedule.

Export: You can export your donors, donations, customers, orders, memberships, and other records as CSV at any time from within KP.

Deletion: You can delete individual donor records, merge duplicates, or request a full tenant data wipe by contacting info@kindredpoint.com. Tenant wipes are confirmed in writing and logged.

Your donors' rights: Donors and constituents whose data you've collected in KP have rights under applicable law (GDPR, CCPA, state privacy laws) including access, correction, and deletion. KP gives your organization the tools to honor those requests — exports, edits, deletions, and consent tracking — and you, as the data controller, are responsible for responding to them.

We rely on a small set of trusted subprocessors to operate KP. Each is bound by data protection terms equivalent to or stronger than those we offer you.

• Base44 — application hosting and managed database (encrypted at rest)
• Stripe — payment processing (PCI-DSS Level 1)
• OpenAI / Anthropic / Google — AI model inference under enterprise API terms (no training on submitted data)
• SendPulse / SMTP provider — transactional email delivery
• Twilio — SMS delivery (only when you've configured it)
• Optional connectors — QuickBooks, Constant Contact, EasyPost, Printful — used only when you choose to connect them

7. Cookies & Local Storage

KP uses cookies and browser local storage strictly for authentication, session management, and user preferences (e.g. remembering your selected tenant or sidebar state). We do not use third-party advertising cookies or cross-site tracking.

8. Security Incident Response

In the unlikely event of a security incident that affects your data, we will notify affected tenant administrators without undue delay and provide details on scope, impact, and remediation. We maintain an internal incident response process covering detection, containment, recovery, and post-incident review.

9. Changes to This Policy

We may update this policy as our platform evolves or as legal requirements change. Material changes will be communicated to tenant administrators by email. The "Last updated" date at the top of this page always reflects the current version.

10. Contact Us

Questions about this policy, data security, AI usage, subprocessors, or a specific data request:

info@kindredpoint.com