Privacy Policy

1. Who we are

Allinaa is a service of iGlomart LLC, a limited liability company registered in Delaware, United States of America. In this policy "we", "us" and "Allinaa" mean iGlomart LLC.

• Marketing website: https://www.allinaa.com
• Chatbot product ("Allinaa Bot"): https://bot.allinaa.com, including the embeddable chat widget and the management panels at /manage, /cabinet and /admin
• Contact for all privacy matters, including rights requests: info@allinaa.com

We have not appointed a statutory data protection officer. Privacy requests are handled by the Allinaa team at the address above.

No EU or UK representative is appointed yet. iGlomart LLC is established in the United States and has no establishment in the European Union or the United Kingdom. Where the GDPR or the UK GDPR applies to our processing, Article 27 requires a controller in that position to designate a representative in the Union and, separately, in the United Kingdom, and to make its identity available to data subjects. We have not yet done so, and we are not relying on the narrow exemption for occasional processing. Appointing both representatives is an open item; we will name them here, with their addresses, as soon as they are appointed. In the meantime every request, including a complaint, reaches us directly at info@allinaa.com and is handled on the timelines in section 12.2.

This page, the Terms of Service and the Data Deletion Instructions are published in English only; the rest of www.allinaa.com is available in many languages.

2. Our two roles: controller and processor

Allinaa handles personal data in two clearly separate situations. Which rules apply to you depends on which situation you are in.

If you are in the second situation and want your data corrected or deleted, the fastest route is to ask the business you were talking to. You can also write to us at info@allinaa.com and we will pass the request to that business and help carry it out. See section 14 and our Data Deletion Instructions.

Businesses that use Allinaa Bot are responsible for having a lawful basis for the conversations they run through it, for their own privacy notice, and for telling their customers that an AI assistant answers on their behalf.

3. Data we collect from visitors to www.allinaa.com

3.1 What the site loads

• Google Fonts. Every page of www.allinaa.com, and these legal pages, load web fonts from fonts.googleapis.com and fonts.gstatic.com. This happens on page load, before you interact with anything, and it discloses your IP address and browser user agent to Google. There is currently no consent banner on the site, so this request is not based on your prior consent; we rely on our legitimate interest in presenting the site in a legible, consistent way. We are stating this plainly rather than hiding it. Google's handling of that request is described in the Google Privacy Policy.
• Allinaa's own chat widget, loaded from bot.allinaa.com/widget.js. It behaves exactly as described in section 4. For conversations on our own site, we are the controller.
• No analytics, no tag manager, no advertising or tracking pixels. The site loads no Google Analytics, no Google Tag Manager, no Meta pixel and no advertising script of any kind. We have verified this in the page source.

3.2 Contact form and e-mail

If you fill in the contact form on www.allinaa.com, it submits through the same inquiry route described in section 5: your name, e-mail address, phone number (if given), your message, the language you used and your consent tick. We use this to answer you and, if you become a customer, to run the service. If you e-mail info@allinaa.com directly, we keep that e-mail in our Hostinger mailbox.

3.3 Server logs

Our hosting provider's web server produces access logs in the normal way. The Allinaa application itself does not write visitor IP addresses or user agents into its database for chat traffic (see section 10).

4. Data the chat widget collects from website visitors

This section describes the embeddable chat widget as it runs on our own site and on our business customers' sites.

4.1 In your browser

• One local-storage entry named allinaa_s_<bot_id>. It holds an opaque session id, the session token the server issued, the ids of files you uploaded in that conversation, and the reference of the last inquiry you sent (for example INQ-XXXXXX), so that a file you attach afterwards is added to that request. It is stored in your browser's local storage, not in a cookie, and it lets the conversation continue when you move between pages or come back later.
• No cookies are set by the widget. The widget never writes document.cookie. It performs no device fingerprinting, no cross-site tracking and no advertising measurement.
• Your browser language is read when you send a message, so the assistant can answer in a language the business has configured. It is not stored as a profile about you.
• Your time zone is read and sent to the server only when you make a booking, so an appointment is shown in your own local time. It is stored on that booking record.

The session token is a secret held only by your browser. The server stores only a SHA-256 hash of it, so the token cannot be read back out of our database.

4.2 On our servers

4.3 Page context

So the assistant can answer about the page you are reading, the widget reads the page when you send a message and sends with it: the page address, its title and meta description, up to 40 links that point to the same host as the page, with their link text (taken from the first 300 links on the page), and up to 4,000 characters of the text of the page's main content (its main or article area, or the whole page when it has none). On a page whose path looks private (for example account, checkout, cart, login, admin) the widget sends no page context at all.

Our server checks the page context again before it is used: it refuses a page that is not on the business's own website or whose path looks private, removes query strings and URL fragments from the page address and from every link, keeps only links to the business's own website, and cuts the context down to at most 25 links and 2,500 characters of page text. Only this trimmed version is given to the AI model (section 8.2), labelled as data, not as instructions.

What is stored: the cleaned page address, with each message and on your visitor session, and the page title, on your visitor session (section 4.2). The cleaned page address is also copied to any inquiry or booking you send (section 5). The page text, the meta description and the links are used to write the reply and are not saved in our database.

