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.
| Data | Bibha-hosted | Your cloud |
|---|---|---|
| Training data | Stored 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 weights | Models 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 outputs | Processed in the hosted environment by the model that serves the request. | Processed inside your environment by the models served there. |
| Logs and traces | Task 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 website | Separate 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.