Data Residency - Graphor Docs

The footprint

All Graphor production processing and storage occurs in the us-central1 Google Cloud region (Iowa, USA), with one exception: large-language-model inference is served from US AWS regions through Amazon Bedrock. There are no other production regions, no multi-region buckets, no edge caches that hold customer content, and no replication across continents. This single-region posture is intentional. Regulated customers benefit from a residency story that fits on one line and that an auditor can verify with a single check per component.

1. Per-component residency

The table below covers every layer of the Graphor production environment that touches customer data, including derived content and operational telemetry. Anything not listed here does not process customer data.

Layer	Region	Notes
Authenticated application backend (REST, streaming, MCP transports)	`us-central1`	Stateless. No customer data persisted on the backend instances.
Asynchronous ingestion workers	`us-central1`	Long-running ingestion workflow — parsing, chunking, enrichment, embedding, indexing.
Document parsing service	`us-central1`	Hosts the in-house parsing pipeline (OCR, partitioning, visual embedding). Runs in-house parsing models — no document content sent to an external parsing provider.
Primary relational database	`us-central1`	Stores Account Information, Conversations, Project metadata, API tokens, and billing-record identifiers. Automated backups + point-in-time recovery enabled (Data Retention §5).
Managed graph store	North American region under the managed graph provider’s footprint	Holds source nodes, document partitions, retrievable units (with embedding vectors), and per-Project indexes. See Subprocessors §2.
In-memory cache + streaming fan-out	`us-central1`	Ephemeral cache, streaming notifications, idempotency keys. No Customer Content persisted.
Internal event bus + analytics aggregation	`us-central1`	Carries operational events and aggregates them into an internal analytics store (counters and metadata only — no Customer Content).
Object storage — Customer documents	`us-central1` (single-region; migrated from US multi-region)	Raw uploaded sources (PDFs, DOCX, audio, video, etc.).
Object storage — internal artifacts (model weights, public marketing assets, TLS certificate artifacts)	`us-central1` (single-region)	No Customer Content.
Self-hosted observability store	`us-central1`	Tier-aware (Enterprise default OFF, Free/Pro default ON with PII mask). See Data Retention §4.
Encryption keys	`us-central1`	Cloud-provider-managed by default; customer-managed encryption keys available on enterprise request. See Trust Center Overview.

2. AI model providers

AI inference is the only customer-data path that leaves Google Cloud. The provider chain (and the regions involved) is summarized below; full subprocessor characterization is in Subprocessors.

Provider	Production region(s)	Customer data sent	Retention
AWS Bedrock (serves Anthropic Claude family)	US regions only — `us-east-1`, `us-east-2`, `us-west-1`, `us-west-2`. The São Paulo region (`sa-east-1`) is configured as an optional failover but is not active in standard routing.	Per-request: the user’s question, retrieved chunks, conversation history, system prompt.	Per AWS Bedrock data-protection commitments — content is processed and encrypted in the AWS region selected; not retained for training; not shared with model providers.
OpenAI (embeddings + optional reranker)	Not pinned by basic documentation.	Per-build: chunk text for embedding. Per-request (only when reranker is enabled, which is off by default): retrieved chunks.	Zero Data Retention enrolled — abuse-monitoring logs eliminated. See Model Use and Training §4.3.
Cerebras (chunk enrichment + fast-tier inference)	US-based infrastructure.	Per-build: chunk text for enrichment. Per fast-tier request: user question + retrieved chunks.	Zero retention per published Privacy Policy.

No customer content transits any region that is not listed above.

3. International transfer regime

Synapse is incorporated in Brazil and the catalyzing pilot customers are subject to LGPD; the same posture also satisfies GDPR for European customers.

