Privacy Policy
Last updated: June 2026
At Wissenswerk we take the privacy of your data seriously. This Privacy Policy explains what information the Wissenswerk platform ("Wissenswerk", "we", "us") collects, how it is used, where it is stored, how it is protected, and the choices and rights you have. This policy describes the actual data-handling behaviour of the application. It is provided for transparency and does not constitute legal advice.
Wissenswerk can be operated as a managed (hosted) service or self-hosted on your own infrastructure. Where this policy refers to "the operator", it means the party running the deployment you use. The party responsible for your specific deployment is identified in our Impressum.
1. What Wissenswerk Is
Wissenswerk is an organisational knowledge management and AI assistant platform. Within Wissenswerk you can:
- upload documents,
- create notes, interviews, and debriefs,
- connect external content sources such as Google Drive and Confluence,
- process files into searchable knowledge segments,
- search and chat with an AI assistant ("Astra"), and
- manage organisation members, collections, and synced knowledge sources.
2. Information We Collect
2.1 Account data
- Username
- E-mail address (stored in lowercase; used as your login identifier)
- Password hash (hashed with bcrypt; the plaintext password is never stored)
- Optional profile picture
- Optional avatar colour value
2.2 Organisation and membership data
- Organisation name and owner
- Your role within an organisation (
adminoremployee) - Optional bio, job title, and department
- Onboarding completion status and onboarding context text
- Onboarding transcript and any uploaded onboarding content with its document metadata
2.3 Invitation data
- Invited e-mail address
- Inviting organisation and the user who issued the invitation
- Invitation acceptance status
2.4 Content you upload or sync
- Uploaded files (for example PDF, DOCX, XLSX, PPTX, TXT, HTML, and common image formats)
- Notes and transcript-style text stored in debrief records
- Converted document content
- Confluence page content and Confluence-hosted images/attachments fetched during sync
- Google Drive files fetched during sync
- Spreadsheet workbook data processed for descriptions and queryable sheet access
2.5 Data the application derives from your content
- Knowledge segments extracted from uploaded or synced content
- Embedding vectors used for semantic search
- AI-generated tags, titles, summaries, and image descriptions
- Thumbnails, extracted document images, and slide/page images
- Conflict-detection records and resolution metadata
2.6 Chat and interaction data
- Chat titles
- Your full stored chat message history per chat session
- Search history and retrieval context processed at runtime to answer your queries
2.7 Integration data
- Google Drive OAuth tokens, token expiry metadata, and the connected account e-mail address
- Confluence/Atlassian OAuth tokens, token expiry metadata, cloud/site identifiers, site URL, and the connected account e-mail address
- Your synced selections (for example chosen folders, spaces, or pages)
- Tracked synced file/page metadata and sync status
2.8 Technical and authentication data
- A JWT access token issued at login, together with its expiry metadata
- The application stores this token in your browser's
localStorage - No application-managed, cookie-based session is used
2.9 What we do not collect
- No built-in analytics integrations (for example Google Analytics, Mixpanel, or Segment)
- No advertising identifiers and no ad-tech integrations
- No third-party error-tracking or telemetry service in the application by default
- No application-level persistence of your IP address (infrastructure or reverse proxies may still log IPs independently of the application)
3. How We Use Information
3.1 Core product functionality
- Your account is used to authenticate access to your organisation's data.
- Uploaded and synced content is processed into searchable knowledge.
- Segments and embeddings power retrieval-augmented search and chat.
- Files may be converted, OCR-processed, image-processed, or summarised.
- Spreadsheet content may be described and queried to generate answers.
3.2 Collaboration and administration
- Organisation members can see organisation-relevant profiles, content, and activity according to their access level.
- Admins can manage members, integrations, collections, and deletion flows.
- Events are recorded for operational visibility, such as content creation, deletion, conflict detection, and integration activity.
3.3 AI and retrieval workflows
- Content is chunked into knowledge segments and embeddings are generated for semantic retrieval.
- Retrieved segments and/or file excerpts are sent to a large language model (LLM) to answer your questions, generate tags, produce summaries, or analyse extracted images.
3.4 Integrations
- Google Drive and Confluence credentials are used to fetch the external content you select into Wissenswerk.
- Integration tokens are refreshed automatically where possible.
- Disconnecting an integration deletes the integration record and the synced knowledge content tracked by that integration.
4. Storage, Encryption, and Security at Rest
4.1 Database and vector storage
- Primary database: PostgreSQL
- Semantic vector search: Qdrant
4.2 Encrypted database fields
The following classes of data are encrypted at rest using a per-organisation Data Encryption Key (DEK) and authenticated AES-256-GCM encryption:
- Integration credentials
- Organisation LLM API keys
- Converted debrief content
- Debrief transcripts
- Knowledge-segment content
4.3 Fields not covered by field-level encryption
- Embedding vectors remain in plaintext because vector search requires direct access to them.
- Operational metadata such as titles, filenames, tags, timestamps, and status flags generally remains unencrypted.
- Passwords are hashed with bcrypt rather than reversibly encrypted.
- Usernames and e-mail addresses are stored as identifiers and are not field-level encrypted.
4.4 File storage
- Uploaded files — including documents, thumbnails, extracted document images, profile pictures, and feedback screenshots — are stored in cloud object storage provided by our infrastructure operator within the European Union.
- Access to stored files is controlled by the application: requests are authenticated and your organisation membership is verified before a short-lived, time-limited access URL is issued.
- Your browser or client fetches the file directly from the storage service using that time-limited URL, which expires automatically and cannot be reused.
- During file processing, temporary copies may briefly exist in a secure in-memory temporary location; they are deleted after processing is complete.
4.5 Key hierarchy
- A Master Encryption Key (MEK) is derived from an environment- or KMS-backed secret.
- Each organisation has its own randomly generated 256-bit DEK.
- DEKs are wrapped (encrypted) and stored in the database.
- Supported key-management backends include local/environment, AWS KMS, Azure Key Vault, and HashiCorp Vault.
- DEK wrap/unwrap operations are recorded as metadata only (provider, organisation, operation, timestamp) — never plaintext content or raw keys.
5. Data in Transit
- Browser-to-server traffic should be served over HTTPS in production; TLS termination is the responsibility of the deployment operator.
- External API calls made by the application are performed over HTTPS, including calls to DeutschlandGPT, Google APIs, and Atlassian.
6. Third-Party Services and Data Transfers
6.1 DeutschlandGPT
- Purpose: LLM inference for chat, document conversion, tagging, summaries, and image analysis, as well as embedding generation.
- Data that may be sent: document text, converted content, extracted image data, spreadsheet-derived content, your chat messages, retrieved knowledge context, and the system prompts and chat history needed to produce a response.
- Default models: chat defaults to
gpt-4.1-mini; embeddings default totext-embedding-ada-002(configurable by the operator). - Data location: DeutschlandGPT processes data within Germany.
6.2 Google Drive API
- Purpose: browsing folders and syncing the Google Drive files you select into Wissenswerk.
- Data exchanged: OAuth authorisation/refresh requests; your e-mail address, folder and file metadata, and file contents (including Google Workspace exports for Docs/Sheets/Slides where applicable).
- OAuth scopes requested:
drive.readonlyanduserinfo.email. - Stored after connection: encrypted access and refresh tokens plus token expiry metadata.
6.3 Atlassian / Confluence Cloud API
- Purpose: browsing Confluence spaces/pages and syncing the content you select into Wissenswerk.
- Data exchanged: OAuth authorisation/refresh requests; your profile info, accessible sites/resources, space and page metadata, page HTML/export content, and attachment/image content.
- OAuth scopes requested:
read:page:confluence,read:space:confluence,read:attachment:confluence,read:content-details:confluence,read:me, andoffline_access. - Stored after connection: encrypted access and refresh tokens, expiry metadata, and cloud/site identifiers.
6.4 Cloud infrastructure and object storage
- Purpose: storage of uploaded files and all derived artefacts (thumbnails, extracted document images, profile pictures, and feedback screenshots).
- Data stored: the file content and artefacts described in Section 2 above.
- Data location: infrastructure is located within the European Union.
6.5 Services we do not use
- No built-in analytics SDKs.
- No advertising-network integrations.
- No built-in payment-processor integration.
- No built-in third-party telemetry/error-reporting service.
7. Data Retention and Deletion
7.1 Accounts
- Accounts persist until deleted by an administrator or the operator; there is no automatic expiry.
- Full account deletion is currently handled by an administrator rather than a self-service control.
7.2 Documents, debriefs, segments, and embeddings
- These persist until deleted through the application or by administrator action.
- Deleting a debrief removes the database record and attempts to remove the associated stored file and thumbnail.
7.3 Chats and events
- Chat records persist until explicitly deleted; deleting a user removes that user's chats.
- Event records are stored in the database; no automatic purge policy is currently applied.
7.4 Integration data
Deleting a Google Drive or Confluence integration removes the integration record, the tracked synced debriefs, related segments/embeddings owned only by that synced content, and the associated sync metadata.
7.5 Invitations
Invitation records persist in the database; accepted invitations are marked as accepted rather than automatically removed.
8. Your Rights and Choices
8.1 Access and correction
- You can view and update profile fields exposed in the interface, including username, e-mail, password, avatar, bio, job title, and department.
- Organisation admins have broader visibility and management rights over organisation data.
8.2 Deletion
- You and your admins can delete debriefs and other knowledge items through the application.
- Administrators can delete user accounts and remove users from organisations.
- For full account or organisation deletion, contact the operator of your deployment.
8.3 Export and portability
A self-service export feature is not currently provided in the interface. To request a copy of your data, contact the operator of your deployment, who can fulfil the request at the administrative level.
Depending on your jurisdiction (for example under the EU/EEA GDPR), you may have additional rights including access, rectification, erasure, restriction, objection, and data portability. To exercise these rights, contact the operator identified in our Impressum.
9. Authentication and Access Control
- Authentication method: e-mail and password.
- Password storage: bcrypt hash.
- Access token: a JWT signed with a server secret, valid for 24 hours.
- Client storage: the token is held in your browser's
localStorage; there is no application-managed cookie session. - Multi-factor authentication (MFA/2FA) is not part of the current application.
- Role model: organisation-scoped
adminandemployeeroles. - Protected file access: non-avatar uploaded content requires a valid token and organisation membership before a short-lived, time-limited access URL is issued for retrieval.
10. Security Summary
- Password hashing with bcrypt.
- Field-level encryption for sensitive content and integration credentials.
- Per-organisation DEK model with a wrapped key hierarchy.
- Uploaded files and derived artefacts stored in EU-based cloud object storage; access is controlled by the application and delivered via short-lived, expiring access URLs.
- Cleanup of temporary file copies created during processing.
- HTTPS for third-party API calls and JWT-based authentication with 24-hour expiry.
- Upload size limits: avatars up to 5 MB; documents/uploads up to 10 MB.
11. Uploads and Supported Content
Supported processing and storage paths include common document and image types, such as PDF, DOCX/DOC, XLSX/CSV, PPTX, TXT/HTML/plain text, ODT, and JPG/JPEG/PNG/GIF/WEBP images. Avatar uploads are limited to image types and are resized/normalised before being saved.
12. Deployment Models
12.1 Hosted / managed service
In a hosted deployment, the LLM runtime uses the operator's DeutschlandGPT API key from the server environment by default. Your organisation's content may therefore be processed through an operator-level DeutschlandGPT account in that mode.
12.2 Self-hosted / on-premise
In a self-hosted deployment, infrastructure, HTTPS termination, backups, and log handling are the responsibility of the operator running the deployment. The exact runtime behaviour, including which LLM provider is used, should be confirmed for your specific deployment.
13. International Data Transfers
When you use AI features or connect integrations, your content may be transmitted to and processed by third-party providers (such as DeutschlandGPT, Google, or Atlassian) whose infrastructure may be located outside your country, including outside the EU/EEA. The operator of your deployment is responsible for ensuring an appropriate legal basis for any such cross-border transfer where required.
14. Children's Privacy
Wissenswerk is intended for business and professional use and is not directed at children. We do not knowingly collect personal data from children.
15. Changes to This Policy
We may update this Privacy Policy to reflect changes in the application or in legal requirements. Material changes that affect your rights or data will be communicated with reasonable advance notice, and the "last updated" date above will be revised.
16. Contact
For privacy questions or to exercise your rights, contact the operator responsible for your deployment, identified in our Impressum, or reach out via our contact page.