Privacy Policy

Last updated: October 26, 2026

1. Introduction

Welcome to NovixAgent AI, an AI-powered concierge and chatbot service provided by NOVIXAGENT ("we", "our", or "us"). We are committed to protecting your personal information and your right to privacy. This Privacy Policy governs the data collection, processing, and usage practices in three relationships, and they are not the same one. You may be a visitor using the NovixAgent AI widget embedded on one of our customers' websites — sections 2A and 2B — or somebody whose own AI app contacts such a website — section 2F. You may be somebody writing to us through our marketing website at novixagent.ai, or asking it to email you a projection, with or without an account — sections 2C and 2D. Or you may be an account holder signed in to manage a NovixAgent AI account — section 5.4, the partner program in section 2E, AI apps and API keys in section 2F, and the account rights in section 6. Where a section applies to one of those and not the others, it says so; where it says nothing, it applies to all three.

2. Information We Collect

We collect information that identifies, relates to, or could reasonably be linked to you ("Personal Data"). Parts A and B describe the widget. Parts C and D describe the separate, much smaller collections that happen on our marketing website — when you write to us, and when you ask us to email you a projection from our ROI calculator. Each has its own purpose, its own set of fields and its own route out of our systems.

A. Information You Provide Directly:

• Chat Inputs. The text and questions you type into the chat interface, and the assistant's replies.
• Uploaded Files. Two different things arrive under this heading. Documents the website owner uploaded to inform the agent (PDF, DOCX, TXT) are stored and indexed so the assistant can answer from them. Files you upload yourself, from inside the chat, are supported on two separate paths, each only where the site owner has enabled it. A document you attach to a question is read so the assistant can answer about it: the file itself is not kept — what is kept is the result worked out from it, and the filename you gave it. Whether the filename, and the names and wording that result took from the document, are kept follows the site owner's storage setting, the same one that governs your questions and the assistant's replies (see section 8); the rest of the result — such as a quote's figures, a CV's score, verdict and years of experience, which checklist items were missing, and the document's language and its page and word counts — is kept whatever that setting is. A file you send to a human operator in a live chat is accepted only on a site whose owner has switched visitor attachments on, which is off unless they do; it may be an image as well as a document, and it is stored alongside that conversation, and kept for as long as the conversation is, so the operator can open it. The retention periods are in our Data Retention Policy.
• Contact Information. The contact details you choose to give through a lead-capture flow within the widget (for example name, email, phone, free-text message).
• Feedback. When you click the 👍 / 👎 buttons on a reply, we record the rating and the message it relates to.

B. Information Collected Automatically:

• Log and Usage Data. IP address, browser type, device characteristics, operating system, language preferences, referring URLs, and timestamps associated with your interactions.
• Approximate Location. We derive a coarse location — country, region and city — from your IP address, and store it with the record of your conversation so the site owner can see where their visitors come from. The lookup runs on our own servers against an offline location database rather than through a location service. In a live chat with a human operator, the country is instead read from the header Cloudflare attaches to the request (Cloudflare sits in front of the service and sees your address, as section 4.1 says), and from the offline database where that header gives no usable value; the city still comes from the offline database. The IP address itself is not written into the conversation record — only the coarse location derived from it.
• Device Fingerprinting. We use browser fingerprinting (powered by the open-source FingerprintJS library) to generate a pseudonymous device identifier from publicly available browser attributes, such as canvas rendering, installed fonts, screen resolution and graphics capabilities. The fingerprint is signed by our server and kept in your browser's session storage; our servers keep only values derived from it, one for each of its uses. It has two uses, and they are not granted together. The first is rate limiting and abuse prevention. The second is counting distinct visitors for the analytics of the site you are on, and it happens only where that site has declared a basis for it; a site that has not gets the first use and not the second. There is also a third state: a site owner may switch the device signal off entirely for their embed, and then neither use happens. Neither use is advertising. The identifier used for counting is derived separately per website, so the same browser yields unrelated values on two different customers' sites. The identifier used for abuse prevention is not derived per website: one browser yields the same value on different customers' sites, although each site's limits count only the requests made to that site. If your browser sends Global Privacy Control, both uses are refused, and that refusal overrides the site's declaration. Refusing means no fingerprint is taken, so the abuse control loses its per-browser window; the per-address and per-site limits are unaffected and keep running.
• Cookies and Browser Storage. We use a small number of essential browser-storage entries (localStorage, sessionStorage) to maintain chat session state, enforce rate limits, and remember your language choices. Most of them live inside the chat window itself; two — a flag and a timestamp holding no personal data — are written on the domain of the website you are visiting, so that a proactive invitation to chat is not repeated. Section 5 lists both groups separately. No third-party tracking cookies or advertising pixels are used.

C. Information You Give Us by Writing to Us:

This part is not about the widget. It describes the contact form at novixagent.ai/contact, which anybody can use without holding an account.

• What you type. Your email address, which is required; your name, your company and a subject line, where you fill them in; the topic you choose; and the message itself.
• What your browser tells us. The IP address the submission came from, the browser user-agent string it sent, and the address of the page that sent you to the form. These three are stored with the submission on our own servers, and they travel with it: the notification email sent to the mailbox that handles your topic carries them as well, so under the Support topic they reach Zoho Desk with it (section 4.1). They are there for abuse prevention and rate limiting, and so that a report about something going wrong on a particular page can be made sense of. They are not used to build a profile of you, they are not combined with records from a Customer's site, and they are not shared for advertising.
• Where it goes. The submission is written into our own database, and a notification is emailed to the mailbox that handles that topic through Resend (section 4.1). A submission sent under the "Support" topic additionally becomes a ticket in Zoho Desk, because the support mailbox is polled by that helpdesk — so Zoho receives your name, email address, company and message, together with what the notification carrying them adds: the topic, the subject line where you gave one, the time it was submitted, your IP address, your browser user-agent string, the address of the page that sent you to the form, and the identifier we gave the submission. Zoho is listed in the table in section 4.1.
• The bot check. The form is protected by Cloudflare Turnstile, which receives its challenge token together with your IP address (section 4.1). What it places in your browser is in our Cookie Policy.
• How long we keep it. For the period our Data Retention Policy sets for contact-form submissions, after which it is deleted.
• Having it erased sooner. Section 6 says how, and it does not require you to have an account.

D. Information You Give Us by Asking for a Projection:

This part is not about the widget either. It describes the ROI calculator at novixagent.ai/roi-calculator. The calculator works out its figure in your browser and shows it to you in full; none of the numbers you enter leave your browser unless you choose to have the figure emailed to you. If you do:

• What you give us. Your email address, and the figures the projection was built from and showed you: your monthly visitors, conversion rate, deal value and uplift, the industry, plan and scenario you picked, and the resulting leads, revenue, net gain and payback.
• What your browser tells us. The IP address the request came from, the browser user-agent string it sent, and the address of the page that sent it, stored with the request for abuse prevention and rate limiting.
• What we record about your request. That you asked for this one email, when you asked, and which version of this Privacy Policy was in force at that moment. That record is how we can show what you agreed to.
• Why, and on what basis. We are the controller of this data — it is ours, not a Customer's. We send the projection because you asked for it, on the basis of your consent (Article 6(1)(a) GDPR), which you may withdraw at any time by asking us to erase it. We keep the request afterwards so we can answer you if you write back and as the record of what you asked for, which is our legitimate interest (Article 6(1)(f)).
• What we do not do with it. We send one email. We do not add you to a mailing list or a newsletter, and we do not pass your address to our marketing email provider. If your address is on our list of addresses not to be mailed — after a bounce, a complaint or an earlier request to stop — we keep the request and send nothing.
• Where it goes. The request is written into our own database, and the email is delivered through Resend (section 4.1). The form is protected by Cloudflare Turnstile, which receives its challenge token together with your IP address.
• How long we keep it. For the period our Data Retention Policy sets for projection requests, after which it is deleted.
• Having it erased sooner. Section 6 says how, and it does not require you to have an account.

Automatic PII redaction. Server-side telemetry (error reports, structured logs) is filtered before it leaves our infrastructure: email addresses in Latin letters (jane.doe@example.com), with an accented letter before the @ (müller@example.de), with accented letters in the domain (jöhn.doe@exämple.de), inside a web address (a=bea.ch@d.com) and with letters of another script before the @ (иван.петров@пример.рф); telephone numbers with a country code and a bracketed trunk zero (+44 (0) 20 7946 0958), in national groups (020 7946 0958), as two groups of four digits (2123 4567), in dotted pairs (06.12.34.56.78), with a slash after the area code (0151/23456789), in groups of 3-3-4 digits joined by dashes (415-555-1234), after other digits (1 2 3 4 5 6 0170 7654321), written two in a row (0170 7654321 0170 1234567), written two in a row around a slash (030 1234567 / 0170 7654321) and in another script's digits (+٤٤ ٢٠ ٧٩٤٦ ٠٩٥٨); card numbers of 13 to 19 digits even in a list (4111111111111111), joined to a word (card4111111111111111), stored as a number in structured data and in another script's digits; other long numbers of twenty digits in groups of four (1234 5678 9012 3456 7890); access tokens written after the word Bearer are replaced with masked placeholders. A masked email address reads like j***@example.com. These are not recognised and stay as written: a telephone number in four dotted groups with no plus sign (44.20.7946.0958) or written as ten digits with no space or separator (4155551234); a long number of eleven digits written together (12345678901) or of thirty-two digits written together. Error reports sent from your browser are filtered the same way, except that they also replace record identifiers in the standard hyphenated form (550e8400-e29b-41d4-a716-446655440000) and of 32 or more hexadecimal characters even with a card number inside it.

