Legal

Privacy Policy

Last updated: July 5, 2026. Braize is operated by Aize. This notice explains what personal data we process, in which role, and the architectural guarantees behind it.

Abstract padlock representing data protection

1. Who we are, and in which role

Braize is the permission-aware answer layer operated by Aize (the “Company”, “we”). For company information see aize.dev.

We act in two different roles, and this policy is organized around that split:

  • Data processor.For the documents, URLs, and other source data your workspace connects to Braize, and the chunks and embeddings derived from them (“Workspace Content”), your organization is the data controller and we process Workspace Content on your behalf, under your instructions, to provide the service. Our processor obligations are set out in a Data Processing Agreement, described in Section 8.
  • Data controller. For account and identity data, billing information, support communications, and marketing-site visitor data described below, we are the data controller and this policy describes that processing directly.

2. Data we process as a controller

  • Account & identity data — the email, name, and workspace-membership claims used to sign you in and enforce roles (owner / admin / editor / viewer).
  • Billing data — for paid plans, the billing contact and transaction records needed to process payment; card details are handled by our payment processor and not stored by us.
  • Support & communications — messages you send us (email, contact forms) and their metadata.
  • Marketing-site data — strictly-necessary cookies (Section 12) and content-free server logs when you browse br.aize.dev.

3. Workspace Content we process as a processor

Workspace Content — the documents, URLs, and source data you connect, plus the chunks and embeddings derived from them — is processed strictly under your instructions to provide the service. We treat embeddings as personal data (they can encode the underlying text), so they are protected exactly like the content itself.

Separately, we generate operational logs (request method, path, status, timing, and problem type) that are content-free by design: a schema lint forbids any customer-content column (query, answer, prompt, document text) in the control plane, and log attributes are scrubbed of content-named keys.

4. How we use it, and on what legal basis

  • To parse, index, and retrieve your content to answer questions (contract / your instructions as controller).
  • To enforce access control, quotas, billing, and rate limits (contract; legitimate interest in service integrity).
  • To operate, secure, and debug the service using content-free logs (legitimate interest; legal obligation for security).
  • To communicate with you about your account, billing, and material service changes (contract).

We do not sell personal data, and we do not train shared foundation models on your Workspace Content.

5. Data residency & tenant isolation

Each workspace lives in its own isolated Postgres database, pinned to a single region you choose at creation. Cross-workspace and cross-region access is structurally impossible, not merely policy-filtered: every workspace has its own login role with REVOKE CONNECT FROM PUBLIC, and services receive a single-workspace-scoped connection. Embeddings never leave the workspace database — not in logs, analytics, or backups.

6. Access control

Answers are permission-aware. Access-control lists are applied as a pre-filter inside the retrieval query — never a post-filter — with default-deny: content you are not explicitly granted is excluded, and an anonymous request resolves to public scope only. Revoking access rotates the answer-cache key so previously cached answers become unreachable.

7. Subprocessors, inference routing & international transfers

We use a small number of subprocessors, in these categories: cloud hosting and infrastructure, AI inference (embeddings, reranking, generation), and payment processing. A current subprocessor list is available on request — see Section 8.

Inference obeys a per-workspace processing_policy: you can constrain allowed regions, require zero-data-retention (ZDR) endpoints, or lock inference in-region. The policy is enforced in the inference gateway and hard-failsrather than silently falling back. New inference endpoints are admitted only after subprocessor verification. Where personal data is transferred across borders (for example, to a subprocessor outside your workspace’s region), we put appropriate safeguards in place, such as Standard Contractual Clauses or an equivalent lawful transfer mechanism, before that transfer occurs.

8. Data Processing Agreement

Enterprise customers can request our Data Processing Agreement (DPA) and current subprocessor list at [email protected]. The DPA sets out our processing instructions, sub-processor flow-down obligations, deletion on termination, and audit rights, and incorporates Standard Contractual Clauses where required for your region.

9. Security

  • Encryption in transit (TLS) and at rest.
  • Outbound fetches pass an egress proxy that blocks SSRF and cloud-metadata access; ingested content is sanitized for prompt-injection before indexing.
  • Secrets are held in a secrets backend, never in code or logs.

10. Retention, deletion & breach notification

Deleting a document soft-deletes it immediately (it disappears from retrieval at once) and enqueues a purge that nulls the content, vectors, blobs, and cached answers, targeted within 24 hours. Content-free tombstones are retained for audit. Closing a workspace deletes its database; a nightly logical export is available and doubles as your data-portability export.

If we become aware of a security incident affecting your personal data, we will notify you without undue delay and, where required by law, aim to do so within 48 hours of confirming the incident, so you can meet your own regulatory notification duties.

11. Your rights

Under the EU GDPR and the UAE PDPL you may request access, rectification, erasure, restriction, portability, and objection. Most rights are self-serve from the dashboard (export and delete); for the rest, contact us below and we will respond within the statutory window. If you are in the European Economic Area or UK, you also have the right to lodge a complaint with your local data protection supervisory authority. If you are a California resident, you have the right to know, delete, and correct your personal information and to non-discrimination for exercising these rights; we do not sell or share personal information as defined by the CCPA.

12. Children’s privacy

Braize is a business product and is not directed at, and must not be used by, children. We do not knowingly collect personal data from children. If you believe a child has provided us personal data, contact us at [email protected] and we will delete it.

13. AI-interaction disclosure

In line with EU AI Act Article 50, every end-user channel always discloses that responses are AI-generated. This disclosure is enforced at the channel boundary and cannot be themed away.

14. Cookies

The dashboard uses strictly-necessary cookies for authentication, your session, and your language preference. We do not use advertising or analytics cookies on the marketing site or dashboard.

15. Changes

We will post material changes here and update the date above. Continued use after a change constitutes acceptance.

16. Contact

Privacy questions and rights requests: [email protected], or via aize.dev/contact. See also our Terms of Service and Security & Compliance overview.