Our commitment to your data

We believe a private conversation should stay private, and that whoever builds a messaging app has a responsibility to say clearly what it does with people's data, not to hide it in fine print.

We believe in data sovereignty: that a person's or a company's data belongs to them, and that deciding where it lives and who can touch it is part of that ownership. That's why weSmile can be installed on a company's own server (more on that below).

This page states only what weSmile's code does today. It isn't a marketing promise: it's a description, with the same update date as the Privacy Policy and the Terms and conditions, and it changes together with them if something changes.

Personal and business are kept apart: a company never sees its people's personal chats — not the owner, not whoever administers it, not the weSmile team.

Every company on weSmile has its own audit base: its records never mix with another company's or with anyone else's, and the company's owner chooses how long they're kept.

When a company audits or reviews something in its work chats, that is never secret: its people are told inside the app itself. No oversight happens behind anyone's back.

Let's say the uncomfortable part, because it's the one that matters: your regular messages are stored encrypted in the database, but with a key the server holds. That means weSmile can decrypt them — for example, under a court order. We'd rather say this plainly than promise something we don't do.

The exception is the Secret chat: there, the encryption is end-to-end — text and files leave each person's device already encrypted, and the server only holds something it can't open.

And here's the small print, because we'd rather say it: turning on the Secret chat, each person chooses whether their key is also held in escrow — encrypted with a weSmile public key whose private half lives on no server, only the administrator has it — or whether to keep no backup copy at all. Whoever chooses escrow can recover their chats through support if they lose their code, but whoever holds that private key could open those messages: that's end-to-end encryption with support-assisted recovery. Whoever chooses not to keep it gets end-to-end encryption with no asterisk at all — not even we can open it — with a real cost: if they lose their code and don't have the key on another device, those messages are gone for good.

This distinction isn't a footnote: it's the difference between «we store it encrypted to protect it» and «not even we can read it» — and now it's also each person's own choice, not a fixed default. The full detail is in the Privacy Policy.

weSmile can be installed entirely on a company's own server (the Private plan). There, that company's data doesn't pass through our database or our servers: it never leaves that company's own infrastructure.

That's data sovereignty in practice: whoever owns the information decides, literally, which machine it lives on and who gets to see it.

Two-factor authentication with an authenticator app, plus backup codes in case you lose the device you use it on.

App lock with a PIN, and with the device's own fingerprint or face recognition.

You can see all your open sessions and close them one by one, whenever you want.

Logging in, creating an account and requesting a password reset all have a rate limit: past a certain number of attempts, you have to wait before trying again.

When something asks whether an account exists (at login or when requesting a password reset), we answer with the same message whether it does or not: so no one can use those screens to find out who has a weSmile account.

Who is making a given request always comes from that person's signed session, never from something the browser sends along: there's no way to tell the server «I'm someone else» just by changing what gets sent.

Every piece that uses AI (building a bot, an appearance theme, replying in a chat) runs in an isolated flow with a closed list of what it's allowed to do, taken straight from the code: the AI doesn't invent new actions, it picks from the ones that already exist.

Whatever the AI returns gets re-validated on the server before it's saved or touches anything. A result that fails that check never runs.

A bot's keys and connection secrets never reach the AI: it's told to use a name (something like {{secretos.MI_CLAVE}}), and the server fills in the real value afterward, outside of anything the AI ever saw.

Two bits of fine print worth spelling out: whoever uses weSmile's free AI shares, in front of the outside provider, the same account weSmile itself uses as a platform (it isn't a separate account per person). And a bot's AI is paid for by whoever owns that bot, never by whoever writes to it.

weSmile reviews itself periodically and adversarially: the code is attacked looking for holes before someone outside does it first. Whatever turns up gets fixed, and gets its own regression test so it doesn't happen again.

In September 2026 one of those complete reviews was done across the whole application.

If you find something that looks like a security or privacy problem, write to this page's support email (it's also in Support). We'll look into it.