Sensitive content.
Several layers of protection.

1. Your text is processed on the application server

When using the cloud app, you send text or files from your browser to the application server. It reads the document, detects personal data and produces the result. Scans are converted to text there using OCR. Detection uses locally installed language models, without sending document text to an external AI service.

The server can read the original text during this processing. “Local language models” here means local to the server. Processing therefore does not take place entirely in your browser. HTTPS and secure session cookies are required in the production configuration to protect the connection.

Source files are used temporarily and then cleaned up. The complete source text and detection positions are not stored as a permanent source in your case file. They may be temporarily available for processing and your review screen.

2. Encryption protects stored content

By default, the app encrypts results, reversal keys and project identity memory with a server key. This stored data cannot be read without the corresponding key. The default encryption uses Fernet.

With pseudonymisation, links between original data and pseudonyms deliberately remain available for restoration. These links are also personal data and are stored encrypted. Anonymisation does not store a reversal key or identity memory for that processing.

Extra storage protection with your own vault key

An organisation administrator can enable a workspace key of their own, also known as BYOK. The browser then additionally encrypts stored document content and key mappings with AES-256-GCM. The key file is not stored on the server. You import it into your browser to open the content.

This extra layer protects stored content. During detection and OCR, the server still sees the original text. The platform also supplies the browser code. This is therefore not complete end-to-end encryption or absolute protection against every form of provider access.

Keep a secure backup of your vault key outside the app. Other authorised members need the same key; share it through a secure channel. If all copies are lost, we cannot restore content protected by that key. The vault key is different from the reversal key used to undo pseudonyms.

Account details, access permissions, billing and technical usage data remain fully or partly readable by the server. Encrypted document content therefore does not mean the entire database is unreadable.

3. Access is checked per workspace

An account can access the workspaces for which it is authorised. Roles and additional document permissions govern viewing, editing, reviewing and exporting, among other actions. The server checks these permissions when data is requested or changed.

Passwords are hashed with an individual salt. The app supports two-factor authentication with an authenticator and single-use recovery codes. Session cookies are inaccessible to JavaScript; additional checks protect requests from misuse originating on other websites.

Organisation administrators decide which members have access. Use a separate account for each person, enable two-factor authentication and revoke access as soon as it is no longer needed.

4. You choose how long results and keys are retained

You can set separate retention periods for results and reversal keys. By default, neither has automatic deletion configured. That content is then retained until deletion. If you want a shorter storage period, deliberately choose one that matches your purpose and obligations.

With a configured period, the app deletes expired content. A key may expire before a result, or vice versa. After key mappings are deleted, you can no longer restore pseudonymised text using that key. Project memory is also covered by the retention period for keys.

Shortening a period can also delete existing content. Extending it later does not bring deleted content back. Technical administration and billing are not automatically covered by your document retention period.

Deletion from the app does not erase previous downloads or copies held by other services. Backups have their own retention policy; the precise periods and restoration process will be established before use.

5. Hosting and operational arrangements

The intended hosting for the app is Zerops in Prague, region prg1, Czechia, European Union. OVH is planned for the DNS service that points the domain name to the hosting. This describes the chosen direction; the actual production setup and processing locations will be confirmed before launch.

What we will establish before use

The data processing agreement and its annexes describe the technical and organisational measures, including at least:

• the actual hosting region, enabled subprocessors and any international transfers;
• who has production and support access, for what purpose and under which confidentiality obligations;
• backup protection, retention periods and restoration procedures;
• the deletion procedure when a retention period or the agreement ends;
• contacts and procedures for security incidents, personal data breaches and data subject requests.

The technical architecture alone does not confirm these operational measures. The outstanding arrangements in the data processing agreement will therefore be completed before real documents are processed.

If you later choose a cloud integration for import or export, the app exchanges data with that service for that purpose. Separate services are also involved in payments and any external sign-in. The final arrangements cover which services are enabled and what data they process.

6. Sharing safely also starts with your final review

Security protects processing and storage. Whether a result can responsibly be shared also depends on its content. Automatic detection may miss personal data or flag it incorrectly. Someone may also remain identifiable through context, even if a name has been removed.

• Only process data that you are allowed and need to use for your purpose.
• Review the result, including context and scan recognition errors, before sharing it.
• Store reversal keys securely and separately from the documents you distribute.
• Set appropriate retention periods and delete content you no longer need.
• Limit access to authorised people and secure your own devices and downloads too.

Pseudonymisation is reversible and remains personal data processing. You must also assess anonymised results for identifiability. We do not guarantee that all personal data will be detected automatically and do not present the app as a GDPR-certified product.