Skip to content
BuildClub — AI Built in Plain Sight

DATA SECURITY

You choose where it runs.

How BuildClub deploys, handles customer data, and meets your security posture. Deployment modes, controls, and the architecture in plain terms.

Request a conversation →

Data handling

  • We do NOT use your data to train shared or public models
  • Customer data is processed within isolated workspaces, not shared infrastructure
  • All data in transit is encrypted (TLS 1.3); data at rest is encrypted (AES-256)
  • Access is gated by SSO and short-lived tokens with audit logging
  • Deletion on request — within 30 days, with deletion audit trail

Hosting & infrastructure

  • Primary infrastructure on AWS (us-east-1) and Google Cloud (us-central1)
  • Data residency available on request for EU customers (eu-west-1)
  • Backups encrypted and retained for 30 days
  • DDoS protection via Cloudflare

AI model access

  • LLM calls through enterprise-grade API tiers (Anthropic, OpenAI, Google) with zero-retention agreements
  • For sensitive workloads, we deploy on-premise or private cloud LLMs (Mistral, Llama)
  • Model selection per workload — we don't lock you into any single vendor

Compliance posture

  • SOC 2 Type II audit in progress. Gap assessment available under NDA.
  • HIPAA-ready for healthcare engagements
  • GDPR-aligned for EU operations
  • Annual penetration testing and vulnerability scanning

Operational practices

  • Background checks for all team members with customer data access
  • MFA enforced on all internal systems
  • Quarterly access reviews
  • Incident response: 4-hour notification commitment for material incidents

Vendor management

  • We maintain an up-to-date subprocessor list
  • Customer notification before adding new subprocessors
  • Each subprocessor reviewed annually

Three deployment modes

Where your data lives is your call. We build to match. BuildClub deploys in three modes depending on what your security, compliance, and data residency posture requires. The deployment mode is decided in Phase 0, not after — and the choice shapes everything that follows: integration points, identity flow, audit logging, and where models actually run.

In-tenant. The full system runs inside your existing Azure, AWS, or GCP tenant. Your data never leaves your environment. Your identity provider stays the source of truth. Your existing audit logging captures every action. Best for HIPAA, financial services, regulated industries, and any organization with a formal data residency posture.

BuildClub-managed dedicated. A dedicated environment in BuildClub's AWS infrastructure, isolated per customer at the account level. Faster to deploy than in-tenant. Appropriate for companies with strong confidentiality requirements but no specific data residency mandate. Backed by signed DPAs, BAAs where applicable, and named-account SRE coverage.

Sovereign deployment. For organizations with explicit sovereign data residency requirements — regulated industries in specific jurisdictions, defense-adjacent work, certain public-sector deployments. Hosted entirely within the customer's specified national cloud region with no cross-border data flow.

Standard across every deployment

Regardless of deployment mode, every BuildClub system enforces:

  • Identity and access. Customer SSO is the source of truth. We do not maintain a parallel user directory. Every action is attributable to a named identity in the customer's IdP.
  • Knowledge partitioning. Access-scoped knowledge partitions enforced at the data layer, not at the UI layer. The same source material can serve multiple teams without any team being able to access another team's scope.
  • Audit logging. Every query, every retrieval, every tool invocation logged with timestamp, identity, and content reference. Routed to the customer's existing SIEM or audit trail.
  • PII and PHI handling. Sensitive data is filtered at ingestion when possible, segregated by partition when not. PHI handling complies with HIPAA in all deployment modes; the in-tenant mode is the default for HIPAA-regulated customers.
  • Encryption. TLS 1.3 in transit. AES-256 at rest. Customer-managed keys where the deployment mode supports them.
  • Model routing. Customers choose which models we use. Production deployments default to Anthropic Claude; we support Azure OpenAI, AWS Bedrock, and Google Vertex AI based on the customer's existing model relationship.
  • No training on customer data. We do not use customer content to train models. This is contractual, not aspirational. Applies across every deployment mode.

The architecture in plain terms

When a user asks a question through BuildClub, the request is authenticated against the customer's IdP, evaluated against the user's partition scope, routed to the model layer with the appropriate retrieved context, and logged before the response returns. The model itself does not have unrestricted access to the customer's data — it sees only the partitioned, retrieval-grounded slice that the user's scope and the query intent justify.

The retrieval layer is what gives the system its operating discipline. We do not pass entire databases or document corpora to the model. We pass the minimum relevant context for the question being asked, drawn from partitions the user is authorized to access. This is what makes the same underlying knowledge base safely usable across teams with different access scopes.

Tool invocations — writing back to Salesforce, drafting a reply in Outlook, opening a case in ServiceNow — go through audited, scoped integrations. We do not give the model raw access to customer systems. Every tool call is an explicit, logged, permissioned operation, and the underlying integration uses service principals or OAuth scopes that the customer's IT team controls.

Architecture diagrams covering all of this in detail are in the Security & Architecture Brief, available under NDA.

Available under NDA

Security & Architecture Brief. A detailed technical document covering identity flow, data flow, model routing, encryption posture, key management, audit logging architecture, and per-deployment-mode variations. Standard request from security review desks.

SOC 2 audit posture. Type II audit in progress. Gap assessment and bridge documentation available under NDA. Full attestation will be shared once complete.

Penetration test results. Most recent third-party penetration test summary, available under NDA.

How this gets decided

Deployment mode is decided in Phase 0, alongside the data audit and operational mapping. By the end of Phase 0, you have an explicit recommendation on which deployment mode fits your security posture, your compliance requirements, and your operating model — and a clear-eyed view of what that decision implies for cost, timeline, and integration complexity downstream.

If you are evaluating BuildClub for an engagement and your security team needs answers before the first call, start with a Phase 0 conversation. We will give you the architecture briefing and the deployment-mode recommendation as part of that work.

Want to walk through the security model with our team?

Most security reviews are 30–60 minutes. We're happy to talk through deployment modes, controls, and how we'd structure your specific engagement.