4.4 How the widget is added to a website, including WordPress

A business adds the widget with one script tag that names its bot id, either in a data-bot-id attribute or in the script address itself (widget.js?bot=<bot id>, for tools that can load a script but cannot set an attribute on it). When both are given the attribute wins, and a value that is not a valid bot id loads nothing. The bot id is public: it is part of the page's code and identifies the business's assistant, not you. However the widget is added, it works exactly as described in this section 4.

• WordPress plugin from the cabinet. A business can download a WordPress plugin made for it from its Allinaa cabinet. It prints the script tag with the bot id on the site's pages. It has no settings, stores nothing, holds no password, key or token, and the WordPress server sends nothing anywhere because of it.
• The "Allinaa Chat" WordPress plugin and the connect page. Our general WordPress plugin, "Allinaa Chat" (not listed in the WordPress.org plugin directory today), adds the script tag with the bot id to the public pages of a site once a bot id is saved in its settings. It stores two things in the site's own WordPress database, not with us: the bot id, and, for 15 minutes, a random one-time value for the administrator who clicked "Connect with Allinaa". Deleting the plugin removes both. The WordPress server itself never contacts us. When an administrator clicks "Connect with Allinaa", their browser opens bot.allinaa.com/connect/wordpress with the site's address, the address of the plugin's settings page and that one-time value. There they sign in with their Allinaa account (the same sign-in as the cabinet, kept in that browser tab's session storage, see section 11), choose a business they manage as its owner or as a team member with the Administrator role (or, as a member of the Allinaa team with platform administrator rights, a business they act for), and confirm. The browser is then sent back to the plugin's settings page with the bot id and the one-time value; no password, key or token goes to WordPress. We record the connection in the audit log (section 9): the site's address (scheme, host and port only, never a path), the account that confirmed it, when, and, as for every management request, the IP address it came from. Connecting saves nothing on the business's record. The address of the connect page, with the site's address and the settings-page address in it, can appear in our server logs (section 3.3): our application removes the one-time value from its own request log, but the web server's access log may still record it. The one-time value can be used only once, only by the WordPress user who started it and only within 15 minutes.

However the widget was added, once it runs on the business's own website, that website's origin (scheme, host and port, never a path) and the time are noted on the business's record, at most once an hour, so the cabinet can show that the installation works (section 9). Nothing about you is recorded with it.

5. Inquiries, bookings, problem reports and quotes

If you choose to send your details through the chat, we store them so the business can answer you.

• Fields: name, e-mail address, phone number, your message, the conversation language, your consent, the service you asked about, timing, requirements, the next step you chose, an AI-written summary of the conversation, which fields you edited by hand, the ids of any files you attached, and the page URL from your session. Bookings add the date, time and your time zone. A problem report adds a description and the service concerned.
• Reference: each record gets a reference such as INQ-…, which is shown to you and used in the e-mails.
• Consent is required. The submit button is blocked until you tick the consent box, and the server refuses the submission without that tick and without at least one contact method (e-mail or phone). The consent text names the business you are contacting.
• Quotes keep a copy of your name and e-mail address so the quote can be addressed and sent.

5.1 E-mails that are sent, and what they contain

All outbound e-mail is queued in our database before it is sent through SMTP. The queue keeps the full message body indefinitely, including the names, phone numbers and e-mail addresses inside it. Only invitation and password-reset links are removed from the stored copy after sending. We are telling you this because many policies quietly omit it.

5.2 Automated follow-up e-mails

A business may enable follow-up e-mails for inquiries that were not answered, where you gave an e-mail address (not for bookings). By default at most two are sent, about 24 and 72 hours after your inquiry; the business can set up to five, each at its own delay of between 1 and 720 hours after the inquiry. Every follow-up e-mail carries a signed opt-out link. Using it records an opt-out on your contact record and stops further automated follow-ups.

Follow-ups stop when you write again in the chat you sent the inquiry from (a message or a file), when you send a new inquiry or problem report from the same e-mail address or phone number (a booking does not stop them), when a member of the business's team takes over your chat, when the business marks the inquiry in progress or completed, stops the follow-ups or switches them off, or when you opt out. An answer by e-mail is not detected automatically: where the business has set a contact e-mail address, a follow-up invites you to reply and your reply goes to that address, but it stops further follow-ups only once the business updates the inquiry. If nothing stopped the follow-ups, the business's team gets one reminder after the last of them, with your request and contact details.

6. Files customers send

