Privacy

This policy covers the Galior application and this website. It is written in plain language on purpose: a policy nobody can read is not a disclosure. Where something is awkward — a provider outside the EU, a gap we have not closed — it is stated here rather than left for you to find.

Who is responsible

Galior is operated by an individual, not a company. That individual is the data controller for the purposes of this policy and is the person you would be contracting with:

Two roles are worth separating. For your account and billing, and for this website, we decide what is collected and why. For the content you put into your workspace — your colleagues, your projects, your files, the work you ask an AI employee to do — you decide what goes in and what it is for, and we hold and process it in order to run the service for you. The formal wording of that split belongs in a data processing agreement, which we will write properly when you need one rather than pretend already exists.

What we never do

• We do not sell your data, and we do not share it for anyone else’s marketing.
• We do not use your content, or anything imported from your directory, to train AI models.
• We do not run advertising, and there is no advertising or analytics tracker on this website.
• We do not read your workspace content to build a profile of you or your company.

What Galior holds

• Your account: the email address you sign in with, and the sign-in records that go with it. Your password is handled by our authentication provider and is not in any Galior table.
• Your workspace: the people and groups in it — names, work email addresses, roles, group membership — plus projects, trackers and their items, messages, files you upload, and the settings that govern all of it.
• The work itself: every AI session and every turn in it, what an AI employee read, what it produced, what it was allowed to do, what it was asked to approve, and what it spent.
• What your AI employees have remembered, so they can recall the right thing later.
• Billing: your subscription state and the identifiers our payment provider gives us. Card numbers are entered on the payment provider’s own pages and never reach Galior.
• Credentials you give Galior to hold on your behalf — your own model-provider API keys, credentials for a machine you enrol, connected-account tokens. These are encrypted before they are written, and there is deliberately no path that stores them in the clear.
• If you left an enquiry on the design-partner form on this website: your work email, plus any first name, last name, role, company or message you chose to include, and which page you left it on. Nothing else about the visit — no IP address, no browser, no referrer.

Two of those deserve their own sentence. If you connect one of your own computers so an AI employee can work on it, what that AI sees on the screen is sent to the model driving it — that is what makes the feature work, and it means whatever is on that screen at the time goes with it. And an AI session is kept as a record of what happened; it is not a chat you can quietly rewrite afterwards.

Why we process it

To provide the service you or your employer asked us for, to bill for it, to keep it secure, and to comply with the law where it applies to us. Nothing here is processed for advertising or for profiling, and we do not rely on a “legitimate interest” to do anything a reasonable reader would be surprised by.

Google Workspace data

Galior can connect to a Google Workspace directory so that the team you already have comes into Galior instead of being retyped. This section is about that connection specifically, and it applies whether or not you also read the rest of this policy.

An administrator of your Google Workspace starts the connection, from Settings → Connections inside Galior, and chooses which part of the directory Galior may read. Everything outside that choice is never read at all. This page renders the same permission list the consent screen asks for, so the two cannot disagree.

If the person setting Galior up is not the administrator of your directory, they can send a one-time link to whoever is. The person who opens it sees who asked and what will be read, grants it through Google’s own consent screen, and gets no account, no session and no way into the workspace — approving the read is the only thing that link can do, once, and it expires.

What we ask for. A Google Workspace administrator authorises the connection, and Galior requests these permissions and no others:

• https://www.googleapis.com/auth/admin.directory.user.readonlySensitive scope

  The people in your Google Workspace directory: their name, their work email address, and whether the account is active or suspended.

  Galior brings your existing team into a workspace instead of asking you to retype it. There is no narrower read of the directory’s people.

• https://www.googleapis.com/auth/admin.directory.group.readonlySensitive scope

  The groups in your directory, their name and description, so the teams you already have come across as teams.

  Without it the people arrive as a flat list and every group has to be rebuilt by hand.

• https://www.googleapis.com/auth/admin.directory.orgunit.readonlySensitive scope

  The organisational units in your directory, their name and where they sit, so you can say which part of the company Galior is for.

  The connection asks an administrator to choose which part of the directory Galior may read. Without this, that choice cannot be offered and the only options would be "everyone" or nothing.

• https://www.googleapis.com/auth/userinfo.emailBasic scope

  The email address of the administrator who authorised the connection.

  So the workspace can show which Google account a connection was made with, and who to ask before it is changed or removed.

