1. Who we are and what this covers
This policy applies to Hardi AI, operated by Deviantce (the company). The company's representative is Bin Heo, and its address is 401, 8-11 Baekjegobun-ro 41-gil, Songpa-gu, Seoul 05621, Republic of Korea.
- The Hardi AI desktop app (macOS and Windows builds are published today — Linux comes after launch)
- The Hardi AI mobile app (in test distribution)
- Workspace servers (<workspace>.hardiai.com) and the admin console
- This website (www.hardiai.com)
Hardi AI does much of its work, such as running agents, on your computer, and keeps only what your team shares on the workspace server. Section 2 covers what stays on your device; section 3 covers what the server stores.
2. What stays on your device
The following is stored on your computer and is not sent to our servers.
- Your conversation sessions with agents. The agent engine ships inside the app and runs on your computer.
- Your AI model connections (Claude or ChatGPT subscription sign-ins, API keys you enter).
- Meeting recording audio. There is no feature that uploads it, and transcription runs on the device. Recordings are deleted from the device after 30 days by default; you can choose 7, 30, 90 or 180 days, or keep them indefinitely.
- Your workspace identity key (the device private key). Installed builds keep it in the operating system keychain (on Windows, in a file in your user folder encrypted with DPAPI, which only your Windows account can decrypt).
- File lists and contents of folders set to This device only. Watched folders default to This device only.
- What an agent reads from the app windows it operates (text and window pictures) when you turn on Control the screen, which is off by default.
Cloud transcription is optional. It is off by default and can only be turned on after you accept a notice that audio will leave the device. No external transcription provider is connected today.
Our servers cannot delete data on your device. The app does not yet have a control that deletes all device data at once; device data is removed by deleting the app's data folder.
3. What the workspace server stores
| Category | What |
|---|---|
| Account and devices | Display name, profile image address, email address, device public key, device name, operating system, app version, last seen time, and workspace role (owner, admin, member, guest). If you join with an invite link, a placeholder address made from the device public key is used instead of a real email address. |
| Hardi account sign-up and sign-in | When you sign up or sign in with a one-time email code, we keep your email address and a record of each code sent to it. The code itself is kept only as a hash and works once, for 10 minutes; a hash of the IP address the request came from is kept in the same record to limit how many codes are issued. Records older than a day are deleted when a new code is issued. When you sign up or sign in with a Google account, we keep the email address and name Google confirms and that Google account's unique identifier. When an account is created, it records how you signed up (email code or Google) and when, the version (effective date) of the terms you agreed to and when you agreed, whether you chose to receive product news by email (optional — you do not unless you choose it), the language you chose, your display name if you gave one, and any campaign tags in the sign-up page's address (values starting with utm_, up to 8). Account events such as the day you first signed in to the app and the day you asked for the account to be deleted are kept as the date and kind only. Each app and browser you sign in to keeps a sign-in session (the app type, the device public key for an app, and when it was created and expires). Sign-in code emails are sent through the email delivery provider in section 9 (Resend). |
| Beta news waitlist | If you sign up with 'Get beta news' on the website (www.hardiai.com), we keep your email address and, if you fill them in, your name, team size and the AI you use now. Kept with them: the language of the page you signed up on, the campaign tags in the link you arrived by (the utm_source and utm_campaign values), the version of the notice you agreed to and when you agreed, and when you signed up. The IP address the request came from is counted in the server's memory for a few minutes only, to stop too many sign-ups from one place, and is never stored. We take it only if you tick the consent box yourself; it does not create a Hardi account and is not linked to one. For an address that unsubscribed or asked to be deleted, we keep only a code made with our server's secret key (it can only tell whether an address is the same one and cannot be turned back into the address), so that we never email it again. News emails are sent through the email delivery provider in section 9 (Resend). |
| Prospective customer contacts | To propose the founding team and partnerships, we collect business contacts that a company has published itself on its website, in a public directory or in a community: the company name, its website, a business email address or a contact form or community address (which may include a person's name), the public page where we found it (the source), notes on whether the company fits and what to do next, and the record of our contact. We do not collect personal contacts, and we always note the source. When someone joined the waitlist or reached out first, we note that instead. For a contact that asked us to stop or to delete it, we keep only a code made as above so that we never contact it again. |
| Workspace content | Channel and DM messages, attachments and images, team boards, team documents (including the 20 most recent earlier versions), tasks, projects and goals, team calendars and to-do lists. Request bodies sent from outside the workspace to a routine's webhook address (up to 64 KB) are kept as an attachment of the task the request created, for as long as the task is kept. Records of received requests (time, size and result) are kept for the latest 100 per routine; requests that are not accepted (a wrong signature, a routine that is turned off, or too many requests) are only counted, with no body or record kept. |
| Booking links | When someone outside the workspace books a time through a member's booking link: the name, email address and note they enter, and the time they book. |
| Agent run records | Start and end time and status of agent runs in task threads. Visible to members of the same workspace. Conversation text, token counts and costs are not included. |
| Usage records | Model usage totals for seat usage accounting: account, time, model name, billing route (subscription, your own key and so on), token counts and estimated cost. The app sends them at most every 15 minutes. Prompt and response text are not included. |
| Plan and payment | The workspace's plan, its number of seats and the end of the paid period. If you paid by tax invoice (bank transfer): the date the payment arrived and the tax invoice approval number. The business name, business registration number and the name and email of the person in charge, needed for the quote and the tax invoice, are received by email and kept in the company's mailbox and tax records. Payment method details such as card numbers are neither received nor stored by the company. |
| Knowledge search list | For folders you choose to share with your team or your account: file name, relative path inside the folder, type, size, times, content fingerprint (SHA-256), and a summary card made on the device. Original files are not uploaded. |
| Meetings | A meeting list (title, time, which participants may see it, fingerprint). Meeting transcripts are stored only if a workspace admin turns on the transcript upload policy; it is off by default. |
| Connected services | For services you connect (Google, Slack, GitHub, Notion and others): access tokens (encrypted), the connected account address, and items received from that service. Calendar subscription (ICS) addresses are stored encrypted. Google data is described separately in section 7. |
| Moving over from Slack | When a workspace owner or admin uploads an export (ZIP) downloaded from Slack: its channels, conversations, messages, reactions and files, and its list of Slack people (name, email address, Slack user ID, and whether each is a bot or deactivated). Messages and files become workspace content and carry an 'Imported from Slack · imported by' label. The list of people is used only to link members confirmed with the same email address and to send invitation emails. The uploaded ZIP is deleted as soon as it has been read, and messages of private channels and DMs whose original members have not joined yet stay on the server only until they open. When an owner or admin chooses [Delete what was imported], the imported channels and conversations and the list of people are deleted. |
| Mobile notifications | The push token of a device on which you turn on notifications in the mobile app. It is stored encrypted. |
| Measurement (optional) | Team-level work totals, stored only if a workspace admin turns measurement on. It is off by default. The totals have no column that identifies a person, and groups smaller than five are not shown. |
| Audit records | Type, actor, target and time of administrative actions such as sign-ins, permission changes, connecting or disconnecting services, and exports. |
| Reports and blocks | When you report a message, a person or an agent: your account, what you reported (the key and account of the person or agent, and for a message the identifiers of the message and its channel), the reason, the short note you add (up to 500 characters), and the status, handling note and times. The text of the message is not copied into the report. When you block a person or an agent: your account and the key of whoever you blocked. Reports and blocks are not shown to the person reported or blocked, or to workspace admins. |
| Service totals | Counts for the whole service, one row a day: accounts signed up, workspaces, paid seats, monthly recurring revenue by currency, and the people and workspaces that opened the app in the 7 and 30 days up to that day. In the same way we keep totals used to improve the service: how many passed each step after signing up (first workspace, first agent, first delegated task, coming back), how many of each week's sign-ups came back, and how much each feature (tasks, agents, calendar, wiki, connected services and so on) is used. The app usage statistics below are also kept only as weekly totals in the same way (installs that passed each step; counts by kind of work, by person or agent, and the installs that did it; installs that used each feature; agent runs that ended, by how they ended, what started them and how long they took, and the installs that sent them; and counts by screen, agent engine, kind of approval request, error code, app version and operating system). Releases and installs are kept the same way, as daily counts only: installer downloads (by platform and version), update checks and update downloads by installed desktop apps (by operating system and app version), and the devices that connected to the server in the last 1, 7 and 30 days (by app, operating system and app version). The device counts come from session and device records the service already keeps, so devices with 'Send usage statistics' turned off are included; they are daily totals not linked to any person. There is no column that identifies an account, a device or a workspace. |
| App usage statistics | Usage records the desktop and mobile apps send to improve the service: the kind of thing that happened (the app starting, a screen opened in the app, creating an agent, an approval request and whether it was allowed or denied, an error, work such as creating an event, creating and finishing a to-do, creating and handing off a task, or a routine, an agent run in a task thread ending, and steps after installing such as the first launch, the first screen, the first workspace, the first agent created, an agent's first reply and the first task handed to an agent), the fixed words that go with it (the kind of screen, the kind of agent engine and whether the agent came from a template, the kind of approval request, an error code the app defines, the kind of work and whether a person did it in the app or an agent did, and for a run how the run ended (done, failed, stopped or cut off), how long it took, in bands (1, 5 and 15 minutes and 1 hour), and the kind of request that started the run (only the owner's, mixed with other people's messages, or scheduled or a routine)), when it happened (stored rounded to the hour), the app type, version, operating system and language and region setting (for example ko-KR), and a random value made for each install (made anew every 30 days). They do not include the contents or titles of messages, files, documents, events, to-dos or tasks, names, file paths, addresses, error messages, what an approval request was about (the command, file or tool), or any value that identifies an account, a device or a workspace. The app proves it is the genuine app with a device signature when it sends them, but the server does not keep that device key in these records or in its logs. |
| Error reports | When an error occurs in the apps (desktop and mobile) or on the server: the kind of error, a cleaned-up error message, where in the code it happened (file, function, line), and the app version and kind of operating system. Before anything is sent, email addresses, tokens and keys, user folder names in paths, file names, web addresses, text in quotation marks and text written in Korean, Chinese or Japanese are removed from the error message, and only its first line, up to 200 characters, is kept. Request bodies, screen contents and the values of program variables are not included, there is no field that identifies an account, a device or a workspace, and the IP address a report was sent from is not kept with it. The apps follow 'Send usage statistics' in Settings — when it is off nothing is sent, and in the EEA, the UK and Switzerland reports are sent only if you agree in the app. They are kept on the server the company operates itself (section 9) and deleted 30 days after they are received. |
| Improvement samples (optional) | Collected only in workspaces where a workspace admin turned on 'Help improve Hardi'; it is off by default. The workspace's agent role descriptions, task titles, calendar event titles, routine names and wiki page titles, one line each (up to 300 characters) with its kind, the date the original was created or changed, and when it was collected. Only items created or changed in the last 30 days are collected (for agent role descriptions, the agents that exist now), up to 200 of each kind, and only what the whole team can see — personal to-do lists and tasks of projects not open to the workspace, personal and external calendars and private events, wiki pages only you can see or that belong to a channel or project, and routines only for yourself are left out. They do not include the bodies of messages, files, documents or wiki pages, task notes, event descriptions or routine instructions, and nothing links a sample to who wrote it or to which task or event it came from. The account of the admin who turned the setting on or off, and when, is also recorded. |
| Access logs | IP address, request time, request address, response status, referring page address and the browser or app identifier (User-Agent), recorded when you reach the server. The app server's access log drops the query string after the path; the front web server's access log keeps the request address as received. The same entries are created when the app checks for updates. When it checks for updates, the desktop app also sends its app type, operating system and app version (the X-Hardi-Client request header) if 'Send usage statistics' is on — in the EEA, the UK or Switzerland, or when the region cannot be determined, only after you agree in the app. Installer downloads and update checks and downloads are counted only as numbers per day, platform and version (Service totals, section 3). In this counting the IP address and the browser or app identifier are used only in the server's memory on that day, to count repeats from the same place once and to cap how much one place can add in a day; they are kept neither in the totals nor in the app server's access log (the front web server's access log is as described above). |
Hardi AI does not collect keystrokes, screen contents, app switching or working hours, and does not use prompt contents for measurement.
4. Why we use it
- To provide the workspace: delivering messages, syncing between devices, search, calendar and task features
- To provide features of the services you connect
- Account and device authentication, security, abuse prevention and recording administrative actions
- Seat usage accounting, counting seats and charging for the paid plan, and issuing tax invoices
- Beta news waitlist: emailing beta and launch news and invitations to the founding team to people who agreed when they signed up
- Prospective customer contacts: proposing the founding team and partnerships. We make first contact only through an introduction, a partnership or contact form the company offers, or when they showed interest first, and we send advertising emails only to people who agreed. Our first message says where we found the contact and how to stop hearing from us.
We do not use personal information for advertising and we do not sell it. We do not produce per-person productivity scores or rankings, and we do not use it for performance reviews or automated decisions.
To handle sign-ups, payments, support and abuse, and to improve the service, the company's operators can see the following in the operator console.
- Accounts: email address and display name, sign-up date and method, language, whether marketing messages were accepted and the version of the terms agreed to, the dates of account events such as creating a first workspace, getting a first agent reply or asking for deletion, the date of the last connection, the operating system and app version of each device, and the workspaces the account belongs to with its role in each
- Workspaces: name and address, the date it was created and the date of its last activity, the owner's email address, the plan, the number of seats, people, guests and agents, and subscriptions and payments (amount, currency, seats, billing period, the payment provider's subscription and transaction numbers, and tax invoice approval numbers), and receipts for card payments (the payment provider's receipt shows the buyer's name and billing address, and each time an operator opens one it is recorded), and the ownership transfer history (the email addresses of the person who handed over and the person who took over, the date, and whether and by when the new owner registered a card), and a workspace's weekly usage (the days the app was opened, the number of active people and how much each feature was used — no contents, titles or names, and each time an operator opens it this is recorded), and storage usage for one workspace (the number of messages and their total size, and the number of attached files and their total size — no message or file contents)
The operator console does not show the contents of messages, files or documents, the names of channels, projects, tasks or calendar events, or the names given to devices. The only exceptions are a reported message and the improvement samples of workspaces that turned on 'Help improve Hardi', both below, and what you send us yourself with 'Send feedback' in the app. Operators read that feedback in their inbox; an image sent with it is opened only by an operator who has re-entered their password, and each opening is recorded. When an operator opens the details of an account or a workspace, or changes anything, this is recorded in a hash chain, so edits to past records are detectable.
When someone reports a message, a person or an agent, the company's operators see what was reported, the reason and the workspace, so they can handle the report. For a reported message, while the report is open and for 30 days after it is closed, an operator who has re-entered their password can open that one message, and each opening is recorded. Who made the report is not disclosed to the person reported or to workspace admins, and is not shown in the operator console either.
To run the service, we record totals for the whole service once a day, such as the number of accounts signed up and the number of people who opened the app in the last 7 and 30 days (Service totals in section 3). Totals of the steps after signing up and of how much each feature is used are recorded the same way. To see whether releases and updates reach people, we also record daily totals of installer downloads, update checks and update downloads and of the devices that connected in the last 1, 7 and 30 days (by app, operating system and app version) — the device counts come from records the service already keeps, so devices with 'Send usage statistics' turned off are included. These records have no column that identifies an account, a device or a workspace; they hold only totals for the whole service.
To improve the service, the apps send the company which features were used, when and how often (for example how many agents were created, how many approval requests were made, the kinds of screens opened and the kinds of errors) — App usage statistics in section 3. They do not include the contents or titles of messages, files or documents, or names, and instead of a person or a workspace they carry only a random value made for each install that cannot be traced back. The app sends these records in batches every 5 minutes, and a batch that could not be sent is discarded, not sent again. You can turn off 'Send usage statistics' in Settings; from then on nothing is sent, and the app asks the company to delete the records that device sent. In the EEA, the UK and Switzerland they are sent only if you agree in the app — decided from the device's language and region setting or its time zone, and if neither is known, the app asks before sending anything. The mobile app also asks first whenever it cannot read the device's time zone, whatever the region setting. The company groups what it receives into weekly totals for the whole service and looks at them in the operator console. The app type, operating system and version the desktop app sends when it checks for updates (Access logs, section 3) follow this setting and this consent in the same way — nothing is sent while it is off or before you agree.
When a workspace admin turns on 'Help improve Hardi', the company may see that workspace's agent role descriptions, the names of its tasks, calendar events and routines, and its wiki page titles to improve the service (Improvement samples in section 3). The bodies of messages, files and documents are not included. Once it is turned off nothing more is received, and what was received is deleted within 30 days. Each time an operator looks, it is recorded. The setting is off by default, only the workspace's owners and admins can turn it on or off, and when it is turned on the desktop app tells the workspace's members once. The operator console shows which workspaces turned it on and when, when samples were last collected and how many there are of each kind; the samples themselves can be opened by one of the company's operators one workspace at a time, after re-entering their password.
5. AI models and agents
Hardi AI servers do not call AI models.
Agents run on your computer and call models through the model provider account you connected yourself (for example a Claude subscription, a ChatGPT subscription, or an API key you entered). The content needed for the work you ask for (the conversation, file contents, information read from connected services and, if you turned on Control the screen, what the agent reads on screen) is sent from your device to that provider. This does not pass through our servers and is governed by the terms and privacy policy between you and that provider.
We do not train AI models on your data.
6. How long we keep it and how it is deleted
- Account and workspace information and workspace content: kept while the workspace exists. The app has no workspace deletion feature yet, so deletion is handled on request through the contact in section 14.
- Channel messages: kept with no time limit. The cleanup job that deletes older messages automatically is not turned on in production yet; deletion is handled on request through the contact in section 14.
- Connected services: when you disconnect a Google account or a calendar subscription (ICS), the server immediately deletes its tokens and the subscription address. For a Google account, the copies and search lists that came from it are deleted as well; Google is covered separately in section 7. Slack, GitHub, GitLab and Gitea, which a workspace owner or admin connects, can be disconnected on the app's connection screen. Disconnecting immediately deletes that service's tokens from the company's server and, for Slack, GitHub and GitLab, also asks the service to revoke them (Gitea does not accept revocation, so its token is deleted from the company's server but stays valid at Gitea until it expires). Items read from GitLab or Gitea are taken out of the search lists when you disconnect and come back if you connect again; items read from Slack (search lists and summaries, notifications not yet processed, and linked Slack accounts) are deleted from the company's server when you disconnect (the same happens when Slack tells us the app was removed); items read from GitHub stay as workspace content. To have read items deleted, ask through the contact in section 14. Tokens a member connected personally are deleted when that member is removed from the workspace; otherwise they are deleted on request through the contact in section 14.
- Removed members: when a member is removed from a workspace, their connected-service tokens, connections, server calendar copies and the Google search lists uploaded to that workspace's server are deleted with them.
- Knowledge search list: when you set a folder back to This device only, the app asks whether to delete the entries already uploaded.
- Access logs: the workspace server keeps up to five 20 MB files per service, oldest removed first. The front web server's access log has no automatic deletion configured yet. The log store the company keeps on the same server (section 9) to watch the service also collects each service's logs, access logs included, and deletes them after 7 days.
- Audit records: kept while the workspace exists; they are not deleted automatically.
- Meeting recordings (device): deleted from the device after 30 days by default.
- Backups: since October 3, 2026 the database and attachments are backed up every day to a separate disk in the same server. Backups from the last 14 days are kept, plus one weekly backup for each of the four weeks before that; the rest are deleted. Data deleted from the server remains in those backups until they are deleted.
- Plan and payment records: records of payments and of what was supplied are kept for 5 years under the Korean e-commerce and tax laws.
- Reports and blocks: reports are not deleted automatically, and they remain as the basis for the operators' action even if the person who made the report deletes their account. A block is deleted when it is lifted or when the account of the person who set it is deleted.
- Records of what the company's operators opened and changed: the log can only be added to, so its entries cannot be edited or deleted, and they are not deleted automatically.
- Service totals: kept with no time limit.
- App usage statistics: deleted after 90 days. If you turn off sending them in Settings, the app asks for the records that device sent to be deleted, and the server deletes them as soon as the request arrives (if the request does not get through, they are deleted after 90 days). Weekly totals remain as service totals.
- Improvement samples: collected anew every night, and deleted 30 days after they were collected. When 'Help improve Hardi' is turned off, that workspace's samples are deleted right then, and they are also deleted when the workspace is closed or deleted. When an account is deleted, the samples of the workspaces that person belonged to are deleted too (if the setting is still on, they are collected again the next night from what remains in the workspace). The record of turning the setting on and off, including the account of the admin who turned it on, is kept while the workspace exists.
- Error reports: kept on the server the company operates itself (section 9) and deleted 30 days after they are received. A report does not keep the IP address it was sent from (the server's access log entry for that request follows 'Access logs' above). When their storage reaches a set size, new error reports are not accepted until space frees up.
- Beta news waitlist: deleted when you unsubscribe with the link in any email it sends you, or right away when you ask the contact in section 14 to delete it, and otherwise one year after the public launch (or one year after you signed up, if that was after the launch). The code we keep so as not to email you again (section 3) is used for nothing else.
- Prospective customer contacts: the contact details, source address and notes are deleted when a year passes after our last change or contact without the company starting to work with us (only company details such as its name and website stay). If someone asks us to stop, we mark them 'do not contact' that same day; if they ask us to delete it, we delete the contact details and notes right away and keep only the code described in section 3 so that we never contact them again.
Deletion is done by deleting database rows and stored files. Information that the law requires us to keep is kept for that period.
7. Google user data
A Google account is connected only when you connect it yourself from the app's connections screen. Connecting Google Calendar asks only for calendar access and the basic permissions (openid, email) used to show which account you connected. Google Tasks, Gmail, Drive, Meet, and writing to Sheets and Docs are optional connections that you turn on one by one, and each asks only for its own additional permission. Hardi AI does not access Google data for a feature you have not turned on.
| Permission | What is read and written | Used for | Stored |
|---|---|---|---|
| OpenID and email address (openid, email) | Reads the email address of the Google account you connect. Writes nothing. | Showing which Google account is connected | Server: the connected Google account address |
| Read calendars, write events (calendar.readonly, calendar.events) | Reads your calendar list and events (title, description, location, meeting link, time, recurrence, attendees, organizer). Writes: creating, changing or deleting events and answering invitations when you or an agent you direct asks; events booked through your booking links (the name and email address the person booking entered are added as an attendee); and copies of team events you attend (you can turn these off in calendar settings). | The calendar view, finding free time, event reminders, and creating and changing events | Server: event copies (title, description, location, meeting link, time, recurrence, attendees, organizer) and a search list only you can see (title, time, busy state). Device: the same search list. |
| Google Tasks (tasks) | Reads your task lists and tasks (title, notes, due date, completion, subtasks, order). Writes: tasks that you or an agent you direct add, change or delete in Hardi AI are written back to Google Tasks. | The to-do view, importing tasks and writing them back | Server: task copies (in your private lists) |
| Read and send Gmail (gmail.readonly, gmail.send), optional connection | Reads message subject, date, labels and size, and the sender, recipient and cc addresses (addresses are used only to build a fingerprint that tells identical messages apart and are not stored in the search list). When you ask an agent to find mail, the device reads the sender, subject, date and preview line. When you ask an agent to reply to a message, the server reads only that message's headers (subject, sender and reply-to address, message ID, thread) to fill in the reply card. Full message bodies are not requested. Writes: sending mail only. An agent cannot send mail; it only puts up a mail card that shows the recipients, subject and full text as they will be sent. When you press Send on that card, that one message is sent from your Gmail (a reply goes into the same thread). Hardi AI does not save unsent messages in your mailbox, change labels or delete mail. | A mail search list only you can see, and sending or replying to a message when you press Send on its mail card | Your private area on the server: the search list's subject, date, labels, size and fingerprint (sender and recipient addresses are not stored in the search list). Mail cards: the recipient, cc and bcc addresses, subject, sending Google account and, for a reply, the original message's ID and thread. A card's message text is kept on the server only while the card is open; it is deleted as soon as you send it or press Don't send, and within a day after an unsent card expires (7 days after it was made). The sent message is in your Gmail Sent folder; the mail card on the server keeps no message text. |
| Read Drive (drive.readonly, drive.metadata.readonly), optional connection | Reads file name, type, size, times and permission information. Writes nothing. | A file search list only you can see. Permission information is checked so that only documents you may open appear in search. | Your private area on the server: file name, type, size, times and permission information. File contents are not stored. |
| Meet records (meetings.space.readonly), optional connection | Reads meeting start and end time and number of participants. Participant names and addresses are not received. Writes nothing. | A meeting list only you can see | Your private area on the server: meeting start and end time and number of participants. |
| Write Sheets and Docs (spreadsheets, documents), optional connection | Writes only the entries you approve on a confirmation card to a sheet or document. | The record-to-Sheets-and-Docs feature, if you turn it on separately | Written from the device. Not stored on the server. |
Server copies are kept in the database of the workspace server that the company operates itself in the Republic of Korea (section 9). Refresh tokens for Google connections are kept only on the server, encrypted with AES-256-GCM; devices receive only access tokens that last at most one hour. Calendar and Google Tasks syncing is done by the workspace server directly with Google. When you ask an agent about your schedule, the agent tool on your device may also read events (title, start and end time) from Google Calendar directly with that access token. The permission to send mail (gmail.send) is never included in the access tokens sent to devices; only the server uses it, to send the message you pressed Send on.
By default, members of the same workspace (and the agents they use) see the time and title of your events. You can change each calendar to busy only, titles, or full details, and workspace admins cannot see beyond that setting. A workspace admin can, however, change the default visibility applied to newly connected calendars; in a workspace where it is set to full details, the description, attendees and location of calendars connected after that are also visible to members until you change it (calendars already connected are never widened). Events marked private in Google appear to other members as busy only. Tasks imported from Google Tasks go into your private lists and are not visible to other members unless you move them to a team list.
When you ask an agent to do something that needs your schedule or tasks, the agent, which runs on your device, sends the Google Calendar and Tasks information needed for that request to the AI model provider you connected yourself (for example Anthropic for Claude or OpenAI for ChatGPT). This transfer happens only to process that user's own request. It goes from your device straight to that provider and does not pass through our servers. Our servers do not call AI models.
If you create a booking link, people who open it see only the open times they can book. Event titles and details are not shown. Other than the cases described in this section, and where the law requires disclosure, Google user data is not shared with anyone.
Hardi AI's use and transfer of information received from Google APIs to any other app will adhere to Google API Services User Data Policy, including the Limited Use requirements. The policy: https://developers.google.com/terms/api-services-user-data-policy
- Google user data is used only to provide or improve user-facing Hardi AI features.
- It is not used for advertising, including personalized, retargeted or interest-based advertising.
- It is not sold.
- It is not used to determine creditworthiness or for lending purposes.
- It is not used to develop, improve or train generalized AI or machine learning models.
- Humans do not read it, except with your explicit consent for specific items, when needed for security purposes such as investigating abuse, to comply with applicable law, or for internal operations after it has been aggregated and anonymized.
- It is transferred only when needed for a feature you asked for (for example, sent from your device to the AI model provider you connected), to comply with applicable law, or as part of a merger, acquisition or sale of assets after notifying you and obtaining your consent.
Retention and deletion: copies of events and tasks received from Google are kept while the connection exists; what is changed or deleted in Google is reflected in the copy at the next sync. When you disconnect a Google account from the app's connections screen, the server immediately deletes its tokens, the server copies of that account's calendars and events, and the task copies imported from Google Tasks, and asks Google to revoke access. If the same Google account is also connected in another workspace or by another member, the Google-side revocation happens when the last connection is removed. The same deletion happens when a member is removed from a workspace. You can also revoke access in your Google account settings (https://myaccount.google.com/permissions); if you revoke it only there, the server copies are deleted when you disconnect in the app. Gmail mail cards (recipients, subject, the sent message's ID) are a record only you can see; they are deleted within a day once 90 days have passed since the card was closed (sent, not sent or expired), and earlier when you are removed from the workspace or when your account or the workspace is deleted.
Search lists and deletion requests: when you disconnect a Google account in the app, the server of the workspace where you disconnected also immediately deletes that account's search lists uploaded to your private area (calendar, Gmail, Drive, Meet), together with the tokens and copies. Anything it could not delete at that moment is deleted automatically afterwards. The search lists on your device are removed from search at the app's next sync. Once you have disconnected your last Google account in that workspace, the latest version of the app also deletes them from the device after the deletion has reached the server (earlier versions of the app only remove them from search; the rows marked as deleted that remain on the device are removed by deleting the app's data folder). If you have connected more than one Google account and disconnect only one, the server deletes only that account's lists; however, older Gmail, Drive and Meet search lists that carry no record of which account they came from are deleted when you disconnect your last Google account, and the search lists on your device stay removed from search (latest version of the app) and are deleted when you disconnect your last Google account. Two cases are not deleted automatically and are deleted on request through the contact in section 14: search lists from an account you disconnected before this feature existed that remain on the server, and, if you belong to several workspaces, copies of search lists that the app uploaded to the server of a workspace other than the one where you disconnected. Use the same contact to have specific Google data deleted without disconnecting. Data deleted from the server disappears from backups once the backup retention period in section 6 has passed.
9. Service providers and international transfers
Apart from the cases described in this section (delivery of phone notifications, diagnostics from the Android app's QR code scanner, sending sign-in codes and service emails (beta news emails included), website visit statistics and card payment), we do not entrust the processing of personal information to outside providers. Workspace servers, databases, file storage and backups are operated by the company on its own server located in the Republic of Korea.
Cloudflare is used only for domain name resolution (DNS) of hardiai.com. Your requests and data go directly to our servers and do not pass through Cloudflare.
The cases described in this section are the only personal information we send abroad. Transfers to AI model providers and outside services that you connect yourself happen between you and that provider.
Notifications for the iOS app are delivered through the Apple Push Notification service (APNs) of Apple Inc. (United States). What we send Apple is the device's push token and a fixed wake-up signal with no content; the app then fetches the notification text directly from the workspace server. Notifications for the Android app are delivered through Firebase Cloud Messaging (FCM) of Google LLC (United States); what we send Google is likewise only the device's push token and a wake-up signal with no content. In both cases it is sent over the internet each time a notification is delivered.
The Android app's QR code scanner uses ML Kit barcode scanning (com.google.mlkit:barcode-scanning) by Google LLC (United States). The code is read on the device by a model bundled in the app, and the camera image and the content of the scanned QR code are not sent to Google. When you open and use the scanner, however, ML Kit sends diagnostic information to Google. What is sent: device information (manufacturer, model, OS version and build, and the available ML hardware accelerators), app information (package name and app version), a per-installation identifier that is not intended to identify a user or a device, performance metrics such as processing time, scanner settings (image format and resolution), the ML Kit feature version and input and output sizes, and event types and error codes. It is sent over the internet, encrypted with HTTPS. Google uses this information for ML Kit diagnostics and usage analytics and does not pass it to third parties, and Google sets how long it is kept. You can also connect with Use pairing code instead of using the QR code scanner. The iOS app's scanner uses a feature built into the phone by Apple and does not use ML Kit.
Visit statistics for the website (www.hardiai.com) are processed with Google Analytics by Google LLC (United States). What is sent: the address of the pages you visit, how you arrived, browser and device information, a cookie identifier, and your IP address (used to estimate an approximate location). It is sent over the internet when you visit. The retention period follows the data retention setting of the Google Analytics property; ask the contact in section 14 and we will tell you the current setting.
Sign-in codes and service emails are sent through Resend, the email delivery service of Plus Five Five, Inc. (United States; 2261 Market Street #5039, San Francisco, CA 94114; support@resend.com). Service emails are notices about payments, plans and seats, about account and workspace deletion, and about workspace ownership transfers; workspace invitations go to the invited person's address when a workspace owner or admin chooses [Send by email] in the app; operational alerts to the company's operators (such as a new report or an account deletion request) go the same way. The sign-up confirmation (the notice that we recorded your consent), beta news and founding team invitations to people who signed up for them on the website go the same way too. What it receives: the recipient's email address, the email's subject and body (the sign-in code, or the notice's contents such as a workspace address or a date), and the email's kind and language. Country, timing and method of transfer: to the United States and the countries Resend uses to deliver email, over the internet (HTTPS) each time an email is sent. Purpose: delivering email. Retention: Resend's retention periods; when the company stops using Resend, Resend deletes the data within 90 days (Resend Data Processing Addendum, https://resend.com/legal/dpa). If you do not want this transfer, you cannot sign up or sign in with an email code, and you will not receive service emails or beta news emails.
Card payment is not open yet and nothing is sent to Paddle today. Once it opens, this is how it works. Card payments are processed by our reseller Paddle.com Market Limited (United Kingdom; 30 Old Bailey, London EC4M 7AU; privacy@paddle.com), which is the seller of those orders. What it receives: the buyer's name, email, country (billing location) and payment method details are entered on the payment screen and received by Paddle directly, and we send the workspace identifier and the number of seats so the payment can be tied to the workspace, and the email address of the workspace owner's account so the paying customer can be determined. We do not receive card numbers. Where, when and how: to the United Kingdom and the countries Paddle uses to process payments, over the internet when the checkout page is opened. Purpose: processing the payment, calculating and reporting taxes, issuing receipts, refunds and preventing fraudulent payments. Retention: the period set by applicable law, as described in Paddle's privacy notice (https://www.paddle.com/legal/privacy). If you do not want this transfer, do not pay by card and ask to pay by tax invoice (bank transfer) instead; in that case nothing is sent to Paddle.
10. Your rights
You may at any time ask to access, correct or delete your personal information, to stop its processing, or to withdraw consent. Legal guardians of children under 14 have the same rights.
You can do the following yourself in the app.
- Disconnect a Google account or a calendar subscription (ICS)
- Change a watched folder's sharing scope and delete entries already uploaded
- Change how long meeting recordings are kept
- Change the sharing level of each calendar
- Turn off sending app usage statistics (the app also asks for the records that device sent to be deleted)
- Workspace owners and admins: turn 'Help improve Hardi' on or off (turning it off deletes that workspace's samples)
- Workspace owners and admins: disconnect Slack, GitHub, GitLab or Gitea (this deletes the tokens on the company's server — section 6)
You can leave the beta news waitlist at any time with the unsubscribe link in every email it sends you, or by asking the contact in section 14 to delete your entry, which we do right away. Not signing up, or leaving, does not affect your use of Hardi AI.
If we contacted you through a prospective customer contact, you can ask where we found it (our first message says so too), and you can reply to our message or write to the contact in section 14 to make us stop (the same day) or to delete it.
Send other requests to the contact in section 14.
In a workspace run by a company or organization, that organization can manage its members' information, so you can also send your request to it.
We do not make automated decisions.
11. How we protect it
- Traffic between the app and the server is encrypted with TLS.
- Connected-service tokens and calendar subscription addresses are encrypted with AES-256-GCM and bound to their workspace and connection, so they cannot be decrypted if moved to another row.
- Google refresh tokens are never sent to devices.
- Device identity keys are kept in the operating system keychain (on Windows, a DPAPI-encrypted file that only that Windows account can decrypt).
- Server data is separated by workspace and access is limited by role.
- Administrative actions are recorded in a hash chain, so edits to past records are detectable.
- Sign-in access tokens last 15 minutes and refresh tokens 30 days.
13. Children
Hardi AI is a service for teams at work and is not directed at children under 14. There is no age check at sign-up. If you tell us that personal information of a child under 14 is stored, we delete it on request through the contact in section 14.
14. Privacy officer and contact
- Privacy officer: Bin Heo (representative)
- Contact: deviantcemaster@gmail.com
- Mail: Deviantce, 401, 8-11 Baekjegobun-ro 41-gil, Songpa-gu, Seoul 05621, Republic of Korea
For privacy complaints you can also contact the following Korean authorities.
- Personal Information Dispute Mediation Committee: 1833-6972 (https://www.kopico.go.kr)
- Personal Information Infringement Report Center: 118 (https://privacy.kisa.or.kr)
- Supreme Prosecutors' Office: 1301 (https://www.spo.go.kr)
- Korean National Police Agency: 182 (https://ecrm.police.go.kr)
15. Changes to this policy
If we change this policy, we will post what changes and its effective date on this page.
Effective date: October 14, 2026