E. Information You Give Us If You Apply to the Partner Program:

This part is not about the widget. It describes the partner program for installers, which an account holder joins by applying in the Partners section of the dashboard. Somebody who signs up as an affiliate on the form of our commission platform gives that form what it asks for, and FirstPromoter holds it for us as our processor (section 4.1).

• What you give us. Your name or company name, which the clients you invite see; whether you are an agency, a freelancer or a consultant; your country; the languages you work in; a website address, if you give one; and a paragraph about which businesses you work with, roughly how many clients you have and how you find them. We also record which revision of the Partner Program Terms you agreed to, and when. Our staff read the application to decide on it.
• What we add. The name and email address your account already carries. The decision on your application (approved, not approved or suspended), the code for its reason and the member of staff who decided it, which are written to the audit trail described in section 8. Staff can also read the number of invitations, clients and demo sites you have, as counts.
• Clients you invite. The email address and website domain of a client are typed by you, so they are a third party's details that you hand to us. We use the address to send the invitation you asked for and to check that the account that accepts is the one invited. When the client accepts, the typed address is removed from the invitation, which keeps a keyed pseudonym of the address, a masked form showing its first letters, and identifiers, as the record of who brought the client. Next to each invitation, your list of clients shows you the name of the client's current plan (the plan you offered, while the site holds no plan or once the client has removed your access) and whether the client is waiting for payment, in trial or paid; it shows no price or amount. An invitation that is not accepted is deleted after the period in our Data Retention Policy.
• Demo sites. To count your allowance we record that you started a demo site, from which template and when.
• FirstPromoter. When we approve you, we create your record in FirstPromoter, our commission platform, from your email address, name, website if you gave one, country, company name and user id; it is where you see your link, clicks and earnings. We do not send it the paragraph you wrote about your work or the list of your languages. When a client you invited accepts, we register that client there under you, with the client's email address and account identifier. Payments reach it through its own connection to our Stripe account, which is set up in FirstPromoter's own settings and not by our software (section 4.1).
• Email. We email you when your application is received, approved, not approved or suspended, and when you have left the program at your request, and when a client you invited accepts, and we email a client when you invite them. If you are suspended or have left, we also email the owner of each account where you work as a helper. These emails go through Resend (section 4.1). FirstPromoter, which holds your record, may also send you its own program emails.
• Invoicing. Zoho Invoice, which we suggest to partners for invoicing their own clients, is the partner's own tool; we send it no data.
• Why, and on what basis. To decide on your application and to run the program under the terms you accept: performance of a contract, or steps taken before one (Article 6(1)(b) GDPR). To keep the record of our decisions and to check for fraud and abuse of the program: our legitimate interest (Article 6(1)(f)). The same interest covers sending the invitation you asked for to the address you typed.
• How long we keep it. An application that was not approved, an invitation that was not accepted and the record of a demo site each have their own period in our Data Retention Policy. The profile of an approved or suspended partner is kept while the partnership stands. It is deleted, together with the record of the partner's demo sites and the invitations the partner sent, accepted ones included, when we end the partnership, which we do at the partner's request, so that the company can be handed to a new owner, or for another reason we record, and when the account is erased.
• Having it erased. Account → Close this account deletes your partner profile, the record of your demo sites and the invitations you sent, accepted ones included. We remove your record at FirstPromoter as well: it is deleted if it earned no commission and archived if it earned one, because the financial history stays. Ending the partnership deletes the same records and removes the FirstPromoter record in the same way. While your partnership is approved, the account is not erased: write to support@novixagent.ai and we end the partnership first, which tells your clients and cancels your demo sites, and the closure then goes through. The same wait applies while a suspension for a breach of the terms or suspected fraud is under review, and while a notice or a cancellation that belongs to the partnership has not yet been delivered.

F. Information From AI Apps and API Keys:

This part is not about the widget. It describes software that reaches a Customer's site or account in other ways: customers' AI apps, an AI app or assistant that an account holder connects, and API keys. Where a bullet applies to one of the three relationships in section 1 and not to the others, it says so.

• If your own AI app or assistant contacts a business. Here you are in the position of a visitor and the Customer is the controller, as in sections 2A and 2B. A site owner has to switch this on, and has to prove control of the site's domain first; it is off until they do. The app can then read the business's published profile (its name, what it does, the contact details found on its website, and its lead form), put a question to the business's assistant, leave an enquiry through the business's lead form, check availability, book an appointment and look up an order, as far as the owner has allowed each. It sends us what it chooses to send, which includes what you told it. A question is answered as a question typed into the widget is, so it reaches the AI provider that writes the answer (section 4.1); the question and the answer are not stored as a visitor record. The answers it types into the lead form, usually a name, an email address, a phone number and a message, become a lead for the Customer, marked as coming from a customer's AI app, and are kept like the leads from the widget, for the period in our Data Retention Policy. The name, email address, optional phone number, time zone and chosen time of a booking go to the Customer's calendar provider (section 4.2), which sends its own invitation or confirmation to the address the app gave. An order number and email address go to the Customer's Shopify store where one is connected (section 4.2).
• What we hold about the app, and what we do not send. We keep the name the app gives for itself, as it reports it and without checking it, and counters of what it asked, left, booked and looked up, so that the Customer can see statistics of AI-app use. A booking request is kept as a record of its state, the time of the slot, the calendar provider's reference, a keyed digest of the slot and of the address and name the app typed (the address and the name themselves are not stored), and the retry key the app chose, stored as the app sent it. A conversation lasts a day. The digest and the retry key are removed a day after the conversation ends, and so is the time of the slot unless the booking could not be confirmed; the site owner sees the time of such a booking to check their calendar and can remove it from that list. The record itself, with the other booking requests made in the conversation, is deleted 30 days after the conversation ends. These periods are suspended while a legal hold covers them, as our Data Retention Policy section 4 describes. To limit how often one person is contacted or booked at a site, we also keep a keyed digest of the address the app typed, which our rate-limit store removes no later than two days after that person's last request. We use the address a request arrives from to apply limits against spam and abuse, and a refused request is counted in the statistics the Customer sees. It enters the audit trail described in section 8 only when a shared source used by an AI provider uses up a site's limit, and that entry names no address. We have no means of confirming whose address an AI app typed, so we send no follow-up or reminder of our own to it.
• If you connect an AI app or assistant to your account. An account holder who owns a site can connect an AI app or assistant of their choice from that app's own settings. When you allow it, we ask for your account password, and for a code from your authenticator if you have one turned on; you choose which of your sites it may reach and which kinds of data (for example leads, conversations, analytics and knowledge-base content), and it is limited to what your own account may do. The connection is personal to you as the person who allowed it, lasts 90 days unless you renew it, is listed under Account → API keys and AI apps, where you can end it, and ends when you close your account. We email you when an app is connected. What the app then asks for it receives at your request, and it goes to the provider of that app, whom we do not choose and with whom we hold no contract (section 4.2); it can include the details visitors gave in a lead form, the text of conversations the site kept and messages of live chats. The app can also put a question to your site's assistant, answered as in section 4.1, and suggest changes to your knowledge base, which wait for your approval before a visitor sees them.
• If you create an API key. An account holder can create keys for their workspace, for their own software or for a developer or agency they trust, and a key works only on sites whose plan includes the API. Creating one asks for the account password, and for a code from your authenticator if you have one turned on. The key is shown once; we keep a digest of it, its name, a short display prefix, its scopes, the sites it reaches, the list of addresses allowed to use it if you set one, who issued it, and its dates, including when it was last used. It reaches only the sites and the kinds of data set when it was made, within what the account may do, and expires after the period chosen then. Whoever holds the key receives the data its scopes cover, which includes the details visitors gave in a lead form and the text of conversations the site kept, and acts under the Customer's instruction; we are not a party to what they do with it. A key belongs to the workspace, not to the person who created it. It stays when ownership of the workspace is handed over, and the incoming owner is emailed a list of the keys that others issued, so that they can revoke what they do not recognise.
• Records of keys and connections. Daily counts of the requests each key or connection made on each site, by kind of operation, are kept for 90 days; they are what you see when you review a key. When a key or connection ends, we keep its record for 24 months: name, display prefix, scopes, sites, dates and, for a key, the digest of the key (not the key itself, which is shown once and not kept) and the list of allowed addresses if you set one, so that an audit entry naming it still says which one acted. Revoking a key or connection, rolling a key, renewing a connection, the end of a connection's 90 days and closing the account each leave a row in the audit trail (section 8) that names it by its identifier and a code for the reason. A change made with a key is recorded in the same trail.
• Why, and on what basis. For the access you set up and the records that show it: performance of a contract (Article 6(1)(b) GDPR). For the limits against spam and abuse, the counts and the audit rows: our legitimate interest in the security of the service (Article 6(1)(f)). For a customer's AI app, the Customer decides why its leads are collected, and we act for it as its processor.
• Having it erased. Account → Close this account deletes the connections you allowed and ends the keys of the workspaces you own (the record of an ended key is kept as described above), and removes your name as the person who issued a key in a workspace that someone else owns; that key stays with its workspace. The audit rows that name a key or connection by identifier stay, as section 8 describes. A lead from a customer's AI app is erased like the leads from the widget, with the Customer's site.

