Privacy Policy

1. Introduction and scope

POPRIX is a support desk run by AI agents: the agents read the organisation's own policy, draft answers to customer cases over email, WhatsApp, Telegram and website chat, and take actions in the systems the organisation has connected.

This policy covers poprix.ai, the support desk itself and every channel connected to it. It does not cover third-party sites or services that a link points to.

Where a signed agreement exists between POPRIX and the organisation — including a data processing agreement — that agreement prevails over this page. This page is not legal advice and does not replace it.

3. The legal basis for processing

For data where POPRIX is the controller, and for data subjects in the European Economic Area, processing rests on the following bases:

• Performance of a contract — Providing the service to whoever has contracted for it, running the account, billing and support.
• Consent — Marketing communications, and any use this policy specifically attributes to consent. Consent can be withdrawn at any time, and we stop relying on it from that moment.
• Legitimate interests — Securing the platform, preventing fraud and abuse, and diagnosing faults. The interest is weighed against the data subject's rights, and where those rights prevail the processing does not happen.
• Legal obligation — Keeping records the law requires us to keep, and responding to a lawful demand from a competent authority.

Data subjects in Israel are covered by the Protection of Privacy Law 5741-1981, as amended by Amendment 13 which came into force on 14 August 2025, and by the Protection of Privacy (Data Security) Regulations 5777-2017. Amendment 13 moved Israeli law substantially closer to the European standard and widened the powers of the Privacy Protection Authority.

4. The categories of data collected

The system processes the following categories. The list is closed: data that is not needed for one of the purposes in section 5 is not collected.

• Identity and contact details of the person writing in — Name, email address and phone number, so far as the person or the channel they wrote through supplies them.
• The content of cases — The messages themselves, the replies sent, and transcripts of voice calls where a voice channel is enabled.
• Attachments — Documents and images sent in with a case — an invoice, a photograph of a product, a screenshot of an order — in order to resolve that case.
• The organisation's knowledge documents — Policies, procedures, catalogue and the content of the organisation's public website, which is what the answers are drawn from.
• Account data — The email addresses of authorised users, the permission level each one holds, and sign-in records.
• Technical usage data — IP address, browser type, timestamps, response times and error records — for security, fault-finding and performance. Where the chat widget sits on the organisation's own site it also records the page the visitor was on, the page that sent them there, and any campaign identifiers already present in that page's address (utm_source and its family, gclid, fbclid), so the organisation can tell which of its own campaigns a conversation came from. These are read from the address bar of a page the organisation controls, not from any advertising network, and they are disclosed to nobody.

Cookies

The four usual categories, and what is true of each one here:

• Essential — in use — The sign-in cookie (poprix_session), without which you cannot stay logged in. There is no way to switch it off and keep using the platform.
• Functional — in use — The language preference (poprix_locale), so a page comes back in the language you chose.
• Performance — not in use — We set no third-party measurement or traffic-analysis cookies in the product.
• Advertising and targeting — not in use — There are no advertising pixels in the product, and we share nothing with advertising networks.

You can tell your browser to refuse cookies, or to warn you before one is set. Refusing the essential cookie will prevent you signing in.

5. The purposes of processing

The data is processed for these purposes and no others:

The data is not sold or rented to anyone, and it is not used for targeted advertising — ours or anyone else's.

6. Artificial intelligence: how an answer is produced, and what happens to the data

The product drafts answers with language models, so it should be clear exactly what is sent where.

When a case arrives, the system retrieves the relevant clauses from the organisation's knowledge base and sends them, together with the message, to the model to draft an answer. The answer comes back, is checked against the policy rules, and only then is it sent or held for approval. The record of the case, the answer and the reasoning is written to the database in the European Union.

Model training

POPRIX does not train models on its customers' data, does not sell it, and does not hand it to anyone for training.

The model providers the system calls state in their API terms that data submitted through the API is not used to train their models. That is a description of those providers' published terms, not a guarantee POPRIX gives on their behalf: the providers are named in the sub-processor list below so that their terms can be checked. POPRIX contracts with them on ordinary commercial API terms, not under bespoke enterprise agreements.

Control over what goes out stays with you: you decide which answers are sent automatically and which wait for approval, and you may review and edit anything the system drafts before it is sent. A financial action — a credit, a refund, a change to an order — does not take effect above the ceiling you set without a person approving it.

7. Retention and deletion

Each category of data has its own retention period rather than one blanket figure. The organisation, as database owner, sets those periods in its agreement; below is the structure, and the floors that cannot be shortened:

