BETA
New report Example
Example Pricing Destinations
TripBriefing · Privacy

Privacy policy

We take the protection of your data seriously. This policy explains what data we collect, why, and how long we keep it. Legal basis: GDPR (EU Regulation 2016/679) and Austrian DSG.

Data controller

Daniel Fekete
Tischlerweg 4, 4643 Pettenbach
Email: founder@tripbriefing.ai

What we store

1. Account: email address

When you sign in via magic-link, we store your email address in the users table. Purpose: account recognition + sending of the sign-in link. Legal basis: Art. 6(1)(b) GDPR (contract performance). Retention: until you request deletion (see below).

You can also sign in with Google instead. Only when you click “Sign in with Google” does your browser go to Google (Google Ireland Limited, see section 8). Google then sends us your email address and an identifier for your Google account (sub), no name and no profile picture. We store the email address as above and the identifier in the user_identities table. Purpose: to recognise your account the next time you sign in with Google. We only accept the sign-in if Google confirms the address and manages it itself (a Gmail address or an address of an organisation that uses Google); otherwise we ask you to use the sign-in link. Legal basis: Art. 6(1)(b) GDPR (contract performance). Retention: until your account is deleted.

You can also add a passkey to your account and use it to sign in. Your device or password manager creates a key pair for this. The secret key stays on your device; we never receive it. In the passkeys table we store the public key, an identifier of the passkey, a counter sent by your device, a random identifier of your account (not your email address), the name you give the passkey, and when you created it and last used it. Your device checks your fingerprint, face or device PIN itself. We receive none of this, only the confirmation that the check succeeded. So that your password manager can match the passkey to your account, we give your browser your email address as its name. It is visible to you there. If your password manager syncs your passkeys, for example via Apple or Google, this happens under your settings with that provider, not through us. Purpose: signing in without a sign-in link. Legal basis: Art. 6(1)(b) GDPR (contract performance). Retention: until you remove the passkey or your account is deleted. While you add a passkey or sign in with one, our server keeps a one-time check value for at most 5 minutes (only as a hash). After you add a passkey we send you a short notice email without advertising, so you notice if it was not you. Legal basis for this: Art. 6(1)(f) GDPR (legitimate interest in protecting your account).

1a. Account creation: IP address

When an account is first created we store the requesting IP address. Purpose: abuse prevention (limiting mass account creation). Legal basis: Art. 6(1)(f) GDPR (legitimate interest). This applies to both ways of signing in (sign-in link and Google). Retention: after 30 days we no longer need the IP address. It is deleted by the next cleanup run, that is at every start of our service, whenever a sign-in link is requested, and once a day while it is running. Your account is not affected.

For the same purpose we additionally store a one-way pseudonym of that IP address (a keyed hash; the IP itself is not stored) together with the time of account creation, so the limit still applies after a server restart. Retention: after 48 hours we no longer need this entry; it is deleted in the same cleanup runs. It deliberately survives the deletion of your account. Otherwise the limit could be reset simply by deleting and re-creating accounts. We cannot recognise you from that pseudonym alone. But as long as the IP address named above is still stored, we can technically establish the link.

1b. Use of the preview functions

Two functions can be used before a search is started: the AI location suggestion and the event preview. Both trigger costs at external services but do not consume any of your search credits. To keep that from being abused we store, for each use, your account ID, which of the two functions it was, and the time. Purpose: abuse and cost prevention. Legal basis: Art. 6(1)(f) GDPR (legitimate interest).

We store no content in this log: neither the place name, nor your travel dates, nor the result. Only the fact and the time of a request (for the web search there is one exception, see the next paragraph). Retention: after 7 days we no longer need these entries. They are deleted at every start of our service and once a day while it is running. When you delete your account, we delete them right away.

If the event preview for Pro loads the events with web search, we store three kinds of entries on the same pattern: one entry per place that takes a slot in the cap of 50 places in 30 days, the first time its events are loaded (even if they were already stored) and again with every further web search attempt for it; for another attempt, at most one entry per failed web search and at most one per place whose web search was held back by our daily budget; and, for a place already counted whose stored events are missing, at most one entry in 30 days for reloading it without a new slot. Here too only your account ID, the kind and the time, no place name. All three kinds also carry an identifier that we form from the place and the travel months with a secret key, so that a place counts only once in 30 days and only this place gets the attempt. Others cannot calculate the place name back from it. We ourselves can link it to a place with our key. It is therefore a pseudonym, not anonymous. We need the entries for the cap and for reloading for 30 days, because the cap counts that long; the entries for another attempt for 7 days as above. Deletion works as described above.

If you leave destination fields empty, the AI suggests cities. For those empty stops you have entered a wish text for (a limited number per request), we send these wish texts together in a single request to Anthropic (sections 6 and 8), along with the names of your other stops. Because all the wish texts are in the same request, each of them can also influence the suggestion and the reason for a different stop. If such a stop has an immediate neighbouring stop that already has a place (which can itself be an earlier suggestion you have not yet accepted), we have the suggested place name resolved into a coordinate via the place search of Geoapify (sections 6 and 8) before you accept it (together with the names of those neighbouring stops) to warn you about an unusually long overland leg. Your wish text itself is not sent to Geoapify. The suggestion and the resolved coordinate are held in a technical cache (the suggestion for 5 hours, the coordinate for 30 days) so that an identical request does not have to be computed again; the cache entry for the suggestions covers the entire request. That cache carries no account reference and expires automatically.

