Skip to content

Privacy

Privacy Policy

Last updated: 2026-09-09

01 Policy

1. Controller and privacy contact

The controller within the meaning of the General Data Protection Regulation is:

Anel Alicic, trading as KASP
Brigitte-Frauendorfstr. 6
60486 Frankfurt am Main, Germany
Email: kontakt@kasp.ai

Privacy enquiries can be sent to this address. No data protection officer is currently appointed. If the organisation or its processing activities change, the need for an appointment will be reassessed and documented; if an officer is appointed, their contact details will be published here.

2. Roles in organisation and workspace use

Kasp is the controller for its own website, account, security, billing and product operation purposes. For content that an organisational customer enters in a workspace for its own purposes, the customer may be the controller and Kasp the processor, insofar as Kasp processes the data solely on documented instructions. The allocation of roles does not follow from the product name alone, but from the purpose, actual processing, decision-making authority and contract.

Before Kasp processes personal data on behalf of an organisational customer, the specific allocation of roles, any required data processing agreement, instructions, technical and organisational measures, and the applicable subprocessor list must be documented. The public DPA information does not replace an agreement validly concluded by both parties.

3. Purposes and legal bases

We process personal data in particular for:

  • providing the website, account, workspace, chat, analyses, files, artifacts and support to perform a contract or take pre-contractual steps (Article 6(1)(b) GDPR),
  • billing, bookkeeping, and records required under tax and commercial law (Article 6(1)(b) and (c) GDPR),
  • IT security, prevention of misuse, error analysis and defence of legal claims on the basis of legitimate interests (Article 6(1)(f) GDPR),
  • optional, authenticated and data-minimising daily aggregation of public page/funnel events and normalised Core Web Vitals only with consent (Article 6(1)(a) GDPR and section 25(1) TDDDG),
  • handling data subject rights requests, withdrawals, cancellations and reports of illegal content to meet legal obligations, verify identity and prevent misuse, and perform the contract (Article 6(1)(b), (c) and (f) GDPR).

Where we rely on Article 6(1)(f) GDPR, our legitimate interests include in particular secure, stable and economically viable operations, protection against attacks, prevention of misuse, and the establishment, exercise or defence of legal claims. A user entering data into a free-text field does not in itself create another legal basis or a change of purpose.

4. Website visits and technical logs

Visits involve the processing of technically necessary connection data, in particular IP address, time, requested URL, referrer where transmitted, browser and device information, response status, and security and error data. These data are necessary to deliver content, detect attacks and operate the service reliably (Article 6(1)(f) GDPR).

Vercel Inc. provides hosting, edge delivery and content delivery functions. Due to global delivery networks, processing outside the EU or EEA cannot be ruled out in every case. The applicable region, log configuration, subcontractors and transfer mechanisms depend on the configuration actually used and the associated agreed documentation.

5. Account, sign-in and communication

For an account, we process email address, user ID, authentication events, session and security metadata, settings, plan status and, where applicable, organisation or workspace assignments. Sign-in uses Google OAuth; Kasp does not store a separate account password. The legal bases are Article 6(1)(b) and (f) GDPR.

Google provides the OAuth identity service. When sign-in begins, the technical data required for the OAuth process are transmitted to Google; Kasp receives the identity and profile data authorised by the user. The scope and further processing also depend on the Google account used and the consent dialogue shown there.

Supabase provides, in particular, the database, authentication and file storage. Transactional emails may be sent through Supabase and Resend. Recipient address, message content, and delivery and error data are processed for this purpose.

6. Chat, analysis, workspace and artifact data

During use, we process in particular inputs and chat histories, selected roles and analysis depths, source requests, research results, assessments, feedback, status and usage metadata, workspace assignments, and generated analyses, plans, documents and other artifacts, including their versions. The purpose is to provide the service requested by the user and store their work results (Article 6(1)(b) GDPR).

Kasp does not deliberately use customer content to train its own general-purpose foundation model. Whether and how an external AI provider stores content or uses it for its own purposes depends on the specific provider service, configuration and contractual terms agreed. A zero-data-retention or no-training commitment applies only if it is expressly agreed and technically effective for the specific data flow.

For personal Kasp chats and Orbit, customer inputs must not be transmitted to Perplexity or trigger live research there. A separate service for obtaining public, non-personal sources is not a recipient of customer, account, authentication, chat, file, workspace, Orbit or billing data. The recipients applicable to a particular subscribed function are set out in the current provider information and, where required, the agreed DPA.