G. Information About People Invited to an Account:

This part is not about the widget. It describes the invitation an account holder sends to a teammate.

• What the invited person sees. The email goes to the address the account holder typed. It names who invited, using, where each can be shown, that person's first and last name, their confirmed email address and the account's name, and it names the websites; it does not list the sections. The page the link opens, which can be read without an account, shows the same and also lists, under each website, the sections the invitation offers. A part that cannot be shown, such as an unconfirmed address, is left out.
• Who can read it. Whoever holds the single-use link. It stops working after 72 hours, when it is used or when the account holder withdraws it.
• Why, and on what basis. To deliver the invitation the account holder asked for and to let the invited person recognise who sent it before accepting: our legitimate interest and the account holder's, in preventing impersonation (Article 6(1)(f) GDPR). Once the person accepts, performance of our contract with them (Article 6(1)(b)).
• How long we keep it. An answered or lapsed invitation, including the invited address, for the period in our Data Retention Policy.
• Having it erased. The sender's name and address are read from their account when the invitation is shown, so Account → Close this account takes them out of every invitation, which then names the account only. The invited address leaves with the invitation after the period above, or sooner on an erasure request (section 6).

3. How We Use Your Information

• Provide and Maintain the Service. Generate real-time AI responses and maintain conversational context.
• Analytics and Reporting. Allow the Customer (the website owner hosting the widget) to see how the assistant is performing — aggregate analytics, visitor intent, and, to the extent their storage setting retains it (see section 8), the wording of the conversations themselves.
• Support and Troubleshooting. When you or the Customer report a problem (for example, "the assistant answered incorrectly"), our authorised support personnel may review the relevant conversation turns — your question and the assistant's reply — to investigate. This is protected by two layers that work together on our servers: (1) a least-privilege field whitelist that returns only the minimum needed to troubleshoot and structurally excludes all financial and business data; and (2) automatic PII masking that replaces email addresses, phone numbers, and payment-card numbers with placeholders before the data ever leaves our API. What the masking replaces, and what reaches the support interface as you typed it, is set out under What the masking recognises below; messages repeating the lead answers described in the next paragraph are withheld as that paragraph says, and other personal data you typed into the chat, such as a name you did not give in a lead form, reaches the support interface as you typed it. Support access is restricted by role-based permissions and recorded in our append-only audit log. What the masking replaced cannot be revealed in this view; the only path to it is a separate, multi-factor-authenticated support workflow that notifies the Customer and is itself fully audited. A search across conversations, which needs its own permission, looks through a fixed number of the most recent questions in the period searched, chosen by time alone, and reads each one as the support interface shows it, after the masking and the lead-answer cut described in the next paragraph; which conversations it returns and how many are decided on that text alone, they are listed by when each conversation started, and every word typed must appear in it (a leading minus sign or the word "or" is read as a word, not as an exclusion or an alternative), so neither a result nor a missing one can confirm a value either of them hides.
• Captured leads read by our staff. Our authorised staff can read a Customer's captured leads in four places: the lead list, the lead export file, a failed delivery of your answers to the Customer's own systems, and a chat transcript, read on screen on our support desk, or by a platform administrator on the Customer's conversations page, on screen or as a downloaded file. In the list and the file they see each lead's identifier, when it arrived, which form captured it, its status, the identifier of the chat it came from and whether its email and webhook notifications were delivered, and of your answers only those that are a choice from a fixed list, a date, a time or a small number — a date or time as the form's date and time pickers record it, a small number being a whole number of at most six digits — or a yes or no — and those only where the Customer kept the question as our form catalogue words it. Where your answer to one of our catalogue's identifying questions — the email question or any of those listed next — is a whole email address, it is shown masked (j***@example.com); an email address in any other answer is withheld with that answer. Every other answer is withheld and reads as withheld, with its reason: your name, phone number, street address, city, postal code, company name, job title, website, order number and a student's age, anything you wrote in your own words, every field the Customer added to their form themselves, and every answer to a catalogue question the Customer reworded. The same applies when they read a failed delivery of your answers to the Customer's own systems. What such a delivery shows them, and which of your answers a chat transcript they read is compared against, are set out in the two paragraphs after this item. Each such read or export is recorded in our append-only audit log with the staff member, the site (for a list or file covering every site, each site whose leads it contained; for a failed delivery whose site has since been deleted, none can be named) and how many answers were withheld or masked (for a transcript, also how many messages were withheld), never the answers themselves, and unmasked answers, and the address a failed delivery was sent to, are reachable only through the separate workflow described above.

In a failed delivery of your answers to the Customer's own systems, our staff also see the delivery's event type, its website, lead and session identifiers, the form's name, where the lead came from, whether the person asked for a human to get back to them and the time it was sent, and the delivery's own record — when it failed, how many attempts were made, the class of the error and the HTTP status the receiver answered, and the names, never the values, of any authentication headers the Customer configured — but not the address it was sent to, only whether it went out as a signed event, a Slack message or a Discord message; any other key in the delivery is withheld, and a delivery written as a chat message (to Slack or Discord) is withheld whole.

In a chat transcript our staff read, the answers compared are the ones you gave in lead forms during that same chat, at most its 50 most recent submissions, and a message that repeats, as it was recorded, one of your answers we withhold from them or show only masked is withheld whole and reads as withheld, with its reason; case, spacing and punctuation are ignored in the comparison. A message is also withheld whole when it contains a word of at least three characters, digits counting as characters, from your name, your email address (the part before the @), phone number, street address, city, postal code, company name, job title, website, order number or a student's age, or a run of at least seven digits that is part of, or contains, the digits of an answer withheld or masked from them. Only those identifying answers are looked for word by word; any other answer is looked for as a whole and by its digits. A word from one of those answers written in Thai, Chinese, Japanese or Korean with an ending attached is found even inside a longer run of letters, as names are usually written there, if it is at least two characters long; any other word, and any other answer, is found only where spaces or punctuation set it apart from the rest of the message, a vowel sign counting as part of a word (as in Hindi or Bengali). Digits are compared whatever script they are written in. Not looked for, so a message repeating one of them is shown as written: an answer you gave in a different chat; a word of an identifying answer shorter than three characters; any other answer — something you wrote in your own words, an answer to a field the Customer added or to a catalogue question the Customer reworded — that is a single word shorter than four characters or only a number of fewer than seven digits; a yes or no answer; and a choice from our catalogue's fixed list, which is withheld only where the Customer reworded its question. An answer the assistant recorded in a spelling you did not type is not recognised either.

What the masking recognises. In the support interface, the masking replaces email addresses in Latin letters (jane.doe@example.com), with an accented letter before the @ (müller@example.de), with accented letters in the domain (jöhn.doe@exämple.de), inside a web address (a=bea.ch@d.com) and with letters of another script before the @ (иван.петров@пример.рф); telephone numbers with a country code and a bracketed trunk zero (+44 (0) 20 7946 0958), in national groups (020 7946 0958), as two groups of four digits (2123 4567), in dotted pairs (06.12.34.56.78), with a slash after the area code (0151/23456789), in groups of 3-3-4 digits joined by dashes (415-555-1234), after other digits (1 2 3 4 5 6 0170 7654321), written two in a row (0170 7654321 0170 1234567), written two in a row around a slash (030 1234567 / 0170 7654321) and in another script's digits (+٤٤ ٢٠ ٧٩٤٦ ٠٩٥٨); card numbers of 13 to 19 digits even in a list (4111111111111111), joined to a word (card4111111111111111), stored as a number in structured data and in another script's digits; other long numbers of twenty digits in groups of four (1234 5678 9012 3456 7890); access tokens written after the word Bearer. A masked email address reads like j***@example.com. These reach the support interface as you typed them: a telephone number in four dotted groups with no plus sign (44.20.7946.0958) or written as ten digits with no space or separator (4155551234); a long number of eleven digits written together (12345678901) or of thirty-two digits written together.

