Privacy Policy

1. Controller

PlentyLabs UG (haftungsbeschränkt) & Co. KG
Brunnenstr. 169
10119 Berlin
Germany
Represented by: Carmine Paolino
Email: support@chatwithwork.com

When an organization sets up a bot, the people who write to it are the organization's contacts. The organization decides what its bot reads and answers, and is the controller of that data; we process it on its behalf under our data processing terms.

The same holds for everything an organization's people bring into Chat with Work for their work: the organization is the controller, and we process it on its behalf under our Data Processing Agreement, which is part of the Terms of Service for every business customer. This policy covers what we control ourselves, and describes how the service handles the rest.

2. What data we process

• Account data: email address, password (hashed), your name if you sign in with a connected provider such as Google, account settings, and your default model and timezone. Your profile picture: one you upload, or the one Google, Slack, or Dropbox has of you when you sign in with them, which our servers download and store. We serve it ourselves, so no other service is asked for it when a page shows it. Pictures are stored like chat attachments, encrypted by the application.
• Sign-in security: if you turn on two-step verification, the public key and the name you give each passkey (the private key never leaves your device or password manager), when each was added and last used, your authenticator app's secret (encrypted), and your recovery codes, which we keep only as keyed hashes. We record each sign-in, failed sign-in, second step, lock, and change to how you sign in, with the time, the IP address, a short description of the device (like "Firefox on Linux"), and how you signed in, so you can review them in Settings and we can investigate misuse. Counting failed attempts lets us lock an account after too many and email you an unlock link.
• Launch audience data: email address from previous signup interest forms.
• Google Drive, Dropbox, and OneDrive connections: OAuth tokens (encrypted using Active Record Encryption), file metadata, and file contents needed to answer chats. Every connection starts at "Read", where we request read-only access: Drive, Docs, Sheets, and Slides read-only scopes for Google; account info, file metadata, and file content read scopes for Dropbox; and Files.Read for OneDrive through Microsoft Graph. Dropbox files are searched, listed, and downloaded through Dropbox's official MCP server using the same token. If you set Dropbox or OneDrive to "Read and change", we also request permission to change files: files.content.write and sharing.write for Dropbox, and Files.ReadWrite for OneDrive. Changes to Dropbox are made through Dropbox's HTTP API. If you set Google Drive to "Read and change", we also request Google's drive scope, so the assistant can create Google Docs, Sheets, and text files, add to or replace text in a Doc, rename and move files and folders, share them with someone, and move them to the trash, wherever your Google account may do so, each only after you approve it. Nothing is deleted for good: Drive keeps trashed files for 30 days.
• Gmail and Google Calendar connections, where we offer them: OAuth tokens (encrypted using Active Record Encryption), and the email messages, attachments, and calendar events needed to answer chats. At "Read", we request gmail.readonly and calendar.readonly. If you set Gmail to "Read and change", we also request gmail.compose, so the assistant can save drafts and send email, each exactly as you approved it; it cannot label, archive, or delete mail. If you set Google Calendar to "Read and change", we also request calendar.events, so the assistant can create, update, and delete events and answer invitations, each only after you approve it. Each Google integration keeps its own token with only its own scopes, so your Drive token cannot read your mail.
• Slack connection: OAuth tokens (encrypted using Active Record Encryption), channel and message metadata, message contents, and workspace member profiles (including email addresses) needed to answer chats. At "Read", we request read and history scopes only. If you set Slack to "Read and change", we also request chat:write, reactions:write, and files:write, so the assistant can post messages, add reactions, and share files as you, each only after you approve it. Searches go through Slack's Real-time Search API where Slack lets Chat with Work use it, and through Slack's older search API until then. Messages the Real-time Search API returns are not cached outside your chats.
• Basecamp connection: OAuth tokens (encrypted using Active Record Encryption), project metadata, and the contents of Basecamp records needed to answer chats. Basecamp does not offer read-only tokens, so the token Basecamp issues has the same access as your Basecamp account, at either level. At "Read", Chat with Work's Basecamp tools only read data. If you set Basecamp to "Read and change", the assistant can also post messages, comments, and Campfire lines, upload files, add or complete to-dos, move cards and complete their steps, add events to a schedule, and move items to the trash, each only after you approve it.
• MCP servers you add: the server's name and address, the credentials you give us for it (bearer tokens, custom headers, or OAuth tokens, all encrypted using Active Record Encryption), the list of tools it offers, and the tool requests and results exchanged with it during your chats.
• Outlook and Teams connections: OAuth tokens (encrypted using Active Record Encryption) and the email, calendar events, Teams chats, and channel messages needed to answer chats, read through Microsoft Graph. At "Read", we request read access: Mail.Read and Calendars.Read for Outlook; Chat.Read, ChannelMessage.Read.All, Team.ReadBasic.All, and Channel.ReadBasic.All for Teams, which your Microsoft 365 administrator may need to approve. If you set Outlook or Teams to "Read and change", we also request Mail.ReadWrite, Mail.Send, and Calendars.ReadWrite for Outlook, and ChannelMessage.Send and ChatMessage.Send for Teams.
• SharePoint connection: OAuth tokens (encrypted using Active Record Encryption) and the site, file, and page contents needed to answer chats, read through Microsoft Graph. We request read access to sites (Sites.Read.All), which your Microsoft 365 administrator may need to approve. Chat with Work's SharePoint tools only read.
• Nextcloud connection: your server's address, an app password you grant (encrypted using Active Record Encryption), and the file contents needed to answer chats. Nextcloud app passwords have the same access as your account; at "Read", Chat with Work only offers tools that read. If you set Nextcloud to "Read and change", the assistant can also create, move, share, and delete files (to the trash bin), each only after you approve it.
• Odoo connection: your Odoo's address, its database, your login, an API key you create in Odoo (all encrypted using Active Record Encryption), what connecting learns about your Odoo user (name, language, time zone, and companies), and the records needed to answer chats. Odoo API keys have the same access as your Odoo user; at "Read", Chat with Work only offers tools that read. If you set Odoo to "Read and change", the assistant can also create, update, and delete records and run actions such as posting a bill, each only after you approve it.
• Bugsink connection: your Bugsink's address, an API token you create in Bugsink (both encrypted using Active Record Encryption), how many projects the token can see, and the issues and events needed to answer chats. Chat with Work reads an event's exception, stack trace, tags, and the host of its request, and leaves out its user, request details, and extra data. At "Read", Chat with Work only offers tools that read. If you set Bugsink to "Read and change", the assistant can also resolve, reopen, mute, and unmute issues, each only after you approve it.
• Connections through a vendor's own MCP server (Notion, Todoist, GitHub, Linear, Jira and Confluence, Granola, Fireflies, HubSpot, Salesforce, Intercom, Asana, monday.com, and the thousands of other services listed in the app): the tokens the vendor issues when you sign in (encrypted), if it asks you to, and the requests and results exchanged with that server during your chats. For Intercom, we connect to the server in the region your workspace is hosted in (US or EU).
• Computers you pair (Chat with Work Desktop, which is open source): the device's name and public key, when it connects, a log of each request it answers (without contents), the text of files it reads from folders you allow, and a file the assistant copies from one of those folders into a chat's files, which is kept there like any chat file. In folders where you allow changes on the computer, the assistant can also propose changes to files, each only after you approve it; we store the proposed change and the computer's check of it (for example, the difference it would make to a file), encrypted with your chat. What a change replaces or removes goes to the trash on your computer.
• Commands on your computer: only if your organization's owners or admins turn on commands on computers, and you allow commands in a folder on the computer itself, the assistant can propose a command to run there. Each command runs on your computer, not on our servers, in a sandbox Chat with Work Desktop sets up: it can change only that folder, and uses the network only if you allowed it for that folder. It runs only after you approve it, or without asking in a chat where you chose "Allow everything". We store the command and its result (its exit code and the end of what it printed), encrypted with your chat, like any other tool result. While a command runs, its latest line of output is held, encrypted, for a few minutes at most, until the chat has received it. The audit event for each command records the shared folder and the folder inside it where it started, whether it could use the network, its exit code, how long it ran, and how much it printed, never the command or its output.
• Your browser: only if you install the Chat with Work browser extension (which is open source) and turn on your browser in Chat with Work Desktop, the assistant can use tabs in the extension's own "Chat with Work" tab group, on the sites you allow on the computer. The extension talks only to Chat with Work Desktop on your computer, which passes us what the assistant asks for: the titles and addresses of the tabs in that group, the text of a page as it reads it, and screenshots of it. It never reads password, card, or one-time code fields, and blurs them in screenshots. If you also allow actions there, it can open pages, click, type, choose, and save files into a folder you share, each only after you approve it; we store the proposed action and the screenshot it showed you, encrypted with your chat. The audit event for each request records the site, never the page's address or text.
• Code the assistant runs: unless your organization's owners or admins turn it off, the assistant can write and run code in chats that use a paid model, to calculate and to make files such as documents, decks, and spreadsheets. The code runs in a sandbox on our servers in Germany, with no network, and sees only the chat's attached files and the templates below; nothing is sent to any other service to run it. We store the code and what it printed, encrypted with your chat, and the files it makes in the chat's files, which are encrypted at the application level like attachments. A repository copied into a chat is also unpacked, unencrypted, on our job server while the chat works on it, so code and searches read it in place: that copy is deleted after an hour without use, within a day in any case, and whenever the server restarts. We record how long each run used the processor, for credits.
• Templates: PowerPoint, Word, or Excel files you, your project, or your organization upload for the assistant to build files on. They're stored like chat attachments, encrypted at the application level.
• The Office add-in and the Google Workspace add-on: when you ask Chat with Work from its pane in Word, Excel, or PowerPoint, or from its sidebar in Google Docs, Sheets, or Slides, the pane sends with your question what you selected (text, or a range's cells and formulas with the sheet's data around them) and the open document's name and address. We keep them with the chat, encrypted at the application level. A change the assistant proposes to the open document is made there, by Word, Excel, PowerPoint, or Google's editor, only when you approve it in the pane. The Google add-on asks Google only for access to the document it is opened in (documents.currentonly, spreadsheets.currentonly, presentations.currentonly) and to show its sidebar (script.container.ui); it reads nothing else in your Google account and holds no Chat with Work password or token. The pane signs in to Chat with Work on its own, in a window you confirm.
• Several accounts: if you connect more than one account of the same service, we store, for each, the service's identifier for the account and a name for it (by default the workspace name or the account's email address, which you can change). The model you select receives these names so it can tell your accounts apart.
• Changes you approve: when an integration is set to "Read and change", the assistant may propose a change, such as a message to post or a file to create. We show it to you exactly as it will run and make it only if you approve. You can allow a kind of change for the rest of a chat, or choose a mode for a chat that lets changes run without asking: "Allow edits", where deleting, sharing, or changing who has access still asks, or, where your organization allows it, "Allow everything", where those run too. We store the proposed change (encrypted, with your chat), your decision, and an audit event that records which tool ran, when, and the identifier of what it changed, without the content.
• Service data: chat messages and history, chat titles, conversation summaries created when a long chat is compacted, instructions the assistant reads in your chats (yours, your projects', and your organization's) and their earlier versions, short facts the assistant remembers about you, which you can see and delete in Settings, shared chat links, credits/plan usage, support tickets, and files you upload or that are read from connected accounts (docs, sheets, slides, PDFs, audio, video, images; including extracted text and image descriptions).
• Events your bots' triggers listen to: when you set a bot to start when something happens, we receive what that source sends: the body a service posts to its trigger's webhook address, what a program posts with its trigger's key, your GitHub notifications or a repository's events read with your GitHub connection, the sender, recipients, and subject of new mail in an Outlook folder you chose, and mail you send or forward to its trigger's own address, including its text and attachments.
• The Chat with Work GitHub App: if your organization installs it on a GitHub account, we keep that account's name, the installation's id, and which repositories it covers. GitHub then sends us events from those repositories (issues, pull requests, reviews, comments, pushes, releases, branches and tags). We keep an event only when one of your organization's bots' triggers listens to its repository, and only the repository, what happened, its title, who did it, and its links; the rest we drop without keeping it. A trigger hears an event only while the bot's maker can read that repository on GitHub, which we ask GitHub using their own GitHub connection and their GitHub username. The app can also download a repository into a chat for someone GitHub says can read it. When your organization gives a bot repositories to work on through the app, an issue, pull request, comment, or review there is a message to that bot, kept as bots' messages are (below), with what it says and the GitHub username of who wrote it. Through the app, such a bot reads those repositories' code, issues, and pull requests, and writes comments, labels, and whether an issue is open, as your organization's policies for that bot allow. Only for a bot your owners or admins let write code, it also makes branches of its own, commits code to them (from the bot's chat, or from a computer shared with the bot), and opens draft pull requests; it never merges, and never changes workflows on GitHub.
• Bots: when your organization sets up a bot, the messages people send to it, who sent them, and its replies. Each message is stored encrypted, and becomes part of a chat in the bot's project, which the project's people can read. A bot your organization binds to Slack or Discord channels takes the messages there that mention the app, or, if your organization chose so, every message there, with who wrote it; we read a Discord channel every minute for new messages, and keep only those the bot takes.
• Chat apps: if you talk to Chat with Work in Slack, Microsoft Teams, Discord, or Basecamp's Campfire, we receive what you write to it there, your account's id and name on that platform, and where you wrote (for Slack's /cww, the conversation you typed it in, which we answer in your direct message with the app instead), and, when you open the app's Home tab in Slack, that you opened it. When you link your account, the platform confirms who you are; we keep the link until you remove it. Slack sends us every message in channels where the Chat with Work app was added. We act only on messages written to the app, and on replies in threads it answered in; the rest we drop without reading or keeping them. Teams sends us only messages written to the app or mentioning it, and tells us when the app is added to a chat, team, or group chat; to answer someone who isn't linked yet, we ask Teams which Microsoft 365 organization they belong to and their sign-in name, which we use only to offer the link. When an admin connects your Microsoft 365 organization, their Microsoft sign-in gives us its id and name, and their admin roles, which we check and don't keep.
• Web search: if your organization allows it and you turn it on in a chat, the model may search the web while answering. We keep the searches it ran and the pages it cited with the chat, like the rest of the answer.
• Project membership and sharing: which projects you are on, and, for chats in a project, who asked each question. People on a project can read its chats; guests can read only the chats shown to them, without their links. The results your connected accounts return are shown in full only to you.
• Your agreement to how answers use AI models: before the first thing you send goes to a model, the app asks you once, naming the companies that run the models (section 5) and where. When you agree, we keep when, which version of that text you agreed to, which companies it named, and whether you agreed in a browser, in one of the apps, or in an editor's pane. It holds nothing you asked, and it's deleted with your account. If that text changes or names another company, the app asks again.
• Feedback on answers: when you rate an answer with a thumbs up or down (a thumbs down is also how you report one as offensive or harmful, in the apps from the answer's menu), we store your rating, the reasons you pick, any comment you write, which model answered, which tools the answer used and how often, how long it took, and identifiers for you, your organization, the chat, and the answer. This doesn't include what you asked or what the assistant answered, and staff see only these details. Your comment is encrypted. Only if you tick the box to share the chat do we also keep a copy of it as you saw it at that moment, for our staff to read so we can find what went wrong: your questions and the answers up to the one you rated, the names of files you attached (not the files), the tools used and what your own tools returned, and your own instructions. Other people's tool results in a project chat, other people's names, and your organization's and projects' instructions are not included. Guests can rate answers but can't share a chat. The copy is encrypted, and every time staff read it is recorded.
• Payment data (when billing is enabled): the billing name, address, country, VAT ID, and invoice email your organization's owners and admins enter; whether the European Commission's VIES service confirmed the VAT ID, when, its consultation number, and the name and address VIES returned for it; the country of the card or bank account that paid; and payment method tokens handled by Stripe.
• Dictation: when you dictate into the composer, or into Chat with Work Desktop's app, the recording of what you said, and a record that you dictated, when, and the tokens and cost it used. Your browser asks before it lets us use your microphone.
• Technical data: IP address, user agent, request and error logs, performance traces and metrics, and security audit events.

3. Purposes and legal bases

• Provide the service, including search, reading, and, with your approval of each change, changes in the services you connect, tools from MCP servers you add, and chat responses (contract Art. 6(1)(b) GDPR).
• Security, operations, error monitoring, and self-hosted analytics/support (legitimate interests Art. 6(1)(f)).
• Launch and product communications (consent Art. 6(1)(a)).
• Ratings of answers, their reasons and comments, to improve answers (legitimate interests Art. 6(1)(f)). A chat you share with a rating (consent Art. 6(1)(a)), which you can withdraw at any time: untick the box under the answer, or use Stop sharing in Settings ▸ Shared links.
• Emails about new releases to people with an account. Signing up says so, every one of them says how to stop them, and you can object at any time: turn off New releases in Settings ▸ Notifications, or use the unsubscribe link in any of them.
• Billing and compliance when applicable (legal obligation Art. 6(1)(c)).

4. Cookies and tracking

We use essential session/auth cookies and a cookie that stores your browser's timezone. The pane in Office and Google's editors keeps its own sign-in cookie, which only works inside that editor. No tracking or marketing cookies are set. Plausible is self hosted and cookieless.

5. Processors and hosting

The companies that process personal data for us are listed, with what each receives and where, on our sub-processors page.

• Google Vertex AI (Gemini models) on Google Cloud's eu multi-region endpoint, which keeps processing within the EU while routing between EU regions. Used for chat responses when you select a Gemini model, except a step Google's EU endpoint is too busy to answer, which AWS Bedrock (below) answers instead, or Microsoft Azure (below) where Bedrock isn't set up, and the chat says so; and always used for summaries of long chats, text extraction from scanned PDFs, descriptions of images read from connected accounts, and transcribing what you dictate, except a summary, extraction, or description Google is too busy for, which AWS Bedrock (below) does instead. Uploaded files too large to send inline are staged in a Google Cloud Storage bucket in the EU multi-region while the model reads them, and deleted within a day. If you turn on web search in a chat with a Gemini model, the search queries the model writes are sent to Google Search, which is not covered by the EU processing described here.
• Microsoft Azure AI Foundry (OpenAI GPT models) in an EU resource (Germany West Central) using EU Data Zone Standard deployments, which Microsoft processes only within EU member states. Used for chat responses when you select a GPT model, for the free model's chat responses while Hetzner is busy (a step of a free answer then goes to GPT-6 Luna), for writing chat titles (GPT-6 Luna), and on installs without AWS Bedrock for a step of a Gemini answer while Google is busy. We ask Azure not to store responses (store: false). If you turn on web search in a chat with a GPT model, the search queries the model writes are sent to Microsoft's Bing search, which is not covered by the EU Data Zone described here.
• Amazon Web Services Bedrock (Anthropic Claude models) through its EU cross-region inference profiles, called from Frankfurt (eu-central-1), which AWS routes only between its EU regions. Used for chat responses when you select a Claude model, and by a Claude model for a step of a Gemini answer while Google's EU endpoint is busy, and for a chat title, summary, text extraction, or image description while Azure or Google is too busy for it. AWS runs these models in its own accounts, so Anthropic has no access to your requests.
• Hetzner's Inference API in the EU for the free model (Qwen). Used for chat responses when you select the free model, except while Hetzner is busy, when Microsoft Azure (above) answers instead. Hetzner states that it does not store request content.
• Hetzner (Germany for the app, database, file storage, and malware scanning; Finland for analytics/support infrastructure).
• Amazon Web Services (Amazon SES in Frankfurt, Germany) to send account and notification emails, and to receive mail sent to your bots' trigger addresses: SES checks it for spam and viruses and stores it in Amazon S3 in Frankfurt, encrypted with our key, until we read it, at most 7 days.
• Push notification services, only once you turn notifications on: your browser's own push service (Google for Chrome, Mozilla for Firefox, Apple for Safari, Microsoft for Edge), and Apple Push Notification service and Firebase Cloud Messaging for the iPhone and Android apps. Browser notifications are encrypted so that the push service can't read them; they show a chat's title and the start of its answer, or what waits for your decision, unless you turn that off in Settings. Notifications to the apps carry no chat content: your organization's name, what happened (for example, that an answer is ready), a link to the chat, and an encrypted identifier. As a notification arrives, the app uses that identifier to fetch the chat's title and the start of its answer, or what waits for your decision, from our servers in Germany, unless you turn that off in Settings, so that text never passes through Apple's or Google's push services. While an answer runs, an iPhone's Live Activity or an Android phone's Live Update shows what kind of step it is taking and in which connected service (for example, "Searching Todoist"), and how many steps it took, sent through those push services, but never what it searches for, reads, or writes.
• Error reports go to Bugsink, error tracking software we run ourselves on our Hetzner servers in Germany, so no outside company receives them. A report says what failed and where in our code: the kind of error, the lines of code it passed through, your user ID, and the request's method, host, and route. Each report is rebuilt from a list of what may be kept before it's stored, so it never carries what you asked, typed, or read, your name or email address, error messages that could quote them, search terms, form fields, request bodies, cookies, or IP addresses. Bugsink keeps a fixed number of reports per service and deletes older ones as new ones arrive.
• Performance traces and metrics go to Seq, log software we run ourselves on our own server in Berlin, Germany, so no outside company receives them. They say which page or background job ran and how long it took, which model and tool an answer used, how many tokens and credits it took, and whether something failed, with your user ID, your organization's ID, and the chat's ID. Each trace is rebuilt from a list of what may be kept before it leaves the app, so it never carries what you asked, typed, or read, your name or email address, file names, web addresses, search terms, or error messages. Traces are kept for 30 days and metrics for 90.
• Self-hosted installs, which an organization runs on its own servers, send us nothing about the people who use them unless their administrator chooses to. Once a day an install asks chatwithwork.com for the list of releases, which shows us its IP address and version; its administrator can turn this off. Its error reports reach our Bugsink only if its administrator opted in, or sends one by hand, and hold the same as ours: the person by user ID only, with no email address or name, and no request bodies, query strings, cookies, IP addresses, or error messages that could quote what someone asked or read.
• Chat with Work Desktop on your computer sends crash reports only if you turn them on: it asks once, and you can change your answer in its settings or its configuration file at any time. A report goes from your computer to the same Bugsink and holds where in Chat with Work Desktop's code it crashed, the error message written in that code, its version and which of its parts crashed, and your operating system's name, kernel version, and architecture. It never contains your files or their names, chats, tokens, your account, or your user or computer name. Like any connection, sending it shows our server your IP address; the report itself doesn't contain it.
• Bunny CDN to deliver the app's static assets (scripts, styles, images); your browser's requests for them include your IP address.
• Cloudflare for DNS.
• Stripe for payments (may apply 3DS and Radar fraud checks by default).
• The European Commission's VIES service, which confirms EU VAT IDs. We send it the VAT ID your organization entered, with ours.
• Odoo S.A. (Belgium), whose Odoo Online service, on servers in France, keeps our accounting and issues our invoices and credit notes. For each payment or refund we send it your organization's billing name, address, country, VAT ID or tax number, what was bought, its price and VAT, and the Stripe payment's reference. It never receives your chats, files, or anything from the services you connect, and it doesn't email you: we do.
• getwaitlist.com for historical signup interest records (email only).
• Self-hosted Plausible analytics on EU infrastructure; no third-party access.
• Encrypted backups, every day, in two places: a Hetzner Storage Box in Finland, and Scaleway Object Storage in France. Both receive the backups already encrypted, with a key they don't have.

Google, Microsoft, and AWS may keep model inputs and outputs for a limited time under their own documented policies, for example short-lived caching or abuse monitoring. See Google's Vertex AI data governance, Microsoft's Azure data, privacy, and security, and AWS's Amazon Bedrock data protection pages.

The services you connect (for example Google, Microsoft, Slack, Dropbox, and the vendors whose MCP servers you sign in to) are not our processors. You authorize Chat with Work to read your data from them and, for integrations you set to "Read and change", to make the changes you approve there. Their own privacy terms apply, including to what we write there for you (messages, files, comments, to-dos). OneDrive, SharePoint, Outlook, and Teams are read through Microsoft Graph.

Integrations that work through a vendor's own MCP server (Notion, Todoist, GitHub, Linear, Jira and Confluence, Granola, Fireflies, HubSpot, Salesforce, Intercom, Asana, monday.com, and the others listed in the app) are recipients you choose, like MCP servers you add. When you connect one of them, requests are sent to that vendor's server under your account, and the vendor processes them under its own terms with you, on servers it runs where it chooses; its own privacy policy says where. Some need no account; requests to them are sent without one. We don't review each vendor's terms or where its servers run, so check them before you connect one.

6. Data sharing and model use

We share data only with the processors above, with the MCP servers you add, and with the services you connect. For each answer, the model you select receives the prompt, chat context, uploaded files, and tool results needed for that answer. Chat titles, summaries of long chats, scanned-PDF text extraction, image descriptions, and dictation use a Gemini model on Google Vertex AI, even when you select another model for your chats.

Web search is off unless your organization's owners or admins allow it and you turn it on in a chat. When it is on, the model writes search queries from your question and the chat and sends them to Google (Gemini models) or Microsoft Bing (GPT models), which process them under their own terms, as search providers rather than as our processors. We instruct the model to search only for public information and to leave out private details it read in your connected accounts, but a query can still contain words from your chat. Don't turn web search on in a chat whose contents must stay in the EU. The pages it finds are sent to the model as part of the answer.

Bots' API: what an organization's bot replies goes to the program that called the bot's API with the organization's key.

Slack, Discord, and Basecamp: when you ask Chat with Work in one of them, its answers, and any change it asks you to approve, are posted there and kept by that platform under its own terms, mostly outside the EU. In a channel others read, an answer that used your own connected tools is posted only when you choose to post it. In Slack, the Chat with Work app's Home tab shows you, and only you, the titles of your recent chats that started there, with links to them in Chat with Work; Slack keeps that tab until it's drawn again.

MCP servers are run by third parties you choose, not by us. When your chat uses an MCP server's tools, the tool requests, which can include parts of your chat, are sent to that server, and its results are sent to your selected model. The server's operator decides how that data is processed, retained, and protected. A new server starts at "Read", where we only offer tools that the server labels as read-only, but that label is set by the server and we cannot verify it. If you set a server to "Read and change", we also offer its other tools, and each call to one waits for your approval. You are responsible for choosing servers you trust, for the data you let them see, and for any agreements you need with their operators.

In an organization, owners and admins can turn "Read and change" off for everyone. When it is off, no integration or MCP server offers tools that change anything. Only the person who asked can approve a change their question led to; others in a shared project chat see that a change is waiting, not its contents or their tools.

If you create a share link for a chat, anyone with the link can view the chat's questions, attached files, answers, and source links, but not the raw output of the tools, until the link expires, you turn it off, or you delete the chat.

We do not train models on your data, and the hosted app uses model providers whose business terms say customer data is not used to train their models. Support uses account metadata, error summaries, and usage records; admin screens do not show customer chat text or document text, except a chat you chose to share with a rating (section 2) and the test cases made from it, which only our staff can read.

Chat with Work's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Google user data: we access Google Drive, Gmail, and Google Calendar only through the integrations you connect and the Google Workspace add-on you open, with your own Google account and the scopes listed in section 2. We use what we receive only to answer your questions in Chat with Work and to make the changes you approve there. We send it only to the model you select for that answer and the processors in section 5, never sell it, never use it for advertising, and never use it to develop, improve, or train generalized AI or machine learning models, ours or anyone else's. Nobody at Chat with Work reads it, unless you ask us to (for example by sharing a chat with a rating), it is needed for security purposes such as investigating abuse, or the law requires it. Tokens and cached text are encrypted and deleted as section 7 describes.

The Chat with Work browser extension's use of information it receives from your browser adheres to the Chrome Web Store User Data Policy, including the Limited Use requirements.

Browser data: the extension reads only tabs in its own tab group, on the sites you allow, and sends what it reads only to Chat with Work Desktop on your computer, which passes it to Chat with Work for the chat that asked (section 2, "Your browser"). We use it only to answer in that chat and to take the actions you approve there. We send it only to the model you select for that answer and the processors in section 5, never sell it, never use it for advertising or to determine creditworthiness, and never use it to develop, improve, or train generalized AI or machine learning models, ours or anyone else's. Nobody at Chat with Work reads it, unless you ask us to (for example by sharing a chat with a rating), it is needed for security purposes such as investigating abuse, or the law requires it. It is kept with your chat, encrypted, as section 7 describes.

7. Retention

• Account: kept until you delete it in Settings, or ask us to. Deleting your account cancels your plan and deletes your chats, uploaded files, integration tokens, MCP server settings and credentials, cached provider content, notifications, and audit events. Stripe keeps its own payment records as tax law requires.
• Sign-in history: kept for one year, then deleted. If you delete your account sooner, the history stays until then without the link to your account, so we can still investigate misuse. Your passkeys' public keys, your authenticator app's secret, and your recovery codes are deleted at once when you remove them or delete your account.
• Invoices and credit notes: kept for 10 years after they're issued, in our accounting in Odoo and in Chat with Work, as German tax law (§ 147 AO, § 14b UStG) and the EU's One-Stop Shop rules require, even after your account is deleted. Each keeps the billing name, address, country, VAT ID, and invoice email as they were when it was issued, what was bought and its price and VAT, and the country of the card or bank account that paid. Deleting your account deletes your billing details but not your invoices.
• Chats: kept until you delete them. Deleting a chat hides it at once and turns off its share link. 30 days later we permanently delete its messages, tool results, attachments, title, and summary. We keep a record of the tokens and cost each answer used, without any chat content, for credits and billing. Files that a branched chat still uses stay with that branch.
• Bots' conversations: an organization's bot keeps each message it receives for 30 days, then deletes it. Its conversations are chats in the organization's project and are kept like other chats, except that a conversation with no new message for 12 months is deleted automatically, with its chat, whose content we then permanently delete 30 days later. The organization can delete a conversation sooner.
• Trigger events: what a bot's trigger receives is kept encrypted for 30 days when it started a run and for 7 days otherwise, then deleted. The chat a run starts is kept until you delete it, like any chat. Mail to a trigger's address is deleted from Amazon S3 once we read it, and within 7 days in any case. Events the GitHub App receives for triggers are kept encrypted for 7 days, then deleted. An installation of the GitHub App is kept until it's removed, here or on GitHub.
• Chat apps: what Slack, Microsoft Teams, Discord, or Basecamp's Campfire sends us is kept encrypted for 30 days. Your chats keep your questions and answers until you delete them. A link between your chat-app account and Chat with Work is kept until you unlink it, the app is removed, or you leave the organization.
• Code runs and commands on your computers: the code, commands, their results, and the files code makes are part of the chat, and are kept and deleted with it. Commands' audit events, which hold no command or output, are deleted with your account.
• Templates: kept until you remove them, or until their project, your account, or your organization is deleted.
• Chat share links: expire 30 days after they are created or renewed.
• Feedback on answers: your rating, reasons, and comment are kept until you remove the rating, or until the chat is permanently deleted (30 days after you delete it) or your account is. A chat you shared with a rating is deleted 90 days after you shared it, or sooner: as soon as you stop sharing it, delete the chat, or leave the organization. Our staff may turn a rating into a test case for checking answers: from a shared chat, its question, the files and tool results it needed, and what a good answer does, which our AI model in the EU drafts from the shared chat for staff to edit. A test case is encrypted and deleted with what it came from: one from a shared chat with the shared chat, as above, and one from a rating alone with the rating. We keep a test case longer only after rewriting it with made-up details in place of everything from your chat (names, companies, numbers, documents), so it no longer contains your data. Results of test runs keep only whether a case passed, never its text.
• Dictation: your recording is sent to a Gemini model on Google Vertex AI in the EU to be transcribed, and is not kept. We hold it in memory only while it is transcribed, never write it to our database, file storage, or logs, and delete the upload's temporary file as soon as the transcription is done. The words go back to your composer and become part of a chat only if you send them. Google may keep it briefly under its own policies, as with any model input (see section 5). We keep that you dictated, when, and its token usage and cost, without the recording or its words, for credits and billing.
• Content cached from Google Drive, Gmail, Dropbox, OneDrive, and Slack (extracted document text, messages, attachment text, and member profiles): encrypted and deleted after 30 days without being read, or as soon as you disconnect that provider. Slack messages found through its Real-time Search API are not cached. Basecamp content and Google Calendar events are not cached outside your chats.
• Text read from Outlook, Teams, SharePoint, Nextcloud, and your computers is cached encrypted like Drive's and deleted after 30 days without use. Disconnecting an integration, or removing a computer, deletes its tokens and everything cached from it. Disconnecting one of several accounts of a service deletes that account's tokens and what was cached from it; your other accounts stay connected.
• Integration tokens: when you disconnect an integration, we delete its tokens. For Google, Dropbox, and Slack we also revoke them with the provider; Google revokes all of an app's access to a Google account at once, so we revoke it when you disconnect the last of Google Drive, Gmail, and Google Calendar connected to that account. Microsoft and Basecamp do not offer a way for an app to revoke its own access, so for OneDrive, SharePoint, Outlook, Teams, and Basecamp you can also remove Chat with Work in your Microsoft or Basecamp account settings. For Odoo, we delete the API key we stored; you created the key in Odoo, and it keeps working there until you delete it. Bugsink is the same: we delete the API token we stored, and it works until you revoke it in Bugsink.
• MCP servers: removing a server deletes the settings and credentials we stored for it. We cannot revoke credentials on the remote server.
• Logs: kept only as long as needed to operate and secure the service, on our own servers. Error reports: on our own servers, until newer ones replace them under Bugsink's limit on reports per service. Performance traces: 30 days, and metrics: 90 days, on our own server.
• Launch audience email: kept until you unsubscribe or ask us to delete it.
• Backups: encrypted and kept under our backup retention schedule, at most two years. Deleted data may remain in backups until they expire.

8. Your rights

You have the rights to access, rectification, erasure, restriction, objection, data portability, and to withdraw consent. Contact hello@chatwithwork.com to exercise them.

9. Security

We use HTTPS, access controls, two-step verification with passkeys or an authenticator app (which an organization can require of everyone in it), locking after repeated failed sign-ins, audit logging, least privilege (write permissions are requested only for integrations you set to "Read and change", and every change waits for your approval), malware scanning of uploads, encrypted application backups, and application-level encryption for chat content (messages, chat titles, conversation summaries, and tool requests and results, including code the assistant runs and commands on your computers), instructions, memories, OAuth tokens, MCP server credentials, cached provider content, and stored files (what you upload, what the assistant and its code make, profile pictures, and templates). See the Security page for the public control overview.

10. International data transfers

Google Vertex AI, Microsoft Azure, and Amazon Web Services Bedrock process model requests within the EU, but all three providers are part of US-based groups. Hetzner, and Microsoft Azure while Hetzner is busy, process free-model requests within the EU. Stripe and Cloudflare may process data outside the EU/EEA. Where data leaves the EU/EEA, we rely on appropriate safeguards such as standard contractual clauses or the EU-US Data Privacy Framework; our sub-processors page says which for each. MCP servers you add, and the vendors' MCP servers you connect, may be located anywhere; their operators, not us, determine where your data goes. If you turn on web search, the search queries leave the EU: Google and Microsoft run the searches on their global infrastructure. If you ask Chat with Work in Slack, Discord, or Basecamp's Campfire, what you write there and the answers posted there are kept by that platform, mostly outside the EU. In Microsoft Teams, they're kept where your organization's Microsoft 365 keeps its data, and pass between Teams and us through our Azure Bot registration, in the EU. Other processing occurs on EU infrastructure.

11. Children

The service is not intended for children under 16. Please do not sign up if you are under 16.

12. Changes

We may update this policy and will post the updated version here with a new effective date.

13. Contact

Email: support@chatwithwork.com