BrandOS Privacy Policy

Effective 13 August 2026

The Thai version is above and governs where the two versions diverge.

1. Who we are and what this policy covers

BrandOS is a brand workspace operated by Simplisis Co., Ltd. (“Simplisis”, “we”, “us”), a company established in Thailand, registered office 126/33 Moo 5, Ratsada Sub-district, Mueang Phuket District, Phuket 83000, Thailand, company registration no. 0825558000140.

This policy covers the BrandOS web application (including the installable web app) and the optional LINE messaging channel a customer organisation may connect. It describes what personal data the system actually collects, what it is used for, who receives it, how long it is kept, and the rights you have under Thailand’s Personal Data Protection Act B.E. 2562 (PDPA).

BrandOS is a business tool provided to client organisations. There is no self-serve public signup: accounts are created by invitation from Simplisis or from a client organisation’s administrator.

2. Our two roles: controller and processor

For the content a client organisation and its staff put into their brand workspace — brand knowledge, brand assets, documents, designs, and the text of chat conversations held with the brand assistant — the client organisation decides why and how that data is used. For that data the client organisation is the data controller and Simplisis is the data processor, processing it only to provide and support the service as described here.

For the data needed to run BrandOS itself — your account and profile, workspace membership records, invitations, consent records, security and hosting logs, usage analytics, and bug reports — Simplisis is the data controller.

If you are a member of a client organisation’s staff and want to exercise rights over workspace content, we will route your request to your organisation and assist it; for account and platform data you can come to us directly (section 9).

3. The personal data we actually collect

Account and profile: your email address, name, avatar (a chosen preset or an uploaded image), and your authentication credentials. Passwords are handled by our authentication provider (Supabase Auth) and stored only in hashed form; we never see them.

Signing in with Google (optional): where we have enabled social sign-in for BrandOS and you use it, Google returns to us the email address of that Google account, whether Google has verified that address, your name, your Google profile picture, and the identifiers that tie the Google account to your BrandOS account. We ask Google for nothing beyond your name, email address and profile picture; we never receive your Google password, and we are granted no access to Gmail, Drive, or any other Google service. What Google itself learns from the sign-in is governed by Google’s own privacy policy. Signing in this way does not by itself create a usable account — an invitation is still required, and a Google account with no invitation is signed out again and shown how accounts here are created. Our authentication provider does record that sign-in attempt; if you were never invited and want that record erased, write to the address in section 15 and we will remove it.

Membership and invitations: which organisations and brands you belong to and your role in each. An invitation stores the invited email address, the intended role, an expiry date, and a one-way (SHA-256) hash of the invite token — the token itself is not stored.

Consent records: when you accept these legal documents, we record which document, which version, the time of acceptance, and — for evidence quality — the IP address and browser identifier (user-agent) of the accepting request.

Chat: the messages you exchange with the brand assistant are stored (message text, language, timestamps), together with conversation records that include your email address, a hashed session identifier, and conversation titles.

Bug and feedback reports: when you choose to send a report, it captures your description, your account email, the page you were on, technical context (browser user-agent, window size, the app version), up to 25 recent console error or warning messages (each truncated to 400 characters), and a trail of your last 30 interactions in the app (clicks, navigation, commands — with element labels of up to 120 characters each).

The most detailed part of a bug report is the descriptor of the element you pinned, and we would rather set it out in full than summarise it: it can include up to 80 characters of that element’s visible text and up to 80 more from its nearest labelled ancestor, the element’s HTML attributes, a rendered-appearance probe covering it and up to 8 neighbouring elements, a chain of up to 12 ancestors describing how the page is layered at that point, and a best guess at which interface component and source file drew it. A report also carries the workspace state (for example which design and tool were active) and any screenshots you attach — up to four, stored inside the report record itself. Voice dictation in the report widget is transcribed on your device; the audio is never uploaded.

Usage analytics (only with your consent — section 11): named product events such as “feature used”, with the organisation, brand, a random per-tab session identifier, your internal user ID, language, coarse device class (mobile/tablet/desktop) and channel. Event properties are restricted to simple values, capped in size, and email addresses are redacted before storage. Analytics events do not include your IP address, your browser fingerprint, or the text of anything you typed: property names that would carry typed text — a search term, a query, a prompt — are refused by the recorder on your own device, before an event is sent anywhere, and refused again by our servers on arrival, because a service that accepts events over the internet can never assume the sender cleaned them. Events recorded by our servers are subject to the same consent as events recorded in your browser; if you have not chosen “Accept all”, no event is recorded for you at all.

