Privacy Policy — Emet
Effective: 2026-09-15 · Last updated: 2026-10-16 · Technical claims verified against the running system on 2026-08-05.
Hesed Assessoria em Software LTDA (“Hesed”, “we”) operates Emet, a computer-assisted translation platform at emet.ing / app.emet.ing — and, for organisations onboarded before the Emet domains existed, at app.hesedtranslation.com. This policy explains what personal data the platform holds about you, why, for how long, and what you can do about it.
It is written to be checkable. Where a statement describes what the software does, it describes what the software actually does today.
1. Two kinds of data, two different roles
The distinction matters, because your rights differ between them.
Customer Content — the documents your organisation uploads, the translations produced from them, translation memory, glossaries and style guidance. This belongs to the organisation that uploaded it. We process it on that organisation's instructions, as their processor (operador). If you are a translator working on a client's manuscript and you want that content deleted, the decision is the client's, not ours and not yours.
Account data — who you are, how you sign in, what you did in the platform. For this we are the controller (controlador), and the rights in §6 are yours directly.
Your rates and word counts sit in between, so it is worth being explicit: if you are a translator, reviewer or language manager, the organisation you work for sets your rate and pays you — Hesed does not. We are not your employer or client and we do not pay you. The platform calculates your payable words and shows them to you and to that organisation; the money is between the two of you. That data is therefore held on the organisation's instructions, and a question about what you are owed goes to them, not to us.
2. What we hold about you
| What | Why | |
|---|---|---|
| Identity | name, email address | to identify you, address you, and send account email |
| Credentials | password (stored only as a bcrypt hash — never the password itself), optional two-factor secret and backup-code hashes, optional passkey public keys | to sign you in securely |
| Sessions | each active session: creation time, expiry, last activity, IP address, browser user-agent | so you can see and revoke your own devices, and so idle sessions expire |
| Messages from our contact form | if you write to us through the form on emet.ing: your name, your organisation, your email, the topic and your message (and the campaign labels of the link you came from, if any) — before you have an account | to answer you; read only by us |
| Where you signed up from | if you created your account from a campaign link: the link's campaign labels (utm_source, utm_medium, utm_campaign or ref), read from the link itself — no cookie, nothing stored in your browser | to learn which of our outreach reaches people; seen only by us |
| Membership | which organisations you belong to, your role in each, and your per-word rates where you are paid | to decide what you may see and do, and to calculate what you are owed |
| Work you produce | every translation version you author, with your identity and timestamp | this is the point of the product: an audit trail of who translated what |
| Comments | text you write on segments, with your identity | collaboration |
| Activity log | sign-ins, assignments, status changes, administrative actions | security, and answering “who changed this?” |
| Time on files — only if your organisation switches it on | per file and day: the time you actively worked on it in the editor, and short pauses (up to 3 minutes each) counted when you came back to it. Never what you typed, what is on your screen, or other tabs and apps. The editor tells you whenever it is on, and you can see your own figures on your dashboard | your organisation's planning and quotes, and seeing where someone needs help — not calculating pay |
| API tokens | name, creation and expiry, hash of the token (never the token) | for scripts you choose to authorise |
| Billing details, if you buy a plan | the buyer's name, email address and billing address, and their purchase history — received from Paddle, not collected by us | to provision and support the subscription. No card number is ever among it — see §4 and Subprocessors §9 |
We do not use advertising identifiers or advertising cookies. We do not sell personal data, and we do not share it for advertising — there is no advertising here.
Cookies. Inside the application the only cookie we set is the session cookie that keeps you signed in; we run no third-party product analytics. When you buy or manage a subscription the checkout is Paddle's, and Paddle sets its own cookies on that page to complete the transaction and to detect fraud. That is Paddle's processing under Paddle's own privacy notice, not ours — but it happens because we sent you there, so we say so.
Sensitive data. The platform is not designed for special-category personal data and you should not put it in. Note that the subject matter — Scripture and religious commentary — is not personal data about you; your religious beliefs are not inferred, recorded or processed by our handling of it.
3. Why we are allowed to hold it
Under the LGPD (Lei 13.709/2018) and, where it applies, the GDPR:
- Performance of a contract — your account, your assignments, your pay calculation. Without this data the service cannot be provided to you.
- Legitimate interests — security (the activity log, session records, sign-in throttling), keeping the service running, and preventing abuse. We have kept each of these to what the purpose needs.
- Legal obligation — where record-keeping is required of us.
We do not rely on consent for anything necessary to run the service, so there is no consent for you to withdraw and no service that stops working if you decline something. Optional features (two-factor authentication, passkeys, API tokens) are simply optional.
4. Where your data goes
Primary storage: São Paulo, Brazil, on a server operated by Hostinger.
Some processing happens outside Brazil. The full list, with what each party receives, is in Subprocessors — please read it, it is short and specific. In summary:
- Anthropic (US) and Google (US) receive segment text for AI drafting and quality review, on every project whatever the language pair. They do not receive your name, your email, your organisation, or any account data.
- Backblaze (US) holds nightly backups, which do include account data, retained 14 days. They are encrypted before upload with a key Backblaze does not hold, so Backblaze stores your data without being able to read it.
- Sentry (EU) receives software error reports, configured not to collect personal data. Moved from the United States to Sentry's European data region on 2026-09-10.
- Brevo (EU) delivers our account emails only to addresses hosted by Outlook.com (outlook.com, hotmail.com, live.com, msn.com), because Microsoft refuses mail from our server directly. For those people it receives the email itself: your address and name, and the message — an invitation names your workspace, a password reset carries a one-time link, an assignment names the project and files. Since 2026-10-15.
- Paddle is the Merchant of Record for subscriptions. When you buy a plan, Paddle receives your name, email address, billing address, any tax or VAT identifier, and your payment details. Card details go to Paddle, never to us — we do not see, transmit or store a card number. Paddle uses that data as its own controller for the tax, invoicing and anti-fraud obligations it takes on as seller of record. This is the only place in the platform where financial personal data exists at all, and it is not with us. See Subprocessors §9. The flow runs both ways: because you contract with Paddle rather than with us, Paddle passes back the name, email address, billing address and purchase history we need to provision your subscription, which we then hold as our own controller (§2). A card number is never part of that. *Which Paddle entity, and therefore which country, depends on where you are. Under Paddle's standard Master Services Agreement (definition 1.1, read 2026-09-09), a buyer in the United States contracts with Paddle.com Inc (Astoria, New York); a buyer anywhere else contracts with Paddle.com Market Ltd* (30 Old Bailey, London). So a US buyer's payment data is held in the United States, not in the UK — see Subprocessors §9 for the full table. We are on Paddle's standard agreement, not a negotiated one.
Account email involves no third party — unless your mailbox is on Outlook.com. Invitations, password resets and notifications are sent by our own mail server in São Paulo. The one exception is the Brevo relay above, used only for Outlook.com-hosted addresses; an organisation on Microsoft 365 with its own domain, like every other address, is delivered by our own server.
What that adds up to, stated plainly. Look down that list and notice what is not in it: no third party outside Brazil receives your name, your email address or your organisation together with your work. The AI providers get sentences to translate. Backblaze gets a file it cannot open. Sentry gets stack traces. Paddle gets what you typed into Paddle's own checkout, under your own relationship with Paddle. Brevo, for Outlook.com addresses only, gets the notification emails themselves — your name and address, and the workspace or project they concern — but never your documents or translations; it processes them in the European Union, which Brazil recognises as adequate.
So for most of what happens here there is no international transfer of personal data to justify, because there is no personal data in what crosses the border. The exception is honest and worth your attention: if you upload a document that names people, those names are in the text, and the text goes to the AI providers like any other segment. That is your content and your decision, and Terms of Service §4 puts it in front of you before you upload rather than afterwards. The full reasoning, transfer by transfer, is in the Data Processing Agreement §7.
Why we do not cite the ANPD's standard clauses. They are the usual answer here, and we are deliberately not leaning on them: as at the date above the ANPD had recognised no foreign standard contractual clauses as equivalent to its own, so the European clauses that our providers do carry would not do the job, and none of them offers Brazil's. Describing what actually leaves the country is worth more to you than citing a mechanism we do not hold.
5. How long we keep it
Automatically deleted on a schedule (from api/app/config.py; the sweep runs weekly via infra/scripts/cron-retention.sh):
| Data | Kept for |
|---|---|
| Activity / audit log | 90 days |
| Webhook delivery records | 30 days |
| Search and retrieval logs | 30 days |
| AI usage and cost records | 365 days |
| Time on files | 365 days |
| Contact-form messages | 365 days |
| Password-reset tokens | 7 days |
| Organisation data exports | 30 days |
| Backups | 14 days |
Kept until deleted, not on a timer, because deleting them would destroy the work product or the account: projects, files, segments and translation versions; translation memory and glossaries; user accounts and organisations. These go when the organisation deletes them or when the organisation itself is deleted.
Sessions expire on their own: 7 days at the outside, or 12 hours without activity, whichever comes first. You can revoke any session immediately from your profile page.
6. Your rights, and how to actually use them
Under the LGPD (Art. 18) and the GDPR you may ask for confirmation of processing, access, correction, anonymisation or deletion, portability, and information about with whom we share data. Concretely:
- Get a copy of everything — sign in and use Security → Download my data (
/me/export). You get a ZIP immediately containing your profile, sessions, API-token records, two-factor status, comments, your activity log and every translation version you authored. Password hashes, two-factor secrets and token hashes are deliberately excluded, so the file is safe to keep. This is self-service — you do not need to ask us and you do not need to wait. - Get a copy of the whole organisation's data (administrators) — a client administrator can request a full organisation archive from Organisation settings → Your data and download it there. Also self-service; also no waiting on us.
- Correct your details — your profile page, directly.
- Delete your account — write to
privacy@emet.ing. Two honest caveats: (a) translation versions you authored are Customer Content belonging to the organisation and are part of its work product's audit trail, so removing your identity from them is possible where removing the work is not — tell us which you are asking for; (b) whatever we delete persists in backups for up to 14 days (§5) before rolling out. - Object, or ask us to restrict processing —
privacy@emet.ing. - Complain — to us first, please, at
privacy@emet.ing; and to the Brazilian data protection authority (ANPD) or your local supervisory authority if we do not resolve it.
We will respond within 15 days for LGPD requests and within one month where the GDPR applies.
Identity check: we will verify that a request comes from you before acting on it. We will not accept a deletion request for an account from anyone but its holder or that organisation's administrator.
7. How your data is protected
Stated accurately, including where the answer is “not yet”.
In place today:
- All traffic encrypted in transit (TLS 1.2+).
- Passwords stored only as bcrypt hashes.
- Two-factor authentication available to every user (authenticator app or passkey), and your organisation's administrator can require it for everyone.
- Sign-in throttling: ten wrong passwords in a row locks that email address for 15 minutes, so a password cannot be guessed at scale.
- Sessions expire absolutely at 7 days and after 12 hours idle.
- Strict separation between organisations, enforced in the database layer rather than left to individual queries, with an automated test that fails if a new table is added without it.
- Role-based access: editors and reviewers see only the files assigned to them.
- Off-site backups, encrypted by us before they leave the server, so the backup provider stores blobs it cannot read. A full copy is taken nightly and the database transaction log is archived continuously, which narrows how much recent work a failure could cost from a day to minutes. The decryption key is held off-site; the server has only the half that can encrypt. Recovery — including to a chosen moment in time — is rehearsed against the real encrypted backups rather than assumed.
- Error monitoring configured not to collect personal data.
- Encryption at rest. On both deployments —
app.emet.ingandapp.hesedtranslation.com— the database, object store and cache sit inside a LUKS2 volume (AES-XTS, 512-bit key), each deployment in its own separate container. Be clear about what that does and does not do: the key is held on the server, so it protects a disk that is decommissioned, removed or seized. It does not protect against someone who compromises the running machine, because a running machine can read its own disk. That is the same protection, and the same limit, as the cloud-provider encryption used by comparable platforms — a running instance reads plaintext there too.
Not in place, so you know:
This is disclosed in Subprocessors §1 and is being worked on. No system is perfectly secure and we would rather tell you what ours does not do than let you assume.
8. If something goes wrong
What we commit to depends on which of the two roles in §1 we are in, because the law puts the clock in different places.
Where the incident affects Customer Content, we are your organisation's processor. We will notify your organisation without undue delay and in any case within 48 hours of confirming that an incident has affected personal data you control, with enough detail for you to meet your own obligations. Notifying the ANPD and the affected people is then the organisation's to do as controller — Resolution CD/ANPD nº 15/2024 gives a controller three business days from confirming that personal data was affected — and we will help you do it.
Where the incident affects account data we control — your identity, your sign-in records, the things §1 lists as ours — we notify the affected people and, where required, the ANPD, without undue delay and in any case within 72 hours of becoming aware.
9. Children
Emet is a professional tool. It is not directed at children, and we do not knowingly create accounts for anyone under 18.
10. Changes
We will post any change here with a new “last updated” date, and will tell affected organisations directly before a change that materially reduces your rights or widens our processing.
11. Contact
Hesed Assessoria em Software LTDA Rua Leroy, 119, Jd. Monsenhor Rossi, Limeira-SP, 13484-229, Brazil · CNPJ 15.025.740/0001-50 Privacy and data-protection requests: privacy@emet.ing Data protection officer / encarregado: Nielsen Tomazini, reachable at privacy@emet.ing. We publish a role address rather than a personal one so the channel survives any change of person.