Transfer leg	Legal basis	Source of contract
Customer → Synapse	Direct controller-to-processor relationship under the Graphor Data Processing Addendum.	Synapse–Customer DPA.
Synapse → cloud infrastructure provider (`us-central1`)	LGPD art. 33, II, b (specific or standard contractual clauses for international transfer); art. 35 governs ANPD’s role in defining the model clauses. Inherited via the cloud-provider DPA, which incorporates Standard Contractual Clauses 2021/914 for EU customers and the ANPD-approved Cláusulas-Padrão Contratuais (Resolução CD/ANPD nº 19/2024) for Brazilian customers per DPA Annex 4.	Cloud-provider Data Processing Addendum (linked from Subprocessors §2).
Synapse → AWS Bedrock (US regions)	LGPD art. 33, II, b; AWS DPA incorporates Standard Contractual Clauses.	AWS Data Processing Addendum (linked from Subprocessors §3).
Synapse → OpenAI	LGPD art. 33, II, b; OpenAI DPA incorporates Standard Contractual Clauses; ZDR addendum signed.	OpenAI DPA + ZDR addendum (linked from Subprocessors §3).
Synapse → Cerebras	LGPD art. 33, II, b; subject to Cerebras Terms of Use and Privacy Policy commitments cited in Model Use and Training §4.4.	Cerebras Terms of Use + Privacy Policy (linked from Subprocessors §3).
Synapse → managed graph store provider	LGPD art. 33, II, b; provider DPA incorporates Standard Contractual Clauses.	Provider DPA (linked from Subprocessors §2).
Synapse → payment processor	LGPD art. 33, II, b; payment-processor DPA incorporates Standard Contractual Clauses. Payment processor handles only billing identifiers, not Customer Content.	Payment-processor DPA (linked from Subprocessors §5).

Every transfer is governed by a contract that incorporates Standard Contractual Clauses or an equivalent. The complete set of clauses is referenced and made available to enterprise customers under NDA via privacy@graphorlm.com.

4. Transfer Impact Assessment — US compelled-disclosure regime

Customers subject to LGPD or GDPR conducting a transfer-impact assessment (“TIA”) for the Brazil → US (and EU → US) leg should be aware of the following. This section satisfies the ANPD transfer-impact-assessment expectation under Resolução CD/ANPD nº 19/2024 and the Schrems II–style impact-assessment expectation under GDPR art. 46(2)(c).

4.1 US compelled-disclosure vectors

Customer Personal Data Processed in us-central1 and in AWS Bedrock US regions is in principle reachable by the following US legal mechanisms:

US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2713) — extends Stored Communications Act process to data held by US-based providers irrespective of storage location.
FISA Section 702 / Executive Order 12333 — authorities relevant to non-US persons; primary Schrems II concern.
Federal subpoenas, search warrants, and National Security Letters under standard US federal criminal procedure.

4.2 Technical and operational safeguards that constrain reachable scope

Encryption at rest on every backing store; cloud-provider-managed keys today, customer-managed encryption keys available on enterprise request (see Tenant Isolation §1). A request that compels the cloud provider rather than Synapse cannot decrypt customer data without the application-layer access path; customer-managed keys further reduce reachability. Personnel-side safeguards on the application access path are documented in Tenant Isolation §7.
Encryption in transit TLS 1.2+ on every public surface (Architecture §5).
Logical tenant isolation enforced at the application layer (Tenant Isolation §1); compelled disclosure of “all data” at the infrastructure level still requires Synapse-side application access to reconstruct a Customer-scoped view.
Zero-retention or no-training commitments at AI providers (Model Use and Training §4): AWS Bedrock does not retain or share inputs with model providers; OpenAI ZDR eliminates the default 30-day abuse-monitoring log; Cerebras commits to zero retention. A US request against any of these providers reaches a smaller residual surface than a request against a provider with default retention.

4.3 EU–US Data Privacy Framework (DPF) — additional safeguard for EU customers

For EU/EEA/Swiss customers, the EU–US Data Privacy Framework adequacy decision (Commission Implementing Decision (EU) 2023/1795 of 10 July 2023) provides an additional adequacy basis where the US importer is DPF-certified. Synapse confirms DPF certification status of each US subprocessor at least annually via the DPF participant list:

