> For the complete documentation index, see [llms.txt](https://boza.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://boza.gitbook.io/docs/settings-and-security/data-privacy-gdpr.md).

# Data Privacy & GDPR

Use this page to understand the product's main data flows and the decisions your organization must make before rollout.

{% hint style="warning" %}
This is a product guide, not a Data Processing Agreement (DPA), privacy notice, or legal opinion. Your contract, DPA, current sub-processor list, and approved security materials are authoritative. Have your privacy and legal owners validate the legal basis, retention, employee notice, and access model for your deployment.
{% endhint %}

## Roles and Responsibilities

Boza generally processes customer workspace data under the instructions of the customer organization. The organization remains responsible for defining the purpose of its deployment, deciding who can access the data, choosing an applicable legal basis, setting retention requirements, and responding to its users.

Do not copy a legal basis or retention period from this guide into an employee notice. Those decisions depend on your configuration, contract, jurisdiction, and internal policy.

## Data Boza Can Process

The actual data depends on the features and integrations you enable.

| Category              | Typical source                                                                             | Examples                                                                                |
| --------------------- | ------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------- |
| Corporate directory   | Google Workspace or Microsoft Entra ID                                                     | Name, work email, account status, job information, group, team, and organizational unit |
| Application inventory | Identity-provider logs, browser signals, direct integrations, invoices, and manual records | Application, domain, approval state, owners, users, lifecycle, and security fields      |
| Application activity  | Browser extension, identity-provider sign-in logs, and direct integrations                 | Recognized application, corporate user, login or activity time, and source              |
| Contracts and spend   | Manual records, invoices, Pennylane, Powens, and CSV imports                               | Vendor, amount, currency, billing terms, payments, licenses, and renewal dates          |
| User-entered content  | Platform forms and workflows                                                               | Notes, custom fields, announcement content, review comments, and AI questions           |
| Operational metadata  | Platform and integration operation                                                         | User, organization, action, timing, outcome, and technical diagnostics                  |

An identity-provider synchronization is generally a source of directory and sign-in data. Explicitly initiated onboarding, offboarding, messaging, and extension-deployment workflows can also create, update, or delete provider data. Review each integration guide before granting consent.

## Browser Extension Signals

The browser extension needs URL and tab access to compare visited domains with Boza's professional-application catalog.

For a supported match, Boza can associate the application domain or URL and activity time with the employee's corporate identity. This supports application discovery, inventory, usage, license, and access workflows.

The extension does not collect:

* Page content or documents.
* Form values, passwords, or keystrokes.
* Screenshots.
* Email or chat contents.

Pages that do not match the catalog are not part of the application signal sent to Boza. A domain match does not, by itself, tell Boza whether a particular visit was professional or personal. Scope the extension to the managed browsers, devices, and employee groups approved by your organization, and explain that scope accurately in your employee notice.

See [What is the Browser Extension?](/docs/browser-extension/browser-extension.md) and the [Communication Kit](/docs/communication-kit/communication-kit.md).

## Boza AI Assistant

Boza AI turns a natural-language question into a read-only database query and formats the result as an answer.

### Current access scope

{% hint style="warning" %}
The current release makes Boza AI available to every authenticated platform user who can see the assistant. Its data queries are restricted to the current organization, but they are not filtered by application ownership, team, or Access Reviewer assignment. Application-level roles do not limit the organization-wide data the assistant can return.
{% endhint %}

Treat access to the Boza platform as access to an organization-wide analytics surface until a more granular AI authorization model is implemented. Review platform membership accordingly.

### Data sent for AI processing

Boza uses OpenAI to:

1. Generate a read-only query from the question, recent conversation context, database schema metadata, selected categorical values, and similar successful examples from the same organization.
2. Produce the written answer from the question, generated query, and a capped sample of the query result.
3. Suggest follow-up questions from the question and a smaller result sample.

The complete query result is returned to the signed-in user's browser and can be used by the interface for an answer, chart, or CSV export. The answer-generation step currently sends at most the first 40 rows to the model.

Avoid entering credentials, secrets, or personal information that is not needed for the analysis.

### Stored questions and reuse

For each successful data question, Boza stores the question and generated SQL as a tenant-scoped example. A later question from the same organization can reuse up to three similar examples to improve query generation.

* The reusable example stores the question and SQL, not the full result rows.
* A thumbs-up marks the latest matching example as useful.
* A thumbs-down excludes that example from later reuse.
* A separate audit record contains the organization, user, question, generated SQL, outcome, and timing.

The current interface does not provide a self-service control to inspect or delete these examples and does not display their retention period. Confirm retention and deletion terms in the applicable contract, DPA, and privacy process before enabling broad access.

See [Boza AI Assistant](/docs/platform/ai-assistant.md) for usage guidance.

## Invoice Processing

When you upload an invoice—or synchronize one from a supported accounting source—Boza uses document and AI services to extract text and identify vendors, subscriptions, services, discounts, amounts, and contract terms.

| Sub-processor          | Purpose                                                                   | Data involved                                                                                                                      |
| ---------------------- | ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| **Amazon Textract**    | Primary optical character recognition                                     | Uploaded invoice file                                                                                                              |
| **Google Document AI** | Supported OCR fallback                                                    | Uploaded invoice file                                                                                                              |
| **OpenAI**             | Structured invoice extraction and Boza AI query generation/interpretation | Extracted invoice text; for Boza AI, the question, prompt context, generated query, and capped query-result sample described above |

Only upload documents that your organization is authorized to process. Review extracted values before approval; uploaded invoices can contain names, addresses, account references, and other personal or confidential data.

The authoritative list of sub-processors and applicable international-transfer safeguards is maintained through Boza's contractual privacy materials. Contact **<privacy@getboza.io>** or your Boza account contact for the current version.

## Access Control

Boza uses Google or Microsoft single sign-on and a tenant identifier from the authenticated session to select the organization's data.

Workspace and application roles have different purposes:

* A workspace **Admin** can operate the administrative platform, settings, integrations, and supported workflows.
* Application **Super Admin**, **Budget Owner**, **Admin**, and **Access Reviewer** roles assign responsibility for an application.
* An Access Reviewer normally sees only assigned certification records in **My Reviews**.
* The current AI Assistant is an exception: any authenticated platform role with access to it can query organization-wide data.

See [Roles & Permissions](/docs/settings-and-security/settings/roles-and-permissions.md). Roles in the interface do not replace server-side authorization; security-sensitive workflows require engineering review and testing.

## Tenant Isolation and Transport

Boza stores each customer tenant's operational data in a separate PostgreSQL schema and validates authenticated API requests with signed, expiring tokens. The AI query path permits read-only statements and applies an organization-schema scope check before executing a generated query.

Boza hosts customer data in France through Scalingo infrastructure. Request the current security pack for details about hosting, encryption, resilience, logging, incident response, access review, and certifications. Do not rely on a marketing summary as audit evidence.

## Retention, Deletion, and Data-Subject Requests

Retention is governed by the applicable contract, DPA, and customer instructions. This guide does not promise a universal deletion period.

Keep these product behaviors in mind:

* Disabling or deleting a user in an identity provider does not automatically prove that every related Boza record has been deleted.
* Deleting an approved subscription removes its billing history in Boza; deleting an invoice removes its stored file and record.
* AI reusable question/SQL examples do not have a self-service deletion control in the current interface.
* Aggregated reports, audit records, backups, and connected-provider records can follow different retention rules.

Document the offboarding and deletion process that applies to your organization. Data-subject requests should normally go to the customer's designated privacy contact or data controller. Boza assists its customers under the applicable contractual process.

## Before Go-Live

* Identify the enabled sources, workflows, and employee groups.
* Approve platform membership and application roles.
* Review the organization-wide scope of Boza AI.
* Confirm the browser-extension deployment scope and employee notice.
* Record the legal basis, retention schedule, data-subject request path, and internal recipients.
* Obtain the current DPA, sub-processor list, and security pack.
* Test deletion, offboarding, and access-review procedures.

For product support, contact **<support@getboza.io>**. For privacy materials, contact **<privacy@getboza.io>**.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://boza.gitbook.io/docs/settings-and-security/data-privacy-gdpr.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