7. Organisational analyses and employee data

The contractual purpose of Kasp's organisational analyses is limited to roles, tasks, skills and aggregated organisational structures. Kasp is not intended to assess or rank identified or identifiable applicants or employees, or to make decisions on hiring, promotion, performance monitoring, dismissal or the allocation of tasks to individuals.

Names, personnel numbers, email addresses, CVs, and performance, behavioural, health or disciplinary data must not be entered or uploaded for such purposes. In the intended analysis path for organisational data, recognised records are processed into role aggregates; raw rows are not intended to be used as model context, and groups of fewer than five units are to be suppressed. These technical safeguards do not prevent every incorrect input and do not replace a legal basis or an organisational review.

Before any processing of employee data, the organisational customer must review in particular necessity and the legal basis under the GDPR and employee data protection law, information obligations, erasure, data subject rights, and the involvement of employee representatives. The need for a data protection impact assessment must be examined before processing begins, and an assessment carried out where the conditions are met. Consent in an employment relationship is not automatically freely given because of the relationship of dependence.

Further binding limits are set out under AI transparency and in the Acceptable Use Policy.

8. Files, extracted content and special categories of data

For uploads, we process file name, file type, file size, storage path, file content, security status, extracted text and the results generated from it. Before use, files may be checked for supported formats, size and identifiable security risks. Depending on the file type, the necessary content may be transmitted to an appointed service provider for OCR or model processing (Article 6(1)(b) and (f) GDPR).

Users may upload only content that they are legally entitled to have processed. Without an expressly documented data flow covered by law and contract, users must not transmit, in particular, health data, biometric data, data on religion or trade union membership, criminal offence data, professional secrets, trade secrets or personal employee data. The mere existence of an upload field does not authorise the processing of special categories of data.

9. AI processing and web research

  • Mistral AI SAS, France: Where Mistral AI is used for the subscribed function, the prompts, selected parts of conversations, artifacts and file content needed for a response may be processed. The endpoint, region, contract, subcontractors and retention agreed for the specific data flow are decisive. Mistral's public Data Processing Addendum distinguishes processing on behalf of customers from its own purposes, including abuse monitoring and, under certain conditions, model training. Any contractual or configured exclusion from training, and exceptions for feedback sent to Mistral, must be checked for the specific service used. This link does not establish any special arrangement agreed by Kasp.
  • Perplexity AI, Inc.: Perplexity is not a recipient of customer data within the service scope described here. Where Kasp uses a separate service to obtain public sources, that service may receive only search requests concerning public, non-personal sources. Its results are unqualified leads and may be incorporated into customer results only after a separate review of the source, rights, attribution and substantive validity. A Perplexity output is neither a source nor a subject-matter authority.

The legal basis for AI processing requested by the user is generally Article 6(1)(b) GDPR. Security and abuse filters may additionally rely on Article 6(1)(f) GDPR. For organisational data, the specific role and instructions must also be considered. Information on the system's purpose and human oversight is available under AI transparency.

10. Voice input and public sharing

Where supported by the browser, voice input uses the Web Speech API. Through this function, Kasp generally receives the recognised text, not an audio recording intentionally stored by Kasp. Whether audio data are processed locally or by a browser or operating system provider's service depends on the browser, device and its settings. The function is optional and requires microphone permission.

If a user enables sharing, selected results may become publicly accessible or accessible to people with the sharing link. Users must first remove personal, confidential and protected content. Kasp processes sharing status, technical identifier and access data to provide this function and prevent misuse (Article 6(1)(b) and (f) GDPR).

11. Payments and subscription management

Where Stripe is used for a paid plan, Stripe processes in particular contact, billing, payment, tax, subscription and fraud prevention data. Full card details are not stored in Kasp systems. Depending on the transaction, Kasp receives, among other things, email address, customer and subscription identifiers, payment status, amount, currency and legal checkout metadata. The legal bases are Article 6(1)(b), (c) and (f) GDPR.

12. Data subject rights, withdrawals, cancellations and reports

Through the Data subject rights, Withdrawal, Cancellation and Report illegal content pages, we process the identification, contract, contact and explanatory data required there, the data subject right asserted, receipt time, a case reference, and identity, delivery and processing status. Name and email address are not required for reports concerning suspected offences of child sexual abuse or child sexual exploitation. Without an email address, a subsequent electronic decision cannot be delivered.