Google Cloud Platform (incl. Firebase Auth) — DPF-certified (verify on the DPF list at engagement).
AWS (incl. Bedrock) — DPF-certified (verify at engagement).
OpenAI — DPF certification status varies; the OpenAI ZDR enrollment is the primary safeguard for OpenAI transfers.
Cerebras — DPF certification status to be confirmed at engagement.
Stripe — DPF-certified (verify at engagement).

The DPF does not displace the SCC-based safeguards in §3 or the technical and organizational measures in §4.2; it complements them as an additional adequacy anchor for EU customer transfers. If a Synapse subprocessor loses DPF certification, the SCC-based safeguards remain in force and customers are notified per the subprocessor-change procedure in Subprocessors.

4.4 Synapse’s commitments under compelled disclosure

Per DPA §9, if Synapse receives a binding legal request directly from a competent authority for disclosure of Customer Personal Data:

Synapse notifies the Customer of the request to the extent legally permitted, allowing the Customer to seek a protective order or other remedy;
Where notification is prohibited, Synapse takes reasonable steps to inform the Customer of the request once the prohibition expires;
Synapse discloses only the minimum data required to comply with the request;
Synapse challenges overbroad or facially unlawful requests using available legal procedure, engaging Brazilian counsel for requests received in Brazil and instructing US counsel-on-retainer for any request properly served on Synapse in the US.

For requests served on a US-based subprocessor (e.g., a CLOUD Act subpoena to Google or AWS for data Synapse stores on their infrastructure), Synapse has no direct standing to challenge in US courts. Synapse relies on (i) each subprocessor’s own published transparency-report commitment to challenge overbroad requests (e.g., Google’s Government Requests for User Information policy, AWS’s law-enforcement information-requests page) and (ii) the SCC clauses obligating the subprocessor to notify the data importer (Synapse) and to challenge unlawful access. Synapse will, in turn, notify the Customer per the bullet list above to the extent legally permitted.

4.5 Brazilian Marco Civil interplay

For Customer Personal Data of Brazilian data subjects, Lei nº 12.965/2014 (Marco Civil da Internet) art. 11 establishes that the Brazilian legal framework applies to data-collection, storage, and processing operations where at least one of the parties is in Brazil — applicable to Synapse (incorporated in Brazil) as the controller in the controller-to-processor chain. This means:

Brazilian data subjects retain full LGPD enforcement rights against Synapse irrespective of the US processing location;
ANPD has jurisdiction over Synapse’s processing of Brazilian personal data, including the international-transfer leg;
The Cláusulas-Padrão Contratuais incorporated in DPA Annex 4-B bind Synapse contractually to LGPD-equivalent protections at the US processing destination.

4.6 Customer options for compounded risk reduction

Customers with elevated transfer-impact concerns may:

Request customer-managed encryption keys (see Tenant Isolation §1) so that even infrastructure-level compelled disclosure does not yield decryptable data without Synapse-side application access — typical scoping engagement: 4–8 weeks.
Request the São Paulo region option on the Data Residency roadmap §6, which removes the US processing leg for the relational, object, and (where supported) graph stores.
Disable observability tracing entirely (the Enterprise default) and rely on the DSR API for any post-hoc audit need.
Restrict ingestion of special-category personal data (LGPD art. 11) to non-Graphor channels until the alternative-region engagement is in place.

5. Why us-central1

A single cloud region was chosen rather than a multi-region storage deployment or a cross-region active-active design for three reasons:

Auditability. A regulated customer can verify the residency claim by running a single command per layer against the cloud-provider CLI and confirming the region. A multi-region claim demands provider-level trust that data does not move between sub-regions.
Predictable latency for the Brazilian user base. us-central1 (Iowa) is one of the lower-latency US regions for traffic originating in Brazil over public-internet routes. The latency tradeoff vs a São Paulo region is acceptable for current traffic patterns; see §6 for the Brazil-region roadmap.
Subprocessor co-location with AWS US regions. Bedrock-hosted inference returns to Graphor over public network paths; co-locating the Graphor backend with the Bedrock regions reduces round-trip variance.