We ask for no access to Gmail, to Google Drive, or to Google Calendar. Galior requested Drive and Calendar permissions in an earlier version of its code and never used them; they were removed on 31 July 2026. If we ever wanted them we would have to ask you again, separately, for a feature that actually existed.

How Google user data is accessed. Only after an administrator of your Google Workspace grants it, through Google’s own consent screen. Galior calls Google’s Admin SDK directory API and nothing else — the people, the groups, and the organisational units they are arranged in, which is what lets an administrator say which part of the directory Galior may read. There is no Gmail, Drive or Calendar call anywhere in the product. Two things cause a read: someone in your workspace starting an import or asking for a check, and the daily check described next.

The daily check. Once a connection exists, Galior re-reads the same chosen part of your directory once a day, so your workspace stays true without anybody maintaining it by hand. It reads exactly what the first import read and nothing more. Routine changes — a new colleague, a changed job title or name, somebody joining a team — are applied and reported in your workspace’s Activity. Anything consequential is not applied: a person who has disappeared from your directory, a team that has been removed, a reporting line that has moved, or an unusually large batch of changes at once is put in front of a person in your workspace to decide. A day on which nothing changed still writes a line saying so. An administrator can pause the daily check, run it on demand, or disconnect — see How to stop it below.

How it is used. To create and keep up to date the people and groups in your Galior workspace. The first import goes through a review step where someone from your side approves the shape of it before anything is created. After that, the daily check applies routine changes without asking and reports each one, and holds everything else for a person, as described above. Galior creates and updates; it never deletes a person, a group or a membership, because a partial export is indistinguishable from someone having left — a departure is recorded as a departure, by a human, and the person’s record stays. A field somebody in your workspace edits by hand stops being managed by the directory from then on. The administrator’s email address is used to show which Google account the connection was made with.

How it is stored. The imported records are stored in your workspace’s own database, alongside the rest of your workspace, under the same access rules — which means other Galior customers cannot see them. The access token Google issues is encrypted before it is written.

How it is shared. It is not shared with anyone. It is not sold, it is not transferred to a third party, and it is not passed to an AI model provider as part of the import. Once it has become people and groups in your workspace, it is workspace content like any other — so if you then ask an AI employee a question about your team, the part of that content it needs to answer travels to whichever model you have enabled, exactly as any other question would. That is a thing you do, not a thing the import does.

How to stop it. An administrator can pause the daily check, which stops the reading and leaves the connection in place, or disconnect entirely — which removes the stored token and asks Google to revoke it. You can also revoke Galior’s access from your Google account’s own permissions page at any time, without asking us. People already imported into your workspace stay there, because at that point they are your workspace’s records rather than Google’s — delete them in Galior, or ask us and we will.

Microsoft Entra ID directory data

Galior can connect to a Microsoft Entra ID directory so that the team you already have comes into Galior instead of being retyped. As with Google, an administrator of your Entra ID directory starts the connection and chooses which part of it Galior may read; everything outside that choice is never read.

What we ask for. A Microsoft Entra ID administrator sees these permissions and no others:

• Directory.Read.AllDirectory permission

  The people and groups listed in a Microsoft Entra ID directory.

  Galior brings your existing team into a workspace instead of asking you to retype it, and keeps it current as people join, change role or leave. Only the part of the directory an administrator selects is read.

• GroupMember.Read.AllDirectory permission

  The membership information that relates people to directory groups.

  Without it the people arrive as a flat list and every team has to be rebuilt by hand.

• offline_accessRefresh permission

  No directory records. It lets Microsoft refresh an authorised connection.

  The daily check that keeps your team current needs a connection that stays authorised without asking an administrator to consent again every hour.

The reader is limited to people and groups. The group-membership permission is what lets the teams you already have arrive as teams rather than as a flat list of names. The offline access permission exists only so Microsoft can refresh an already authorised connection; it is not a separate directory-data read.

How it is accessed, used, stored and stopped. Exactly as described for Google above, and by the same code. An administrator consents through Microsoft’s own screen; Galior reads only the part of the directory they chose; the first import is approved by someone from your side before anything is created; and the same daily check keeps it true afterwards — applying routine changes and reporting them, and putting anything that would cost somebody their access, remove a team or arrive all at once in front of a person instead. The token Microsoft issues is encrypted before it is written, and the directory data it brings in stays inside your own workspace, where other Galior customers cannot see it.

We do not sell directory data, share it for marketing, or use it to train a model. An administrator can pause the daily check or disconnect at any time; disconnecting removes the stored token. People already in your workspace stay there as your own records.

