Frequently asked questions

No. Zero third-party API calls per anonymization. This is the single hard invariant Idonym is built around.

The AI model that helps detect personal data is an open-weights model running on the same EU server as the web application. The model has no internet access. Your document travels from one program on our server to another program on the same server during processing. It does not leave the machine, and it is never relayed to a cloud AI provider.

This is why Idonym's pseudonymisation never reaches a cloud AI before you choose to paste anything into ChatGPT, Claude, Gemini, or any other external AI: the pseudonymisation itself doesn't touch them.

Inside the European Union, end to end.

• The application server and the AI model run in a hardened data centre in Germany (Hetzner). Full-disk encryption (LUKS) at rest.
• The database is a managed PostgreSQL instance hosted within the EU (Neon), replicated within EU regions.
• Your interface, your account, and every byte derived from your documents stay under EU jurisdiction.

We do not operate a US-hosted tier, and we will not introduce one without an updated Privacy Policy and a clear notice.

You can recover your account, but mappings from before the reset are permanently unreadable. This is by design.

The key that decrypts your mappings (the MEK) is derived from your password. We never store the password in plain text, and we never store the MEK on disk. That is the same property that prevents the Idonym team, or anyone who steals our database, from reading your mappings. The trade-off is that we cannot recover what we cannot read.

Practical recommendation: use a password manager. Treat the Idonym password the way you would treat the master password to your client files.

No, not in any normal operation of the service.

• Original documents are held in the server's RAM for seconds during processing and then actively overwritten with zeros. They are never written to disk.
• The anonymized output (text and rendered file) is stored encrypted at rest, locked with the same password-derived key as the mapping below. We do not have the key.
• The encrypted mapping that lets you reverse pseudonyms is stored in the database as AES-256-GCM ciphertext, locked with a key derived from your password. We do not have the key.
• Restored file bytes (if you keep them after Restore) are stored with the same per-user encryption.

• Original document: seconds. RAM only; zeroed after processing.
• Anonymized output: stored encrypted (AES-256-GCM, under your password-derived key) until you delete the session or your account.
• Encrypted mapping: until you delete the session or your account.
• Restored file bytes: until you click Remove, delete the session, or delete your account.
• Restore verification record (counts and leftover-pseudonym scan): kept indefinitely as round-trip proof, even after you click Remove. It contains numbers, not text.
• Audit log: kept indefinitely (append-only, enforced by the database). Survives account deletion as orphaned metadata. No document content is ever written to it.
• Bug-report attachments (screenshots or files): auto-purged after 30 days. Descriptions and metadata stay.

A full retention table is in the Privacy Policy.

Idonym accepts DOCX, PDF, and plain text for upload, plus direct paste for short inputs. DOCX restore preserves the original formatting (bold, italic, fonts, tables, headers, footers) exactly; the pseudonyms appear in the same place and the same style as the original entities. PDF supports line-level anonymization.

If your firm needs a format we don't yet support (e.g. RTF or scanned PDFs that require OCR), tell us through the in-app bug widget; format support is on a public roadmap.

Restore is the second half of the round-trip. Without it, pseudonymisation is a one-way street: you get a de-identified file you can review and paste into an AI tool, but you cannot send the AI's output back to your client, because every name in it is fictional.

Workflow:

1. Anonymize your document in Idonym. Download the clean version.
2. Paste it into the AI tool of your choice. Edit, review, finish your work.
3. Upload the AI-edited result back into the same Idonym session.
4. Idonym deterministically swaps each pseudonym back to its original value and produces a client-ready file in the original format.
5. A verification panel shows: substitution count, and any pseudonyms that survived the round-trip into the restored output (a safety net so no fictional name accidentally reaches your client).

Restore is deterministic find-and-replace using the encrypted mapping. There is no AI in the loop on the return path, and there is no third-party call. This is the workflow Idonym is built around. It is also the reason Idonym replaces each entity with a consistent, deterministic role-tag pseudonym (PARTY-A, COMPANY-A d.o.o.) rather than an indistinct blackout block: a unique, labelled pseudonym is what makes an exact reverse substitution possible.

Yes. Idonym ships with jurisdiction-specific detection for Croatian and English at parity.

Croatian entities recognised include:

• OIB (Osobni identifikacijski broj), with checksum validation, not just shape matching.
• MBS (Matični broj sudskog registra) for legal entities.
• Court file numbers in Croatian formats (e.g. P-1234/2024, Pn-567/2023, and other recognised stems).
• Land-registry triples (cadastral municipality / parcel / sub-parcel).
• Croatian person names, addresses, IBANs, and case-specific identifiers.

English / multilingual coverage handles names, organisations, addresses, dates, and document-type-aware patterns through a separate detector.

Wave-2 jurisdictions (German first) are on the public roadmap.

Yes. Every processing session has a downloadable audit record.

From the session's review page you can export a JSON audit log with the timestamps, document format, page count, per-entity-type detection counts, and the substitution / restore round-trip outcome. The export contains metadata only, no document content. You can attach it to your case file or hand it to a client who asks how you used AI on their matter.

The audit log itself is enforced as append-only at the database level (a BEFORE UPDATE OR DELETE trigger blocks any modification). Even with admin database access, the trail cannot be silently rewritten. That property is exactly what makes the export credible as a compliance artefact.

Per-session delete. Every row on the dashboard has a trash icon. One click and a confirm dialog wipes the encrypted mapping, any restored bytes, and all per-session artefacts in a single database transaction. There is no soft-delete tombstone for content, no retention window; it is gone immediately. The audit log records the deletion event itself.

Restored-bytes-only delete. After Restore, the verification panel has a Remove button. This clears the restored file bytes but keeps the verification record (counts and leftover scan) as proof the round-trip was clean, so you can demonstrate after the fact that no real names leaked into what you sent out.

Account deletion. From the Settings page, you can delete your account self-service. This cascades through the database: profile, all sessions, all mappings, all restored bytes, all login tokens. The only things preserved are (a) audit-log entries, intentionally kept as orphaned metadata under GDPR Art. 5(2) and 30, no longer linked to your identity, and (b) bug reports you filed, with the foreign key to your user nulled out.

If you want a full export before deleting, your per-session audit-log JSON is available from each session, and you can write to shield-support@delegee.ai for an account-level export under your right to data portability (GDPR Art. 20).

Yes, through an encrypted bundle. A completed session has a Share action that packs the anonymized document and its mapping into a single encrypted file (a .idonym bundle — previously .shieldpkg; old files still open) and generates a one-time access code.

1. Send the bundle file and the access code to your colleague through separate channels, for example the file by email and the code by phone or chat.
2. Your colleague opens Idonym, chooses Import shared bundle on their dashboard, picks the file, and enters the code. They see who shared it and when, then confirm.
3. The bundle becomes a normal session in their own Idonym account, re-encrypted under their password-derived key. They can review it, work the anonymized text against an external AI tool, and run Restore to recover the real entities.

The bundle is sealed with AES-256-GCM and the access code is required to open it; Idonym shows the code only once. The file alone or the code alone is useless, so sending them through separate channels keeps the share safe. Idonym never brokers the transfer: nothing about the share is stored on our servers, there is no shared cloud folder, and the bundle never contains your original document. It works even if your colleague is at a different firm.