• Security and Fraud Prevention. Detect, prevent, and respond to fraud, API abuse, and security incidents (rate limits, anomaly detection).
• Service Improvement. Debug issues, monitor reliability, and improve the underlying architecture of the NovixAgent AI service.

We do not sell your personal information. We do not use your conversations to train AI models, ours or our AI providers'. Our software contains no training code. For our AI providers' models the commitment rests on the terms that apply to our account with each provider, stated per provider in section 4. Our chat calls to OpenAI also carry a request header asking for organisation-level opt-out from data use. That header is not part of OpenAI's published API, so we cannot show that OpenAI acts on it; it is a best-effort signal on that one path, not the basis of the commitment. Three of our OpenAI paths do not send it: our embedding calls, our speech-synthesis calls, and an internal model we use for the work around a conversation rather than for answering you. That internal model serves more than a dozen steps: it rewrites your question before we search the knowledge base, summarises a conversation, classifies what you are asking for, works out what you are trying to book, judges and previews the text extracted from a document you attached, re-ranks the passages we retrieved, prepares the Customer's own knowledge-base pages and crawled pages for indexing, classifies what kind of business a crawled site is and extracts the facts it states about itself, drafts and translates the assistant's welcome message, translates into English the custom instructions the Customer writes for the assistant, and drafts the outbound message sent to a captured lead. Depending on the step it receives your question as you typed it, the conversation so far, the text extracted from your attachment, passages from the Customer's knowledge base, and — on the outbound step — the name and the free-text answers left on a lead form. The commitment not to train on your conversations applies on these paths as well, and rests on the account terms, not on the header.

4. Third-Party Sub-processors

This section lists each company outside our own systems that receives personal data about you. It comes in three parts, because your position differs in each: in 4.1 we chose the provider and hold the contract, in 4.2 the Customer chose it and holds the contract, and in 4.3 the Customer names a destination of its own that we cannot know in advance.

4.1 Providers we engage

We keep this set small and vetted. We sign a Data Processing Agreement, or accept the provider's standard processing terms, with each provider below that processes personal data on our behalf; the browser push services, Have I Been Pwned, YouTube and the Google sign-in are public services with which no agreement is signed. We restrict the data each receives to the minimum necessary, and rely on appropriate transfer safeguards where data crosses borders.