1c. Report by email: request counter

When you have a finished briefing sent to you by email, we store your account ID and the time of the request. Purpose: abuse and cost prevention. These emails go out through the same allowance as your sign-in link. Without a limit, a single account could empty that allowance, and after that nobody's sign-in link would get through. Legal basis: Art. 6(1)(f) GDPR (legitimate interest).

We store no content here. Neither which briefing it was, nor the subject, nor the recipient address. Only the fact and the time of a request. What is counted is the request itself, not the delivery: if sending fails afterwards, the entry stays. Retention: after 48 hours we no longer need these entries. They are deleted at every start of our service and once a day while it is running. When you delete your account, we delete them right away.

1d. Starting a trip: request counter

When you start a trip, we store your account ID, the current hour and how many places that trip searches. If you edit a briefing, we count at least one place, even if no place is searched again. Purpose: abuse and cost prevention. Every trip runs paid searches on our side, and a stop that returns no place to stay gets its steps credited back to you. Without a limit on how much a single account can start per hour, those searches could be triggered over and over at our expense. Legal basis: Art. 6(1)(f) GDPR (legitimate interest).

We store no content here. Not where you want to travel, not your dates, not your notes. Only your account ID, the hour and a number. There is one row per account and hour, not one per request. Retention: after 4 hours we no longer need these entries. They are deleted by the next cleanup run, that is when trips are started again, at every start of our service, and once a day while it is running. When you delete your account, we delete them right away.

1e. Sign-in links: daily limit per network address

Every sign-in link is an email, and all of them come out of one shared daily allowance. Without a limit, a single sender could use up that allowance, and after that nobody's sign-in link would get through. We therefore count how many sign-in emails were requested from one network address on the current day. Legal basis: Art. 6(1)(f) GDPR (legitimate interest in keeping the sign-in path open for everyone).

We store a one-way pseudonym of the network address (a key-based hash; the address itself is not stored here), the calendar day in UTC, and a number. Nothing else: no email address, no account ID, no content. There is one row per address and day, not one per request. Retention: after 48 hours we no longer need these entries. They are deleted at every start of our service and once a day while it is running.

These entries are not tied to your account and therefore also survive its deletion. Otherwise the limit could be reset simply by deleting an account. We cannot recognise you from the hash alone. But as long as the IP address stored when your account was created is still on file (see 1a), we can technically establish the link.

1f. Acceptance of the terms and this privacy policy

Every time you sign in you confirm the terms and this privacy policy. We store your account ID, the time and the version of the texts you confirmed; for each version we keep the first confirmation. Purpose: proof of when which version was confirmed. Legal basis: Art. 6(1)(f) in conjunction with Art. 5(2) GDPR (accountability). Retention: until you delete your account.

Unlike the pseudonymous entries in 1a and 1e and unlike the input log in section 10, these rows do not survive the deletion of your account. The version you confirmed at a purchase stays with the purchase records (section 8).

1g. Abuse protection: addresses briefly in memory

To stop individual senders from blocking our service with masses of requests or causing costs, we limit in a few places how often something can be triggered from one IP address: when requesting a sign-in link, when signing in with Google and when signing in with a passkey, when joining the waiting list and when leaving it, when applying as a creator, when checking a discount code, when unsubscribing via the button in your mail program, when submitting a withdrawal declaration, when allowing hotel photos in the sample briefing and in shared briefings, and when opening shared briefings. When you request a sign-in link, join the waiting list or apply as a creator, we also limit how often this happens for the same email address. Legal basis: Art. 6(1)(f) GDPR. Our legitimate interest is to keep the service available to everyone and to prevent abuse and costs.

For this our server keeps the IP address or email address together with the times of the requests (for a blocked email address in addition the number of times the limit was exceeded and when the block ends), in memory only, not in the database and not on disk. The daily limit per network address for sign-in links in section 1e is separate from this. For withdrawal declarations over IPv6 it is only the front part of the address, which identifies your connection.

Retention: we delete the address at the latest two minutes after the last request from it (IP addresses for sign-in, Google, passkey, waiting list, creator application, discount code and unsubscribing), one hour after it (hotel photos, shared briefings, email addresses), 24 hours after it (withdrawal declaration), and two hours after it if an email address was briefly blocked because of too many sign-in links. In any case we delete it when our service restarts.

2. Sign-in links

We store a hash of each sign-in link with a 15-minute validity. After use or expiry the link is invalidated. The plain-text token is never stored.

3. Trips and briefings

