Skip to main content
Bibha home

Trust

Data residency is a deployment decision, not a region checkbox.

On Bibha, residency is set by how you deploy: Bibha-hosted, in your own cloud and region, or a hybrid of the two. Each choice determines where your data is stored and processed, where models run and who operates them.

Three layers of residency control

Start from the arrangement that matches where your data may be stored and processed. Hybrid arrangements and deployments in your environment are defined with you for each system.

  • Bibha-hosted

    Bibha runs your system as a cloud service, in an agreed hosted environment that Bibha operates. You build, deploy and monitor it from the platform. Bibha does not publish a list of hosting regions, so residency specifics are agreed with you before you commit.

  • Your cloud and region

    Run the qualified Bibha stack within your own cloud account, in the region you choose, or on infrastructure you control. Storage, model serving and inference for the components deployed there stay inside your environment.

  • Hybrid

    Run some parts of the system in your environment and others on Bibha. We define with you which parts run where and how they connect, so every component has a recorded location.

A deployment label alone does not settle residency. For each system, we map with you where the model runs, where information is stored and processed, which business systems it reaches and who operates each part.

Where each kind of data lives

Residency claims fail in the details. This is where each kind of data is stored and processed in the two main arrangements.

Where each kind of data is stored and processed, by deployment arrangement
DataBibha-hostedYour cloud
Training dataStored in the agreed hosted environment, where data preparation and training jobs run.Stays in your cloud account. Data preparation and training jobs run on the compute in your environment.
Models and weightsModels you train or adapt are stored and served from the hosted environment.Models you train or adapt are stored and served inside your environment.
Prompts and outputsProcessed in the hosted environment by the model that serves the request.Processed inside your environment by the models served there.
Logs and tracesTask traces, activity history and audit history are kept in the hosted environment for the agreed retention period.Kept in your environment for the agreed retention period. Any monitoring data shared with Bibha is agreed with you.
Enquiry data from this websiteSeparate from any deployment. Our website hosting provider processes the form, and Google Workspace delivers it to the Bibha mailbox.Handled the same way, separately from your deployment.

Where each kind of data is stored and processed, by deployment arrangement

Data
Training data
Bibha-hosted
Stored in the agreed hosted environment, where data preparation and training jobs run.
Your cloud
Stays in your cloud account. Data preparation and training jobs run on the compute in your environment.
Data
Models and weights
Bibha-hosted
Models you train or adapt are stored and served from the hosted environment.
Your cloud
Models you train or adapt are stored and served inside your environment.
Data
Prompts and outputs
Bibha-hosted
Processed in the hosted environment by the model that serves the request.
Your cloud
Processed inside your environment by the models served there.
Data
Logs and traces
Bibha-hosted
Task traces, activity history and audit history are kept in the hosted environment for the agreed retention period.
Your cloud
Kept in your environment for the agreed retention period. Any monitoring data shared with Bibha is agreed with you.
Data
Enquiry data from this website
Bibha-hosted
Separate from any deployment. Our website hosting provider processes the form, and Google Workspace delivers it to the Bibha mailbox.
Your cloud
Handled the same way, separately from your deployment.

If a system uses a supported external model or another external service, the data sent to it goes to that provider. Each external service is recorded in the supplier and dependency register for the configuration, so your reviewers can see what the system relies on.

In a hybrid arrangement, each kind of data follows the component that handles it, and the configuration records where that component runs.

EU and UK customers

If your data must stay in the European Union, deploy the qualified stack in your own cloud account in an EU region. Training data, models, prompts, outputs, logs and traces held by the components deployed there stay in that region.

For a Bibha-hosted deployment, residency specifics are agreed before you commit. Where personal data is transferred outside the European Economic Area or the United Kingdom, the transfer is covered by standard contractual clauses approved by the European Commission and, for the United Kingdom, by the UK International Data Transfer Agreement or the UK Addendum to those clauses.

If Bibha people will support or operate a deployment in your EU region from outside the European Economic Area, we agree that access with you as part of the engagement, including the transfer safeguards it needs.

Your counsel decides what the regulation requires of you. Our role is to give you the deployment control to meet it, and to state where each kind of data goes. For transfer safeguards and data protection contacts, see data protection at Bibha.

India and the United States

Bibha operates through two companies: Bibha AI Labs Private Limited, headquartered in Bangalore, India, and its US affiliate, Bibha AI Inc., in Palo Alto, California.

For customers in India, the Digital Personal Data Protection Act 2023 applies. Section 16 of the Act allows personal data to be transferred outside India, except to countries the Central Government restricts by notification. Other Indian laws that restrict transfers more strictly still apply. If your policies require data to stay in India, deploy in your own cloud account in an Indian region.

Customers in the United States contract with Bibha AI Inc., which is also the contact point for privacy requests from US residents. The same deployment choices apply: Bibha-hosted, with residency agreed before you commit, or the qualified stack in your own cloud account in the region you choose.

Telemetry and access

The operating data Bibha receives from a deployment in your environment depends on who operates it. In a fully managed engagement, Bibha operates the system, so the monitoring that work needs is part of the agreed scope. In a co-build engagement, operating responsibilities after launch are agreed with you.

Access by Bibha people is governed by agreed responsibilities and our information security practices. The Bibha AI Trust Center lists ISO 27001 as compliant. On the platform:

  • Roles separate viewing, editing, execution and release authority.
  • Audit history records important access, configuration and operational changes.
  • Authorised people can stop work and revoke access.
  • In your own cloud, the access Bibha people have is agreed with you and can be withdrawn.

PeachDesk, the voice-agent solution built on Bibha, ships with product telemetry off by default. PeachDesk security describes its product controls.

Read more about security at Bibha, or check our current security and compliance status in the Bibha AI Trust Center.

Bring your residency requirements

Tell us which data may leave your environment and which may not, and which policies, contracts or regulations the deployment must meet. We will map them to a deployment with you, component by component.

Frequently asked questions

Where does our data live when we use Bibha?

That depends on the arrangement you choose. Bibha-hosted runs your system in an agreed hosted environment that Bibha operates. In your own cloud, the qualified Bibha stack runs within your cloud account, so storage, model serving and inference for those components stay in your environment. A hybrid arrangement splits the system, and we record with you which parts run where. If the system uses a supported external model or another external service, the data sent to it goes to that provider.

Can Bibha meet EU data residency requirements?

Yes, by deploying the qualified stack in your own cloud account in an EU region, where the data held by the deployed components stays in that region. For a Bibha-hosted deployment, residency specifics are agreed with you before you commit. Bibha does not publish a list of hosting regions, so we do not quote one here. Transfers of personal data outside the European Economic Area or the United Kingdom are covered by standard contractual clauses or the UK International Data Transfer Agreement.

Does the platform send our data to external model providers?

Only when your configuration uses one. Models served inside your environment process prompts and outputs there. If a step uses a supported external model or another external service, the data for that step goes to that provider. Each external service is recorded in the supplier and dependency register for the configuration, so your reviewers can see what the system relies on.

What operating data does Bibha see from a deployment in our cloud?

That depends on who operates the system. In a fully managed engagement, Bibha operates it, so the monitoring that work needs is part of the agreed scope. In a co-build engagement, operating responsibilities after launch are agreed with you. In both cases, access by Bibha people is agreed with you and governed by our information security practices.

Where is enquiry data from this website processed?

Separately from any customer deployment. Our website hosting provider processes the enquiry form, and Google, through Google Workspace, delivers enquiries to the Bibha mailbox. If no work follows, we delete an enquiry 12 months after our last contact with you. The privacy policy explains the details, including transfer safeguards.