LINE channel (only if your organisation connects one and you use it): your LINE user ID and, where available, your LINE display name and avatar, plus the link between that LINE identity and your BrandOS account. The text of LINE messages is processed to answer you but is not stored by BrandOS; only short-lived technical records (webhook deduplication entries, kept about 7 days, and hashed single-use linking tokens) are kept.

Hosting and security logs: our hosting provider (Vercel) keeps standard request logs, which include IP addresses, as part of operating the infrastructure. Inside the application, IP addresses are recorded only in the consent ledger (above) and as a short-lived rate-limit key when linking a LINE account.

4. What we deliberately do not collect

No advertising trackers and no third-party analytics: BrandOS loads no Google Analytics, no social pixels, no third-party measurement scripts. Usage analytics is first-party, consent-gated, and stored in our own database.

No raw content in analytics: usage telemetry stores derived values (event names, buckets, counts), never the text of your prompts, your searches, or your documents. One text field is deliberately kept — the message of a technical error, for example “HTTP 500 on /api/chat” — because it is written by our own code rather than typed by you, and without it a fault cannot be diagnosed.

No audio uploads for dictation or subtitles: speech-to-text runs entirely in your browser on your device and your audio never leaves your machine — there is no server transcription endpoint in BrandOS at all. What is downloaded is the recognition software itself: the model weights from the Hugging Face CDN and the runtime from the jsDelivr CDN. Those are ordinary file downloads, so each CDN sees the IP address of the request and nothing else; both are listed in section 7. The model is large — roughly 200 MB — and is fetched once when you first open the app, with a visible progress badge, then cached by your browser; it is skipped entirely if your device reports a metered or data-saver connection.

We do not intentionally collect special-category (sensitive) personal data as defined by PDPA §26, and we ask that you do not upload it into brand workspaces.

5. Purposes and legal bases (PDPA §24, §26)

Creating and operating your account, providing the workspace, chat, design, and channel features — performance of a contract (§24(3)).

Generating AI answers, designs, and media from your organisation’s brand data — performance of a contract (§24(3)).

Security, abuse prevention, rate limiting, and service diagnostics (including bug reports you choose to send) — legitimate interest (§24(5)).

Recording your acceptance of these documents and your PDPA consent — legal obligation and legitimate interest in evidencing consent (§24(1), §24(5)).

Product usage analytics — consent (§19), which you may give or refuse in the cookie banner and may withdraw (section 11).

Complying with Thai law, including tax and accounting obligations for commercial billing (handled outside the product) — legal obligation (§24(6)).

6. AI processing — what is sent, to whom

When you use the chat assistant, the following is sent to our AI model provider to generate the answer: your message, the recent turns of the same conversation, and the relevant parts of your organisation’s governed brand knowledge, brand memory, and retrieved document passages.

To make brand content searchable, document text and asset descriptions are sent to the same class of provider to compute embeddings (numerical representations). To describe and classify uploaded brand assets, asset images are analysed by a vision model.

Our current model provider for chat, embeddings, and asset vision is OpenAI (api.openai.com), processed in the United States. Under OpenAI’s API terms (checked 2026-08-10), API data is not used to train OpenAI’s models unless the customer opts in — we have not opted in — and API inputs and outputs are retained by OpenAI for abuse monitoring for up to 30 days unless law requires longer.

Voice features in Studio (text-to-speech, voice transformation, sound effects, voice cloning) send the relevant text or audio to ElevenLabs (United States) to generate the output. ElevenLabs’ own privacy terms govern its retention and use of that data; if your organisation does not want voice inputs processed by ElevenLabs, do not use the voice features.

Background removal in Studio, where it is enabled, sends the image being edited to an external background-removal service to produce the cut-out — either Adobe’s Firefly/Photoshop API or an alternative provider configured for the deployment. It is not enabled today: no such provider is configured, so no image is sent to one and the feature reports itself unavailable. It is named here so that switching it on is a documented change to this policy rather than a silent one.

AI providers may change as the service evolves. The list in section 7 is the authoritative current list; a material change is notified through a new version of this policy, which you will be asked to accept before continuing to use BrandOS (section 14).