Trip configurations (cities, nights, preferences, questions about your trip) and the resulting briefings (including the answers to your questions) are stored in your account so you can revisit them. They are not shared with third parties beyond the services listed in sections 6 and 8 (our processors and the booking and geodata services our server queries to research your trip) and the people you yourself give a link to a briefing (see “Sharing a briefing by link” below). Retention: until you delete the trip or your account. Briefings created on the free quota additionally expire 30 days after creation and are permanently deleted by the next automatic clean-up run; briefings created with a Pro account or purchased steps do not expire. While Pro is suspended because of a chargeback, section 11 applies. If you unlock Pro while such a briefing has not yet expired, it stops expiring. If you edit a briefing, a new briefing is created. It carries over the unchanged stops with their results at the time and is kept from the edit onwards under the same rules; your earlier briefing is not affected.

Chat with Tibo: when you are signed in, you can ask our mascot Tibo, an AI, general questions about your trip in the trip form and in your briefing (sections 6 and 11). We do not store the content of the chat on our server: neither your questions nor Tibo's answers nor Tibo's notepad. History and notepad are kept only in your browser's storage (see the cookie overview). We only store numbers: how many questions you have asked in the trip form and from the Pro quota (with your account) and how many about a briefing (with that briefing). They are deleted together with the account or the briefing. In addition, for each question we record your account ID, the kind “Tibo chat” and the time, so that one account can ask at most 100 questions within 24 hours. Purpose: abuse and cost prevention. Legal basis: Art. 6(1)(f) GDPR (legitimate interest). After 7 days we no longer need these entries. They are deleted at every start of our service and once a day while it is running; when you delete your account, we delete them right away. The log line our server writes for each question contains neither the content nor your account ID, only where it was asked (trip form or briefing), what it cost and how it turned out.

Your briefings are only accessible from your logged-in account, unless you share a briefing by link (see below). The report email only ever goes to your own account address. If you export a briefing as a PDF, what you do with that downloaded copy (storing, passing it on) is your own responsibility; the briefing in your account is not affected.

Sharing a briefing by link: In your briefing you can create a link that lets others view the briefing without signing in, but not change it. You choose what the link shows: hotels only (maps, hotels and booking links, without destination texts, without the list of your activities and without trip questions) or the whole briefing as you see it, including your wishes and trip questions. Even when the link shows hotels only, each hotel still shows how far it is from your activities and from your arrival station or airport, with their names, and how well it matches your wishes. If your wishes or trip questions contain anything about you or your travel companions that others should not read, do not share the whole briefing. There is at most one link per briefing and view. Anyone who has the link can see the briefing; your name, your e-mail address, the name of your trip and your plan do not appear on the page. You decide who gets the link. For each link we store a check value of the link (not the link itself), a random number from which we can show you the link again, the chosen view, when it was created, when it expires and which briefing it belongs to. Legal basis: Art. 6(1)(b) GDPR (you use a function of our service). The link works until 7 days after your trip ends; for a briefing from the free quota at most as long as the briefing itself. After that we delete the entry at the next start of our service or in the daily clean-up run. You can delete the link or create a new one at any time; the old link then stops working immediately. If you delete the briefing or your account, we delete its links as well.

Someone who opens a shared briefing is a visitor to us like on any other page. Our server processes their IP address to deliver the page, uses it in memory for one hour to limit how often shared briefings can be opened from one address, and writes it to the server logs, see section 8 (hosting). The link itself is written to the log in masked form. Legal basis: Art. 6(1)(f) GDPR. Our legitimate interest is to deliver the page securely, to prevent links from being tried out in bulk and to find errors. Our hosting provider keeps the server logs for 7 days. The page loads hotel photos only once the visitor allows them there, with the same consent as in the sample briefing (see transfer to Singapore). The only thing we store permanently is the number of such permissions per hour, without IP address and without account. To stop anyone from triggering the permission in bulk, our server keeps the IP address in memory for up to one hour (section 1g).

3a. Special categories in free-text fields (sensitive details)

Our service is not designed to process special categories of personal data within the meaning of Art. 9 GDPR (such as health, disability or mobility needs, religion (e.g. religious dietary requirements), philosophical beliefs, ethnic origin or sexual orientation). Please do not enter such details into the free-text fields (the destination in the “Location” field, general preferences, “Questions about your trip”, per-stop preferences, activities, “Station / airport”, “Preferred neighborhood”, “Hotel should be close to”, “Question for Tibo”); and do not enter details of that kind about other people (travel companions, children) at all: only the person concerned can consent for their own data. Before starting a trip you must additionally confirm that you have read the notice shown above the start button; a short pointer at the free-text fields leads there. The same notice appears before your first question for Tibo, and you must confirm it there as well.

Entries in these nine free-text fields are checked automatically. If the check detects typical sensitive details, the entry is rejected with a notice and not stored. The short-term check-processing serves solely to reject it, and rejected entries are not logged. The check recognises typical sensitive details; it is expressly not a complete Art. 9 filter and cannot catch every wording. Because place names can overlap with sensitive terms, the check may in rare cases also reject an innocuous place name in the “Location” field; please rephrase the entry in that case (for example, the next larger town). If the check detects such details in a question for Tibo, Tibo tells you that he cannot take it; the question is then not sent to Anthropic and does not count towards your questions.