Sub-processor	Purpose	Region
OpenAI	Generative AI inference (chat completion, embeddings, and speech synthesis for most languages) — API platform, whose terms exclude using API inputs to train OpenAI's models. Receives what you type, the conversation so far, the passages retrieved from the Customer's knowledge base, the text extracted from a document you attached to your question, the address of the page you are reading on the Customer's site — reduced to origin and path, so any query string is dropped before it leaves us — and the reply text when it is read aloud. In the help assistant built into our own product, which is not mounted on a Customer's site, it also receives the signed-in user's name, email address and account identifier. Separately, where the Customer has switched follow-up messages on, a lead you submitted is sent so that the follow-up can be written: for an automatic message, your first name, the topic of your enquiry and the language detected from it, and for an automatic reminder of an appointment you booked, also the service booked and its duration, the time and its timezone, the location, the host's name and, in an email or WhatsApp reminder, the link to reschedule or cancel; for a draft the Customer reviews before sending, also your name, what you asked about, the intent detected in it and the details you entered in the lead form	United States
Google (Gemini)	Generative AI inference under Google's paid-services terms for the Gemini API, which exclude using inputs to improve its products. Where Gemini is the model answering you, it receives the same conversation inputs listed for OpenAI above, and where it is the model the service uses for its own work around a conversation, the same follow-up and reminder details. Separately, where the Customer's plan enables the higher-tier document reader and our own reader's first result for a PDF you attach to a question is of low confidence, within the plan's page and cost limits, that PDF may be sent to Gemini as a file, not only as extracted text	Set by Google; our integration does not select one
Anthropic	Generative AI inference for chat answers only — its commercial API, under terms that provide that Anthropic may not train models on customer content, and whose Data Processing Addendum is part of those terms by reference. Where a Claude model is the one answering you — because the site owner's website has been assigned one, or because the model first chosen for it was unavailable and the answer is passed on — it receives what you type, the conversation so far, the passages retrieved from the Customer's knowledge base, the text extracted from a document you attached to your question, and the address of the page you are reading on the Customer's site, reduced to origin and path, so the query string is dropped before it leaves us. In the help assistant built into our own product, which is not mounted on a Customer's site, it also receives the signed-in user's name, email address and account identifier. It is not used for speech, for embeddings or for the work around a conversation, and it receives no file: a document you attach reaches it as extracted text only	Stored at rest in the United States; by the vendor's default routing the model may run in other regions the vendor operates (read 2026-10-15)
Speechify	Text-to-speech audio synthesis — receives the reply text to be spoken and the voice settings; no site, session or visitor identifier travels with it. Which of the two speech providers is asked first depends on the language of the reply text, which our servers detect from the text itself; the microphone and browser languages play no part. Speechify's model officially covers English, German, Spanish, French, Italian and Portuguese, and is asked first for those; for every other language we support, and for a reply whose language our servers could not determine or whose language is not on our list, the reply text goes to OpenAI's speech model first instead. Each is the other's fallback, so either may receive the text if the first is unavailable	United States
Stripe	Subscription billing, payment processing, customer portal — the Customer's billing data. A company has one customer record at Stripe, made by Stripe when the company's first payment is taken and used for the payment of each website of the company. Our checkout asks Stripe's payment page to offer to save the card you pay with; a card you choose to save is kept by Stripe on that record, not by us, and is used for the company's subscriptions	Global (PCI-DSS Level 1, as Stripe attests)
Google (sign-in)	Offered on the sign-in and registration screens of our own consoles, so it concerns account holders and our staff. Where somebody chooses to sign in with Google rather than with an email address and password, their Google sign-in identity is exchanged with Google under our application registration. Not offered where the deployment has not been given a Google client	Set by the vendor
Resend	Transactional email delivery (welcome, billing, lead notifications, operational alerts to our own staff, and the projection you ask our ROI calculator to email you). Where a Customer has switched on follow-ups to their leads, it also delivers the follow-up or appointment-reminder email written for you to your own address, so it receives your email address and the subject and text of that message, and a copy addressed to the Customer where the Customer keeps one. Each such message whose text a model wrote carries a machine-readable header marking its text as AI-generated; a message built from our fixed fallback wording carries no such header, and if building the mark fails or the mail provider refuses the header, the message is sent without it and the gap raises an alert for our staff. Separately, when we send a marketing broadcast to our own account holders — a staff-operated feature, not something a Customer can run — Resend also stores that recipient list, the account holders' email addresses and names, rather than only carrying a message in transit. That list is about our customers, not about visitors to their sites	Set by Resend; our integration does not select one
Zoho Desk	The helpdesk our support mailbox is worked in. It polls that mailbox, so anything addressed there becomes a ticket — including a message you write to support@novixagent.ai yourself, as section 6 invites you to — and our software addresses two things there. First, a message you send through the contact form on our marketing site under the Support topic: Zoho then holds what that message carried — your name, email address, company and the text you wrote — together with what the notification carrying it adds: the topic, the subject line where you gave one, the time it was submitted, your IP address, your browser user-agent string, the address of the page that sent you to the form, and the identifier we gave the submission. Of that form's topics only Support is forwarded; sales, partnership, security and general enquiries go to a mailbox the helpdesk does not poll. Second, if you hold an account with us, a support request you send from the help bubble inside your own dashboard: that becomes a ticket carrying your name, your email address, your account identifier and a list of the workspaces you own with the status of each. Our software sends it no text typed into a chat widget on a Customer's site. The help bubble that forwards to support is recognised by the workspace identifier it is mounted under, which is one of ours; a chat widget on a Customer's own site is not, and a visitor's chat messages and lead answers from a Customer's site are not sent here by our software; a visitor who writes to support@novixagent.ai directly reaches it like any other sender	Set by the Zoho account the desk runs under; our software does not select one. Ask at support@novixagent.ai if you need it named for a due-diligence answer
Hetzner Cloud	Application, database and file hosting. The files the service keeps — documents and notes the website owner supplied, files exchanged in a live chat in either direction (yours to the operator and the operator's to you), the encrypted archive of expired audit records, and the record of each erasure described in section 8 under "An erasure survives a restore" — are stored in Hetzner object storage, encrypted there as described in section 8	Germany (EU)
Vercel	Hosting for our public marketing website (not the product). Receives IP addresses and request logs for visits to that site	Global edge; no single region is pinned
Cloudflare	DNS, CDN and the reverse proxy in front of the product — so web traffic to the service passes through Cloudflare, which sees your IP address and country; the relay that carries a voice call's audio is reached directly, not through Cloudflare. Also the Turnstile bot check on the contact form, the ROI calculator's email request and the newsletter form on our marketing site where that form is shown, on our public endpoint for a request, made without an account, to erase what we hold under an email address (no page of ours calls it), and on the email sign-up form of the customer dashboard, before the account is created (signing in with Google runs no such check), which sends the challenge token together with your IP address	Global edge
Sentry	Error monitoring and performance traces — EU data residency (de.sentry.io), PII redaction enabled. Sentry also runs inside the chat widget in your browser, configured without session replay and without collecting personal data by default, so it reports diagnostic errors rather than what you wrote.	Germany (EU) for the product; our marketing site's security policy also permits Sentry's non-EU ingest hosts
PostHog	Product analysis for the customer dashboard only. It receives one record for each action an account holder takes — the name of the action, a short list of coded values, the time it happened, and an internal random identifier for the account — so it holds one account's sequence of actions, not only totals. The records are forwarded from our servers: PostHog runs no code in the dashboard, and the chat widget does not contact it. EU cloud (eu.i.posthog.com). Full detail in section 5.4	Germany (EU)
Healthchecks.io	Out-of-band monitoring of our own servers — a dead-man's switch that notices when our scheduled jobs stop running, when our alert pipeline goes blind, or when our metrics collector stops or raises a service-wide outage alert (server errors across the fleet, the fleet missing from the metrics scrape, or the alert pipeline failing to deliver); while no such alert is firing, the critical check also receives an hourly signal saying so. Each ping carries a check identifier and, where something failed, a short typed fault code; a ping from our metrics collector carries only the word firing or resolved and, on the critical check, the names of the alert rules. The time is stamped by the vendor when the ping arrives rather than sent by us. Listed for completeness: what it receives holds no personal data	Not stated by the vendor. Its privacy policy names Hetzner as the provider hosting the service and refers to transfers outside the EEA without naming a country (read 2026-08-25)
Have I Been Pwned (Pwned Passwords)	Checking a new password against known data breaches when you set or change the password of a NovixAgent account. The password is hashed on our server and only the first five characters of that hash are sent; the service answers with every breached hash sharing them, padded so the answer's size reveals nothing, and we make the comparison ourselves. Listed for completeness: the five characters sent do not identify you or your account	Not established in this document
Browser push services (Google, Apple, Mozilla and other browser makers)	Delivering a missed-message alert to a human operator's device, and a notice to the site owner's devices that a lead was captured, whose text names only the site and carries no answer from the lead. The missed-message alert text — which contains a preview of your message — is encrypted so that only the operator's device can read it; the push service relays it without being able to open it, but does see the delivery took place	Set by the browser the operator uses
Google Analytics 4	Website analytics on our marketing site, configured with Google Consent Mode v2 — the script is not loaded until you accept Analytics cookies; IP anonymised, Google advertising / ad-personalisation signals disabled	United States
Formbricks	Optional feedback surveys on our marketing site. The surveys that appear on their own are gated behind Analytics consent; the Feedback button is not, because pressing it is your own request to send us feedback — that click is what stores its survey state (a local-storage entry, no cookie), and section 5.3 says the same. Off entirely unless a survey workspace is configured	Formbricks Cloud (app.formbricks.com) by default; a self-hosted instance can be substituted by configuration. We do not state a region here because the workspace in use is not fixed by the software
FirstPromoter	Optional partner and affiliate attribution and commission accounting for our partner program. On our marketing site its tracker script loads only after you accept Marketing cookies, and only where a partner program is configured; it then records a click on a partner's link, with what such a request carries (your IP address and browser details), so that the partner can be credited if you subscribe. The fields its script sends beyond that are not listed in the vendor's documentation and are not established here. When you pay for a plan it also receives from Stripe, through a connection to our Stripe account that is set up in FirstPromoter's own settings and not by our software, the email address on your company's Stripe customer record (the current owner's, which changes to the new owner's address when the company changes owner), an account identifier we write once to that record (fp_uid, the user id of the account that owned the company when its first payment completed; a later change of owner does not move it) and the invoice amounts and identifiers of each website of the company, whether or not a partner is involved. From our servers it receives the details of an approved partner (section 2E) and, for a client a partner invited, the client's email address and the same account identifier. It does not receive what you say to a customer's assistant. It keeps its copy for 2 years for expired trial and cancelled users and 5 years for the rest, as its own privacy page states (read 2026-10-18). Off by default	Not stated by the vendor
YouTube (Google)	The product tour video on our marketing site. The video is requested from Google only when you press play. Pressing play loads the video from youtube-nocookie.com, the privacy-enhanced host, and the player script from www.youtube.com, which is an ordinary Google domain	Global

Built but not switched on. Two more companies appear in our software. Each is inert until a key for it is configured, and neither is configured in the service we run:

• Cohere, for re-ranking search results, which would receive your question and the candidate passages from the site owner's knowledge base. Switching it off does not remove that step: how the passages are ordered while no dedicated re-ranking service is configured, and which providers see them, is set out under 4.1.1 below.
• Retell AI, for outbound AI voice calls, which would receive your telephone number and a spoken script naming you, the service and the appointment.

If either is switched on, it moves into the table above and the change is published before it takes effect.

4.1.1 How retrieved passages are ordered

Every search puts its results in order, and there is no setting in which the passages we retrieved reach the model that writes your answer in the order the database returned them. That ordering always has a first stage, and on some searches a second one follows it.

The first stage is a scoring pass that runs inside our own service. It happens on every search, it re-orders the candidate passages, and it sends them nowhere.

The second stage does not happen on every search. Where a dedicated re-ranking service is configured, that service does it and receives your question and the candidate passages; it is not called if the time set aside for ordering has already run out, the site owner's plan does not include that stage, the plan's monthly allowance for it is zero, that monthly allowance has already been used up, the search found no more than one passage or the plan uses it selectively and the leading candidates already score far enough apart.

Where none is configured, the second stage is done instead by the internal model we run for the work around a conversation rather than for answering you; it is not asked if the time set aside for ordering has already run out or the search found no more than five passages. When it is asked, it receives your question together with at most twelve candidate passages, each cut to its first 300 characters. It runs on OpenAI and Google (Gemini), OpenAI tried first and the other standing as its fallback, so either may receive it.

When the second stage does not happen, the order the first stage worked out is the one we use, and neither your question nor the passages leave our service for either of them.

4.2 Providers the Customer connects

These are engaged only if the Customer connects them, using the Customer's own account and credentials. The account belongs to the Customer, not to us, and that provider's agreement with the Customer governs what happens to the data there.

Provider	What we send	Region
Cal.com	Your name, email address, phone number, and time zone, plus the note the assistant recorded for the meeting, where there is one (capped at 500 characters), and the identifier and web address of the website you booked from. The web address also opens that note as "Booked via" followed by the address	United States (api.cal.com) or EU (api.cal.eu), depending on the region set on the Customer's integration
Calendly	Your name, email address, and time zone. No phone number and no meeting note are sent	Set by the vendor; our integration does not select one
Meta — WhatsApp, Messenger, Instagram	If you reach the assistant through one of these apps, the conversation happens on Meta's platform: your WhatsApp number or your Messenger / Instagram account identifier, and the text of the messages either side sends. Your number can also reach Meta without your having used WhatsApp: where the site owner has connected WhatsApp and outbound reminders are switched on for the deployment, a message about a booking or an enquiry you left elsewhere is sent to your telephone number through the same platform	Not established. Meta's developer documentation describes encryption in transit and at rest but does not state where the service is hosted. For WhatsApp only, Meta lets each business phone number choose a region where its message data is stored at rest; our integration does not choose one
Slack	The details you gave the lead form — typically name, email address and phone number — posted into the Customer's Slack workspace	Set by the Customer's own Slack workspace. Slack stores data in the United States by default; a workspace on Slack's data-residency plan may store it elsewhere
Shopify	If you ask about an order, the order number and email address you supply go to the Customer's store as a lookup, and the order, fulfilment and tracking details come back	The Customer's own Shopify store; our integration does not select a region
An AI app or assistant the account holder connects	Whatever the account holder lets the app read, within the sites and kinds of data they chose when they connected it. It can include the details you gave in a lead form, the text of your conversation with the assistant where the site's storage setting kept it, your messages in a live chat with a human operator, and analytics about the site. The app can also put a question to the site's assistant and suggest changes to its knowledge base, which wait for the account holder's approval	Set by the provider of that app; our integration does not select one

Google Calendar is not offered where the deployment has not enabled it. Our software can talk to it, but the connection appears only where the deployment has enabled it; where it has not, a site owner has no way to link a Google calendar and no booking is sent to one. Cal.com and Calendly cover the same ground, and our help pages say the same. If it is ever offered, it will appear in the table above first.

The meeting note is free text the assistant composes from your conversation to give the meeting context. Whether a provider then emails you a confirmation is governed by that provider's own settings and privacy policy, not by us.

4.3 Destinations the Customer chooses

The Customer can tell us to forward captured lead details, or values from your conversation, to an address of its own. We cannot list those recipients in advance, because the Customer supplies the address. The Customer is responsible for where it points and for what happens there. We send over TLS. A lead-webhook delivery is signed so the receiving system can confirm it came from us, although Slack and Discord do not check that signature; a custom action is not signed and carries only the headers the Customer configured for it, authentication headers included, and a content type.

What is forwarded	What it contains
Lead webhook	The answers you entered in the lead form — typically name, email address and phone number — with the event type lead.captured, the website and session identifiers, the lead identifier (left out if the lead could not be saved), the form's name, where the lead came from (the widget, a messaging channel or a customer's AI app), whether you asked for a person to get back to you, and the time it was sent. A delivery to a Slack or Discord address carries instead a message titled "New lead from" and the form's name, a line saying where the lead came from and whether a person was asked for, then each question you answered with your answer, each answer cut to 500 characters and the message cut to 3,000 characters for Slack and 2,000 for Discord, without those identifiers. The product offers one-click presets for Zapier, Make, n8n, Slack and Discord as well as a plain address, so choosing a preset places the data with that vendor under its own terms. Deliveries that fail are retried later with the same content
Custom actions	Values the assistant took from your conversation, as defined by the action the Customer set up, sent to the address that action names