7. Sub-processors and international transfers (PDPA §28–29)

Supabase, Inc. — database, authentication, and file storage for all workspace and account data — hosted in Australia (Asia-Pacific region, Sydney).

Vercel, Inc. — application hosting, content delivery, and request logs — United States and a global edge network.

OpenAI (OpenAI, L.L.C. / OpenAI Ireland Ltd) — AI text generation, embeddings, and image understanding for the features in section 6 — United States.

ElevenLabs, Inc. — AI voice generation for Studio voice features — United States.

Google LLC — “Sign in with Google”, and only if you choose to sign in that way — United States. Google learns that a sign-in to our application took place; we receive your name, email address and profile picture. Microsoft and Meta sign-in are supported by the software but are not switched on: Google is the only social sign-in available today, and enabling another one adds a recipient, which requires a new version of this policy first.

Adobe Inc. (Firefly / Photoshop API) — background removal for images in Studio — United States. Not enabled today (section 6): no background-removal provider is configured, so no image reaches one.

LY Corporation (LINE) — messaging platform, only where your organisation connects a LINE channel — Japan/Thailand, under LINE’s own terms.

Hugging Face (CDN) — delivery of the on-device speech-recognition model weights only. It receives the IP address of the download request and no other personal data.

jsDelivr (operated by Prospect One) — public code CDN delivering the on-device speech-recognition runtime — European Union, on a global edge network. It receives the IP address of the download request and no other personal data.

These providers are located outside Thailand, so personal data is transferred internationally. Thailand’s PDPC has not yet designated an adequacy list; we rely on appropriate safeguards under PDPA §29 — each provider processes data under its contractual data-protection terms (data processing agreements/addenda) binding it to protect the data and use it only to provide its service to us — together with the necessity of the transfer for performing our contract with you (§28(5)). This policy is our notice to you of these transfers.

We will keep this list current and notify material changes through a new version of this policy requiring re-acceptance.

8. How long we keep data

Account, profile, and membership data: for the life of the account, then removed through the deletion process in section 10.

Retention windows are set in the software: chat messages 24 months, usage analytics events 24 months, and bug and feedback reports 12 months — each a rolling window, each configurable but never shorter than 30 days.

We have to be exact about the status of those windows, because it would be easy to read them as a promise already being kept. The scheduled job that enforces them is not yet running: the database component it depends on is not installed, so nothing has been deleted on that schedule to date. Nor has anything reached those ages — BrandOS only began holding this data in 2026. Until the schedule runs, deletion happens on request (section 9) and through account deletion (section 10). We will update this section when it starts running, rather than describe a mechanism you cannot presently rely on.

Conversation records (titles and metadata) are kept until deleted through section 10 or on request.

Invitations: invite links expire after 14 days; the invitation record (the invited email address, the role, and the status) remains in the organisation’s administration records. If that person later has their BrandOS account erased, the stored address is replaced by a one-way hash.

Consent and acceptance records: kept for as long as your account exists, as the evidence of what you accepted and when. They are attached to your account, so erasing the account removes them with it (section 10). An earlier version of this policy said in this section that they survived deletion, which contradicted section 10 and was wrong; section 10 was the correct one. What does survive an erasure is the deletion record itself, which stores your email address only as a one-way hash — enough to match a request to it, without keeping the address.

LINE technical records: webhook deduplication entries are pruned after about 7 days; linking tokens are single-use and expire.

Commercial and tax records (kept outside the product): as required by Thai accounting and tax law.

Brand workspace content (knowledge, assets, designs): kept until your organisation deletes it or the workspace is closed; on termination see the Terms of Service.

9. Your rights and how to exercise them (PDPA §30–36)

Subject to the limits in the PDPA you may: request access to and a copy of your personal data; have inaccurate data corrected; request erasure or anonymisation; request restriction of processing; object to processing; request portability of data you provided in a machine-readable form; and withdraw consent at any time (without affecting processing already done lawfully).

How to exercise them: email thoetphong@simplisisdesign.com, or for deletion use Settings → Privacy & data → Request deletion inside the product. Access and portability requests are currently fulfilled manually by our staff — there is no self-serve export button — and we respond within 30 days of a verified request.

Where the data belongs to your organisation’s workspace (section 2), we will route the request to your organisation, which as controller decides on it, and we will assist it in answering you.