The field “Hotel should be close to”: what you enter there is not stored as text. After the check we send the entry, together with the place of the stop, to our processor Anthropic (sections 6 and 8). The model returns a kind of place (such as sea, lake, station or sight) and a coordinate. From that we form a place class (place, mountain, water, with the kind of water: sea, lake, river), a distance in metres and the coordinate; only that structure is stored, the text you typed is discarded. The text does not feed into the text generation of your briefing. The derived place class and the distance threshold do, just without the name you typed. This does not make the entry disappear entirely: the place you meant can still be derived from a coordinate; what is gone is the reason why you chose it. Only this one field is handled that way: “Station / airport” and “Preferred neighborhood” are stored as text and passed on to Anthropic, also to determine where they are (section 6).

Should special categories nonetheless reach us despite this check (for instance because the check does not recognise a particular wording), that happens unintentionally. We do not ask for such details, we expressly advise against them above, we automatically check the free-text fields listed above when you start a preview, create a briefing or ask Tibo a question, and we do not evaluate such details as a special category. We do not infer consent from this: typing a travel wish is not a declaration about data processing. Technically such details travel the same path as the rest of your wish: they feed into the research and into the text generation by our processor Anthropic (sections 6 and 8; the text you typed into “Hotel should be close to” goes to Anthropic only to determine the place, and only the place class derived from it feeds into the text generation). A question for Tibo that the check does not recognise goes to Anthropic to be answered, like any other question, and together with it the context named in section 6. They are used for that purpose only: not for advertising, not for analytics, not for any profiling beyond planning that specific trip.

We treat such cases for what they are: something we aim to make as rare as possible through data minimisation (Art. 5(1)(c) GDPR) and data protection by design (Art. 25 GDPR); not something we hold a permission for. If you notice you have entered such details: delete the trip in your account or write to us at founder@tripbriefing.ai; we will remove them (Art. 17 GDPR). If they are in your chat with Tibo, we hold nothing of it on our server. In the trip form, closing the tab removes history and notepad; in your briefing, the delete button at the chat clears notepad and history (see the cookie overview). Technical intermediate caches then expire automatically (the PDF cache after 7 days at the latest, AI-related intermediate results after 30 days at the latest; final removal happens with the next clean-up run). You may also lodge a complaint with the Austrian Data Protection Authority at any time.

4. Cookies

We only set technically necessary cookies (login session, language preference, and a record of your cookie choice). If you click „Sign in with Google“, we also set the short-lived cookie tb_oidc for 10 minutes. It links Google's reply to your click and is deleted once you are back. If you add a passkey or sign in with one, we also set the short-lived cookie tb_passkey for 5 minutes. It links your device's reply to your click. The cookie notice offers "Accept all" and "Accept necessary only" side by side. There is currently no category that would require consent, so today both buttons lead to the same result. The notice stays in place as a precaution: should we ever add a category such as statistics, it cannot start without your choice. See the cookie overview for details and settings.

5. Tracking / Analytics

We use no analytics or tracking scripts of third parties when you visit our pages: no Google Analytics, Hotjar, Meta Pixel, or comparable tools. One exception concerns the price-check links in briefings: they lead via the advertising partner CJ to Booking.com, and CJ registers the click (section 8).

Visit count on our own server (no cookies, no script in your browser): when you open one of our public pages (home page, sample briefing, destination pages, pricing, waiting list, sign-in, legal texts), our server counts that page view while delivering the page. Purpose: to know whether the site is visited, where visits come from and whether the purchase path is reached. For each day we only store a number: the day, the page or the step (purchase started, return from the payment page, route copied into the form, from the Pro offer in the trip form on to pricing or sign-in) and, for the home page, the sample briefing and the destination pages only, a rough origin from a fixed list (for example “TikTok”, “Google” or “opened directly”). We derive the origin from the information your browser sends by itself (the referrer) and keep only the name of the source, not the address. If your browser does not send this information, we use a marker in the link if it is on our fixed list (for example “?ref=se” in our own links on Stack Exchange). Here too, only the name of the source is counted. One exception is the marker “?ref=ga” in the address of our Google ads: it counts as the origin “ad” even if your browser sends another page, but not when you keep clicking within our site. We do not store your IP address, a cookie, an identifier, your browser, the full referring address, or the path of an individual visitor across pages. Known search engines and programs that create link previews are not counted. Programs of AI providers (OpenAI, Perplexity, Anthropic) that read one of our pages for their search or for a person's question are the exception: we count their requests separately from visits, per day only as a number per provider and purpose, without the page. Legal basis: Art. 6(1)(f) GDPR (legitimate interest in knowing whether and how the site is found).

Count of the place suggestions: For this count of the AI place suggestions (section 1b), our server stores only five numbers per day: how many suggestions were newly generated and delivered (a repeated identical request served from the cache is not counted), for how many of them the leg to a neighbouring stop could be checked, how often we warned about a long overland leg, for how many of those warnings a place search went to Geoapify in the same check (an approximation), and how many place searches went to Geoapify for this in total. Purpose: to check whether it is necessary to resolve the suggested place name before you accept it (section 1b). In this count we do not store your account ID, any other identifier, a place name, your wish text or the suggestion itself. Legal basis: Art. 6(1)(f) GDPR (legitimate interest in showing whether resolving the place name before you accept it is necessary).