• Cases, messages and replies — Kept while the case is open, and after it closes for one year by default, or for the period agreed with the organisation. At the end of that period the record is deleted from the live system. A year, because a customer complaining a month after they bought something is precisely the question a support desk exists to answer.
• Attachments — Deleted before the case record itself: 180 days by default, against a year for the correspondence. An attachment is a photograph of an invoice, of a damaged product and sometimes of an identity document — the bytes are the part whose continued existence is an exposure rather than an asset, so they go first.
• Knowledge documents — Kept for as long as the organisation chooses to hold them in its knowledge base, and never deleted by age. Removing a document deletes it and the embeddings derived from it. Age is the wrong measure here: a returns policy nobody has edited in three years is usually the most relied-upon document in the set, not the most stale.
• Audit records — Kept for at least 24 months — the floor regulation 10(d) sets — and not deleted before it, even where erasure of the underlying data has been requested. An audit record says who did what and when, not what a case said.
• Account data and sign-in records — Kept while the account is active. Closing the account — from the account screen, by typing the organisation's own name — marks it closed and stops anyone signing into it; the data is then kept for 90 days for accounting, dispute resolution and legal obligations, and purged after that. A session already open on another device is not torn down, and expires on its own within seven days. Audit records are separate and keep their own statutory period.
• Single-use sign-in tokens — Expire within minutes, and the record itself is purged after 30 days — long enough to see how many links one address asked for, and no longer.
• Backups — Backups are managed by Supabase and retained for seven days. A backup is not a live database and is not searchable. So anything deleted from the live database is gone from the backups within seven days as well — we state that number because a deletion promise that stops at the live database is not a deletion promise, and the backup window is the question an auditor asks next.

The retention periods above are the policy we work to. The scheduled mechanism that enforces them is deployed and currently runs in counting mode ahead of being switched on: it reports what would be deleted and deletes nothing. Until it is switched on, deletion happens on request. We put it this way rather than in the present tense, because a page describing a mechanism that is not yet running is precisely the kind of claim this page was rewritten to remove.

A record deleted from the live database may persist in a backup until that backup cycle ends, and then it is gone from there too. We say so rather than imply otherwise, because every cloud provider that keeps backups is in the same position.

8. Where the data sits, and what crosses a border

The precise version, component by component:

Storage of record — the database, customer files and backups — is in the European Union. The application runs on Vercel in Frankfurt (fra1); the database is Supabase Postgres in eu-central-1, Frankfurt; customer files are in Supabase Storage in the same region; and backups are managed by Supabase in the European Union.

Model inference is not in the European Union. Replies are drafted by Anthropic's Claude models, served from the United States, and a Google Gemini fallback is served from Google's global endpoint — so a message may be processed outside the EU. Storage of record is in the EU; inference is not.

POPRIX is operated from Israel, so support staff reach the platform from Israel. A separate fetcher runs in Israel to read Israeli websites that block traffic from Europe — it reads public web pages and is not in the path of customer messages.

Israel holds an adequacy decision from the European Commission, reconfirmed on 15 January 2024. In practice that means personal data can move from the European Economic Area to Israel with no Standard Contractual Clauses and no additional transfer mechanism. Against a US processor, for whom clauses and a transfer impact assessment are required, that is a real difference rather than a form of words.

Onward transfers — to the United States sub-processors in the list below — rest on the appropriate contractual basis with each provider. Some movement of data follows from the service itself: a message on WhatsApp or Telegram travels over that channel's own infrastructure, as any use of those channels requires.

9. Sub-processors

10. Disclosure to third parties

Beyond the sub-processors listed above, data is disclosed only in these cases:

• Service providers — Providers who help us run the service, to the extent their task requires, and only where they are bound to confidentiality and to using the data for the purpose it was given to them for.
• Legal requirement — Disclosure required by law, by a court order or by a competent authority, and to protect rights, personal safety and against legal liability. Where the law permits, we will tell the organisation before making such a disclosure.
• Change of ownership — A merger, acquisition or transfer of the business — in which case notice is given in advance, and the data stays subject to a policy no less protective than this one.

Beyond that the data is not disclosed. It is not sold, not rented, and not passed to advertisers or data brokers.

11. Information security

The controls that are actually in place. The full detail is in the Regulation 15 security annex, which we send at the request of a customer's security team.