The migration of the customer-content storage from US multi-region to us-central1 single-region was completed as part of this trust-documentation initiative. Stg is intentionally not migrated — it does not host real customer data.

6. Roadmap

Two alternative regions are on the roadmap. Neither has a committed delivery date — both unlock on customer request for the enterprise tier, subject to a cost/timeline review per customer. EU region — for GDPR-bound customers that require EU-only residency end-to-end. Tradeoffs:

Requires migrating every component in the per-layer residency table to an EU region.
Requires switching the Bedrock region to an EU Bedrock region. Anthropic Claude availability in EU Bedrock regions varies by model; the Standard tier model would be pinned to whichever Opus version is GA in the chosen EU Bedrock region at the time of provisioning.
OpenAI does not pin a residency region today; the EU posture would rely on the OpenAI ZDR addendum (zero retention) as the compensating control, or replace OpenAI embeddings with a self-hosted embedding model on the EU footprint.
The managed graph store supports EU regions natively.

Brazil region (São Paulo) — for LGPD-bound customers that prefer Brazilian residency, or for customers in regulated sectors where Brazilian residency is explicitly required (some federal-government workloads, certain Bacen guidelines). Tradeoffs:

The cloud infrastructure provider supports the full Graphor stack in the São Paulo region.
AWS Bedrock is already available in sa-east-1 (São Paulo) — Anthropic Claude on Bedrock is GA in this region. The Standard tier could be served entirely from Brazilian regions if the customer requires it; this is the lightest-lift alternative residency option.
The managed graph store does not currently offer a São Paulo region; the Brazil deployment would either accept a North-American managed instance (with the contractual residency commitment from the provider) or migrate to a self-hosted graph store on the São Paulo footprint.
OpenAI embeddings remain non-region-pinned; same compensating control as the EU case.

Customers interested in either region should email privacy@graphorlm.com with a brief description of the residency requirement (regulatory citation, contractual obligation, internal policy). A scoping conversation establishes feasibility, timeline, and any incremental cost surcharge for the alternative region’s infrastructure.

7. Things that explicitly do NOT happen

Stating these explicitly removes ambiguity for security and privacy reviewers:

No cross-region replication of Customer Content. The customer-content storage is single-region; the primary relational database has no cross-region replica; backups stay within the cloud-provider region’s redundancy posture.
No CDN caching of authenticated responses. Authenticated application responses are not cached in any edge location. Public marketing assets may be edge-cached but contain no Customer Content.
No content sent to a multi-region or global resource by default. The legacy multi-region customer-content store has been migrated; no production component routes customer data through a multi-region resource.
No silent regional failover. AWS Bedrock has configured failover regions (US-only) that activate on quota or availability events; the failover regions are all US. The São Paulo (sa-east-1) slot is configured but inactive in standard routing — a future activation will be published on the Subprocessors page before it takes effect.

8. Change history

Version	Date	Change
1.0	2026-06-21	Initial publication. Documents the single-region `us-central1` posture post-migration of the customer-content storage.

When the production region, the subprocessor region inventory, or the alternative-region roadmap status changes, this table is updated and subscribers to subprocessors@graphorlm.com receive an email.

Contact

General privacy and data-residency inquiries: privacy@graphorlm.com
Residency change notifications: subprocessors@graphorlm.com
Customer support: support@graphorlm.com

​The footprint

​1. Per-component residency

​2. AI model providers

​3. International transfer regime

​4. Transfer Impact Assessment — US compelled-disclosure regime

​4.1 US compelled-disclosure vectors

​4.2 Technical and operational safeguards that constrain reachable scope

​4.3 EU–US Data Privacy Framework (DPF) — additional safeguard for EU customers

​4.4 Synapse’s commitments under compelled disclosure

​4.5 Brazilian Marco Civil interplay

​4.6 Customer options for compounded risk reduction

​5. Why us-central1

​6. Roadmap

​7. Things that explicitly do NOT happen

​8. Change history

​Contact