Count of sign-ins with Google: for each day our server stores only how often a sign-in with Google succeeded (in total, with a new account, with an existing account, with a changed address at Google) and how often it failed, per reason from a fixed list (for example cancelled at Google, address not managed by Google, Google not reachable). Purpose: to notice whether signing in with Google works. In this count we do not store your account ID, your email address or any other identifier. Legal basis: Art. 6(1)(f) GDPR (legitimate interest in a working sign-in).

Count of passkey actions: per day our server stores only how often signing in, adding and removing a passkey succeeded, how often a notice email could not be sent, and how often they failed, by reason from a fixed list. Purpose: to notice whether signing in with a passkey works. In this count we do not store your account ID, your email address or any other identifier. Legal basis: Art. 6(1)(f) GDPR (legitimate interest in a working sign-in).

Our own evaluation of accounts (no cookies, no third parties): we measure how many registered accounts actually start a briefing. For that we evaluate: when you registered, whether and when a briefing was started, whether the account is a Pro account, and (for deleted accounts) the time of deletion (section 10). We do not evaluate your travel wishes, free text, destinations or travel dates. The result is aggregated figures per day and per week without names, addresses or identifiers (sign-ups and purchases per day, started briefings per sign-up week). It is not passed on and never used for a decision about you as an individual. Legal basis: Art. 6(1)(f) GDPR (legitimate interest in knowing whether the product is used); as further processing for statistical purposes it is not considered incompatible with the original purpose under Art. 5(1)(b) in conjunction with Art. 89(1) GDPR.

Retention: on our server, daily counts older than 90 days are deleted when the server starts and in the daily clean-up run. The controller transfers the figures from all counts in this section to the controller's own computer. There, daily figures are kept for up to 90 days; older daily figures are combined into weekly totals the next time the evaluation program runs, and only the weekly totals are kept.

You may object to all processing activities in this section at any time (Art. 21 GDPR) by e-mail to founder@tripbriefing.ai.

6. External APIs