• Encryption — TLS in transit, and AES-256 at rest. Encryption keys are managed by the platform providers, Vercel and Supabase. We do not operate customer-managed encryption keys (CMEK).
• Network isolation — The database is not open to the public internet. The application reaches Supabase Postgres over a TLS-encrypted, authenticated connection through Supabase's connection pooler, and no other network is authorised against it.
• Signing in — Sign-in with a Google account or with a single-use link sent to an email address. Anyone can open an account with a verified address, and a new account gets its own organisation; an address that already belongs to an existing organisation is checked against that organisation's named list at every sign-in.
• Permissions — Three levels — owner, admin and member — which decide what can be seen and what can be approved. The session cookie is signed and verified on every request.
• Secret management — Keys and passwords are held in Vercel's encrypted environment variables and injected into the service at runtime. None is in the code or in the git repository.
• Customer files — Customer files are held in a private Supabase Storage bucket in the European Union, reachable only by the service. No customer file has a public address.
• Tenant isolation — The platform is multi-tenant. Each organisation's data is isolated by a tenant identifier that the application sets and scopes every query and every channel to, so one organisation's desk never sees another's.
• Backup and recovery — The database is a managed Supabase Postgres with automatic daily backups. A restore is carried out on request.
• Audit records — Every action an agent takes is recorded with a timestamp, the identity behind it and the reasoning. The record is append-only and hash-chained, so any alteration to it can be detected.
• Operational guardrails — A spending ceiling per agent, and human approval for any financial action above it. These are controls enforced in code, not statements of policy.

We will engage an external security firm for penetration testing and security assessments. No test has been carried out yet and no report exists today. Once one is complete, the report will be available to download through your account manager in the product, on signature of a mutual NDA, as is standard. POPRIX does not hold a SOC 2 or ISO 27001 certification today.

No method of transmission over a network and no method of storage is 100% secure. We use accepted, current measures, and we do not promise absolute security.

12. Data subject rights

The rights below apply to data for which POPRIX is the database owner. For an organisation's own end customers' data, the organisation is the database owner — see the note at the end of this section.

Under the GDPR (European Economic Area and United Kingdom)

• Access — To be told whether data about you is being processed, and to receive a copy of it.
• Rectification — To have inaccurate data corrected and incomplete data completed.
• Erasure — To ask for deletion, subject to records the law requires us to keep.
• Restriction — To ask that processing be paused while a dispute about accuracy or about the basis for processing is resolved.
• Objection — To object to processing based on legitimate interests, and to marketing at any time and without giving a reason.
• Portability — To receive the data you provided in a structured, machine-readable format, and to move it to another provider.
• Withdrawal of consent — To withdraw a consent you gave, without affecting the lawfulness of processing carried out before.

Under the Israeli Protection of Privacy Law

A data subject in Israel additionally has:

• The right of inspection (עיון) — To inspect the data held about them in the database.
• The right of correction (תיקון) — To ask that data which is incorrect, incomplete, unclear or out of date be corrected, changed or completed.
• The right of erasure (מחיקה) — To ask for data to be deleted, to the extent Amendment 13 provides and subject to its exceptions.

Under the CCPA (California)

A California resident has the following rights:

• To know — Which categories of personal information were collected, from whom, for what purpose and who they were disclosed to.
• To delete — To ask for deletion of the personal information collected, subject to the exceptions in the statute.
• To opt out of sale or sharing — We do not sell personal information and we do not share it for cross-context behavioural advertising. The product sets no advertising cookies and carries no advertising-network pixels.
• Not to be penalised — Exercising a right does not mean different treatment, a different price or a lesser service.

How to exercise them

One email is enough. We will respond within the period the law allows, and in any event within 30 days. We may ask you to verify your identity before we hand over data — so that one person's data is never given to somebody who is not them. sales@poprix.ai

If you wrote in as the end customer of a business that uses POPRIX, that business is the database owner. Please approach them; if you approach us, we will pass your request on and help them answer it, but we will not act on the data ourselves.

A data subject in Israel has the right to complain to the Privacy Protection Authority at the Ministry of Justice. A data subject in the European Economic Area has the right to complain to the supervisory authority in their country of residence.

13. Children, changes and contact

Children under 16

The service is not intended for children under 16 and we do not knowingly collect data from them. If you become aware that a child has given us personal data, tell us and we will remove it.

Changes to this policy

We will update this policy from time to time. The date at the top of the page changes with every revision, and for a material change — including the addition of a sub-processor — customers are told in advance.

Contact

For any question about this policy, and for any request to exercise a right, write to the contracting party named at the top of this page, at: sales@poprix.ai