Privacy

This policy covers two groups of people, and our responsibilities are not the same for both.

• Organizers — the people who sign up, build a concierge and pay for it. For their data we are the controller: we decide what to collect and why, and this policy is the notice.
• Attendees — the people who ask a concierge questions. For their data the organizer running that event is the controller, and we are the processor acting on their instructions. What we do with it is set by the Data Processing Addendum, and by the notice the attendee reads on screen.

One thing does not fit that split cleanly, and we would rather name it than let you find it: the traces we use to debug and improve how answers are generated contain attendee questions, and improving our own service is our purpose, not the organizer’s. We describe it below under “Where we are on less certain ground”, and it is on the list we have asked a lawyer to look at.

AskConcierge is operated under the trading name Pulsier Labs, established in Portugal. You can reach a person at contact@pulsierlabs.com.

Pulsier Labs is currently operated by an individual and is not a registered company. Two things a contract normally names are therefore not yet stated: the legal name for service (not yet stated) and the postal address (not yet stated). We would rather say this plainly than let a document imply a corporate form that does not exist. If you need a counterparty that is a registered entity before you can sign, write to us and say so — it is a reasonable thing to need, and it is the one thing standing between these documents and a signature.

We have not appointed a Data Protection Officer. On our reading we are not required to: we do not carry out large-scale systematic monitoring of people, and processing special categories of data is not a core activity of ours. That reading is ours, made without legal advice, and it is on the list of things we have asked a lawyer to check.

This document exists in English only, and the English text is the one that governs. Our website, and the notice an attendee reads before asking a question, are available in English, Portuguese and Spanish. We would rather hand you one text we have read carefully than three that can drift apart, because a mistranslated clause in a document like this is not a wording problem — it is two different promises.

This is the notice you saw above the message box, in full. It is the whole of what we do:

Answers come from the organizer’s own information. What you ask is shared with the organizers to improve answers, and is deleted within 90 days. We don’t ask who you are — and if you choose to leave an email so we can tell you when a question is answered, it is used for that one message and deleted as it is sent.

What that means concretely — what we hold about you:

• Your questions and the concierge’s answers.
• A random identifier for your browser at this one event, so a returning phone sees its own earlier conversation. It is not your name and it is not linked to one.
• The language you are reading in, and rough timing information — when the question was asked.
• An email address, only if you typed one in to be told when a question gets answered, or to send the organizer a message. It is used for that one thing and then deleted.
• Your answers to a survey, if the organizer runs one and you choose to answer it.

What we do not hold:

• Your name, unless you type it into a question yourself.
• Any account — there is nothing to sign up for.
• Behavioural tracking. There is no analytics tracker on a concierge, no advertising, and nothing that follows you to another site.
• A record joining what you asked at one event to what you asked at another. The identifier is per concierge and the event’s address is signed into it, so the two cannot be joined — that is deliberate, and it is enforced in code rather than promised in a policy.

The identifier is pseudonymous, not anonymous. It distinguishes your browser from another browser without naming you, and we are careful not to call that anonymity, because it is not the same thing.

The organizer sees the questions asked at their event. They are told, in the product, not to treat that as a way of identifying individuals, and the reports we generate for them are aggregated with a floor beneath which a group is not reported at all.

For organizers we are the controller. We hold:

Card details go straight to Stripe and never reach us.

When somebody from our side opens your workspace to help you, that access is capped below owner — support can administer a workspace, never transfer or delete it — and every change it makes is recorded against the person who made it. You can ask us for that record.

These periods are enforced by a job that runs every day, not by us remembering. That ordering is deliberate: the deletion was built before the promise was made.

The aggregate counts are the one thing that deliberately survives. They hold numbers and topics — how many people asked about parking — never anything that identifies a person. The classifier that writes them is instructed never to record a name, a phone number, an email address or a booking reference, and a topic that fewer than a set number of people asked about is not reported at all.

One exception is worth stating plainly, because our own deletion job cannot reach it: the diagnostic traces we send to PostHog contain the question that was asked, and they age out on PostHog’s schedule rather than ours — around 30 days by default. It is shorter than our own retention period, but it is not us doing the deleting, and we would rather you knew that than have us describe a promise we do not control.

We do not sell personal data, and we do not share it for anybody else’s marketing. We use a small number of service providers to run the product, and the current list is below. It is generated from the same register the product uses internally, so it cannot quietly fall behind.