You have the right to lodge a complaint with Thailand’s Personal Data Protection Committee (PDPC) if you believe your rights under the PDPA have been violated.

10. What account deletion actually removes

You can request deletion at any time from Settings → Privacy & data. The request is queued with a due date, and our staff complete the purge within 30 days.

Deletion removes outright: your login account; your profile (name, email, and avatar, including any avatar file you uploaded); your organisation memberships; and your recorded acceptances of these documents.

Deletion strips rather than removes, for bug and feedback reports you sent: everything of yours in the report goes — your email address, your account reference, the title and description you wrote, the console messages, the interaction trail, the browser and window details, and any screenshots. What is left is the engineering skeleton: the case code, status, area, route, app version, and how it was resolved, because those references are woven through our repair records and deleting the row would tear holes in a history that no longer says anything about you. One residue we would rather state than leave for you to find: the first four letters of a case code are derived from the local part of your email address. With the account and every email column erased there is nothing left to match them against, so it is kept as a bare ticket reference.

Deletion replaces rather than removes, in four places: the email address held on your chat conversation records is cleared; the address on any invitation to you, and on the deletion request itself, is replaced by a one-way hash; and your identifier on usage analytics events is replaced by a single random pseudonym, generated at the moment of erasure and stored nowhere else — so that “these events belong to one person” survives while every link to who that person was is severed.

Deletion anonymises rather than deletes, for the organisation’s work: content you authored for your organisation (designs, uploads, approvals) stays with the organisation — it is the organisation’s data — with your authorship reference removed. Erasing a person must not destroy their employer’s work.

Deletion keeps one thing on purpose: the deletion request record, as the evidence that we did what you asked, with your email held only as the hash described above.

Backups and logs held by our infrastructure providers cycle out on those providers’ own schedules after deletion from the live system.

11. Consent, and how it is recorded

Before first use you are asked to accept the Terms of Service, this Privacy Policy, and a PDPA consent statement covering the international transfers in section 7. Each acceptance is recorded with the document key, the exact version accepted, a timestamp, and the IP address and browser identifier of the request — so what you consented to can be identified later.

Usage analytics runs only after you choose “Accept all” in the cookie banner. Your choice is recorded in two places, and both matter: on your device, which is what stops your browser from sending events, and in the same append-only ledger as your other consents — with the statement version, a timestamp, and the IP address and browser identifier of the request — which is what our own servers read before recording anything. A withdrawal is written as its own entry rather than erasing the earlier grant, so the record of what you decided, and when, stays intact.

You can change the choice at any time in Settings → Privacy & data, and either direction takes effect immediately: your browser stops or starts sending on the spot, and the next event our servers would record reads the new decision. Declining is a first-class outcome — it is never re-asked as a condition of continuing to use BrandOS.

If you reach BrandOS only through a connected LINE channel, you are not shown this banner, so no analytics consent exists for you — which means no product analytics event is recorded for you at all.

When a document materially changes, its version number is raised and you will be asked to accept the new version before continuing to use BrandOS. The cookie statement is versioned the same way: because declining analytics must never block your work, a new version of it is not put in front of you as a barrier — instead your earlier answer stops counting and the banner asks again, with analytics off until you answer. That is the whole of the imposition, and it is why an answer given to an older version is never read as agreement to a newer one.

12. Security

Measures actually in place: all traffic is encrypted in transit (HTTPS/TLS with HSTS); data at rest is stored with providers that encrypt storage; passwords are hashed by our authentication provider; every database read and write is scoped to your organisation through row-level security verified server-side; especially sensitive tables (entitlements, channel data, bug reports) are locked to server-only access with no direct client path; LINE channel credentials are encrypted at the application layer with AES-256-GCM; invite and account-linking tokens are stored only as one-way hashes; key endpoints are rate-limited; and standard browser protections (frame, content-type, referrer policies) are set.

Access by Simplisis staff: a small allowlist of Simplisis operator accounts, verified server-side on each request, can administer client workspaces across organisations to set up and support the service. Operator access is a service function, not a data-use right — operators act under this policy and our confidentiality obligations.

No system is perfectly secure and we do not claim certifications we do not hold. If a personal-data breach occurs that is likely to pose a risk to your rights, we will notify the PDPC without undue delay and within 72 hours of becoming aware of it, and affected users where the PDPA requires.