• Accepted types: JPEG, PNG, WebP and GIF images; PDF, DOCX, XLSX, PPTX, CSV and TXT documents. Anything else is refused. The real type is detected from the file's content and must match its extension.
• Size limits: 10 MB per image, 15 MB per document, with per-visitor and per-business daily quotas.
• Where they are stored: on our server's file system, in a folder belonging to that business only, under a random file name. Uploaded files are stored unencrypted. We do not operate encryption at rest for uploads or for the database. The only encryption of stored data in the service protects the credentials of connected messaging channels.
• Images are fully decoded and re-encoded on upload. As a side effect, EXIF metadata — including GPS coordinates — and any payload hidden in the file do not survive.
• Checking: every file goes through built-in safety checks (for example macros, active content in PDFs, archive bombs, mismatched content). These checks are not antivirus software. An optional ClamAV antivirus scan is supported and is used only where it has been configured on the server; it is not enabled by default, so please do not read this policy as a promise of antivirus scanning.
• Deletion: 30 days after upload the file's bytes and any text extracted from it are deleted automatically. A metadata row is kept: file name, size, type, SHA-256 hash, the result of the checks, who uploaded it and when it was deleted — and, for an image the assistant read, the facts it extracted from the picture: the kind of image, brand, product name or model, colours, any web address and short pieces of text visible in the image. That description of the picture is not deleted with the file; it stays on the metadata row until the row is deleted on request. A file that was refused is never stored, but the same kind of metadata row is kept for it.
• Who can open a file: the business it belongs to, limited by the role of the team member. An Allinaa staff member signed in with a staff account can open a customer's file only under a time-limited, reason-recorded support-access grant, and that access is written to the audit log. A maintenance token that works only from a terminal on the server itself can also open files without a grant; such use is logged and marked as maintenance access. Files downloaded from the business cabinet are served as attachments with hardened headers (nosniff, no-store caching and a restrictive content security policy); the staff maintenance route serves the file without those headers and records the route rather than the file name and hash.
• Telegram copy. If a business has enabled Telegram alerts, the file you send is also uploaded to Telegram and delivered to that business owner's Telegram chat. In that case the file leaves our servers. We do not claim that customer files stay on our servers only.
• A business can delete an individual file at any time from its panel.

7. Messaging channels and what each provider gives us

Premium businesses can connect their own messaging accounts so conversations from those channels arrive in one inbox. When a business connects a channel, we receive from that provider the identifier and public name it chooses to give us, plus the message content, and we store it per business. Identifiers are never merged across businesses.

Alongside those identifiers we store the message text, a contact record (the provider's public display name, plus e-mail, phone and name if the business keeps a CRM record), one identity row per handle, one thread row per conversation (including the customer's public name), and a delivery record for each reply we send (text, provider message id, status timestamps and who approved it). Credentials for a connection are stored separately and encrypted; they are never returned by any interface, written to a log, or included in a report.

Attachments that arrive over a channel are downloaded with the business's own credential and then handled by exactly the same pipeline as web uploads — same type checks, same safety checks, same image re-encoding, same 30-day deletion. A file a customer sends over a channel is treated exactly like a file sent through the website chat, including being read by the AI where the business's plan allows it (see section 8.2).

7.1 Extra limits we apply to specific providers

• LinkedIn: the text of member content is replaced with a note after 48 hours, is never given to the AI model, and never appears in reports, summaries or staff alerts.
• YouTube: comment text, thread participant names and contact display names are replaced after 30 days. If a business disconnects its YouTube channel, everything that connection read is anonymised immediately.
• All channels: the stored raw provider event payload is emptied after 30 days; the event row itself is kept so a redelivered message is never processed twice.
• Public surfaces (comments and reviews) are never answered automatically. A reply is posted only after a person at the business approves it.

8. AI processing and the model provider

8.1 Who processes the prompt

Replies are generated by a large language model that we do not host. Our sole AI sub-processor is OpenRouter (openrouter.ai), which routes the request to the model provider behind the chosen model. The default model is openai/gpt-4o-mini; a separate vision model may be configured for turns that include an image. Each request carries our API key, our site URL as a referrer header and the product name "Allinaa Bot".

8.2 What is sent to the model