The list of the parties in 4.1 is kept current in this policy and is sent on request. We notify Customers in advance of a material change (new sub-processor, region change) so they can object; the Data Processing Agreement sets out how.

The Customer (the website owner) on whose site you are using the widget has access to whatever their site retains — the chat transcripts kept under their storage setting (see section 8), and the contact information you provide. They act as the Data Controller; we act as the Data Processor.

4.4 Your own browser, where you dictate instead of typing

Where the site's plan includes dictation and the site owner has not switched it off, you can speak a message instead of typing it. This differs from the providers above: the audio of a dictated message does not pass through us. Your browser captures it, sends it wherever that browser sends it, and hands us back only the text — and only once you press send.

By default a browser does not do the recognition on your device, and the widget does not ask it to. As published developer guides describe it, Chrome transmits the captured audio to Google's speech service; other browsers send it to whichever service their maker uses, and some, such as Edge, often fail to recognise speech. Which company receives it is decided by the browser you are using; neither we nor the site owner can choose, redirect or switch it off at that level.

We are not a party to that transfer and cannot contract for it, so it is listed here rather than in 4.1. It happens under the terms of your browser vendor, not ours.

If you would rather no audio left your device, type your message instead. Capture starts when you press the microphone and goes on until you press it again or send the message: the widget restarts listening by itself after a silence and after a spoken reply, and the text reaches us only when you send the message.

5. Cookies and Local Storage

The NovixAgent AI widget uses minimal browser storage to function. That storage is written in two different places, and we list them apart because they are two different privacy footprints — one inside our own chat window, one on the page of the website you are visiting. Both groups are strictly necessary: without them the widget keeps a conversation, its own message throttle and the memory that it already spoke to you only until the page is reloaded.

5.1 Inside the chat window (our domain)

The chat interface runs in a frame served from our own domain, and the entries below are stored there. The website you are visiting cannot read them.

• ag_chat_state (localStorage) — small JSON blob holding your preferred chat language, speech-to-text language, a flag recording that you closed the legal notice, and the welcome-screen view count. An earlier version of the widget also stored a browser id in this entry. The current widget stores none, never reads one, and never sends one — the identifier it uses is the session fingerprint fp-visitor-id described below. If your browser still holds a value that older build left, it stays there until you clear your own browser storage: we do not read it and we do not remove it. The flag records only that the notice was closed; it is not a record of consent.
• novixagent_session_id:<websiteId> (sessionStorage, one browser tab) — a random identifier for this tab's chat session, so the several requests that make up one conversation are recognised as the same conversation. It is generated in your browser, holds no personal data, and a new tab starts a new one.
• fp-visitor-id (sessionStorage, browser session) — pseudonymous device fingerprint used for rate limiting and abuse prevention and, only where the site has declared a basis for it, for counting distinct visitors.
• fp-token (sessionStorage, browser session) — server-signed fingerprint token for abuse prevention.
• rate-limit-timestamps (sessionStorage, browser session) — timestamps of recent messages so the client can throttle itself before sending.
• novixagent_unsent_messages:<websiteId> (sessionStorage, one browser tab) — messages you typed that could not be sent, so they can go when the connection returns. They are your own words, held on your own device and not sent to us until the message actually goes; at most ten are kept, each stops being retried after five minutes, and closing the tab discards them.