13. Cookies and on-device storage

Strictly necessary: authentication session cookies from Supabase Auth keep you signed in and are refreshed as you use the app; they exist for your session and its refresh window and cannot be declined while using the service.

On-device storage (localStorage and session storage, never sent to a server as tracking): your theme, interface language, legal-document language, cookie-consent choice, and other interface preferences such as display size and recently used tools.

Also on your device, and worth naming separately because it is the most personal thing there: so that your chat history opens instantly, a copy of your conversation list and the text of your messages is held locally under your own account’s key. It stays on the device, it is not a second copy for us, and it is removed when you clear this site’s data in your browser. On a shared computer, signing out does not erase it — clear the site’s data if that matters to you.

Analytics: with your consent, first-party usage events are recorded keyed by a random per-tab session identifier (section 3). BrandOS sets no third-party or advertising cookies of any kind.

Embedded video: a brand library card may embed a YouTube or Vimeo player. We load these from the providers’ privacy-preserving endpoints — youtube-nocookie.com, and Vimeo with do-not-track requested — so that a video on the page does not plant advertising cookies on you. The provider still sees the request, including your IP address, when a card containing a video is displayed. An administrator can also paste an embed address from some other provider; if they do, that player is loaded as given, and the promise above cannot be made about its cookies.

14. Changes to this policy

When this policy materially changes we publish a new version with a new effective date, and the product requires you to accept the new version before continued use — silent “continued use means acceptance” is not our mechanism for material changes.

The changelog (section 16) records what changed in each version.

15. Contact and Data Protection Officer

Data protection contact: เทอดพงษ์ หรรษทานสถิต, Director, Simplisis Co., Ltd., 126/33 Moo 5, Ratsada Sub-district, Mueang Phuket District, Phuket 83000, Thailand, +66 89 176 5252 (office 076-608865), thoetphong@simplisisdesign.com. (The director’s name is shown in Thai script, which is the form registered with the Department of Business Development.)

This policy is provided in Thai and English. If the two versions diverge in meaning, the Thai version governs.

16. Changelog

2026-08-13 (this version, draft): a full audit of this policy against the running system found four statements that were not true of it. Each was fixed in the software rather than softened here. (1) Analytics no longer receives the text typed into the Library search box, and the recorder now refuses any property that would carry typed text — the promise in sections 3 and 4 had been false since that search box shipped, and those terms were additionally being shown as “topics” on the organisation’s own Insights page. (2) Events recorded by our servers now obey the cookie banner, which until now governed only your browser. (3) The consent withdrawal control described in section 11 now exists in Settings; previously the only way to withdraw was to clear the site’s browser data. (4) Embedded video players moved to their providers’ no-tracking endpoints. Corrected in the text: the retention section, which claimed no schedule existed while the software had one that cannot yet run; the contradiction between sections 8 and 10 over whether consent records survive account deletion (they do not); an understated account of what deletion removes; and an understated account of what a bug report captures. Added: “Sign in with Google” and the recipients it involves, the jsDelivr CDN, and the not-yet-enabled background-removal provider.

A second review of that same day went further, and three of its findings are worth stating plainly rather than folding into the list above. First: six analytics events recorded before this date still held text typed into the Library search box — including partly-typed words — and stopping new collection would not have removed them, so that text was deleted from the database. Second: the refusal of typed text now happens on your own device, before an event is sent, and not only on arrival at our servers; the earlier wording claimed the former when only the latter was true. Third: the cookie statement is versioned, and until this date raising that version changed nothing, because your stored answer was read without checking which version it answered — so an agreement given to a narrower arrangement was being read as agreement to a wider one. Section 11 now describes how that is handled, and the software does what it describes. Also corrected: this policy said your organisation enables social sign-in, when in fact we do; it described an uninvited sign-in as simply refused, without saying that our authentication provider still records the attempt; and section 13 did not mention that a copy of your chat history is kept on your own device.

2026-08-10 (draft): complete rewrite verified line-by-line against the implemented system — corrected the sub-processor list (OpenAI as the AI model provider; ElevenLabs for voice; database region Australia), described the real deletion path and what it leaves, the real retention behaviour, the consent ledger, and removed claims the system does not implement.

2026-07-19 (draft): first bilingual scaffold.