Privacy Policy

Last updated: 1 November 2026

This privacy policy (the "Policy") sets out what information is kept when any person uses Qder.ai or contacts Qder, including as a diner, as a person booking a table or as a business (any such person, the "User"); who sees that information; where it is sent; how long it is kept; and what the User can do in respect of it. The Policy has been written so that it can be understood without a lawyer, and every line of it has been checked against what the code actually does.

This English text is provided for convenience. The Hebrew version of this document is the governing version: מדיניות פרטיות.

1. Responsibility for the information

Qder.ai is operated by Itay Funes, an exempt dealer (עוסק פטור), trading as "Qder" (קיודר) (the dealer number is provided to businesses in the agreement and on every receipt) (hereinafter "Qder"). Qder operates the platform. The restaurant at which the User is sitting, has placed an order or has booked a table, as the case may be (the "Restaurant"), is an independent business, and it owns the information concerning the User's order, visit and booking.

In the terms of the Israeli Protection of Privacy Law, 5741-1981 (as amended by Amendment 13): with respect to orders, visits and bookings, the Restaurant is the controller of the information, and Qder holds and processes it on the Restaurant's behalf; with respect to personal accounts, business accounts, applications to join and security records, Qder is the controller. In the terms of the GDPR, to the extent that it applies: with respect to the order, the Restaurant is the controller and Qder is the processor; with respect to the account, Qder is the controller.

In this Policy, words in one gender include every other gender.

1A. Voluntary provision of information

The User is under no legal obligation to provide information to Qder, and the provision of information depends on the User's own choice. The User may order and pay without an account; an account cannot be opened without a telephone number and a date of birth; and, where no allergies have been saved, the digital waiter takes into account only what the User tells it in the conversation. The purposes, the recipients and the period for which information is kept are set out in sections 2–6. As to the right to inspect the information concerning the User and to request its correction or deletion (sections 13 and 14 of the Protection of Privacy Law): see the page Your rights over your data (Hebrew), or write to privacy@qder.ai.

2. Information kept concerning diners

By default, the User is anonymous. The User may scan a code, ask questions, order and pay without providing a name, a telephone number or an email address. The following is kept in every case:

Information	Purpose	Retention period
The table session: the branch, the table number, the time at which the session was opened, and the last time at which the phone communicated with the server	To identify the table to which an order belongs, and to flag in the panel a table whose phone has been silent for three quarters of an hour with no open bill	4 hours, after which it is deleted
The order: the dishes, the quantities, the prices, the time at which it was sent and the time at which it was served	To transmit it to the kitchen, to produce a bill, and to measure for the Restaurant how long serving takes	Kept by the Restaurant as a sales record; see Keeping and deleting data
An allergy note or a request to the kitchen, if the User wrote one	To transmit it to the kitchen verbatim	Together with the order
The manner in which the User asked for each dish to be prepared (the degree of doneness, the level of spiciness, extras, and a free-text request concerning a dish, such as "no onion", if the User wrote one)	To transmit it to the kitchen together with the dish, and to price a paid extra, if the User chose one	Together with the order, as part of the dish line
The most recent messages in the conversation with the digital waiter, linked to the table session (and not to the User)	So that the digital waiter remembers what was said a moment earlier, and so that words cannot be falsely attributed to it from the browser	24 hours, after which they are deleted from the server
The conversation log: what was asked and what was answered, after email addresses, telephone numbers and long numbers (such as identity and card numbers) have been replaced with a generic marker; without any name and without any link to an account	To improve the digital waiter: to identify which questions it answers poorly, and to enable a manager to correct it. Recurring failure patterns are also examined across restaurants, but only after the name, the restaurant, the chain and the dish names have been replaced with a generic marker; what is kept from that examination is the pattern, and neither the conversation nor the restaurant. The conversation itself is never provided to another restaurant, and is not used to train models	90 days, after which it is deleted. The log itself carries no account identifier; however, for as long as the table session that the User opened as a signed-in diner exists (up to 4 hours), the rows can be linked to it, and they are accordingly included in the User's data export and deleted together with the User's account. Any account holder may switch this off on the account page
A question asked by the User that the digital waiter could not answer from the Restaurant's details (it stated that it would check with the staff): the words of the question only, after email addresses, telephone numbers, long numbers and any name that the User gave as his or her own have been replaced with a generic marker; without any account, table session, table number or reply	So that the Restaurant answers it once, after which the digital waiter gives that answer to every diner. The Restaurant sees the question without knowing who asked it. Before that, the question is checked at the AI model provider (see section 5) against the Restaurant's details: the menu, the hours and the details about the place. If the answer was already there, the error is the digital waiter's and no information is missing at the Restaurant, and the question is therefore not sent to the Restaurant: Qder's team sees it in order to fix the digital waiter, and it becomes a test case that the digital waiter must pass from then on, without the names of the dish, the restaurant and the chain. This constitutes a test, not model training. The same question, expressed in other words or in another language, is merged into one	180 days from the last time a diner asked it, after which it is deleted. If the Restaurant answered it, the topic of the question and the answer remain in the branch's details for as long as the Restaurant keeps them. A test case derived from it: without time limit. Not kept at all in respect of any person who has switched off the keeping of conversations in the log on the account page
A problem report (the "Something not working?" button, or "Send for review" on the safeguards notice): what the User wrote, the table and the branch; and, if the User ticked "attach the conversation" in the report or tapped "Send for review", also a copy of the conversation with the digital waiter, namely what the User's screen showed and what the model received and answered, including spoken turns, after email addresses, telephone numbers and long numbers have been replaced with a generic marker; without any name and without any link to an account	To establish what went wrong and to fix the digital waiter. The report and any attached conversation are read only by Qder's team, are never provided to the Restaurant and are not used to train models. Attaching the conversation is at the User's choice, separately for each report: the box is unticked at the outset, and "Send for review" sends only when the User taps it	The report: 180 days. The attached conversation: 90 days, after which it is deleted, even if the report itself is still kept. If the fault was the digital waiter's, Qder may keep the questions that the User typed or said in that conversation (without the digital waiter's replies, the User's name, contact details or the dish names) as a test case that the digital waiter must pass from then on, without time limit. This constitutes a test, not model training
A 👍/👎 under a reply of the digital waiter: only what Qder knew about that reply (which model answered, the kind of question, the language, and which of Qder's checks were triggered by it), and never a word of what was written or said; and, if after a 👎 the User chose to write under "What went wrong?", the line that the User wrote	To count where the digital waiter is weak. The vote is counted, and is not kept with the conversation. A line written by the User becomes a problem report and a test case as in the row above: the User's questions only, without the digital waiter's replies, the User's name or the dish names. It tests the digital waiter; no vote and no line is ever used to train a model	What Qder knew about the reply: one day, after which it is deleted; only the day's count of votes remains. The line: as for a problem report
The User's chat history: the concierge conversations and the tables, as shown in the app and on the website, linked to the User's account	So that the User sees the same conversations on every device and can continue a conversation that stopped. It is the User's alone: no restaurant sees it, and it is not used to improve the digital waiter or to train models	12 months from the last message, after which it is deleted. Kept only for signed-in diners, and only while the "keep my chats" switch in the settings is on (which is the default); switching it off deletes what was kept. The User may delete one chat or all of them from the menu; they are included in the User's data export and deleted together with the User's account
An email address, if the User entered one at payment in order to receive a confirmation	To send a payment confirmation, and to notify the User if the Restaurant issued a refund	400 days together with the visit details, after which it is removed from the payment record
A link for paying part of the bill, if the User shared one	To enable a person sitting with the User to pay his or her share	The link is signed and is not stored; it expires after 6 hours
IP address	Rate limiting only, in order to prevent the guessing of table codes, mass form submission and repeated sign-in attempts	Until the end of the limiting window (up to a quarter of an hour); it is not written to a log and is not kept with the order

Personal account

An account is a matter of choice, not a condition. Where the User has opened an account, the following are also kept: the email address; the name; the telephone number (which is mandatory, so that the Restaurant can reach the User if something about the order goes wrong; it is provided only to the restaurant at which the User is sitting); the date of birth (used so that alcoholic drinks are not sold through the system to anyone under 18, and, on the User's birthday, so that the digital waiter may wish the User a happy birthday on the User's own screen; the date and the age are not provided to the Restaurant and are not shown to any person); and whatever the User wrote in the allergies and dietary preference fields. Qder does not keep the User's password at all: identity is managed at Supabase, where the password is stored as a one-way hash. The User's visits are linked to the User's account, so that the User can see them on the account page.

Where those fields are empty, the digital waiter asks once, before the User's first order, whether there are any allergies or anything that the kitchen should know. What the User says is included in the order. The system then asks whether to save it to the User's account, so that the User does not have to repeat it, and saves it only if the User agrees; otherwise, it is not kept on the account. Qder records that the User was asked, so as not to ask again. The User may change or delete it at any time on the account page.

Signing in with Google or Microsoft. Where the User has chosen to sign in through either of them, the provider verifies the User's identity and passes to Qder, through Supabase, the email address and the name registered with that provider. Nothing else is received: Qder has no access to the User's mailbox, contacts or files, and publishes nothing on the User's behalf. If the User already had an account with that email address, the sign-in leads to that same account.

Passkeys. Where the User has added a passkey, the User's device holds the private key, and Supabase keeps only the public key and a friendly name for the device. The User's fingerprint or face never leaves the device and never reaches Qder. (Optional age verification, described below, is different: there, the User chooses to send a photograph of the User's identity document and a selfie for a single check.)

Health information. What the User writes in the allergies field is information about the User's health, and under Israeli law such information is information of special sensitivity. It is kept only in order to be communicated to the kitchen and to the digital waiter; it is sent to the restaurant at which the User is sitting and to no other restaurant; and the User may delete it from the account at any time.

Age verification (optional)

The User may verify, on the account page, that he or she is 18 or over. The User photographs a passport (the photo page) or a biometric identity card (the front), and then takes a short selfie: one picture looking straight ahead and a series of small pictures while the User rolls his or her head in a full circle, as when setting up Face ID. During the selfie, a component in the page follows the User's head in order to guide the User; it runs only on the User's phone and sends nothing. Before starting, the User ticks the consent on the card, and Qder keeps a record of the wording to which the User agreed. The images are sent to Qder once, checked in memory and deleted at the end of the check: Qder does not keep them.

Everything is performed by Qder's own service, which runs on Cloudflare's infrastructure without internet access, and no image is sent to any other company: reading the date of birth and the expiry date from the document (in a passport, the machine-readable lines, being those containing <<<; in an identity card, the dates printed on its front, together with a check that the identity number is valid), comparing the face with the photograph in the document, checking that the head moved as asked, and checking that it is a live face rather than a photograph or a screen. Only the document type and the two dates are taken from the document; the name and the document number are not kept and never leave the service. If the date of birth on the User's account indicates that the User is not yet 18, the User cannot verify, and no image of the User is processed.

Qder keeps only the following: whether the check passed or failed, when it took place, the document type, reason codes and how closely the faces matched (a single number, not a face template; attempts are deleted after 30 days); and the consent wording, for as long as the verification stands. Qder does not keep the User's name, identity number, any image or any face template. Once the User has been verified, an order containing an alcoholic drink reaches the staff marked "age verified", with nothing else about the User. A face image and an identity document are especially sensitive information, and verification is therefore entirely optional: the User may order exactly as before without it, and may withdraw it at any time on the account page; changing the User's date of birth or deleting the User's account withdraws it. Verification does not replace a venue's right to ask for identification.

Table bookings

A booking requires a name and a telephone number, so that whoever is at the door knows whose table it is and can call if anything has changed. The following are kept: the name, the telephone number, the number of diners, the time, a note (if the User wrote one) and the link to the User's account. The booking confirmation and any cancellation notice are sent to the account's email address. The name and the telephone number are deleted 90 days after the date of the booking; the fact that there was a booking, and whether the User arrived, remain with the Restaurant for a further year as an operational figure, without a name. While the User is sitting at the table that the User booked, the note is also conveyed to the digital waiter, so that it knows, for example, that the User is celebrating a birthday.

Orders placed through a waiter, where a name and telephone number are given

Where a waiter enters the User's order on the User's behalf, the waiter may ask for the User's name and telephone number. Giving them is at the User's choice: the User may order through the waiter without giving them. If the User does give them, the Restaurant keeps a card on the User in its guest book, containing the name, the telephone number, how many times the User has visited and when the User last did so, what the User ordered there, the User's allergies (only if the User asked for them to be remembered) and the staff's notes. The card is shared only among the branches of that chain, and is used for two purposes: to recognise the User on the User's next visit (by name, and by the allergies that the User asked to have remembered), and to reach the User if a bill is left open. A waiter sees the name, the allergies and the notes, but not the telephone number; the branch manager also sees the telephone number. Neither the Restaurant nor any other branch of its chain with which the card is shared may use the card for marketing without the User's separate consent. The card is deleted two years after the User's last visit, or immediately when the User asks the Restaurant to delete it. The Restaurant is the controller of this information, and Qder holds it on the Restaurant's behalf.

Restaurant ratings

After paying the bill by card on the Qder platform, the User may rate the Restaurant (1–5 stars) and may, if the User so wishes, add a sentence. The rating is kept with the User's account and with the visit. Other diners see only the average and the number of ratings, and only once there are at least 10 ratings. The Restaurant sees its own ratings and sentences, by day only, without any name or contact details, and cannot edit or delete them. When the User deletes the account, the sentence and the link to the User are deleted, and the stars remain in the Restaurant's average, linked to no one; otherwise, the rating is kept in the same way as visit data (see the retention policy).

Taste memory (optional)

Taste memory is off, and is switched on only if the User personally switches it on: on the account page, or by an explicit "yes" when the digital waiter asks about it. The digital waiter asks only once, after an order on a return visit, and if the User says no or does not answer, it never asks again. While taste memory is on, the digital waiter remembers the kinds of dishes to which the User keeps returning at every restaurant that works with Qder (for example, a cheeseburger), and suggests a dish of that kind when the menu at the restaurant at which the User is sitting includes one.

Information kept. The kind of dish (for example, "cheeseburger"), how many times the User ordered it, over how many visits and at how many restaurants, and when it was last ordered. In addition: when the User switched taste memory on, the wording to which the User agreed, when the digital waiter asked about it, and the kinds of dishes that the User asked Qder to forget. The following are not kept: the names of the restaurants and what the User said in conversations; alcoholic drinks are never kept; and no words relating to diet or health are kept (such as "vegan" or "gluten free": such a dish is remembered as what it is, for example a burger). Qder infers nothing from it about the User's health, religion, family or any other personal matter.
Source. Only the visits recorded in the User's account, namely the paid orders at a table at which the User sat while signed in to the account. These may include dishes ordered by others at the User's table, and a single visit therefore counts at most twice for each kind. A kind of dish is remembered only after at least three orders over at least two visits, and older visits count for less. In order to recognise that dishes at different restaurants are of the same kind, the language model reads the dish names on the menus and marks each dish with its kind.
Purpose. Only so that the digital waiter can suggest a dish of a kind that the User likes; not for advertising, not for sale, and not for any decision concerning the User. Such a suggestion is no more than a suggestion: the allergies and dietary preferences in the User's profile always take precedence.
Recipients. The list is kept by Qder and is not provided to restaurants. When the User sits at a restaurant that has a dish of a kind that the User likes, a short line about it (the kind, and the dish's name on that menu) is included in the instructions that the digital waiter receives for that conversation, and is sent with them to an external AI model provider (see section 5), as is every message in the conversation. The suggestion itself appears in the conversation like any other reply of the digital waiter, and therefore also in the scrubbed conversation log that the Restaurant can review (without any name and without any link to the User's account), unless the User has asked, on the account page, that the User's conversations not be kept.
No obligation. The User is under no legal obligation to switch it on, and doing so depends only on the User's choice. Without taste memory, everything works in exactly the same way, save that these suggestions are not made.
Retention and deletion. The list is rebuilt every night from the visits in the User's account, so that older visits drop out of it over time. On the account page, the User may at any time see what is remembered, delete any line (which will then not be remembered again), or switch taste memory off, which deletes the entire list at once. The kinds of dishes that the User asked Qder to forget are kept after taste memory has been switched off, only so that they are not remembered again if the User switches it back on, and are deleted together with the User's account. The list is included in the "download a copy of all my data" file and is deleted together with the User's account.

The referral program (optional)

A diner aged 18 or over, and a business through the administrator of its chain, may join the referral program and receive a personal referral link. Joining is at the User's own initiative only, on the account page or in the chain panel.

Information kept about the referrer. The referral code, when the referrer joined and the version of the terms agreed to; and, for each business that signed up through the link: the business's name, the state of its application and of the referral, the number of branches for which the reward was calculated, its amount, and when and how it was paid. To pay a diner's reward, the name, email address and phone number on the diner's account are used.
Information about the business referred. Qder receives no detail about the business from the referrer and does not contact it because of a referral. If the owner of the business opens the link, a cookie holding only the referral code and the time the link was opened is kept in the owner's browser (see the Cookies Policy), and if an application is sent from that browser, the application records that it arrived through the link. To apply the program's terms, Qder compares the email address, phone number and company number on the application with the records it already holds and with the referrer's details.
Recipients. The referrer sees the state of each referral on the account page or in the chain panel; the business's name is shown only once its application has been approved. The business referred does not receive the referrer's identity from Qder. Qder's staff see the information in the internal console in order to apply the terms and pay the rewards.
Retention. For as long as the account or the business exists, and payment records for as long as the law requires bookkeeping records to be kept. Deleting the account deletes the referral code and the link between the referrer and the referrals, save for the record of a payment already made.

The chat on the website

The pages of Qder's website include a chat with Qubi, Qder's digital assistant, and the User may ask at any time for a person from Qder's team. No account is needed, and the User does not have to give a name.

Information kept. The User's messages, Qubi's answers and the team's replies, after email addresses, telephone numbers and long numbers (such as identity and card numbers) have been replaced with a general marker; the page on which the User started, its language, the topic (sales, getting started, technical support, billing, diners, privacy and security, or partnerships), and the time. If the User asked Qder to reply by email as well, or wrote an email address in the chat so that Qder can get back to the User, that address is kept separately for that purpose. Qder has no telephone support, and a telephone number is therefore not kept. The User's IP address is not kept with the conversation; it is used for rate limiting only, as on the rest of the website.
Purpose. To answer the User, to enable a person from the team to continue from where Qubi left off, and to improve the answers; not for advertising, not for sale and not for training models.
Recipients. Qder's team, in the internal console. In order for Qubi to answer, the User's messages are sent to the language-model provider (see section 5), together with passages from the public pages of the website. Qubi is not connected to any account and cannot carry out any action: no refund, no discount, no change of plan or billing, no change to an account or to a restaurant's settings, and no deletion. Those actions are carried out only by a person, in the usual ways.
In the User's browser. So that the conversation continues as the User moves between pages, the browser keeps the conversation's identifier and a random key for it (localStorage). They hold nothing about the User, and are removed when the User starts a new conversation or clears the website's data.
Retention period. 90 days from the last message, after which the whole conversation is deleted, together with the email address. The User may ask Qder to delete it sooner, in the chat itself or through the contact form.

3. Information not kept

Card details. Payment takes place on the Restaurant's payment page, through the Restaurant's own processor. A card number never passes through Qder, and Qder never sees it at any stage. Qder keeps only the transaction amount and the reference that the processor returned.
Location. Qder does not ask for access to GPS and does not collect location. It is the code affixed to the table that identifies where the User is.
Tracking or advertising cookies. There are none on this website. The only measurement is Cloudflare's page-view count, without any cookie and without any device identifier, which the User may switch off in the settings panel in the cookie policy; switching it off genuinely removes it from the page, rather than merely asking it to stop.
A behavioural profile. Qder does not build a profile, does not score the User, and makes no automated decisions with legal significance concerning the User. The one exception is taste memory, and only if the User personally switched it on: a list of the kinds of dishes that the User likes, which the User can see and delete on the account page. The card in the Restaurant's guest book (described above) exists only if the User gave the waiter a name and telephone number, and it remains with that chain.

4. Information kept concerning businesses

The application to join. The business name, company or dealer number, city, contact name, email address and telephone number, and any document attached (for example, a certificate of incorporation or a business licence). Documents are kept in a private folder at Supabase, with no public address, and are accessible only to Qder's team for the purpose of reviewing the application. They are deleted 90 days after the decision; the details of the application themselves remain as the record of how the account came into existence.
The venue in the application. Since 14 October 2026, the sign-up form has also collected what the account needs in order to work from its first day: the branches and their addresses, opening hours, tables, the menu (with dish photographs, if uploaded), details about the place, how guests pay, and the names, email addresses and telephone numbers of the branch managers and waiters for whom the business wishes to have accounts. Upon approval, all of it is entered into the account, and each staff member is sent an email invitation to set a password. The form is saved as it is filled in, once the email address has been confirmed with a code; a form that is never sent is deleted 30 days after it was last saved, together with its photographs. While such a form is kept, Qder may contact the person named in it once, by the email address or telephone number that such person gave, to offer help in completing the sign-up. A photograph or PDF of the menu uploaded in order to be read is sent to an external AI model provider in order to type out the dishes, and is not kept by Qder. With respect to employees' details, the business is the controller, and Qder holds and processes them on the business's behalf.
Staff accounts. Name, email address, telephone number (if given), role, the branch or chain, and whether two-factor authentication is enabled (the authentication secret is kept by Qder). The password is managed at Supabase. An order that an employee entered at the table is kept with the employee's name, so that it is known who took it, even after the employee's account has been closed.
Payment processor details. The access keys for the processor account that the business entered. They are kept in the database, are used only by the server, and are never returned to the browser; the panel shows only which fields were filled in. Keys entered in the sign-up form are checked with the processor and kept encrypted, separately from the application, until approval; they are deleted if the application is rejected or if the form is never sent.
Operating data. Menu, prices, hours, tables, orders, visits, refunds issued (amount, reason and who issued them) and the branches' bookings, and the number of diners who spoke with the digital waiter (for billing, without the diner's identity).
Information sent to the business assistant. Messages, images and files that an employee sent to the assistant are passed to the model and are not kept by Qder after the reply; the proposals that the assistant created are kept until they are approved or rejected.
The kitchen and bar screen assistant. A person working in the kitchen or at the bar may speak or type to the screen ("table 7 is out", "we're out of salmon"), in any language. The screen records only after its microphone button has been pressed, and stops by itself when the speaking stops. The recording is sent to an external AI model provider for transcription and is deleted at that moment: Qder does not keep it, and it cannot be recovered. The text (transcribed or typed) and the assistant's replies are kept as that screen's short memory for up to 24 hours, without the employee's name and without any link to the employee's account: as far as the system is concerned, it is the screen that is speaking, not an identified person. What the assistant did is recorded in the same way as a tap on the screen (an order's status, a dish that ran out), and a message that it sent to the staff remains in the branch's notification bell for 7 days. It should be noted that a microphone on a kitchen wall also picks up whoever is standing near it while it is recording. With respect to information about the business's employees, the business is the controller, and Qder holds and processes it on the business's behalf.
WhatsApp messages. When the User writes to Qder on WhatsApp, the message passes through Meta's WhatsApp and through Kapso, the provider that connects Qder's number to WhatsApp's business platform, and Qder keeps the telephone number, the name shown on WhatsApp and the conversation, in order to reply and to handle the request. Qder's WhatsApp number is for messages only, not for calls. Messages are answered first by Qubi, Qder's assistant, as in the website chat: in order for Qubi to answer, the messages in the conversation are sent to the language-model provider (see section 5), together with passages from the public pages of the website, and Qubi cannot take any action on an account. Writing "human" brings in a person from Qder's team, and Qubi passes the conversation on of its own accord when a person is needed. When a business that wrote to Qder as a prospective customer is passed on to Qder's team, a draft reply may be written for Qder by a language model from Anthropic: the model receives the messages in the conversation, without telephone numbers or email addresses, and a person on Qder's team reads every such reply and sends it. Meta carries the messages under its own policy. As to how long a conversation is kept, see the retention policy.
Subscription billing. The subscription fee is paid by credit card. The card details pass from the browser directly to SUMIT, Qder's accounting and card-processing provider, and are kept there; Qder receives only a single-use token, the last four digits of the card and its expiry date. The card is cleared through UPay. SUMIT also keeps the business name, the company or dealer number, the billing contact's name and email address, and the receipts. Documents produced before 23 October 2026 are kept at iCount, Qder's accounting provider until that date.
Enquiries through Qder's Facebook and Instagram advertisements. A business that fills in a form in one of Qder's advertisements on Facebook or Instagram (a Meta lead form) sends to Qder, through Meta, what it filled in: name, business name, telephone number, email address, city, number of branches and its answers to the form's questions, and which advertisement it was. Qder's server retrieves the details from Meta and keeps them in the same way as an enquiry from the website, in order to get back to the business. The first reply and up to two follow-ups are drafted for Qder by a language model from Anthropic: the model receives the contact's first name, the business name, city, number of branches, the form's answers and the messages already sent, without the email address or telephone number. Usually, a person on Qder's team reads each message before it is sent by email or WhatsApp, and a message touching on price or terms is always sent only after approval. Meta keeps the form under its own policy.
The restaurant's address and location. The address and the point that the business marked on the map are shown to diners on the restaurant card in Qder's chat. In order to find the point, Qder's server sends only the restaurant's address to GovMap, the service of the Survey of Israel, and, if it is not found there, to OpenStreetMap (Nominatim); the answer is kept so that the question is not asked again. Diners send nothing to those services. The maps themselves are served from Qder's servers.

4A. Kin

Kin is a desktop application operated by Qder, in which the User gives tasks to several coding agents in one conversation ("Kin"). In this section, an "Agent" means a third-party program, such as Claude Code or Codex, that the User has installed on the User's computer and signed in to with the User's own account at its provider; and the "Buyer" means a User who has purchased a paid plan in Kin. In respect of the information described in this section, Qder is the controller.

Information that stays on the User's computer. The code and projects, the conversations with the Agents, attached files, the project instructions (other than instructions shared with a team, as set out below), the application's settings and the Agents' usage figures are kept on the User's computer only and are not transferred to Qder.
The Agents and their providers. Kin runs the Agents on the User's computer, under the User's own accounts with their providers (such as Anthropic or OpenAI). What an Agent sends to its provider, including code and the content of the conversation, passes from the computer directly to that provider, under the terms and policies between the User and the provider. Those providers are not Qder's sub-processors, and Qder does not receive that information.
The account. A Kin account is opened from within the application and is kept apart from the accounts of Qder's restaurant platform, in a store of its own at Supabase (as set out in section 5). On opening the account the User provides a full name, an email address and a password, and confirms that the User is 13 or older and accepts the Kin terms of sale and this Policy; Qder keeps the name, the address, the version of the terms accepted and the time of acceptance, and the password is managed at Supabase. The address is verified by a six-digit code sent to it by email, and such a code also serves to reset a password; the code is kept by Qder in hashed form only and is valid for 15 minutes; the record of the codes sent to an address, which serves to limit their number, is deleted within one day. An account whose email address is not verified within seven days is deleted. The account carries a mark that it may use Kin and how the mark was given (opening the account, or an invitation to a team). The sign-in key is kept in the operating system's credential store on the User's computer. The User may turn on two-factor sign-in, by which every sign-in also requires a six-digit code from an authenticator application; the secret from which the codes are generated is kept at Supabase, and cloud sync and remote control are available only to an account on which two-factor sign-in or a passkey is turned on. The User may also add passkeys (WebAuthn), by which the User signs in with the device's own verification (such as a fingerprint, face recognition or a PIN) without a password or a code; only the public key of a passkey and its name are kept at Supabase, and the device's verification never leaves the device.
Plan and payment. Qder keeps the plan, the number of seats, the plan's status and renewal dates, the currency in which it is charged, and each charge: its amount, currency, date, outcome and receipt. The card details pass from Kin directly to SUMIT and are kept there; Qder receives only a single-use token, the last four digits of the card, its expiry date and the name typed as the cardholder's name. An identity number, requested for an Israeli card only, passes directly to SUMIT and is not kept by Qder. The plan's currency is determined by the country from which the Buyer connects at the first purchase, as identified by Cloudflare from the IP address; only the currency is kept, not the country or the IP address.
Teams. On a Team plan, Qder keeps the team's name, the email addresses of the people invited to it, and the dates of invitation and joining. An invitee's address is provided to Qder by the person who pays for the team, and Qder uses it to send that person one invitation and to allow that person to enter Kin and join the team; a person who invites another represents that he or she may provide that address for this purpose. Instructions that a team member saves for a project are kept by Qder together with the address of the project's git repository, the email address of the person who saved them and the time of saving, and are provided to every member of the team.
Emails. Receipts, notice of a charge that did not go through, notice that a plan has ended, team invitations, a code to confirm the deletion of the account, notice that the account has been deleted and notice to the members of a team that it has ended are sent by email, as set out in section 5.
A copy of the information. From within Kin (Settings, Kin account), the User may download a copy of the information concerning the User that Qder keeps for Kin, as a single file, including the version of the terms accepted and the time of acceptance. The card details appear in the copy only as Qder keeps them (the last four digits, the expiry date and the name). The content of conversations kept for cloud sync is encrypted on the User's computer with a key that Qder does not hold, and the copy therefore lists those items without their content. So that cloud sync may be turned on on a further computer without a code, Qder also keeps that key in a form locked on the User's computer with a key derived from the User's Kin password; Qder does not keep the password, the locked key cannot be opened without it, and Qder provides the locked key only to a sign-in completed with the second factor through an authenticator application that was on the account when the key was locked. The key derived from the password is kept in the operating system's credential store on the User's computer, and is deleted from it on signing out. In the same manner, Qder keeps that key locked with a key derived on the User's device from a secret that a passkey of the User produces on that device and that is never sent to Qder or to Supabase; Qder provides that locked key only to a sign-in completed with the second factor or with a passkey.
Deletion of the account. The User may delete the Kin account from within Kin, after confirming with a code sent to the User's email address or with the User's password; while the outcome of a charge to the account has not yet been established, the account cannot be deleted until it is. On deletion: a paid plan ends at once and no further charge is made; the card is removed from SUMIT; a team that the User pays for ends, and its members, whose own accounts remain as they are, are notified by email; the User leaves any team of which the User is a member, and instructions that the User saved for such a team remain with that team without the User's email address; the information kept for cloud sync, the record of the User's computers, connections to GitHub not yet completed and the codes sent by email are deleted, and, where the computer from which the account is deleted holds a connection of Kin to GitHub, the authorization given to Kin at GitHub is revoked; and the account is deleted, together with the sign-in details at Supabase. Charges that were paid and their receipts are retained, together with the Buyer's email address, as tax records, for the period set out in the retention policy; Qder also retains a record of the deletion that contains the email address in hashed form only, the time of the deletion and a list of what was deleted and what was retained, without any content. Where a step of the deletion cannot be completed at once, the account is closed to sign-in immediately and the deletion is completed by an automated process that runs every night. No refund is made automatically on deletion; a User entitled to cancel a purchase within the first 14 days may cancel it with a refund from within Kin before deleting the account. Deleting the Kin account does not close the User's accounts with the providers of the Agents, which are closed with each provider separately, and does not delete information kept on the User's computer, which the User may remove through Kin when deleting the account or at any time. Information that has been deleted may remain in backups until they are replaced in their ordinary cycle, as set out in the retention policy.

This information is used to provide the service, to collect payment, to manage the team and to comply with legal obligations. Qder does not use it for marketing and does not pass it to others, except as set out in section 5. The retention periods are set out in the retention policy (Hebrew).

5. Recipients of the information

The restaurant at which the User is sitting

The order, the allergy note and the table number reach the kitchen screen of that branch. No other restaurant, not even another branch of the same chain, sees them. The chain manager sees the figures for all of that manager's branches, without diners' names, except in the case of a bill left unpaid (see the next paragraph). If the User ordered while signed in to an account, the branch manager sees, on the screen for the table at which the User is sitting only: the User's name, the User's telephone number (if the User gave one), and the allergies and preferences saved in the User's account. That serves a single purpose: that whoever comes to the table knows what not to bring. The account of a branch waiter sees only the allergies and preferences on that screen, without the name and the telephone number. The information disappears from the screen when the table is cleared. An email address that the User entered at payment is kept in the Restaurant's payment record, in order to send a confirmation and to notify the User of a refund. In the case of a booking, the Restaurant sees the name and telephone number that the User gave, and branch staff see in the panel only that day's bookings, not the whole booking diary.

Unpaid bills

If the User left the table while the bill was still open, the User's contact details (the name, telephone number and email address on the User's account, and an email address that the User typed on a payment page that was not completed) are shown to the branch and to the chain's management, so that they can contact the User and collect what is owed. That is the only purpose, and the legal basis is the Restaurant's legitimate interest in collecting a debt. The details are not stored anywhere else: they are read from the User's account at that moment, shown only while the bill is open, and leave the screen as soon as the bill is settled or voided. Where the User ordered without an account and without starting a payment, Qder has nothing to provide, and will provide nothing. The business undertakes to Qder, in the engagement agreement, to use these details for collecting that bill alone, and not for marketing.

Qder's sub-processors

Entity	Function	Information received	Location
Cloudflare	Hosts the website, the server and the database; counts page views (Web Analytics, without cookies and without any device identifier; this can be switched off); protects Qder's internal operations console (Cloudflare Access; applies to Qder's staff only, and not to diners or to restaurants); and runs Qder's own age-verification service (reading the document and comparing the face)	Everything kept in the system; if the User chose to verify his or her age, the photograph of the identity document and the selfies, in memory only and for the duration of the check; for the page count: the page address, the page from which the User arrived, the browser type and load timings, without any identifier	The database is in Western Europe; the network is global
Supabase	Identity management: passwords and their reset, signing in with Google and Microsoft, passkeys (WebAuthn) and two-factor sign-in with an authenticator application; and storage of the documents attached to applications	Email address and password, for accounts; the public key of a passkey; the secret of an authenticator application; business documents	Frankfurt, Germany
Google and Microsoft (only if the User chose to sign in through them)	Verify the User's identity at sign-in	They see that the User asked to sign in to Qder.ai; what reaches Qder is the User's name and email address, and nothing more	In accordance with the provider's policy
OpenAI	Runs the language model behind the digital waiter, the business assistant, the kitchen and bar screen assistant and Qubi in the website chat and on WhatsApp, and transcribes a recording if the User chose to speak instead of typing (and a recording of an employee speaking to a kitchen or bar screen); at restaurants that have turned on the spoken conversation, also conducts that conversation itself (the voice passes through Qder's server and is not kept)	See Use of artificial intelligence: the message, the menu, what has been ordered, the note written in the booking of the table and, if the User has an account, the allergies, the previous visit to that chain, and whether the User is under 18 or has a birthday today (neither the date itself nor the age), as well as, if the User has turned on taste memory, the kinds of dishes that the User tends to choose (see section 2, "Taste memory"). Not a name, email address, telephone number or IP address. From the kitchen and bar screen assistant: what the employee said or typed (or the recording, for transcription only), that station's menu, and that screen's open orders, namely the table number, dishes, preparation notes and the order's allergy note, without any diner's name, telephone number or email address. From the website chat: the messages of the conversation, after email addresses, telephone numbers and identifying numbers have been removed, and passages from the website's public pages	United States
Anthropic	Drafts Qder's messages to businesses that left their details in one of Qder's advertisements (the first reply and up to two follow-ups)	The contact's first name, the business name, city, number of branches, the form's answers and the messages already sent. Not an email address or telephone number. Nothing about diners is sent to it	United States
Kapso	Connects Qder's WhatsApp number to WhatsApp's business platform and passes messages between WhatsApp and Qder	The telephone number and the name shown on WhatsApp of whoever writes to Qder there, and the messages in the conversation, including earlier messages on Qder's number from before it was connected. Nothing from diners' orders	United States
Cloudflare (email service) and Resend (backup)	Send Qder's email	The email address and the content of the message: booking confirmation, cancellation, application approval, a link to set a password, and a payment confirmation and a refund notice to the address that the User entered	Cloudflare: global network; Resend: United States
The Restaurant's payment processor (PayPlus, Hyp, Grow, Cardcom, Tranzila or Rapyd, depending on which of them the Restaurant works with)	Takes the payment	What the User types on its page and, if the User is signed in to an account or entered an email address at payment, the User's name and email address, so that the Restaurant's payment page and receipt are in the User's name. Without an account, only the table number is passed on. Subject to the processor's own policy and that of the Restaurant, not to Qder's	Israel
SUMIT (Qder's accounting and card-processing provider)	Keeps the credit card of a business and of a Kin Buyer, charges the subscription fee and the Kin plans, and produces the receipts	The card details (directly from the browser or from Kin, not through Qder), the business name, the company or dealer number, the billing contact's name and email address, the charge lines and the receipts; and for a Kin Buyer: the cardholder's name, the email address, an identity number for an Israeli card, and the charge lines. Nothing from diners and nothing from orders	Israel
UPay (SUMIT's card acquirer)	Clears the card charges for the subscription and for Kin plans	The card transaction, as passed on by SUMIT. Nothing from diners and nothing from orders	Israel
iCount (Qder's accounting provider until 23 October 2026)	Keeps the transaction accounts and the receipts produced there until that date	The business name, the company or dealer number, the billing contact's name and email address, the account lines and the documents. Nothing from diners and nothing from orders	Israel
HubSpot (management of Qder's contact with businesses)	Holds Qder's conversations with businesses that contacted Qder, or that Qder approaches, before they become customers: who, at what stage, and the next step	The business contact's name, the business name, city, number of branches, email address, telephone number and role, and the stage of Qder's conversation with them; only businesses recorded from 23 September 2026 onwards, and never applicants or customers. Never any diner data	HubSpot's EU data centre

None of them is permitted to use the information for its own purposes. Qder does not sell information and does not pass it on to advertisers. Qder will not provide information to a competent authority unless the law requires it to do so.

6. Transfer of information outside Israel

Information is stored in Europe (Cloudflare, Supabase and HubSpot). Information is transferred outside Israel and Europe to the following recipients, as set out in the table in section 5: the AI model provider (OpenAI, United States), for conversations with the digital waiter, the assistants and Qubi, and for the spoken conversation; Anthropic (United States), for drafting messages to businesses that left their details; Kapso (United States), for relaying WhatsApp messages; Resend (United States), as a backup for sending email, which is ordinarily sent through Cloudflare's global network; and Google or Microsoft, under their own policies, if the User chose to sign in through them. The transfer is necessary in order to provide the service that the User asked for, and it is made to providers that are contractually bound to maintain information security and not to use the information for their own purposes, in accordance with the Protection of Privacy Regulations (Transfer of Information to Databases Abroad), 5761-2001.

7. Age

A personal account opens from the age of 13, with a date of birth. Opening an account and ordering through it are acts customary for persons of that age and do not require a parent's consent. If the date of birth shows that the account holder is not yet 13, the account and all the information collected in it will be deleted. A person younger than that is able to order without an account, and Qder does not knowingly collect identifying information from children under 13; if Qder learns by other means that such an account has been opened, Qder will delete it. Alcoholic drinks are sold only from the age of 18: the system will not add them to an order for any person whose date of birth on the account indicates that he or she is not yet 18, and it marks every order containing alcohol for the Restaurant's staff to check identification. A diner who has verified his or her age (see section 2) is marked "age verified" to the staff, and the Restaurant may nevertheless ask for identification. The actual check rests with the Restaurant, as the seller.

8. The User's rights

The User has the right to know what is kept concerning the User, to receive a copy of it, to correct it and to delete it. A full copy can be downloaded as a file in a single click, for diners and businesses alike (a business receives all of the chain's or the branch's data, including an export to Excel). At Qder, these are buttons on the account page, not forms. The full explanation, including whom to contact if the User does not have an account, is on the page Your rights over your data.

9. Amendments to this Policy

If Qder changes anything material (what information is collected, who it reaches or how long it is kept), Qder will update the date at the top of the page and show it in the system. Qder does not amend this Policy in order to widen the uses of information already collected.