To deliver hotel research we query external APIs server-side: the Agoda affiliate API for hotel data, the Anthropic Claude API for ranking, editorial text, locating your activities and location wishes, answering your questions about your trip, looking up events at your destinations and dates, translating a report into another language and clarifying a place name that the place search alone cannot match or for which the hotel search finds no accommodation (also with the help of your other destinations), and the place search of Geoapify (turning the names of your destinations and the AI place suggestion (section 1b) into coordinates; district names for the coordinates of hotels found; the outline of a stop's municipality; stations around your destinations). These requests are made by our server; your IP address is not transmitted to any of these services; only the relevant parts of your trip configuration (such as place names, dates and preferences you entered; for the chat with Tibo also your questions, see below). Beyond that no personal data is sent; Anthropic acts as our processor for this (see section 8 below, transfer to the USA via SCCs). To locate them, we send Anthropic the text of your activities, “Preferred neighborhood”, “Station / airport” and “Hotel should be close to” together with the place and the centre of the stop they belong to; the model returns coordinates (and, for “Hotel should be close to”, a kind of place). We only check that a point lies within a reasonable distance of the stop; we compute all distances ourselves. The aim is for the activity to appear on the map at the place you meant and to feed into the ranking of accommodation with a fitting distance. The AI can be wrong in doing so (section 11). Distances to the coast and to lake shores are computed with our own copy of map data on our server (OpenStreetMap coastline and HydroLAKES); nothing is sent out for that. In addition, the model classifies whether an activity is a place where you spend your time (such as a nightlife area) or a destination you visit once. For this we send Anthropic the text of your activities together with the place of the stop; only the classification comes back. If you asked questions about your trip or entered general preferences, the model looks for questions in them and answers them briefly in your briefing. For this we send Anthropic your questions, your general preferences and the place and travel dates of each stop; we do not include any details of the accommodation found. Agoda, by contrast, is an independent controller and is based in Singapore. What goes there and how we assess it is set out in section 8. Booking.com is not queried as an API: briefings contain links to Booking.com that lead via the advertising partner CJ (section 8). Data only flows through such a link once you click it. There is one exception: some hotel photos are hosted on the image server of Booking.com BV (Amsterdam, Netherlands), because the Agoda interface supplies such image addresses. Your browser loads those photos directly from there once you have agreed to load the hotel photos in the briefing. See section 7. Please do not enter other people's personal data into free-text fields (see also section 3a).

If you ask our mascot Tibo a question while signed in, in the trip form or in your briefing (section 3), the model answers it. Tibo is there for general travel questions, such as neighbourhoods, sights, things to do and how to get from one place to another; this is not personal advice, and Tibo declines questions unrelated to travel. On health, law, the security situation and entry requirements Tibo gives no answer of his own and refers you to the official sources. For answering your questions for Tibo we send Anthropic, with each question: your question; in the trip form an extract of what you have currently entered (the places of the stops with their nights, the start of the trip, the number of adults, the number of rooms, the number of children without their ages, the budget and your general preferences); in the briefing an extract that our server builds from your briefing (places and travel dates of the stops and, for each stop, up to five accommodations found with name, type, stars, rating, price per night (with several rooms, together with the number of rooms), breakfast and cancellation terms); in addition Tibo's notepad and your last two questions together with Tibo's answers. Notepad and history are kept in your browser's storage, and your browser sends them back to us with each question (see the cookie overview). The notepad is a short list with fixed fields (destinations, dates, nights, budget, location, amenities and the number of children without their ages) that our server takes from the model's answer and checks before passing it on; it has no influence on prices, quota or ranking.

The static map image in briefings is also fetched server-side from Geoapify (see section 8) and delivered to you by our own server: your browser does not contact Geoapify and your IP address is not transmitted to any map service for it.

7. Embedded third-party content (your browser)

Fonts, scripts and styles are served from our own server: your browser does not contact Google Fonts or other CDNs. Maps in your briefing are a static image that our server fetches and delivers itself; your browser contacts no map service for it (see section 6). The photos and map images on our destination pages also come from our own server. Links to Google Maps in the briefing are only opened by your browser when you click one of them. Only then do your IP address and what the link contains go to Google: depending on the link, the name of one of your activities or of a station together with the destination, the location of a hotel as the starting point of directions or as the place searched for, or the locations of several hotels as a route. For some links Google also sees that you came from our website, but not from which page. One exception remains, where your browser transmits your IP address to a third party without you clicking a link; it only applies once you have agreed:

Proof of your consent. If you are signed in, we record for each briefing when you consented to or withdrew consent for loading the hotel photos: account ID, briefing ID, the version of the information text you saw, the state of the briefing and the time. No IP address and no browser identifier. Purpose: proof of consent (Art. 7(1) and Art. 5(2) GDPR). Legal basis: Art. 6(1)(f) GDPR, as for the confirmation in section 1f. Retention: until the briefing or your account is deleted; for a briefing with an expiry date, until it expires. On the sample briefing and on shared briefings we only store permanently how often consent was given per hour, without a link to your person. To stop anyone from triggering it in bulk, our server keeps your IP address in memory for up to one hour while doing so (section 1g).

8. Processors & hosting

We use the following processors (Art. 28 GDPR); deviations from a concluded data processing agreement (in preparation / inactive) are noted for the service concerned:

Further recipients (independent controllers, no processing on our behalf):

Booking steps. If the "booking steps" programme is running for Agoda or for Booking.com (you can tell by the line at the respective booking button in a briefing), we add a random identifier per briefing to that partner's links (for Agoda as tag, for Booking.com via CJ as sid). It contains neither your name nor your email address nor your account identifier, and like the rest of the link it only reaches the partner once you click. If you book via such a link, the partner (for Booking.com via CJ) reports the booking status and the commission for this identifier back to us; the partner is the source of this information. From it we learn that a booking was made via your briefing and credit you the booking steps (Art. 6(1)(b) GDPR, terms § 6). If the programme is not running for a partner, no identifier is added to that partner's links. We keep the identifier even if you delete the briefing, so that a later booking can still be matched. Retention: 18 months after you last opened the briefing we no longer need it; it is deleted at the next automatic clean-up run (at server start and daily). Together with your account it is deleted immediately. We keep the credits (partner, a check value of the booking number formed with a secret key, number of steps, time) until your account is deleted. We do not store the booking number itself.

Records relating to purchases (e.g. invoice data) are retained for as long as statutory retention obligations require (§ 212 UGB / § 132 BAO: 7 years) and then deleted or anonymised. The same period applies to a copy of the contract confirmation we send you by email after a purchase (text of the email, time, identifier of the email service), so that we can prove which contract terms were confirmed to you (Art. 6(1)(f) GDPR).

9. Creator applications

If you apply via our creator page, we store the data you provide: first and last name, email address, country, platform, profile link, follower count (optional) and your free-text message. To document your consent (accountability, Art. 5(2) GDPR) we also store a timestamp, your IP address, your browser's user agent and the version of the consent text.

Purpose & legal basis: handling your application and contacting you about it: Art. 6(1)(b) GDPR (pre-contractual measures at your request) and Art. 6(1)(f) GDPR (our legitimate interest in recruiting partners). If you additionally opt in to programme updates, we process your email address for that purpose on the basis of your consent: Art. 6(1)(a) GDPR in conjunction with § 174 TKG 2021. This consent is confirmed via double-opt-in and can be withdrawn at any time with effect for the future.

Recipients: applications reach an internal mailbox we control; the confirmation and notification emails are sent via our processor Brevo (see section 8). Your data is not passed to third parties for advertising.

Retention: applications you never confirm are deleted automatically after 14 days; rejected applications after 6 months; accepted applications for the duration of the partnership and the statutory record-keeping periods that follow.

10. Account deletion & deletion log

You can delete your account yourself at any time in your account area (Art. 17 GDPR): after confirming via a link sent to your e-mail address, your account and its content (trips, reports, saved reports, sharing links, sign-in data including the link to your Google account and your passkeys, remaining quota including the counts of your questions for Tibo, any creator application) are deleted immediately and permanently. Requesting deletion informally by e-mail to founder@tripbriefing.ai remains possible. What we retain for legal reasons: purchase records for 7 years (sec 132 BAO; Art. 17(3)(b) GDPR), withdrawal records for as long as required to evidence legal claims (Art. 17(3)(e) GDPR), the record of a payment dispute (4 years from its creation) and the notes on purchases whether they carry Pro or still count (4 years from when they were set; both Art. 17(3)(e) GDPR, section 11), and the submission log (see below).

Ratings of reports (section 14) are not covered by account deletion, because we store them without any link to your account. On request we delete them by the wording of the comment (section 14).

Submission log: When you start a trip with free-text entries (preferences, activities), we record the fact of that entry: your account identifier, the time, the version of the legal texts, the version of the notice you confirmed before starting, the language and the purpose; no free text and no link to the individual trip. Its purpose is to evidence that and when an entry was made under which version of the texts; it is expressly not a record of consent within the meaning of Art. 7 GDPR; the confirmation is an acknowledgement, not consent. Legal basis: Art. 6(1)(f) in conjunction with Art. 5(2) GDPR (accountability). This entry survives account deletion (Art. 17(3)(e) GDPR) and is deleted automatically after 3 years, counted from the entry.

Deletion log (e-mail hash): when an account is deleted we store a pseudonymous HMAC hash of the e-mail address (no plain text) for 24 months. Purpose: preventing abuse of the free quota by deleting and re-creating an account: a new account registered with the same address within that period does not receive a fresh free quota; paid access is unaffected. Legal basis: Art. 6(1)(f) GDPR (legitimate interest). After 24 months the hash is deleted automatically. The bare time of deletion (not the hash) is also included in our own evaluation of accounts (section 5). You may object to this processing (Art. 21 GDPR) by e-mail to founder@tripbriefing.ai. In addition, each deletion is journalled in an operator notification (e-mail address + time of deletion) so deletions can be re-applied after a backup restore (Art. 6(1)(f) and Art. 5(2) GDPR; accountability); access is restricted to the operator mailbox.

11. Automated processing: ranking and AI content

To suggest suitable accommodation, our system automatically evaluates your trip configuration (destinations, dates, budget, the preferences you entered) and ranks the offers it finds accordingly. That evaluation is profiling within the meaning of Art. 4(4) GDPR. It serves only to produce your briefing, has no legal effect and does not similarly significantly affect you. This ranking involves no solely automated individual decision within the meaning of Art. 22 GDPR; the outputs are suggestions, and you make the selection and the booking yourself. Which criteria feed into the ranking and which do not is set out under How we rank hotels. Legal basis: Art. 6(1)(b) GDPR (providing the service you requested).

The editorial text, rationales, recommendations and the answers to your questions in your briefing are generated with AI assistance (Anthropic Claude, see section 8). We label this visibly in the briefing and in machine-readable metadata in HTML and PDF (transparency in the sense of Art. 50 of the AI Act, Regulation (EU) 2024/1689). AI-generated information can be incomplete or outdated; verify booking-relevant details with the respective provider before booking (see also § 9 of our terms). The AI also determines where your activities and location wishes are on the map (coordinates, section 6). It can be off in doing so; a distance shown in the briefing can then be wrong.

Tibo's answers in the chat are also generated by an AI (Anthropic Claude, see section 8). We label every answer visibly as an AI answer, in the trip form it says expressly that Tibo is an AI, and every answer carries a machine-readable label. Tibo's answers can be wrong, incomplete or outdated, especially on connections, times and prices; check them with the respective provider. If you take a route suggested by Tibo into the form, it counts as your own entry from then on. Tibo's notepad does not feed into the ranking of accommodation.

Chargeback of a payment. If our payment provider Stripe informs us that you have disputed a payment to us through your bank or card issuer (Stripe is the source of this information), our system suspends the purchase this payment belongs to, without human review. The disputed purchase counts as used first: we suspend only the steps left over after your other paid purchases. If it is your only paid Pro purchase, Pro is suspended as well: the lower step pack price for Pro then does not apply, and new reports for which you use no purchased steps are, like free reports, accessible for a limited period only. The suspension ends when your bank decides in our favour or you withdraw the chargeback; if you finally get the money back, the purchase counts as unpaid (§ 6 of our terms). This is a solely automated decision within the meaning of Art. 22 GDPR. It is necessary for the performance of our contract (Art. 22(2)(a) GDPR), because a chargeback can arrive at any time and steps can be used up within minutes. The legal basis for this processing is Art. 6(1)(b) GDPR. You can ask for a person to review the suspension, tell us your side and contest the suspension (Art. 22(3) GDPR), by e-mail to founder@tripbriefing.ai. If we suspend steps or Pro when the chargeback arrives, we tell you by e-mail what is suspended and why. If steps later flow back from a report that was already running before the chargeback and then fails, is stopped or is only partly delivered, we suspend them as well, without a separate e-mail. We tell you what is suspended at any time on request.

For each dispute we store a record: the identifiers of the dispute and of the payment at Stripe, their status, which purchase is affected, what was suspended and why, the language for our e-mail, your balance before as evidence, and the times. The purpose is to defend and evidence claims around the dispute (Art. 6(1)(f) GDPR). The record is deleted 4 years after it was created and until then also survives account deletion (Art. 17(3)(e) GDPR). On your purchases we also note whether a purchase no longer carries Pro (for example after a withdrawal) and whether it no longer counts after a lost dispute. As long as your account exists, these notes are part of performing your contract (Art. 6(1)(b) GDPR). After account deletion we keep them to defend claims (Art. 6(1)(f), Art. 17(3)(e) GDPR) and clear them 4 years after they were set.

12. Waiting list for the launch

If you enter your address on our waiting-list page, we store your e-mail address, the language of the page you used, the version of the consent text you agreed to, and the times of your entry and of your confirmation. We deliberately do not store your IP address or your browser's user agent in your entry. For creator applications (section 9) we do. In addition, our server briefly keeps your IP address and email address in memory to slow down mass sign-ups (section 1g). Your confirmation click together with the timestamp and the consent version is the record we need under Art. 7(1) GDPR.

Purpose & legal basis: a single e-mail telling you that TripBriefing has launched. This rests on your consent. The legal basis is Art. 6(1)(a) GDPR in conjunction with sec. 174(3) TKG 2021. We confirm the consent by double opt-in: after you enter your address we send one confirmation e-mail, and without that click we never write to you again. That confirmation e-mail and the unsubscribe receipt are transactional and contain no advertising.

Recipients: the e-mails are sent via our processor Brevo (see section 8). No new recipient arises from the waiting list, and your address is not passed on to third parties.

Storage period: entries you never confirm are deleted automatically after 14 days. Confirmed entries are deleted no later than 90 days after the confirmation. If you delete your TripBriefing account, an entry with the same address goes with it.

Withdrawal: the confirmation e-mail and every later waiting-list e-mail contain an unsubscribe link. One click on it opens a page with a single button, and that button deletes your entry immediately (Art. 7(3) GDPR). The link does not expire. Some e-mail programs additionally show their own unsubscribe button above the message. That button deletes your entry directly, without the intermediate page. The receipt confirming that we removed you may show such a button too. Clicking it has no effect, because your entry is already gone at that point. You can of course also write to us instead, using the address given in the section on your rights.

13. Withdrawing from a purchase (withdrawal function)

If you withdraw from a contract using our withdrawal function, we store the details from the form: your name, the e-mail address you entered, the contract or order ID, the language of the page and the time the declaration was received. We also store whether and when the acknowledgement of receipt was sent. If your details match a purchase, we link the declaration to that purchase.

Purpose & legal basis: the acknowledgement of receipt on a durable medium that the law requires (sec. 13(2) FAGG; for contracts concluded from 1 October 2026 also sec. 13a(5) FAGG) and proof that and when your declaration was received. The legal basis is Art. 6(1)(c) GDPR (legal obligation). To fend off mass submissions, our server keeps the IP address (for IPv6 only the front part) in memory for up to 24 hours; the legal basis for this is Art. 6(1)(f) GDPR (section 1g).

Recipients: we send the acknowledgement of receipt via our processor Brevo (see section 8) to the e-mail address you entered in the form. A notification with the same details goes to our own mailbox so that we can process the withdrawal.

Storage period: as long as the details are required to evidence legal claims (Art. 17(3)(e) GDPR). They remain in place after an account deletion (see section 10).

Below your finished report you can rate it with 1 to 5 stars and, if you like, add a comment. The purpose is to find out how helpful our reports are and to improve them.

What we store: the stars, the comment (if you write one), the month of the rating and the language of the page. We store the rating without any link to your account or to the report. On the report we only note that it has been rated (without a time), so that each report can be rated only once.

Check of the comment: before saving, we check the comment automatically for special categories of personal data, for example health or religion, in the same way as the free-text fields in section 3a. If the check finds such a detail, we save nothing. The check does not catch every such detail, and it does not recognise names or other details about people at all. That is why we ask you on the form not to write names or details about health or religion.

Legal basis: Art. 6(1)(f) GDPR (legitimate interest in measuring and improving the quality of our reports). Rating is voluntary. You may object to this processing (Art. 21(1) GDPR) by e-mail to founder@tripbriefing.ai.

Recipients: the rating is stored in our database with our hosting provider and in the database backup, as described in section 8. There are no other recipients.

Storage period: the whole rating (stars, comment, month, language) becomes due for deletion after the end of the 12th full calendar month after the month of the rating and is removed at the next start of the service or in the daily run. While the service is stopped, no deletion runs. The note "rated" on the report lasts as long as the report.

Access and deletion: because the rating is not linked to your account, we can only find it by the wording of the comment. For access or deletion, send us the wording (or part of it) at founder@tripbriefing.ai. A rating without a comment cannot be found this way. Deleting your account does not delete ratings (section 10).

Your rights

To exercise any of these rights write to founder@tripbriefing.ai.

As of: 2026-11-03