Data handling & security

Who this is for

This page summarizes how we approach customer data, personally identifiable information (PII), and retrieval-augmented generation (RAG) when we design and operate bots and workflows for you. It is written for security questionnaires, IT review, and clinic or regulated-industry buyers. It does not replace a signed Data Processing Agreement (DPA) or Business Associate Agreement (BAA); those are provided when your engagement and regulatory posture require them.

Roles

For website visitors and inbound leads, Bots-AI is typically the data controller for personal data we collect on our own site. For delivery work, when we process personal data on your behalf (for example, content you put into a knowledge base, CRM fields we sync, or conversation logs you ask us to retain), we act as a processor or service provider under your instructions and contract, unless otherwise agreed in writing.

What data shows up in bots and RAG

Knowledge you connect. PDFs, help centers, policies, spreadsheets, and other sources you approve. This often includes PII about customers, patients, or staff if your documents contain it — which is why we work with you on minimization and redaction policies.
Tool and CRM data. Fields and records you authorize for qualification, booking, or routing (names, emails, phone numbers, case IDs, etc.).
Conversation metadata. Transcripts or logs where you request them for QA, compliance, or tuning — scope and retention are set in your order.

How RAG is handled

Retrieval systems we build connect approved sources to a language model so answers can be grounded and cited. In typical engagements: content is chunked and embedded for search; prompts and retrieved snippets are sent to model APIs you approve; outputs are constrained by playbooks you sign off on. We do not use your production knowledge to train public foundation models unless a separate written addendum explicitly allows it. Configuration details (regions, model providers, retention of embeddings) are documented in your statement of work and architecture appendix.

PII minimization and your obligations

You are in the best position to know which fields and documents are necessary. We recommend excluding full clinical records or unnecessary identifiers from general-purpose bots unless the use case and legal basis require otherwise. We can help implement role-based access, allow-lists for tools, and logging — but classification and lawful basis for processing remain your responsibility unless we have agreed to a different allocation in writing.

Encryption and transmission

We use HTTPS/TLS for data in transit between browsers, our applications, and major cloud APIs in standard configurations. Where providers support encryption at rest for vectors, databases, and object storage, we enable it as part of the agreed architecture. Specific algorithms and key management are listed in security appendices or your vendor questionnaire responses.

Access control and logging

Production environments use role-based access for our team and yours, least-privilege credentials for integrations, and audit trails where the stack supports them. Administrative access to your tenant is limited to people who need it for support, under confidentiality obligations.

Subprocessors and LLM providers

Deliveries often rely on cloud hosting, model APIs, telephony/SMS, email, and your existing SaaS stack. We maintain a subprocessor list for active customers and notify you of material changes as required by your DPA. You choose which model and hosting regions are acceptable during design — including private or VPC deployments when scope and budget support them. For procurement-focused detail (including how we share schedules under NDA), see Security & trust.

Retention and deletion

Retention defaults follow your contract: embeddings and indexes are removed or refreshed when you retire a source; logs follow the window you set (for example 30, 90, or 365 days). Upon offboarding, we delete or return customer content per the MSA and runbook, subject to legal holds.

Regulated industries (including HIPAA)

Many clinic and health-adjacent use cases can be structured around operational FAQs, scheduling, and non-clinical workflows to reduce exposure of PHI. Where PHI will be processed by systems we operate, a BAA and HIPAA-aligned architecture are required before go-live. We do not represent that a generic landing-page engagement is HIPAA-ready until that review is complete.

Incidents

We maintain an internal incident response process. If we become aware of a breach affecting personal data we process for you, we notify you without undue delay and cooperate on regulator or individual notices as your agreement and law require.

Security questionnaires

We complete SIG Lite / CAIQ-style questionnaires and architecture reviews under NDA for qualified opportunities. Start with the contact email at the bottom of this page and reference your project timeline.