Limited Use

Galior’s use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. In particular:

• We use Google user data only to provide and improve the features described above — bringing your directory into your workspace, and showing which account the connection was made with.
• We do not transfer Google user data to others, except as necessary to provide or improve those features, to comply with applicable law, or as part of a merger, acquisition or sale of assets with your prior notice.
• We do not use Google user data for serving advertising of any kind.
• We do not allow humans to read Google user data, unless we have your explicit consent for specific messages, it is necessary for security purposes such as investigating abuse, to comply with applicable law, or the data is aggregated and anonymised.
• We do not use Google user data to develop, improve, or train generalised or non-personalised AI or machine-learning models. Imported directory data is never used to train a model — ours or anyone else’s.

AI models, and what reaches them

Galior’s whole purpose is to let an AI employee do work, so content does travel to model providers — that is the product working, not a side effect. What travels is what the request needs: the instruction, and the context the AI was given to answer it.

An administrator chooses which models a workspace may use. A workspace can also be set to an EU residency mode, in which Galior refuses a request it cannot serve within the EU rather than quietly using a different model. What each provider says it does with what reaches it is written next to that provider on our trust page — read those as their commitments, not ours.

We do not use your content to train models. Where you enable a third-party model provider, their own terms govern what they do with the requests you send them, which is why we quote each of them rather than summarise.

Where it is processed

The application and your workspace’s database run in the EU. Durable AI runs execute in the United States and their payloads carry the content being worked on — that is true whatever residency setting you choose, and no wording of ours would change it. The full picture, including which regions we have confirmed and which are still blanks, is on the trust page. It is kept in one place deliberately, so that page and this one cannot drift into disagreeing.

Sub-processors

These are the third parties that process personal data on our behalf. The first group is in the path for every workspace. The second is reached only because an administrator enabled it — a meaningfully different disclosure, so they are listed separately.

Where each one runs is on the trust page rather than repeated here.

• SupabaseAlways in the path

  Hosts the database, the file storage and the sign-in behind Galior. Effectively everything a workspace holds is stored here.

  Account credentials and sign-in records; the names, email addresses and roles of everyone in a workspace; and all workspace content — projects, trackers, messages, AI sessions and their turns, uploaded files, and the record of what each AI employee was allowed to do and what it spent.

• VercelAlways in the path

  Serves the web application and its API, so every request a person makes passes through it.

  Request and connection metadata for pages and API calls, and whatever content is being sent or returned while it is in transit.

• Trigger.devAlways in the path

  Runs every durable AI job — the mechanism that lets a piece of AI work survive a crash, a redeploy, or hours of waiting for a person to approve something.

  The content of the work itself: the instruction given, what the AI read, and what it produced. A job’s payload and its logs carry that content.

• OVHcloudAlways in the path

  Turns what an AI employee has learned into vectors so it can recall the right thing later, and serves the models the EU-sovereign residency setting resolves to.

  The text of what an AI employee remembered, and — where a workspace is set to EU sovereign — the content of the requests it serves.

• Alibaba Cloud Model StudioAlways in the path

  Serves the AI models Galior ships with by default. An administrator can turn them off, but until they do this is where a default request goes.

  The content of a request to one of those models — the instruction, and whatever context the AI was given to answer it.

• StripeAlways in the path

  Takes payment and runs the subscription, if you pay us. Checkout and the billing portal are Stripe’s own hosted pages.

  Billing contact details and payment information, entered on Stripe’s pages. Galior stores only the identifiers Stripe gives back for the customer and the subscription; card numbers never reach Galior.

• ResendAlways in the path

  Delivers email that a workflow of yours asks Galior to send, and the one operator notification created when a visitor submits the public design-partner form. Galior does not send marketing email.

  The recipient’s address and the content of that message.

• UpstashAlways in the path

  Counts requests so that public endpoints can be rate limited. Where it is not configured, Galior counts in memory instead.

  Counters and the identifier a request is limited by. No message content.

Reached only where a workspace enables them:

• MojeekOnly if you enable it

  Answers a web search, where an administrator has turned web search on for a workspace. It receives the words being searched for, and returns page titles, links and short excerpts, which Galior keeps as the sources beside the answer.

  The search query itself — written by an AI on someone’s behalf, so it can carry whatever that person asked about. Nothing else from the workspace is sent, and no personal record is shared.