The data are used to receive, acknowledge, review, carry out and provide legally required evidence of the respective process (Article 6(1)(b) and (c), and, for defence of legal claims, (f) GDPR).

13. Cookies and local browser storage

Technically necessary cookies or comparable storage technologies are used only for sign-in, session security, an expressly chosen language or appearance, requested OAuth/checkout/analysis handoffs, local drafts and results, restoring the interface, and reliably applying the privacy decision. Classification as 'necessary' under section 25(2) TDDDG does not replace the legal basis required under Article 6 GDPR for subsequent personal data processing. The names, triggers, contents, recipients and validity of every currently reachable key are listed in the Cookie and Storage Information.

The device-specific browser consent record, version 2026-08-31, contains only the version, a yes/no value for optional statistics, and the precise decision time. It is valid for no more than 180 days. After expiry, it is no longer accepted as a valid choice and a new decision is required. An older entry may physically remain until the next choice or manual deletion in the browser, but is not used for statistics.

For signed-in users, Kasp also synchronises this browser decision to a separate current account projection containing account ID, version, yes/no value, decision time, source and server time. A separate immutable consent record additionally contains a random request ID, one-way checksums of the data subject reference and payload, and the projection status. It contains no name, email address, IP address or user agent. In particular, the account projection is used to suppress statistics on the server where the account decision differs, is outdated or has been withdrawn.

Kasp does not load any script from an external statistics provider. Optional statistics are sent exclusively to a Supabase Edge endpoint controlled by Kasp. This requires a current affirmative browser record, an authenticated non-anonymous user session, and an exactly matching affirmative account projection. Anonymous public events are not aggregated. Page and funnel events are allowed only for a fixed list of public, non-sensitive route templates. In addition, Core Web Vitals may be counted for a sample of normalised public and specified app route templates. DNT or GPC technically blocks all of these processes even if consent is still stored in the browser.

The Edge endpoint processes the user JWT and exact decision time to verify the session and account consent. Only a UTC daily aggregate of the permitted event name, normalised route template, four finite funnel dimension keys and a counter is stored permanently. For Core Web Vitals, the metric name (LCP, INP or CLS), deterministic rating, navigation type, completion flag, and count, sum, minimum and maximum of the measured value are added. The aggregate contains no user ID, IP address, user agent, raw URL, query string, URL fragment, referrer, JWT, free text, payload, or individual event or decision timestamp. Specific app object IDs are replaced with placeholders in the route template. Sign-in, admin, private sharing, laboratory, data subject rights, withdrawal, reporting, contact, accessibility and support paths, and paths with sensitive token parameters, are excluded.

Consent can be changed at any time through 'Privacy settings' with effect for the future. Refusal does not affect sign-in, basic functions, service scope or prices.

14. Recipients, subprocessors and third-country transfers

Recipients may include Vercel, Supabase, Google, Mistral AI, Stripe, Resend, Plausible and documented subcontractors of these providers, insofar as required for the respective data flow and documented in the current provider or contractual information. Data may also be transmitted to advisers, courts or authorities where legally required.

Supabase is the only external technical recipient for optional statistics: the production Supabase Edge endpoint authenticates the session and checks account consent before the Kasp-controlled database path increments only the account-free daily aggregate. No separate Plausible or other third-party statistics service is loaded. Normal connection and security data that may technically arise when the Edge endpoint is called are covered by the technical log information in section 4 and are not part of the daily aggregate.

Perplexity is not a recipient of customer data within the service scope described here. A separate service for obtaining public sources is limited to public, non-personal data. Where such a service is used, the provider's role, contractual basis and any third-country transfer must be documented separately for that data flow.

The subprocessor list applicable to a specific processing arrangement must contain names, services, data categories, processing locations, transfer mechanisms and the change procedure. A mere list of technically possible integrations is insufficient. Before a B2B contract is concluded, the providers and data regions actually used must be consistent with the DPA, security documentation and product configuration.

Some providers or subcontractors may process data outside the EU or EEA. Where no adequacy decision under Article 45 GDPR applies, the transfer requires appropriate safeguards, in particular EU standard contractual clauses under Article 46 GDPR, and an assessment of any necessary supplementary measures. Information on a specific recipient can be requested via kontakt@kasp.ai , including a copy of the relevant safeguards or information on where they are available.

15. Retention, erasure and backups

Data are stored only for as long as necessary for the respective purpose, contract performance, security, defence of legal claims or statutory retention. Account and product content is generally retained until deletion by the user, account deletion, or the end of a documented contractual and recovery period. Deleted data may remain in encrypted backups for a limited, documented rotation period and must not be restored from them for normal product purposes.