• A system prompt containing the business's name, the language rules and the extract of the business's own approved knowledge that is relevant to the question.
• Up to the last 12 messages of the conversation, and the current message (up to 2,000 characters).
• The page context block: URL with query and fragment stripped, title, description, up to 25 same-site links and up to 2,500 characters of page text.
• An uploaded image, re-encoded as a JPEG with its long side at most 1,280 pixels, sent once per image; and up to 3,000 characters of text extracted from an uploaded document.
• Catalog match information, where the business has imported a product catalog.
• For the form pre-fill feature: the last 30 messages of the transcript (600 characters each, 8,000 characters in total), so that the form can be pre-filled. Any e-mail address or phone number the model returns is discarded unless you actually typed it.
• For the daily and weekly report that a business can enable: the report header — which includes the name, phone number, e-mail address and message of every inquiry in the period — together with up to roughly 14,000 characters of verbatim chat transcripts. We cannot honestly claim that we never send contact details to the AI provider, because this feature does.
• For quote drafting: the relevant inquiry and catalog or knowledge prices.
• For the website scan in the sign-up setup wizard: the text of up to 10 pages of the business's own website (up to 30,000 characters in total, 6,000 per page) together with the business name and website address, so that a first draft of its knowledge file can be written. Those pages are public pages of the business's own site and routinely contain staff names, direct e-mail addresses, phone numbers and customer testimonials. The draft and the list of page URLs and titles are stored in our database until the business replaces or deletes it. Our server fetches the pages itself with the user agent AllinaaBot/1.0 (+https://bot.allinaa.com/start), honours each host's robots.txt, follows no redirect off the domain and never signs in anywhere.
• For a comment or review on a connected public channel, where the business has switched that connection to AI drafting: the text of the comment or review and the author's public name, so that a draft reply can be written. Nothing is published until a person at the business approves it. AI drafting is off by default on every public channel and can be left off; LinkedIn is excluded from it entirely.

8.3 What is never sent to the model

• Your IP address, your user agent, your session id and your session token.
• Page URLs with query strings or fragments, and any page under a private path (account, checkout, cart, login, admin and similar).
• The business team's internal notes on an inquiry or a conversation.
• LinkedIn member content — those threads are excluded from AI drafting and from reports entirely. LinkedIn is the only channel excluded in this way; on every other public channel, AI drafting can be switched on by the business, and then the comment or review text is sent to the model as described in section 8.2.
• Text extracted from documents that the business's own team or the system uploads. A document a customer sends — through the website chat or over a connected channel — is not in this exclusion: an excerpt of it is given to the model where the business's plan allows it.
• Any credential, API key or token. These are masked in logs and never placed in a prompt.

8.4 Model training

Allinaa does not train, fine-tune or evaluate any AI model on your conversations, your files or your contact details. We have no training pipeline in our software.

What happens at the model provider is not under our direct control, so here is exactly what we know and what we require. OpenRouter publicly states that it works with providers so that prompts are not trained on (with exceptions it documents) and offers an account-level setting to avoid providers that train on prompts. We have asked for, and intend to use, routing that excludes providers which train on prompts. We cannot yet state that this is enforced on every request: our software does not currently send a per-request instruction that refuses data collection, and we will not claim a verification or a control we have not carried out. We have not independently audited any upstream provider, and we do not name the upstream provider behind a given model, because the router chooses it. If your business needs a written, provider-specific assurance or a zero-retention route before you send us customer conversations, write to info@allinaa.com before you launch.

8.5 AI answers can be wrong

Replies are generated automatically from the business's approved information. They can be incomplete or wrong. They are not professional, legal, medical or financial advice. Please do not rely on an AI reply for an important decision without confirming it with the business.

8.6 AI usage records

For each AI call we record the business, the kind of call, the model, the number of prompt and completion tokens, the cost and whether it succeeded. These records contain counts and amounts only — never prompts, replies, keys or secrets.

9. Team accounts, panels and audit records

• Accounts: e-mail address (stored case-folded and unique), name, a password hash, creation time, last sign-in time, whether the account is disabled, and, for Allinaa staff, a platform role.
• Passwords are hashed with scrypt using a random 16-byte salt per user and verified in constant time. Plain passwords are never stored. The minimum length is 10 characters.
• Sessions: only the SHA-256 hash of a random 32-byte token is stored, for 14 days. The token travels in a request header, never in a URL.
• Invitations and password resets: the e-mail address plus the hash of a one-time token (valid 72 hours and 60 minutes respectively). Panel links place the token in the URL fragment, so it never reaches our server or any access log, and the link is removed from the stored copy of the e-mail after sending.
• Sign-in limits: at most 10 failed attempts per IP address and per e-mail address in 15 minutes.
• Memberships: role, whether active, and who created or revoked it and when. Revoked memberships are kept as a record.
• Audit log: for management, administration and authentication requests we record the business, the actor's role and display name, the HTTP method, the route template (not the full URL), the object type and id, the response status, the IP address, the acting account id, and handler-supplied details which may include a file name and a file hash. Request bodies, headers and secrets are never stored in the audit log. The audit log also covers file downloads, CSV exports and refused attempts to read sensitive data. It does not cover the chat, session or upload routes.
• Allinaa support access: an Allinaa staff member signed in with a staff account can reach a business's customer content only through a support-access grant that records the business, the staff user, read or write mode, a written reason of at least 10 characters, and a window of 15 to 240 minutes. Every access during a grant is forced into the audit log with the grant id. One exception, stated plainly: a maintenance token that is accepted only from a terminal on the server itself can read files, chat transcripts and inquiry details (including names, phone numbers and e-mail addresses) without a grant, without a recorded reason and without a time limit. Every such access is written to the audit log and marked as maintenance access.
• Support requests you send us keep the subject, category, status, author name and account id, and the full message bodies. New requests are e-mailed to info@allinaa.com.
• Business record: business name, the approved knowledge text, notification e-mail address, optional Telegram chat id, time zone, public contact details, integration ids for features the business has set up, and the installation status: the website origin where the widget was last seen running and when (section 4.4), and the time and result of the last installation check (which of the business's public pages were checked and on which one the widget was found).

9.1 Signing up for Allinaa Bot

Anyone can create an assistant on our public sign-up page at bot.allinaa.com/start. We store one sign-up record for every submission of that form, before any account exists, and we keep it even if the sign-up is never finished. The record holds exactly:

• the work e-mail address (case-folded), the business name, the website address, the chosen plan and languages, the time zone and country code your browser reports, and where the sign-up came from (which button on our site);
• the state of the sign-up (waiting for its code, confirmed, finished, refused, or a join request), and the times it was created, confirmed and finished;
• a SHA-256 hash of the 6-digit confirmation code — never the code itself — with the number of attempts and of codes re-sent;
• the IP address you connected from, and the time the last code was sent;
• the time you accepted these Terms and this Privacy Policy on the page;
• the business and the owner account the sign-up created, once it is finished.

The IP address is stored in that record on disk and is counted to enforce the abuse limits of 5 sign-ups per hour and 20 per day per connection. The confirmation code itself exists in clear only in the e-mail we send you; the stored copy of that e-mail keeps no code once it has been sent, failed or been cancelled, and the code is not in the subject line.

Legal bases: steps towards a contract at your request (Art. 6(1)(b)) for the sign-up itself and the confirmation code; our legitimate interest in protecting our mail sender and our service from abuse (Art. 6(1)(f)) for the stored IP address and the per-connection limits.

Retention: a sign-up record has no automatic time limit today — see section 12.2. Our staff can delete a sign-up that is still waiting for its code, and we delete any sign-up record on request. Write to info@allinaa.com.

10. IP addresses and rate limiting

• Your IP address is used as the key for rate limiting (40 requests per 10 minutes). That counter lives in the server's memory only: nothing is written to disk or to the database, and the data disappears when the service restarts. The one exception is the public sign-up page: its 5-per-hour and 20-per-day limits are counted from stored sign-up records, so the IP address is written to the database there — see section 9.1.
• The true connection IP is used for sign-in attempt limits.
• Your IP address is stored in the audit log for management, administration and authentication requests — that is, actions taken in the panels by business team members and Allinaa staff — and in a sign-up record when you use the public sign-up page (section 9.1).
• Your IP address is not stored with your chat messages, your visitor session or your uploads. The chat path writes no IP address and no user agent to the database.
• We never read or store your browser's user agent anywhere in the application.

11. Cookies, local storage and similar technologies

We set no advertising, analytics or tracking cookies, anywhere, for anyone. The widget loads product images with a no-referrer policy so that your visit is not disclosed to an image host.

12. How long we keep data

12.1 What is deleted automatically

12.2 What we keep until it is deleted on request

We want to be exact here, because this is where most privacy policies overstate what they do.

Completion deadlines for a deletion request

How long we keep data when nobody asks

We do not operate a default maximum retention period for the records listed above, so instead of a figure we cannot keep, here are the criteria we actually apply: we keep a record while the business that controls it still needs it to serve the person it concerns, to run and bill the service, to meet an obligation the law places on us, or to defend a legal claim; we delete it when the business or the person asks, when the business leaves and asks for its data to be removed, or when a platform requires deletion of data received from it. A business can ask us to set up a fixed retention period for its own account — for example 90 days or 12 months for conversations and inquiries — and we will run it as an operational routine; the product has no self-service retention setting today. Building default retention limits into the product is an open engineering item, and we will publish the periods here when they are enforced rather than before.

Two things we will not pretend about:

• The 30-day figure in our conversation settings controls only whether the widget may resume an old conversation. It does not delete the conversation. Starting a new conversation closes the previous one; it does not delete it.
• Disabling an account or deactivating a business stops access. It does not erase the stored data. Memberships are deliberately kept as a record of who had access.

There is also no self-service data export for a data subject. If you want a copy of your data, write to us and we will produce it.

13. Legal bases (GDPR / UK GDPR)

Where the EU GDPR or the UK GDPR applies and we are the controller, we rely on the following legal bases.

Where we act as a processor for a business customer, that business determines the legal basis for its end-customers' data, and we process on its documented instructions.

We ask businesses not to configure the chatbot to collect special category data (health, biometric, political, religious or similar) or government identifiers, and we ask visitors not to type them into a chat. Our service is not designed for that data and is not a HIPAA-compliant platform.

14. Your rights and how to exercise them

Depending on where you live, you may have the right to ask for access to your personal data, correction, deletion, restriction of processing, portability, and to object to processing based on legitimate interests. Where processing is based on consent, you may withdraw it at any time. You also have the right not to be subject to a decision based solely on automated processing that has a legal or similarly significant effect — the Allinaa chatbot does not make such decisions; it answers questions and passes inquiries to a person.

14.1 If we are the controller (our website, our own chatbot, your Allinaa account)

1. E-mail info@allinaa.com from the address concerned, or tell us which address, phone number or inquiry reference the request relates to.
2. Say what you want: a copy, a correction, deletion, or an objection.
3. We may ask one or two questions to confirm the request really comes from you. We will not ask for a copy of an identity document unless we genuinely cannot otherwise identify you.
4. We acknowledge within 5 business days and complete within the deadline for that kind of data in section 12.2 — 7 calendar days for YouTube data, without undue delay for Telegram data, promptly for Meta Platform Data, and up to 30 days for everything else. If a request is complex we will tell you and explain the delay.

14.2 If you are a customer of a business that uses Allinaa Bot

That business is the controller of your conversation. Please contact the business directly — it can act in its own panel and knows your history. If you cannot reach it, or you prefer to come to us, e-mail info@allinaa.com: we will identify the business, pass the request on and carry out the deletion or extraction on its instruction. We will tell you what we did.

Step-by-step instructions, including what exactly gets removed, are on the Data Deletion Instructions page.

14.3 Complaints

If you are in the EEA or the UK you may complain to your national data protection authority. We would appreciate the chance to put things right first.

15. California and other US state privacy rights

• We do not sell personal information, and we do not share it for cross-context behavioural advertising, as those terms are used in the CCPA as amended by the CPRA. We have never done so. We run no advertising or analytics technology.
• We do not use or disclose sensitive personal information to infer characteristics about anyone.
• We offer no financial incentives in exchange for personal information, and we do not discriminate against anyone who exercises a privacy right.
• Categories we collect (CCPA terms): identifiers (name, e-mail address, phone number, account id, provider user id, IP address in the audit log), commercial information (the service you asked about, inquiries and quotes), internet activity (the page URL and title you were on), geolocation only as a time zone you send with a booking, audio/visual information only as files you choose to upload, and professional information only if you type it into a chat.
• Sources we collect it from: you, the business you contacted, and the messaging platform you used to reach that business.
• Third parties we disclose it to: the sub-processors listed in section 19, for the purposes stated there. We disclose personal information to no one else, and we never disclose it for money or for advertising.
• Sensitive personal information. We do not ask for it, and the service is not designed for it. We may receive it only if someone types it into a chat or sends a file containing it; where that happens we hold it only to pass the conversation to the business, and we never use it to infer characteristics about anyone. We do not use or disclose it for any purpose beyond providing the service.
• How long we keep each category: the contents of a file you sent and the raw payload of a channel message are deleted after 30 days; everything else in the categories above is kept according to the criteria in section 12.2 — for as long as the business needs it to serve you and run the service, or as long as the law requires — and is deleted on request within the deadlines stated there. We publish the criteria rather than a fixed period because no fixed period is enforced in the product today.
• Why we collect it: to run the chatbot service, answer your inquiry, secure the service and meet our legal obligations.
• Your rights: to know, to access a copy, to correct, to delete, and to limit the use of sensitive personal information. Exercise them by e-mailing info@allinaa.com. You may use an authorised agent; we will ask for proof of authorisation.
• For data we process on behalf of a business customer, we act as that business's service provider: we use the data only to provide the service to that business and do not use it for our own purposes.
• Appeals. If we refuse a request, you may appeal by replying to the e-mail in which we gave you our decision. We will respond to the appeal within 45 days and explain our reasoning; if we still refuse, we will tell you how to contact your state Attorney General. This right applies wherever you live, and the laws of Virginia, Colorado and Connecticut require it.
• Other US states. Residents of other states with a consumer privacy law — including Virginia, Colorado, Connecticut, Utah, Texas and Oregon — have the rights that law gives them (access, correction, deletion, portability, opt-out of sale, targeted advertising and profiling). We do not sell personal information, we run no targeted advertising, and we carry out no profiling that produces legal or similarly significant effects, so those opt-outs have nothing to apply to. Write to the address above to use any of these rights.

16. Children

Allinaa Bot is a business tool. It is not directed to children, and we do not knowingly collect personal data from children.

• Our website and the management panels are for adults acting for a business.
• The chat widget must not be used to collect data from children. Businesses that use Allinaa Bot must not configure it for an audience of children and must not direct it at anyone under 16 in the EEA and the UK, or under 13 in the United States.
• If you believe a child has sent us personal data, write to info@allinaa.com and we will delete it.

17. Security measures we actually have in place

Only measures that exist in our software today are listed. We hold no security certification: we are not ISO 27001 certified, we have not completed a SOC 2 audit, and there is no such thing as "GDPR certified". We do not claim any of them.

17.1 Implemented

• Passwords hashed with scrypt, random salt per user, constant-time verification, and a decoy hash check on unknown e-mail addresses so that response timing does not reveal whether an account exists.
• Tokens stored only as hashes — visitor sessions, team sessions, invitations, password resets, owner tokens and one-time sign-in values. A token cannot be recovered from our database.
• AES-256-GCM encryption of messaging channel credentials, with a key held only in the server environment, a random nonce per value, additional authenticated data binding each ciphertext to its own connection, support for key rotation, and a fail-closed design: if the key is missing, connecting a channel is refused rather than stored unprotected.
• Webhook signature verification per provider, in constant time, failing closed: an unsigned or wrongly signed call is rejected and nothing is stored. Body size and event count are capped.
• Tenant isolation. Every management route is scoped to one business; files, inquiries, cases and connections are re-checked against the business; identities and contacts are never looked up across businesses; a file path must sit inside its own business folder.
• Audit log of management, administration and authentication actions, including denied attempts, without request bodies, headers or secrets.
• Time-limited, reason-recorded support access for Allinaa staff, with every access recorded.
• The platform administration token works only from the server itself (loopback), is compared in constant time, and a placeholder value is never accepted. Note the limit of this control, which we would rather state than leave you to discover: that token is a maintenance credential, and a request carrying it is not subject to the support-access grant — it can read files, chat transcripts and inquiry details without a grant, a reason or a time limit. Such use is logged and marked as maintenance access (see section 9).
• File handling: type detected from content and required to match the extension, size and quota limits, decompression-bomb guard, images decoded and re-encoded (which removes EXIF and GPS data), built-in content checks, optional ClamAV where configured, refused files never stored, and files downloaded from the business cabinet served as attachments with nosniff, no-store caching and a restrictive content security policy. The staff maintenance download route does not set those headers.
• Secret masking in logs for tokens, OAuth codes and e-mail addresses in error text.
• Prompt-injection guards: page and image content are labelled to the model as data rather than instructions, and links the model invents are stripped from replies.
• Idempotency throughout, so a repeated request is never processed, answered or charged twice.
• Server-side fetches are pinned to public provider hosts. Private, loopback and reserved network ranges are refused, and media is downloaded only from each provider's own hosts.

17.2 Not implemented — stated so you are not misled

• No encryption at rest of the database or of uploaded files. The only encryption of stored data protects messaging channel credentials. If your business requires encryption at rest before it processes customer data with us, tell us before you launch.
• TLS is configured in our hosting infrastructure, not by the application. The application sets no HTTP Strict Transport Security header and performs no HTTP-to-HTTPS redirect of its own. Our site and product are served over HTTPS by the hosting configuration.
• The chat API accepts requests from any origin. This is necessary for a widget that businesses embed on their own sites, and it means anyone who knows a chatbot's public id could embed that widget elsewhere. We do not claim that chat requests are restricted to approved websites.
• No automatic purge of audit records or AI usage records.
• Built-in file checks are not antivirus. See section 6.

18. International transfers

Allinaa is operated from the United States. Our servers are in the United States (Boston, Massachusetts, on infrastructure provided by Hostinger), and iGlomart LLC is a Delaware company. If you are in the EEA, the UK, Switzerland or elsewhere outside the United States, your personal data is transferred to and stored in the United States, and may be processed by the sub-processors in section 19, which operate in the United States and other countries.

Where a transfer out of the EEA or the UK requires a safeguard, we rely on the standard contractual clauses contained in our providers' own data processing terms where those providers offer them, together with the technical and organisational measures in section 17. We have not completed a transfer impact assessment for every sub-processor, we are not certified under any transatlantic data privacy framework, and we will not claim otherwise.

Being exact about which safeguard is in place for whom: for our hosting provider we rely on the standard contractual clauses in its own data processing terms. For a messaging platform a business connects itself, the business's own relationship with that platform governs the transfer, under the platform's terms and its own clauses; we act on that business's instructions. For our AI sub-processor and for the upstream model provider behind a given model, we have not executed standard contractual clauses of our own and cannot point you to an Article 46 mechanism that we hold. That is a gap, we are stating it rather than implying a safeguard exists, and we are working on a written data processing agreement; until it is signed, a business that needs an identified transfer mechanism for every recipient should not send us personal data of people in the EEA or the UK without writing to us first.

A copy of the clauses we rely on is available on request at info@allinaa.com, as is the current state of each agreement. If your business needs a signed data processing agreement with specific transfer terms before it sends us customer data, write to us first.

19. Sub-processors

These are the third parties that can receive personal data when the relevant feature is in use. We will update this list before adding a new sub-processor that processes customer data.

20. Platform-specific disclosures

20.1 Meta (Facebook, Instagram, WhatsApp, Threads)

Where a business connects a Meta channel, Allinaa processes Platform Data only to deliver the messaging and comment features that business asked for, as described in this policy. We do not sell Platform Data, we do not transfer it to any data broker or advertising platform, we do not use it to build or augment user profiles, and we do not attempt to re-identify or de-anonymise it. Allinaa itself does not train, fine-tune or evaluate any AI model on Platform Data — we have no training pipeline at all (section 8.4).

Tech Provider role. For Meta channels Allinaa acts as a Tech Provider under the Meta Platform Terms. We process Meta Platform Data only at the business's direction, we act on the business's deletion requests, and we pass on to the business any communication Meta sends us about a user's data request. The Meta app behind these channels belongs to iGlomart LLC, and the availability of any Meta channel depends on Meta's App Review and Business Verification of that app — see Terms of Service, section 8.3.

What reaches our AI sub-processor, stated plainly. Message and comment text from a Meta channel is sent to OpenRouter, and onward to the model provider behind the chosen model, when the business has switched that connection to AI answering or AI drafting, and it can appear in a generated report where the business has enabled reports. We hold no written agreement with OpenRouter that restricts processing to our instructions and binds the upstream model providers to the same terms, and we do not name the upstream provider because the router chooses it. The Meta Platform Terms require such written commitments from a service provider and its sub-service providers; we do not have them yet, so a business should treat Meta channels with AI answering switched on as an open compliance question for its own Meta app, and can run those connections in human mode — in which no Meta message text reaches the AI provider — until it is resolved.

Deletion. We delete Platform Data without undue delay when the user asks, when the business asks, when Meta asks (including where Meta requires deletion to protect users in its own discretion), when data reaches us in error (which we also report to Meta), when the connection is removed, when the user no longer has an account with the business, and when we stop operating the feature that collected it. We can evidence a deletion on request. Our Data Deletion Instructions URL is https://www.allinaa.com/data-deletion.html. That page explains, in plain language, how to make the request and what happens next.

Automated replies on Meta channels are an ancillary part of the service: a person at the business can take over any conversation at any time, and public comment replies are posted only after a person approves them.

20.2 Google APIs, including YouTube and Google Business Profile

Limited Use. Allinaa'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. Specifically:

• We use Google user data only to provide and improve the user-facing features the business connected the integration for — reading comments or reviews, posting an approved reply, writing an inquiry row to the business's own Google Sheet, and creating or reading calendar events for bookings.
• We do not transfer Google user data except: to provide or improve the user-facing features the business connected the integration for, which are visible and prominent in our interface, and only with the connecting account holder's consent; for security purposes; to comply with applicable law; or as part of a merger, acquisition or sale of assets, after obtaining explicit prior consent.
• We do not use Google user data for advertising, and we never sell or transfer it to data brokers, information resellers or advertising platforms.
• Allinaa does not train or improve any AI or machine-learning model on Google user data — we have no training pipeline (section 8.4).
• Where Google user data is sent for a draft reply, and where it is not. A reply to a YouTube comment or a Google Business Profile review is never published automatically: a person at the business writes or approves every one. But if the business switches that connection to AI drafting, the comment or review text and the author's public name are sent to our AI provider so that the draft can be written, and they can appear in a generated report where the business has enabled reports. The recipients are OpenRouter and the model provider behind the chosen model, which the router selects and which we therefore cannot name. AI drafting is off by default on every public channel and can be left off; with it off, no YouTube or Business Profile content reaches the AI provider. We state this because an earlier version of this page claimed the opposite, and the claim was wrong.
• No human at Allinaa reads Google user data except with the business's explicit permission through a recorded support-access grant, to investigate abuse or a security issue, or where required by law.

YouTube API Services. The YouTube comments channel uses YouTube API Services. By connecting it, the business agrees to be bound by the YouTube Terms of Service. Google's handling of personal data is described in the Google Privacy Policy. Comment text and author names obtained from the YouTube Data API are replaced with a placeholder after 30 days, and everything a YouTube connection read is anonymised immediately when the connection is disconnected. You can revoke Allinaa's access to your Google account at any time through the Google security settings page at https://security.google.com/settings/security/permissions (the same list is also reachable at myaccount.google.com/permissions); revoking access also stops any further processing by us. If you revoke access inside Allinaa by disconnecting the channel, we revoke the token at Google and delete the data obtained from the YouTube Data API within 7 calendar days — for YouTube, the content that connection read is anonymised immediately.

20.3 Telegram

Where a business connects its own Telegram bot, Allinaa acts as the third-party application behind that bot.

• We collect only the data the Telegram Bot API sends us for the conversation: the user's Telegram id, their public username or display name, the messages they send to the bot, and any files they attach. We do not request additional data, and we never try to obtain data beyond what Telegram provides.
• We do not scrape Telegram, we do not collect data to build datasets, and we do not use Telegram data to train machine-learning models or AI products.
• We delete Telegram user data without undue delay when the user asks, when the business asks, when Telegram asks, and in response to a lawful request from a competent authority. We do not currently delete Telegram conversations on a timer — see section 12.2 — and a business can ask us to set up a fixed retention period for its account. Instructions: Data Deletion Instructions.
• What a Telegram user is told, and what they are not. Telegram's Bot Developer Terms require a third-party application to be bound by a privacy policy that is easily accessible to its users, and allow data a user submits voluntarily to be used only with a clear disclosure of its intended use and the user's explicit, revocable consent. Today a person who messages a business's Telegram bot does not see this page and is not asked for consent inside Telegram: the consent tick described in section 5 exists only on the website inquiry form. Under Terms of Service, section 7.1 the business that connects the bot must tell its Telegram users that an automated assistant answers and must make its own privacy notice available to them. Building a first-contact disclosure and an opt-out command into the bot itself is an open engineering item; we will describe the mechanism here when it exists, not before.
• Bot tokens and other credentials are confidential, are stored encrypted with AES-256-GCM, and are never shown in any interface, log, report or audit record.
• Telegram's Bot Developer Terms require user data to be encrypted at rest and stored separately from its encryption key. We do not meet that requirement today. The message database and the files customers send are stored unencrypted (see section 17.2); only the channel credentials are encrypted, and their key is held in the environment of the same server that holds the data, so the key-separation element is not met either. Telegram may treat a failure to meet it as grounds to terminate the application and the developer account. Encrypting the message and attachment store with a key held outside the application server is an open engineering item. We state this rather than claim compliance we do not have, and a business should take it into account before connecting a Telegram bot.
• Breaches affecting Telegram users will be notified as required by law.

20.4 LinkedIn, X, TikTok, LINE, Viber, WeChat, Discord, Slack and Microsoft Teams

For each of these, Allinaa processes only what the provider's own documented API sends for a connected account, as listed in section 7. LinkedIn member content is subject to the stricter rules in section 7.1: it is deleted after 48 hours, never given to the AI model, and never included in reports or alerts; replies to LinkedIn member content are written by a person, never drafted by AI. Slack and Microsoft Teams receive outbound staff alerts only, which never carry a customer's name, e-mail address or phone number.

21. Changes to this policy

We update this page when the service changes. The date at the top shows the last update. If a change materially affects how we handle personal data we will tell account holders by e-mail before it takes effect. For data we process on behalf of a business customer, that business will be informed so it can inform its own customers.

22. Contact

Back to top ↑

---