Privacy
Privacy policy
DirektText can process speech in different ways depending on your setup. Some routes use ready-to-use cloud transcription through DirektText infrastructure. Other routes use supported local models or bring-your-own-key providers where available.
Draft status
This privacy policy is a wireframe draft for legal review. It is written to be honest about known data routes and uses placeholders where launch details, retention periods, service providers, or legal bases still need final confirmation.
Last updated: 28 May 2026
The controller responsible for data processing is:
Tristan Ripke - Marketing und IT
Pestalozzistrasse 25
22305 Hamburg, Germany
Email: [privacy contact email]
DirektText is the product name. The final public policy must identify the natural person operating the Einzelunternehmen.
When you visit the website, technical request data may be processed to deliver the page, keep the site secure, and diagnose problems. This can include IP address, requested URL, time of access, browser and device information, referrer, security events, and server log entries.
Cloudflare may process request metadata as DNS, TLS, security, proxy/CDN, and download infrastructure. The final policy should describe the exact Cloudflare products enabled at launch.
Account and device-linking features may process email address, account identifiers, device-link session data, linked-device metadata, plan and entitlement state, usage counters, security events, and support-relevant account status.
Device credentials are used to connect the Windows app to the account. The final policy should describe the exact account fields, device metadata, and deletion/export behavior implemented at launch.
When you use ready-to-use cloud transcription capacity, audio and related request metadata may be sent from the app to DirektText infrastructure and then to selected transcription or text-processing providers. The purpose is to provide transcription, notes, summaries, cleanup, or other selected output modes.
Known planned provider categories include hosting, edge/security, email, billing, transcription, and text-processing providers. The final policy must state which providers are active, what data they process, where processing happens, and how long audio, transcripts, and metadata are retained.
The Windows app may store local history, transcription text, audio copies, source file names, file paths, settings, recovery checkpoints, and local diagnostic logs on your device. Some credentials, such as device tokens or provider keys, are intended to be stored with Windows user-level protection.
Local data can remain on the device after cloud access changes unless the app deletes it, retention cleanup applies, or the user removes it. The final policy should match the implemented local retention and deletion controls.
Supported local model routes are intended to process selected work on the user device. Bring-your-own-key routes use provider credentials configured by the user and send data to the provider selected by the user.
The privacy posture depends on the chosen route. Local processing, DirektText-managed cloud processing, and BYOK provider processing should not be described as if they have the same data flow.
Provider categories currently expected or under consideration include:
- netcup for hosting infrastructure.
- Cloudflare for DNS, TLS, proxy/CDN, security, and download/model distribution.
- Brevo for transactional and account-based product email.
- Groq for fast transcription where enabled.
- AssemblyAI for premium transcription or speaker separation where enabled.
- Polar.sh for billing and Merchant of Record services when billing goes live.
The final policy should publish only the providers actually used at launch and link or describe the relevant processor terms where required.
Some processing may take place outside the EU/EEA depending on the selected provider, product route, and infrastructure configuration. For example, some cloud transcription routes may rely on providers with processing outside the EU/EEA, while other routes may support EU endpoints.
DirektText should not claim EU-only processing unless the exact route used is configured and verified as EU-only. The final policy should describe transfer mechanisms such as adequacy decisions, standard contractual clauses, or other safeguards where relevant.
Retention periods are not final in this wireframe draft. The published policy should define retention for account data, device-link sessions, usage records, billing records, server logs, security logs, email records, support requests, uploaded audio, transcripts, local history, recovery files, and backups.
Audio and transcript retention should be described separately for local, DirektText-managed cloud, and BYOK routes.
The final policy should list the exact cookies, local storage, session cookies, security tools, analytics tools, and consent tools used on the live website and account dashboard.
No analytics provider is named in this draft because one has not been confirmed in the wireframe context. Non-essential analytics or marketing cookies should be disclosed and consented to before use where required.
Depending on the legal basis and the specific data, users may have rights to access, rectification, deletion, restriction of processing, data portability, objection to legitimate-interest processing, withdrawal of consent, and complaint to a supervisory authority.
The final policy should explain how to exercise these rights and how identity verification works for account, deletion, and export requests.
Privacy requests should be sent to:
[privacy contact email]
The final policy should also include the postal contact details from the Impressum.
This draft reflects the wireframe and known architecture notes as of 28 May 2026. The published policy should be updated whenever processing routes, providers, cookies, retention periods, billing infrastructure, or user rights workflows change.