• AnthropicOnly if you enable it

  Serves AI models, where an administrator has enabled them and one is selected.

  The content of a request sent to one of its models.

• OpenAIOnly if you enable it

  Serves AI models, where an administrator has enabled them and one is selected.

  The content of a request sent to one of its models.

• OpenRouterOnly if you enable it

  Brokers access to one model that can operate a computer. Both EU residency settings refuse it outright.

  The content of a request routed through it, including screen images where that model is driving a machine.

• Z.aiOnly if you enable it

  Wired into our code and used for our own model comparisons. No model in the product’s catalogue routes to it, so a workspace cannot reach it through the product.

  None from a customer workspace today. Listed for completeness rather than because it touches your data.

If we add one, this list changes. Ask at the address below to be told when it does, and you will be.

How long we keep it

• Workspace content is kept for as long as the workspace exists. Deleting a workspace is a soft delete with a recovery window — 30 days by default — after which it is permanently purged.
• Removing someone from a workspace ends their access immediately. Their record in the team roster is kept, so the work they did still has an author and so a later re-invite restores them rather than creating a stranger.
• AI sessions and the record of what an AI employee was allowed to do are kept as a history of what happened. They are deliberately not editable after the fact — an audit trail that can be rewritten is not one.
• A pending invitation expires after 30 days.
• Deleting a file deletes it. Galior offers an undo straight afterwards, which puts it back; there is no separate bin it waits in.
• Billing records are kept for as long as we are required to keep them.
• An enquiry left on the design-partner form is kept for up to 12 months, or until that conversation is closed, or until you ask us to delete it — whichever comes first. A daily job deletes the ones that have passed any of those, so the window is enforced rather than merely stated.

There is no self-serve “delete my account and everything in it” button today. Ask at the address below and it will be done — we would rather tell you the button does not exist than describe a process we have not built.

How it is protected

Everything is HTTPS in transit. The database and file storage sit on managed Postgres which encrypts data at rest. Credentials we hold for you — your model-provider keys, machine credentials, connected-account tokens — get a separate layer of AES-256-GCM encryption on top of that, and with no encryption key configured storing them fails rather than storing them in the open. Access to a workspace is enforced in the database itself rather than only in the application, so one customer cannot read another’s rows.

What we do not claim: we hold no SOC 2 report, no ISO 27001 certificate and no other security certification, and we have not commissioned an external penetration test. The trust page says the same thing at more length.

This website

The public pages — this one, the homepage, the terms, the trust page and the one-pagers — set no cookies, run no analytics, and embed nothing from a third party. Nothing you do on them is tracked. The only cookie Galior sets anywhere is the one that keeps you signed in to the application, and it is set when you sign in.

These pages ask you for one optional enquiry, on the design-partner form: a work email (required to send), and optionally your first name, last name, role, company and a message. Reading the site does not require it. When you send it, it is written to our own database — the same one the application runs on, listed above as Supabase — and it is not passed to a mailing-list provider or a form service. A copy is sent through Resend solely to alert the person who runs Galior, so they can reply to you. We use it to reply to you about becoming a design partner, and for nothing else: no newsletter, no product announcements, no list anyone else can rent. We keep it for up to 12 months, or until that conversation is closed, or until you ask us to delete it, whichever comes first, and a daily job carries that out. Ask at the address below and it is deleted the same way.

Your rights

If you are in the EU or the UK, you can ask for a copy of the personal data we hold about you, ask us to correct it, ask us to delete it, ask us to restrict or stop processing it, and ask for it in a portable form. Write to guilhem.cozier@galiorhq.com and you will get a real answer from a person, normally within a month.

If the data is in a workspace belonging to your employer or your client, they decide what is in it — so we will usually pass your request to them and tell you we have. If you are unhappy with how we have handled it you can complain to the Belgian Data Protection Authority (Autorité de protection des données / Gegevensbeschermingsautoriteit) or to the supervisory authority where you live.

Who this is for

Galior is a business product, sold to organisations. It is not intended for children, and we do not knowingly collect data about anyone under 16.

Changes

When this policy changes, the date below changes with it. If a change materially affects how we handle your data — a new sub-processor, a new purpose — we will tell you rather than let you notice.

Ask us something specific

Galior is early and small enough that a real answer to a specific question is faster than a generic document. This policy was written by us and not by a lawyer; it is accurate about what the system does, and we would rather you asked than assumed. guilhem.cozier@galiorhq.com.

Last updated 5 August 2026.