5.2 On the website you are visiting (the site owner's domain)

The chat button itself is drawn on the page by a small launcher script, outside the chat window. That script writes two entries, and only these two, into the storage of the site you are visiting. Their sole purpose is to stop the widget from inviting you to chat more than once:

• novixagent:proactive:v1:<websiteId>:chat-opened (sessionStorage, cleared when you close the tab) — a single true/false flag recording that the chat was already opened in this browser tab, so you are not invited again during the same visit.
• novixagent:proactive:v1:<websiteId>:last-fired-at (localStorage, persistent) — the time of the last proactive invitation, so you are shown at most one per day.

These two entries contain no personal data — a boolean and a timestamp. No message content, no contact details, no visitor or device identifier, no page address, and no pointer or scroll data are written to the site owner's domain. The <websiteId> part identifies the website you are visiting, not you. Both entries only ever suppress what the widget shows you; if your browser blocks storage, they are kept only in the page's memory until it is closed and the widget still works.

5.3 Our marketing site

The marketing site at novixagent.ai additionally uses:

• cookieConsent (localStorage, persistent) — your granular cookie-consent choices (Necessary / Analytics / Marketing).
• theme (localStorage, persistent) — your chosen light / dark theme.
• _ga, _ga_* (cookies, set only after you accept Analytics) — Google Analytics 4 traffic measurement. Until you opt in, the GA4 script is not loaded; IP is anonymised and ad-personalisation signals are off.
• formbricks-js (localStorage, written only after you click the in-product Feedback button or accept Analytics; removed when you withdraw Analytics consent) — Formbricks survey state. The survey tool sets no cookie.
• novix_formbricks_cooldown_v1 (localStorage, 7 days, written only when you close a survey shown after you accepted Analytics) — that you closed a survey, so you are not shown another.
• novix_exit_intent_v2 (sessionStorage, one browser tab) and novix_exit_intent_cooldown_v2 (localStorage, 7 days after you dismiss the exit-intent offer, 30 days after you open the linked tool) — whether the offer was already shown to you. Both are strictly necessary and placed without a consent choice.
• _fprom* and fprom_* (cookies, set only if you accept Marketing) — FirstPromoter's partner-attribution cookies, which remember which partner's link brought you here so that the partner can be credited if you subscribe. The Cookie Policy gives the names.

The marketing-site items beyond strictly-necessary are placed only when you accept the corresponding category in our cookie banner. See our Cookie Policy for the full breakdown.

5.4 The customer dashboard (account holders only)

This section applies only to people who log in to manage a NovixAgent AI account — owners and the operators they invite. It does not apply to visitors chatting with the widget.

The dashboard does not ask for your consent, because it stores nothing on your device for measurement. There is no consent banner or consent question in it. What it does place in your browser are the entries the product needs to run — your sign-in session, the anti-forgery token, your light/dark choice, the language you picked for the dashboard, which of your workspaces is open, whether a live-chat notification and its sound are on, whether a guided tour is finished, whether you turned down the offer to install the dashboard as an app, and the time zone you chose to keep when this device reported a different one. Three of those are sent to us: the sign-in session and the anti-forgery token go with the dashboard's requests to our own service — the first keeps you signed in, the second lets the service tell a request made by the dashboard from one made by another site — and the workspace you last had open is sent with the requests that ask us for that workspace's data, because the screen has to name which one to load. They go to our own service and nowhere else. If you turn on push notifications, the browser's push subscription (its delivery address and keys) is also sent to us so that we can notify you, and it is deleted when you turn them off. The language you pick is also saved to your account on our own service when you pick it; the stored copy in your browser is not itself sent. A language you pick before you have an account is held in this tab and sent to our service with your sign-up, or at sign-in, so that it is saved to your account. The others are settings you made in the dashboard: they stay in your browser, are read only by the dashboard, and are not identifiers used to measure you. The email sign-up page also shows Cloudflare's bot check in a frame on Cloudflare's own domain (see the Cookie Policy); signing in with Google or with an existing account does not.

Two more entries belong to the dashboard rather than to you. First, while a member of our support staff is working in your account under the audited flow described further down this section, their browser remembers whether the banner announcing that session is collapsed; it is written on the screen where the banner appears — in practice theirs, not yours — holds only that one choice, and is discarded when the tab closes. Second, when we deploy a new version of the dashboard while your tab is open, the tab reloads itself onto it and records the time it did so, so that a reload which does not fix the problem is not repeated; it holds only a timestamp, stays in that tab, and is discarded when the tab closes.

There is no session replay and no click recording. An earlier version of the dashboard offered a session recorder, behind a question; it has been removed together with the analytics library that ran it. If your browser still holds what that recorder wrote, the dashboard deletes it from your browser's storage the next time you open it — the recorder's identifier, its opt-out flag, its per-window markers and the record of the answer you gave to its question. The recorder also kept a copy of its identifier in a cookie on our domain. The dashboard does not write cookies, so our service removes that one instead: the cookie reaches our service with the dashboard's next request, and the answer carries an instruction to delete it. If you do not return, it expires by itself a year after it was written; clearing this site's cookies also removes it.

Counting which features are used

What we record. That a feature was used, and at which step a flow was abandoned: which screens you open, which settings you switch on, and the outcome of actions you take (for example that a conversation was resolved, or that a plan was selected). Each record holds the name of the action, a short list of coded values about it — an identifier, a category, a count, a size band — and which account it belongs to.

Where it is recorded. On our own servers. The dashboard writes each record in your browser and sends it to our own service in an ordinary request addressed to us; no other company's code is involved. Nothing is stored on, or read from, your device to do this: no cookie is set and no browser storage is written. That is why we do not ask for your consent: Article 5(3) of the ePrivacy Directive governs storing information on, or reading it from, your device, and this does neither.

What is not recorded. Free text — what you or a visitor typed, a lead's details, message content — email addresses, page addresses, and browser or device information. Which screen you were on is recorded as an internal short name the software declares, not as the web address in your address bar, so a link carrying an invitation code, a reset code or an email address does not travel with the record. The coded values are capped in length and refused if they are not a plain identifier, category, number or flag.

Who else sees it. These records are forwarded from our servers to PostHog, the analysis tool we use to read them, listed as a sub-processor in section 4. They go one record per action, not as a total, so PostHog holds individual behavioural data about an account. Our servers send them, not your browser: PostHog runs no code in the dashboard. What travels is the coded record described above plus an internal random identifier for the account — not your name, your email address or a page address.

Why we do it, and on what basis. To find out which parts of the product are used and where people give up, so we can fix them. Our legal basis is our legitimate interest (GDPR Article 6(1)(f)) in improving the service we provide to you under our contract. We take no decision about you from it, we do not use it for advertising, we do not combine it with data from other sites or with data about your visitors, and we do not sell it.

How long we hold it. Briefly. A record stays on our servers only until PostHog has accepted it — normally a matter of minutes — and is deleted once it has. If forwarding is interrupted, a record that is refused five times in a row is deleted and not counted, and a record that is neither accepted nor refused waits for the period our Data Retention Policy sets for it and is then deleted whether it was sent or not. After that it exists only at PostHog, which holds it for the retention period configured on our project there. That period is a setting in PostHog's own system, not in a system of ours, so our Data Retention Policy does not publish it; write to support@novixagent.ai and we will tell you what our project is set to.

How to object. Open Account → Product usage counting and turn the switch off. That is your right to object under Article 21. It takes effect immediately and is stored with your account, so it applies whichever device you sign in from; your use of the product does not otherwise change. The switch stops the record being written, so nothing about you is forwarded. You may also write to support@novixagent.ai.

When our support staff act on your behalf under the audited impersonation flow, nothing they do is counted against your account.

Error monitoring is separate. We record technical error reports when something in the dashboard breaks (see the Sentry entry in section 4). That is a different purpose — keeping the service you asked for working and secure — it places no cookie or storage on your device, it carries no session replay, and its basis is our legitimate interest in the security and correct operation of the service (Article 6(1)(f)).

6. User Rights and Data Control

6.1 Rights Under GDPR (EU/EEA/UK Residents)

• Right to Access / Portability. Request copies of your personal data in a structured, machine-readable format.
• Right to Erasure. Request that we delete your personal data. If you hold an account, you do not have to ask: Account → Close this account in the dashboard erases it yourself. You can choose to close at once, or when your subscriptions end; until the closure completes you can cancel it, and once the erasure has completed the product offers no way to undo it, for you or for us.
• Right to Rectification. Request correction of inaccurate data.
• Right to Restrict Processing. Request that we limit how your data is used.
• Right to Object. Object to processing based on legitimate interests. For the product-usage counting described in section 5.4, the switch under Account → Product usage counting is that objection and takes effect at once.
• Right to Withdraw Consent. You may withdraw consent at any time, as easily as you gave it. The dashboard does not ask for consent (section 5.4); for marketing-site cookies, use "Manage cookie preferences" on our Cookie Policy page, linked as "Cookies" in the footer. It takes effect immediately. You may also clear your browser's storage for the site you are visiting and for the widget's own domain, or contact support@novixagent.ai.

6.2 Rights Under CCPA (California Residents)

• Right to Know. What personal information is collected, used, and disclosed.
• Right to Delete. Request deletion of your personal information — or, if you hold an account, delete it yourself from Account → Close this account.
• Right to Non-Discrimination. We will not discriminate against you for exercising your rights.
• Do Not Sell or Share. We do not sell your personal information, nor share it for cross-context behavioral advertising.

How to exercise your rights. Which door you use depends on which of the three relationships in section 1 you are in.

• A visitor to a Customer's website. We act as a Data Processor for that website owner, who is the Data Controller, so a request to delete or access chat logs should go to them first. You may also contact us at support@novixagent.ai and we will assist in fulfilling the request.
• An account holder. Erasure is self-service and you do not have to ask us for it. Account → Close this account in the dashboard ends your subscriptions, removes the workspaces you own, and erases your personal data; the dashboard tells you what goes with it before you confirm, and asks you to type your own email address back. It also asks for your account password, and for a code from your authenticator if you have two-factor authentication turned on. An account created through Google has no password with us until one is added, through Set a password by email in the note that the Account screen shows in place of the password fields (when you are signed out, through Forgot password on the sign-in screen), and closing waits until it has one. Closing is not available while a legal hold covers your data, while you own a company that another member could take over (hand over ownership first; a company that no other member can take over is closed with the account, which ends its teammates' access), or while a partnership you applied for is not settled. Deleting a single workspace asks for the same password, and the same code where it applies. Once the erasure has completed, the product offers no way to reverse it, to you, our staff or an administrator, and a database restored from a backup has it applied again (section 8). What survives is described in section 8 and kept for the periods in our Data Retention Policy: the financial records tax and company law require, the append-only audit trail, the record that keeps a free trial from being repeated (keyed pseudonyms), and the record of the erasure itself, which holds your email address inside an encrypted record so that the erasure is applied again if a database is restored from a backup. Erasure rewrites neither the financial records nor the audit trail: our own payment records hold no name or email address, but the invoices at Stripe, our payment processor, keep the email address and billing details they were issued to, and the customer record holds the email address of the company's current owner (we move it to the new owner's address when the company changes owner) and the billing details entered at payment (a company has one customer record: Stripe itself creates it while the first payment is made, so one can exist for a payment attempt that was not completed; our servers create no customer record when a checkout is opened), and an audit entry keeps the IP address it recorded and the reason a member of staff typed into it, where one was typed. The copy of your email address, account identifier and invoice amounts that FirstPromoter holds stays with it, for up to five years under the period its privacy page states, and so does the record it holds of a client registered under a partner who invited you: erasing your account does not send FirstPromoter a request to erase either, and you can ask FirstPromoter for that directly. The one record we do remove there is a partner's own (section 2E). For access and portability, the dashboard exports your captured leads as a file, with no plan limiting how many exports you run, and offers a per-website subject-access export; for a wider request, write to support@novixagent.ai.
• Somebody with no account, who only wrote to us through the contact form or asked for a projection by email. Those submissions and requests are held against the email address you typed into the form, and that address is the only thing tying them to you. Ask for them to be erased from that address, at support@novixagent.ai: we act on a request that arrives from, or is confirmed at, the address the records themselves carry, because on an anonymous form that is the only proof we have that they are yours. We will not delete somebody else's records on an unverified claim, and we will tell you so. Whether or not you ask, they are deleted on the schedule in our Data Retention Policy.

7. Cross-Border Data Transfers

Your data may be processed in countries other than your own, including the United States. When we transfer data outside the EEA/UK we rely on appropriate safeguards — typically the European Commission's Standard Contractual Clauses (2021) or the EU-US Data Privacy Framework where the receiving provider is certified. Supplementary technical measures (encryption in transit, pseudonymisation, minimised payloads) are applied so the transferred data carries less risk than its EU-resident counterpart.

8. Data Security and Retention

We implement appropriate technical and organisational security measures:

• In-transit encryption. Web traffic between you and the service is encrypted with TLS. From our edge network to our servers our servers accept only TLS 1.2 or higher; between your browser and the edge network the minimum version is also TLS 1.2. The webhooks we deliver on a Customer's behalf are sent over TLS. The audio of a voice call to a human travels over WebRTC to our relay, outside the edge network, and is encrypted by WebRTC. Calls between our own services do not travel over the public internet: they run inside a private network that is not reachable from outside it. Our own service-to-service API calls are additionally signed and checked rather than relying on a second layer of transport encryption — see Inter-service authentication below. The rest of that internal traffic is not signed, and what protects it differs by destination: the database and cache require credentials on top of the network isolation, while the page fetcher we hand crawl jobs to accepts, apart from its health check, only requests carrying a shared token, and is reachable only from inside that network.
• At-rest encryption (disk-level). The database and cache are stored on a LUKS2 / AES-256-XTS encrypted volume.
• At-rest encryption for stored files. Uploaded files do not sit on that volume. They are held in object storage and encrypted there with AES-256 under a key we supply on every single write and every single read — the storage provider discards it after each request and keeps no copy, so it holds no key with which to open the objects it stores. The key is required configuration: the service refuses to start without it.
• At-rest encryption for secrets. Webhook authentication credentials, integration tokens, and the webhook destination address itself are additionally encrypted with AES-256-GCM at rest; the encryption key is sourced from configuration, not stored alongside the ciphertext. The destination is treated as a secret because for receivers such as Slack and Zapier the URL is the credential — anyone holding it can post to that endpoint. One of these is sealed shortly after it is written rather than before, and we say so rather than let "at rest" imply otherwise: the signing secret we generate for a new integration is created by the database itself, and a sweep that runs at six-hour intervals encrypts it, so a newly created one can sit unsealed for up to six hours. The tokens and destination addresses you supply are encrypted by the application before they are written.
• Encrypted backups. Off-site backups are encrypted by borg in its repokey-blake2 mode. We name the mode rather than only the key size, because it decides two different things: AES-256 keeps the archive unreadable, and a BLAKE2b-256 authentication tag on every chunk means tampering with the stored copy is detected rather than silently inherited on restore. The key that opens the archive is held inside the repository itself and is worthless without a passphrase, and that passphrase is kept on our own database host and in our password manager — it is not given to the provider that stores the archive, so the party holding the ciphertext holds no means of reading it. Point-in-time recovery is a separate path and runs from a continuously archived copy kept on the database host itself; the off-site copy is a periodic archive, so a recovery starting from it returns to the last archive shipped rather than to an arbitrary moment. The off-site copy is exercised by restoring a real database from it and checking row counts; a point-in-time restore from the on-host copy has been rehearsed once, in a drill whose record states no target time and no comparison against production.
• An erasure survives a restore. A backup taken before an erasure still holds what was erased, so the erasure of an account, of an email address through our erasure link, and of a deleted workspace is also recorded outside the database, in our encrypted object storage. A workspace is recorded by its identifier. An erasure by email address is recorded by the address itself inside the encrypted record, because the address is what finds that data again. An account is recorded both ways: by its identifier, and, where the account had an email address, by that address inside an encrypted record of its own. When a database is restored, the service applies the recorded erasures again as it starts (the first pass may finish just after the service begins taking requests) and hourly after that, except where a legal hold now covers the data, and counts and reports the ones it could not apply. An erasure of an email address is applied up to the time it was made, so what was created under that address afterwards stays. Each record is kept for the period our Data Retention Policy sets for it, longer than our oldest backup, and then deleted. The records are held in one copy, in the same object storage as uploaded files and not yet copied elsewhere, so if that storage were lost the records would be lost with it, and a database restored after that would have no record of which erasures to apply again.
• A record that a free trial was used outlasts the account. To offer one free trial per customer, we keep a keyed pseudonym of the account, of each website domain and of each messaging channel on which a free trial was used. It is a one-way digest made with a secret key that we hold: it contains no name, email address or phone number, and it does not reveal the domain or channel it stands for without that key. Once the trial has started, the record keeps no link to your account or website. It keeps the identifier of the subscription the trial started, which our own payment records also hold, only while the trial can still run and for the period in which our payment processor can resend its notice that the checkout completed, because that is how a domain or channel added during the trial joins the record; after that it is removed. Erasing your account does not delete these records, because they exist for fraud prevention (section 3). They are deleted 24 months after the trial was granted, on the schedule in our Data Retention Policy.
• A record that the Terms and the DPA were accepted. When an account accepts our Terms of Service and Data Processing Agreement — at sign-up, or later in the dashboard when a new revision is published — we keep a record of which company accepted, the account that accepted (by its internal identifier), which document, its revision (the date under its title and a short code worked out from the document's English text) and the time. It holds no IP address, no browser or device details and not the wording of the box. The account our application runs under holds no privilege to change or delete it, and closing the account does not remove it, because it is the evidence of what the company agreed to; it is kept for the period stated in our Data Retention Policy.
• Inter-service authentication. Internal API calls between our own services use signed HMAC-SHA256 requests with timestamp anti-replay rather than plaintext bearer tokens. The one exception is the page fetcher, which accepts only a shared bearer token; that token travels inside the private network described above.
• Append-only audit log with a defined retention period. Privileged actions are written to an append-only audit_logs table. A database trigger blocks modification and deletion at the engine level, and the account our application runs under has no privilege to update, delete or truncate the table — so nothing done through the product can alter the record. That protection does not by itself detect a change made with the database owner's credentials, and we do not promise to detect one. Entries are kept for the period set out in our Data Retention Policy, first in a searchable store and then in an encrypted archive, and are removed only on that schedule and only after the archive has been verified.
• PII masking (defence in depth). Personal data is masked at multiple points, not one. Operational telemetry (error reports, structured logs) is masked before it leaves the application, as the paragraph after this list sets out. The same masking is applied server-side to conversation content (your questions and the assistant's replies) whenever it is surfaced to our internal support tooling, and the support responses are built from an enumerated set of fields that excludes financial and business data outright; captured leads reach support tooling reduced field by field as section 3 describes. Support staff investigating an issue therefore receive conversation text with these masks applied and captured leads reduced as section 3 describes, and anything you typed that neither recognises — a name you never gave in a lead form, for example — reaches them as you typed it.
• Defense-in-depth. Server-Side Request Forgery (SSRF) guards on the outbound destinations that can be influenced from outside — the pages our crawler fetches and the endpoints a Customer points a webhook at — which are checked against an allow-list of safe schemes and refused if they resolve into a private network range. CSRF protection on state-changing requests. Security headers (HSTS, a content security policy and X-Frame-Options, according to what each host serves; the widget host, which has to be embeddable, is sent no X-Frame-Options) applied at our edge, the one place they are set.

In telemetry and in support tooling, the masking replaces email addresses, telephone numbers, card numbers, other long numbers and access tokens. These are left as written: a telephone number in four dotted groups with no plus sign (44.20.7946.0958) or written as ten digits with no space or separator (4155551234); a long number of eleven digits written together (12345678901) or of thirty-two digits written together.

We retain chat history only for as long as necessary to fulfil the purposes outlined in this policy or as instructed by the website owner, after which it is anonymised or securely deleted.

The website owner controls how much of a conversation is kept, and for how long. This setting governs the assistant's side of the conversation — the questions you put to it and the replies it gives. It does not reach two other places your words can go. A conversation handed to a human operator in live chat is stored in full, including what you write after the handover, because the operator has to be able to read it. Messages exchanged through a connected messaging channel — WhatsApp, Messenger, Instagram — happen on that platform and follow its retention as well as ours. Both are kept for the periods our Data Retention Policy sets for them, and neither is affected by the choice below — except that a closed live-chat conversation is deleted sooner when the site's own period for conversation text, described below, is shorter than the live-chat period. Each site is configured with one of three storage settings:

• No text retained — the wording of your question and the assistant's reply is never written down, and neither is the content or the name of any document you attached. What remains is the visit record described in section 2: counts and timings (how many messages, how fast the reply came, which model answered), together with the technical details and the coarse location listed there. This setting governs the wording of the conversation; it does not switch off the visit record.
• Problem turns only — the default. Text is kept only when the assistant could not answer confidently, so the owner can find and fix the gap. Successfully answered turns store no text at all.
• Full transcript — every turn is kept, so the owner has a complete record of the conversation.

Whichever setting applies, the retained text is automatically erased after a retention period and the underlying analytics record is deleted after a longer one. Both periods, the range a website owner may choose the text period within, and the reason the longer period bounds the shorter one, are stated in our Data Retention Policy. If you want to know which setting a particular site uses, ask that site's operator — they are the Data Controller for your conversation.

9. Data Breach Notification

In the event of a personal data breach in data we control that is likely to result in a risk to your rights and freedoms, we will notify the relevant supervisory authority within 72 hours of becoming aware of it, in accordance with GDPR Article 33. For personal data we process on behalf of a Customer, for example conversations on its website, we notify the Customer without undue delay and no later than 72 hours, and it is the Customer's duty to notify its authority. If the breach is likely to result in a high risk to you, we will also notify you directly without undue delay.

10. Children's Privacy

The NovixAgent AI widget is not intended for children under the age of 13 (or 16 in certain European jurisdictions). We do not knowingly collect personally identifiable information from children.

11. Changes to this Policy

We may update this Privacy Policy from time to time. Material changes will be published on this page with a new "Last updated" date, and customers are asked in the dashboard to accept a new revision of the Terms of Service or the Data Processing Agreement.

12. Contact Us

Questions about this Privacy Policy? Email support@novixagent.ai or visit novixagent.ai/contact.