Invoice and bookkeeping data are retained in accordance with the applicable tax and commercial law periods. Security and abuse logs and legal requests are subject to retention periods defined by data category. The periods and exceptions applicable to a particular subscribed service are set out in the associated product and contractual information; general statements on this page do not shorten statutory retention obligations.

The browser record and the counting permission based on it are valid for 180 days. Daily aggregates are also limited to no more than 180 UTC calendar days; a daily database job and, additionally, each permitted write delete older days. For aggregates, the period starts with the respective UTC calendar day, not the decision time of the browser record. The current account projection is deleted with the account when the account is deleted. For the immutable consent record, the direct account ID is detached upon account deletion; one-way checksums may remain for the documented evidence retention period. Daily aggregates have no account reference and can neither be attributed to an account nor selectively removed from a counter when that account is deleted. The specific retention periods for consent records and technical Edge logs must be separately defined and evidenced in the production erasure policy.

16. Profiling and automated decisions

Kasp does not make a solely automated decision that produces legal effects concerning a data subject or similarly significantly affects them (Article 22 GDPR). Scores and AI outputs provide information and decision support. Users must not use them to make automated decisions about individual employees or applicants.

Role and task analyses may identify patterns, scenarios or priorities at an aggregated level. They are not intended for personal profiling. A function that assesses, predicts or categorises natural persons requires a separate review of profiling, relevance under Article 22, data protection impact assessment and high-risk classification.

17. Required data and security

Certain data are required to conclude a contract and provide the service, in particular email address, authentication data and the inputs necessary for a requested function. Without these data, the respective service cannot be provided. Optional information and optional audience measurement are not prerequisites for basic functions.

Kasp uses technical and organisational measures, including access restrictions, separated roles, encryption in transit, logging, rate limits, security checks on uploads and controlled administrative access. Their scope and effectiveness must be reviewed regularly. Security issues can be reported to kontakt@kasp.ai .

18. Data subject rights

Data subjects have, in particular, the following rights:

  • access under Article 15 GDPR,
  • rectification under Article 16 GDPR,
  • erasure under Article 17 GDPR,
  • restriction of processing under Article 18 GDPR,
  • data portability under Article 20 GDPR,
  • objection under Article 21 GDPR to processing based on Article 6(1)(e) or (f) GDPR,
  • withdrawal of consent with effect for the future under Article 7(3) GDPR.

Your right to object

You may object at any time to processing based on Article 6(1)(e) or (f) GDPR on grounds relating to your particular situation. We will then stop processing the data unless we demonstrate overriding compelling legitimate grounds or need the data for legal claims. You may object to processing for direct marketing at any time without giving reasons, including related profiling. The data will then no longer be processed for such marketing.

Requests and withdrawal of consent

To exercise these rights, use the 'Data subject rights' form or email kontakt@kasp.ai . An acknowledgement of receipt does not confirm identity, substantive entitlement or completion of processing. To prevent unauthorised disclosure, we may request appropriate proof of identity. For organisation accounts, Kasp may forward a request to the organisational customer acting as controller or assist it in handling the request, insofar as Kasp acts as processor.

We will inform you of action taken on your request without undue delay, generally within one month of receipt at the latest. For complex or numerous requests, this period may be extended by up to two further months; we will inform you of the extension and the reasons within the first month. If we refuse a request, we will explain the reasons and the available complaint and judicial remedies. Requests are generally free of charge; statutory exceptions remain unaffected.

Withdrawal of consent does not affect the lawfulness of processing before withdrawal. For optional audience measurement, you can use 'Privacy settings'; you can withdraw other consents through the contact given above.

You may lodge a complaint with a data protection supervisory authority, in particular in your place of habitual residence, place of work or the place of the alleged infringement (Article 77 GDPR). The authority generally responsible for Kasp is the Hessian Commissioner for Data Protection and Freedom of Information. Its complaint form and guidance on secure submission are available online. Postal address: Postfach 3163, 65021 Wiesbaden, Germany.

19. Minors and changes

Kasp is not directed at persons under 18. If we learn that an account is being operated for a minor without valid authorisation, we will assess suspension and deletion, taking statutory obligations into account.

We update this Privacy Policy when data flows, functions, service providers or the law change. Material changes affecting existing users will be communicated appropriately. The version published on this page applies.