Some of these are outside the EU — the model router, the web search and the crawler are in the United States. Where personal data goes there, it goes under the European Commission’s Standard Contractual Clauses in the provider’s own terms. We have not commissioned a formal transfer impact assessment for each of them; that is on the list a lawyer is being asked to look at, and we are not going to describe it as done.

We will tell organizers before we add a provider that can see attendee content, so there is time to object. We would also hand over data if a court or the law required it, and we would tell you unless we were forbidden to.

There is no cookie banner on a concierge, and that is not an oversight — nothing is written there that needs consent. Everything an attendee’s browser stores is either required to make the thing work, or a preference they set themselves.

On the marketing site and the organizer app there is a banner, and it asks first: nothing analytics-related is loaded, sent or stored until somebody accepts. Rejecting is one click, the same size as accepting, and it removes anything a previous acceptance left behind.

You can ask us for a copy of your personal data, ask us to correct it, ask us to delete it, ask us to restrict or stop a particular use, and ask for it in a portable form. Where we rely on consent, you can withdraw it at any time, and withdrawing it does not make what came before unlawful.

Write to contact@pulsierlabs.com with “Privacy” in the subject. We will acknowledge within 5 working days and answer within 30 days. We do not charge for this.

If you asked a concierge a question and want it deleted sooner than the retention period, tell us the event and roughly when. We deliberately do not know who you are, which is good for your privacy and awkward here — we may not be able to find your conversation from a description alone, and we will not delete somebody else’s on a guess. If you cannot be identified from what you give us, the law does not require us to invent a way, and we will say so rather than pretend.

If your question is about an event you attended rather than about your own account, the organizer of that event is the controller, and we will point you at them and help them answer you.

• Everything is served over TLS, and data is encrypted at rest by our hosting and database providers.
• The database is never reachable from a browser. Every read and write goes through our own server, and the key that can reach it exists only there.
• One customer’s data cannot be read from another customer’s account. It is enforced where a request resolves which event it is about — one such point for a signed-in organizer and one for an API key — rather than screen by screen, and there are tests whose whole job is to try to cross that line.
• Support access is capped below owner, time-boxed, and every change it makes is recorded.
• Content that a concierge has read is treated as untrusted: it is kept separate from the instructions the model follows, so a webpage cannot tell the concierge what to do.

If a breach happens that puts people at risk, we will tell the supervisory authority within 72 hours of becoming aware of it, and we will tell affected organizers without undue delay so they can tell their attendees.

AskConcierge is sold to event organizers, and an account is for adults. A concierge itself has no sign-up and no age check, so if an organizer runs an event that children attend, children can ask it questions. We do not knowingly collect anything about a child beyond the question they typed, and the same retention and the same lack of identification apply. If you believe a child has given us something that should not be there, write to us and we will remove it.

If your event is aimed at children, tell us. The honest position today is that the product has no specific protections for that case beyond the ones everybody gets, and you should factor that into your own assessment.

We would rather publish this section than have a policy that reads as though everything is settled. These are the places where our own reading may be wrong, and a lawyer has been asked to look at each of them.

• Diagnostic traces contain attendee questions, and we use them to debug and improve how answers are generated. That is our purpose, not the organizer’s, which probably makes us a controller for that use rather than only a processor. It is described here, it is in the sub-processor register, and it is the first thing on the list.
• The traces age out on our analytics provider’s schedule, not on ours, so our deletion job does not reach them.
• We rely on the Standard Contractual Clauses in our providers’ terms for data going to the United States. We have not done a documented transfer impact assessment for each provider.
• Attendees sometimes disclose health or disability information in a question, because that is often what they need to ask about. We do not seek it, we classify topics rather than people, and we hold reports to an aggregation floor — but the question itself sits in the transcript for the retention period.
• We are not incorporated, so the counterparty to any contract is an individual.

None of this is a claim that we comply with any particular regime, and you will not find that claim anywhere in these documents. We describe what the product does and produce evidence you can check. Deciding whether that meets an obligation of yours is your call, and if it helps, ask us for the evidence.

We will update this when the product changes. If a change matters to you we will tell organizers by email. Every version carries the date it took effect, and we do not backdate.

For anything in this policy — a question, a request about your own data, or a complaint — write to contact@pulsierlabs.com and put “Privacy” in the subject line. A person reads it. We aim to answer substantively within 30 days, and to tell you inside 5 working days that we have it.

If you are not satisfied with how we have handled something, you can complain to a data protection authority. Ours is the Comissão Nacional de Proteção de Dados (CNPD) (https://www.cnpd.pt). You can also complain to the authority where you live or work.