Privacy policy
Version 3.0 · Effective 4 August 2026 · Supersedes version 2.0 (2 August 2026)
1. About this policy
This Privacy Policy describes how Splitbite SRL processes personal data across every part of its platform. It is written to satisfy the transparency obligations in Articles 12, 13 and 14 of Regulation (EU) 2016/679 (the "GDPR"), the transparency obligations in Regulation (EU) 2024/1689 (the "EU AI Act"), Romanian Law 190/2018, and Directive 2002/58/EC as amended (the "ePrivacy Directive").
It covers three distinct applications, each with a different user population and a different processing profile:
| Application | Users | Our role |
|---|---|---|
| Guest application (client.splitbite.ai and venue subdomains) | Diners and venue guests | Joint controller with the venue for service delivery; sole controller for platform improvement, AI development and Derived Data |
| Waiter application (waiter.splitbite.ai and venue subdomains) | Venue floor and service staff | Processor on behalf of the venue (the venue is the employer and controller) |
| Admin application (admin.splitbite.ai, analytics.splitbite.ai, editor.splitbite.ai) | Venue owners, managers and Splitbite staff | Processor for venue-directed processing; controller for our own analytics and product development |
| Agent system (background automation) | No direct users | Processor on venue instruction; controller for aggregate intelligence |
| This website (splitbite.ai) | Visitors and prospects | Sole controller |
If you only want the short version: we collect a great deal of behavioural data about how guests use digital menus, we use it to personalise what they see and to train our models, we build commercial data products from it, and where those products contain personal data we will only share them with your explicit consent. Sections 5, 9, 16 and 17 are the ones most people want to read.
2. Controller identity and contact
| Legal entity | Splitbite SRL |
| Registered office | Bucharest, Romania |
| Establishment | Established in the European Union; no Article 27 representative required |
| Data protection contact | privacy@splitbite.ai |
| Security disclosure | security@splitbite.ai |
| Lead supervisory authority | ANSPDCP (Romania) |
We have appointed an internal privacy lead reachable at the address above. We have assessed our processing against Article 37(1) GDPR and will formally designate a Data Protection Officer, and publish their contact details here, at the point our processing meets the threshold for mandatory designation.
3. Definitions
- "Guest" — an individual who uses the Splitbite guest interface at a participating venue, whether or not they create an account.
- "Venue" or "Customer" — the hospitality business that has contracted with Splitbite and at whose premises the guest interface is presented.
- "Guest Identifier" — the pseudonymous identifier generated in the guest's browser on first use and stored locally as
splitbite-guest-id. It is the key against which behavioural events are recorded. - "Account Identifier" — the identifier issued by our identity provider when a guest registers, used as the primary key of the stored profile.
- "Behavioural Event" — a single recorded interaction (a screen view, an item view, a dwell measurement, an add-to-cart, a search query, and so on).
- "Derived Data" — data produced by our processing of source data: aggregates, statistics, benchmarks, inferred attributes, scores, model parameters and reports.
- "Special Category Data" — the categories listed in Article 9(1) GDPR. In our system this means dietary and allergen information that reveals health status or religious belief. See section 6.
- "Sub-processor" — a third party we engage to process personal data on our behalf.
4. What each application does
4.1 Guest application
A guest scans a QR code at a table. The application identifies the venue and table, presents a digital menu, and reorders that menu according to what it knows or infers about the guest. The guest can browse, view dish detail, save favourites, build a cart shared with others at the same table, place an order, split a bill, ask a natural-language question about the menu, request a waiter, indicate a payment method, and optionally register an account holding preferences and dietary information.
4.2 Waiter application
Floor staff authenticate with a venue-scoped numeric code and receive real-time notifications when a table requests service, together with the table number and the reason for the request. Staff dismiss notifications, and the time taken to do so is recorded.
4.3 Admin application
Venue managers view aggregate performance, a conversion funnel, per-dish engagement and conversion metrics, AI feature performance, and a guest relationship view listing individual guests ranked by spend, with their contact details, visit history, ordered and viewed items, dietary tags, and the natural-language queries they have typed. Managers also edit menus, process menu photography, manage staff records, and configure integrations.
4.4 Agent system
Background automation authenticates to a venue's other software using credentials the venue has supplied, extracts operational data (sales, labour, invoices, reviews, scheduling), stores it, and proposes or executes actions. Certain actions require human approval before execution.
5. Personal data we process
The following is a complete inventory by data subject category. Field names are given where they help you understand precisely what is held.
5.1 Guest identity and account data
- Email address and/or mobile telephone number, used as the account username.
- Given name or chosen first name.
- Account Identifier issued by our identity provider.
- Password, held only in hashed form by the identity provider and never accessible to us in plaintext.
- Verification codes sent by email or SMS, transient.
- Profile photograph, where the guest chooses to upload one.
- Guest Identifier, display name and assigned display colour used for shared-table sessions.
5.2 Guest preference and profile data
- Stated preferences (
preferences) — for example cuisine and flavour leanings. - Dietary and allergen selections (
dietary) — see section 6, this includes Special Category Data. - Taste profile (
tasteProfile) — derived from an optional in-app questionnaire. - Saved favourites (
favorites). - Free-text and inferred notes (
notes) — including preferences our system extracts from things a guest types, such as how they like a steak cooked. - Loyalty and reward state (
rewards).
5.3 Guest behavioural data
The guest application records a detailed event stream. Recorded event types include, without limitation: session start, QR scan, screen view, screen back-navigation, welcome-screen exit with elapsed time, category view, dish view, dish view close with elapsed viewing time, popup open and close, add to cart, remove from cart, cart view, order placement with line items and total, payment started, payment complete, favourite reorder, individual button taps, language change, theme change, logout, onboarding completion, profile sign-up, profile login, profile update, questionnaire skip, and a family of AI interaction events covering search queries, responses, errors, prompts shown, items added from a prompt, upgrade declines, follow-up taps, quick-action taps, panel dismissal and meal feedback.
Each event carries the Guest Identifier, the guest's display name where set, the venue identifier, a session key, a millisecond timestamp, and an event-specific payload. Derived measurements include per-dish dwell time, scroll dwell duration, count of items viewed in a session, session age, time from scan to first cart addition, and time from scan to order.
5.4 Guest transactional and table data
- Cart contents, quantities, unit prices, special requests and item-level notes.
- Order history with line items and totals.
- Table identifier, which places a guest at a specific table in a specific venue at a specific time.
- Co-diner participation on a shared table, including the display names of others at that table.
- Bill split arrangements and per-participant shares.
- Selected payment method (card or cash) and tip percentage or amount.
- Service requests, the reason selected, and any accompanying detail.
We do not process payment card data. No card number, expiry, security code, IBAN or payment token is captured, transmitted or stored by any part of the platform. Where a guest indicates they will pay by card, the platform notifies staff to bring a terminal, and the card transaction takes place on the venue's own payment infrastructure entirely outside Splitbite.
5.5 Technical and device data
- Device type classification, browser and operating system characteristics.
- IP address, processed in transit and in server logs.
- Approximate location derived from IP address, and coordinates derived from it. See section 5.9.
- Language and interface theme selection.
- Session identifiers and authentication tokens.
- Web push subscription endpoints and cryptographic keys, for staff devices only.
5.6 Natural-language input
Where a guest types a question or request into the AI feature, we process the text of that query. Queries are truncated at 300 characters and conversational context at 500 characters. Query text is stored as part of the behavioural event stream, is aggregated into a ranked list of the most frequent queries at a venue, and is surfaced to venue managers in the guest relationship view attributed to the individual guest who typed it. Guests should assume that anything typed into the assistant is retained and visible to venue staff, and should not enter information they do not wish the venue to see.
5.7 Venue workforce data
Processed on behalf of the venue as employer:
- Staff member identifier and full name.
- Venue-scoped numeric access code.
- Assigned tables and shift-level assignment data.
- Authentication events and failures.
- Service response times, measured per notification and per staff member.
- Web push subscription state per device.
- Where the venue has connected a workforce management system, records extracted from it, which may include employee lists, scheduled and actual hours, time punches, labour cost percentages and productivity measures.
Where the admin application presents fatigue-risk indicators or per-staff performance rankings, these are computed from the above. Venues deploying such features are responsible for compliance with applicable employment law, works council consultation requirements and any national rules on employee monitoring, and must inform their staff accordingly.
5.8 Venue administrator data
- Email address, used as the account key.
- The set of venues the account is authorised to administer.
- Authentication and session events.
- Business contact and billing information.
5.9 Location data
We do not request or use device GPS. We do not use browser geolocation, geofencing or physical beacons. Where a contextual suggestion feature is active, the guest's IP address is sent to an IP-geolocation provider to obtain an approximate city-level position, and the resulting coordinates are sent to a weather service to retrieve local conditions. Both providers are named in section 15. Location is additionally implicit in the table identifier, which necessarily places a guest at a known venue.
5.10 Website visitor data
- Enquiry form content: business name, contact name, email address, telephone number and message.
- Standard server log data.
This website loads no third-party analytics, advertising or session-recording technology. The only external requests it makes are for web fonts.
5.11 Data we do not process
For the avoidance of doubt, across the entire platform we do not: capture audio or use a microphone; perform speech recognition or transcription; access a device camera; perform facial recognition, biometric identification or emotion inference; process payment card data; use device fingerprinting libraries; use GPS; or deploy third-party advertising trackers.
6. Special category data
This section is deliberately prominent because it carries the highest legal sensitivity in our system.
The guest application offers a dietary selector containing the following options: vegetarian, vegan, gluten-free, dairy-free, nut allergy, shellfish allergy, halal, kosher, low carbohydrate, and no pork.
Several of these reveal information falling within Article 9(1) GDPR:
| Selection | Category revealed |
|---|---|
| Nut allergy, shellfish allergy | Data concerning health |
| Gluten-free, dairy-free | Capable of revealing data concerning health (coeliac disease, lactose intolerance) |
| Halal, kosher, no pork | Capable of revealing religious or philosophical belief |
| Free-text statements such as "I'm coeliac" typed into the assistant | Data concerning health |
Legal basis. We rely exclusively on explicit consent under Article 9(2)(a) GDPR for all processing of Special Category Data. Providing dietary information is entirely optional and the guest application is fully usable without it. Consent is obtained at the point of selection, is recorded, and may be withdrawn at any time by clearing the selections in the profile screen or by contacting us. No inference of dietary or health status is made from behaviour alone.
How it is used. Dietary selections are used to reorder the menu so that conflicting dishes are demoted, to filter dishes where a guest states an allergen in natural language, and to display dietary tags to venue service staff so they can serve the guest safely. They are included in the guest record visible to venue management.
What we never do with it. Special Category Data is excluded from every commercial data product. It is never licensed, sold, shared with advertisers or data brokers, used for advertising segmentation, or included in any dataset made available to a third party, whether in identifiable, pseudonymised or aggregated form. It is not used to train models made available to any party other than Splitbite. It is not used to make any decision about pricing, service eligibility or access.
Safety limitation. Allergen filtering is a convenience feature and is not a food-safety control. It operates on keyword matching over text a guest types and on allergen labels supplied by the venue. It can fail. Guests with a medically significant allergy must tell a member of staff directly and must not rely on the application. This limitation is also stated in our Terms of Service and is surfaced in the application itself.
7. Sources of data
- Directly from the guest — registration details, preferences, dietary selections, typed queries, orders and special requests.
- Observed from device interaction — the behavioural event stream, dwell measurements, device characteristics.
- Inferred by our systems — taste profiles, item affinities, inferred preferences extracted from free text, segment classifications, propensity and value estimates.
- From the venue — menu structures, allergen labelling, table configuration, staff records.
- From the venue's connected systems — where a venue authorises access, operational records extracted from its point-of-sale, invoicing, accounting, scheduling, marketing and reputation platforms.
- From publicly accessible sources — during venue onboarding we retrieve publicly available business information, including public review content, business listings and published menus. This can incidentally include personal data contained in public reviews written by third parties.
8. Purposes and legal bases
| Purpose | Categories used | Legal basis |
|---|---|---|
| Presenting the menu, taking orders, coordinating a shared table | Identity, transactional, technical | Contract, Art. 6(1)(b) |
| Account creation, authentication, password reset | Identity | Contract, Art. 6(1)(b) |
| Personalising and reordering the menu | Preference, behavioural, dietary | Consent, Art. 6(1)(a); and Art. 9(2)(a) for dietary |
| Dietary and allergen handling | Special Category | Explicit consent, Art. 9(2)(a) |
| Answering natural-language queries | Query text, cart, menu | Contract, Art. 6(1)(b) |
| Proactive suggestions and upselling | Behavioural, transactional | Legitimate interests, Art. 6(1)(f) |
| Routing service requests to staff | Table, request reason, staff identity | Contract, Art. 6(1)(b) |
| Venue analytics and the guest relationship view | Identity, behavioural, transactional, preference | Legitimate interests of the venue, Art. 6(1)(f) |
| Cross-venue guest profile | Preference, behavioural | Consent, Art. 6(1)(a) |
| Staff performance and response measurement | Workforce | Legitimate interests of the employer, Art. 6(1)(f), subject to national employment law |
| Improving the platform and developing features | Behavioural, technical, aggregated | Legitimate interests, Art. 6(1)(f) |
| Training, tuning and evaluating our models | Behavioural, transactional, query text; Special Category excluded | Legitimate interests, Art. 6(1)(f) |
| Producing anonymised market intelligence and benchmarks | Aggregated only, no longer personal data once anonymised | Legitimate interests, Art. 6(1)(f) for the anonymisation step |
| Licensing or selling data products that contain personal or pseudonymised data | Behavioural, transactional; Special Category excluded | Consent, Art. 6(1)(a). Not carried out in the absence of consent |
| Security, abuse prevention, integrity of the service | Technical, authentication | Legitimate interests, Art. 6(1)(f) |
| Service and transactional messages | Identity | Contract, Art. 6(1)(b) |
| Marketing communications | Identity | Consent, Art. 6(1)(a) |
| Accounting, tax, statutory records | Business, transactional | Legal obligation, Art. 6(1)(c) |
| Responding to lawful requests, defending claims | As applicable | Legal obligation, Art. 6(1)(c); legitimate interests, Art. 6(1)(f) |
On legitimate interests. Where we rely on Article 6(1)(f) we have carried out and documented a balancing assessment weighing our interest against the rights and freedoms of the data subject, and have applied mitigations including retention limits, exclusion of Special Category Data, pseudonymisation where feasible, and an unconditional right to object. A summary of any assessment is available on request to privacy@splitbite.ai.
On consent. Where we rely on consent, it is requested separately for each purpose, recorded, and withdrawable at any time without detriment to the guest's ability to use the service for its core purpose. Withdrawal does not affect the lawfulness of processing already carried out.
9. Profiling and the cross-venue guest profile
We profile guests. This section states plainly what that means.
9.1 What profiling occurs
- Every dish and category a guest views, and how long they look at it, is recorded and attributed to their Guest Identifier.
- The menu is scored and reordered for each guest from their favourites, stated preferences, taste profile and dietary selections.
- Preferences are inferred from free text a guest types and written back to their stored profile.
- Behavioural triggers evaluate cart contents, scroll dwell, items viewed, session age and the number of people at the table, and fire suggestion prompts when thresholds are met.
- The venue-facing guest view ranks individual guests by total spend and presents their history, dietary tags and typed queries.
9.2 Linkage of pre-registration activity
Behavioural events are recorded against the pseudonymous Guest Identifier from the first interaction, before any account exists. If a guest subsequently registers, that identifier is written into their profile, and their earlier browsing history becomes attributable to their identified account. Guests should understand that registering links prior anonymous activity at that venue to their identity.
9.3 The cross-venue profile
- Opt-in only. A profile travels between venues only where the guest has given consent specifically for that purpose. Consent to personalisation within a single venue is separate and does not imply cross-venue consent.
- What travels. Preferences, dietary selections, taste profile, saved favourites and inferred taste notes.
- What does not travel. A venue's own commercial records: its pricing strategy, margins, supplier terms, staff data and its own aggregate analytics. One venue does not receive another venue's transaction records.
- Withdrawal. Consent may be withdrawn at any time, after which the profile ceases to be shared onward. Data already lawfully shared with a venue before withdrawal remains subject to that venue's own retention obligations.
9.4 Right to object
A guest may object at any time to profiling carried out on the basis of legitimate interests, including the suggestion engine and analytics profiling, by writing to privacy@splitbite.ai. Where the objection concerns direct marketing, we will stop without assessment. Where it concerns other legitimate-interest processing, we will stop unless we can demonstrate compelling legitimate grounds that override the objection.
10. Automated decision-making
Article 22 GDPR restricts decisions based solely on automated processing that produce legal effects or similarly significantly affect an individual.
Our assessment is that no processing in the guest application meets that threshold. Menu reordering, suggestion prompts and dish filtering change what is presented but do not determine access to a service, price, creditworthiness, or any legal entitlement. Prices are set by the venue and are not personalised by the platform. No guest is refused service, charged differently, or subjected to any adverse consequence by automated means.
Notwithstanding that assessment, we provide the Article 22(3) safeguards as a matter of policy:
- Personalisation can be switched off, returning the menu to its default order.
- A guest may request human review of any automated output that affected them.
- A guest may contest an output and require correction of the underlying data.
In the venue-facing and workforce-facing features, any output that could materially affect an employee — including fatigue-risk indicators and performance rankings — is advisory only. It must not be used as the sole basis for a disciplinary, scheduling-detriment or termination decision, and the venue as employer is contractually required to apply human judgement. Where a venue intends to rely on such an output, that venue is the controller for that decision and must satisfy Article 22 itself.
11. Artificial intelligence
11.1 System inventory
| System | Function | Inputs | Technology |
|---|---|---|---|
| Menu assistant | Answers natural-language questions, recommends dishes | Guest query, conversation context, menu, cart, venue name | Large language model hosted in the EU |
| Suggestion engine | Generates proactive prompts | Cart, dwell, view count, session age, table size | Rule-based triggers plus language model for copy |
| Dish explanation | Describes dishes and ingredients | Menu item data | Large language model |
| Menu personalisation | Scores and reorders the menu | Favourites, preferences, taste profile, dietary | Deterministic scoring, executed in the browser |
| Allergen filter | Removes conflicting dishes, appends a warning | Guest query text, venue allergen labels | Keyword matching |
| Preference inference | Extracts and stores preferences from free text | Special requests, typed notes | Pattern matching |
| Pairing engine | Suggests accompaniments | Menu structure, engagement counters | Rule-based, with conversion tracking |
| Speech synthesis | Reads text aloud | Assistant and menu text | Third-party synthesis provider, with a browser fallback |
| Menu photography processing | Extends, upscales and corrects images | Venue-supplied photographs | Third-party generative image model |
| Menu document extraction | Reads menus from uploaded documents | Venue-supplied documents | Optical character recognition and vision model |
| Onboarding agent | Assembles a venue profile | Public web sources, uploads | Language model with retrieval |
| Operations agent | Plans and executes actions in connected systems | Extracted operational data | Language model planner with approval gates |
Model inference for our own assistant and planning features is executed within the European Union. Speech synthesis and generative image processing are performed by third-party providers, which may involve transfer outside the EEA as set out in section 17.
11.2 Training and improvement
We use platform data to train, tune and evaluate our own models. The following constraints apply and are binding on us:
- Special Category Data is excluded from all training corpora.
- Direct identifiers are stripped before data enters a training corpus.
- We do not permit our third-party model providers to train their foundation models on data we submit through their services, and our commercial arrangements with those providers reflect that.
- Training data is documented, version-controlled, and assessed for representativeness and bias in line with Article 10 of the EU AI Act.
11.3 EU AI Act position
We have classified each system above against the risk framework in Regulation (EU) 2024/1689.
- Prohibited practices (Article 5). None of our systems engage in prohibited practices. We do not deploy subliminal or manipulative techniques designed to distort behaviour in a way that causes significant harm, we do not exploit vulnerabilities of specific groups, we do not perform social scoring, we do not use biometric categorisation or emotion inference, and we do not conduct real-time remote biometric identification.
- High-risk (Annex III). The guest-facing systems do not fall within an Annex III category. Workforce-facing features touch the employment domain, which is an Annex III area. We therefore treat any feature that evaluates or ranks workers as high-risk by policy, and apply the corresponding obligations — risk management, data governance, technical documentation, logging, human oversight and accuracy monitoring — regardless of whether the classification is ultimately mandatory.
- Transparency obligations (Article 50). Guests are told when they are interacting with an AI system rather than a person. Synthetic audio output is identified as such. AI-generated recommendations are labelled. Images materially altered by generative processing are marked as such in the venue's asset library.
- General-purpose AI. We are a deployer of third-party general-purpose models, not a provider of them. Where we fine-tune or substantially modify a model we assume the corresponding provider obligations.
We maintain, and will make available to a market surveillance authority on request: a system inventory, risk assessments, data governance records, technical documentation, human-oversight procedures, performance and accuracy monitoring records, incident logs, and post-market monitoring output.
11.4 Human oversight
Venues configure which agent actions execute autonomously and which require explicit human approval. An approval queue, a full audit log of every action taken, an immediate stop control, and the ability to revoke a system connection are available at all times. Splitbite does not override a venue's oversight configuration.
12. Recipients of personal data
12.1 The venue
The venue at which a guest uses the application receives that guest's identity where provided, preferences, dietary tags, order and visit history, viewed items, typed queries, spend total and device type. Venue staff receive the table number and service request reason. The venue is an independent or joint controller for its own use of that data and applies its own retention and privacy practices.
12.2 Other venues
Only where the guest has consented to a cross-venue profile, and limited to the fields listed in section 9.3.
12.3 Sub-processors
We engage the following categories of sub-processor. Each is engaged under a written agreement imposing obligations equivalent to those in Article 28 GDPR.
| Function | Provider | Data involved | Location |
|---|---|---|---|
| Cloud infrastructure, storage, identity, messaging | Amazon Web Services | All categories | EU (Paris), with the exceptions in section 17 |
| Language model inference | Amazon Bedrock (Anthropic models) | Query text, menu, cart | EU (London) |
| Document text extraction | Amazon Textract | Venue-supplied documents | EU |
| Speech synthesis | ElevenLabs | Text to be spoken | Outside EEA |
| Generative image processing | Google (Gemini) | Venue menu photographs | Outside EEA |
| Business listing and place data | Google Places / Maps | Venue business data | Outside EEA |
| Web search and retrieval | SerpAPI, Firecrawl, Jina | Public web content, venue queries | Outside EEA |
| IP geolocation | ipapi | Guest IP address | Outside EEA |
| Weather data | Open-Meteo | Approximate coordinates | EU |
| Browser push delivery | Browser vendor push services | Staff push endpoint, notification content | Varies by vendor |
| Remote application streaming | Amazon AppStream | Session identifiers | United States |
A current and specific sub-processor list, including legal entity names and processing locations, is maintained and available to Customers on request. Customers under a Data Processing Agreement receive advance notice of new sub-processors and may object on reasonable data-protection grounds.
12.4 Venue-authorised connected systems
Where a venue instructs us to connect to its other software, we exchange data with those systems on its behalf. Systems in this category include point-of-sale, inventory, invoicing and accounting, workforce scheduling, marketing and reputation platforms. The venue is responsible for the lawfulness of that access and for its own agreements with those providers. Several are established outside the EEA.
12.5 Professional advisers and authorities
Auditors, insurers and legal advisers under duties of confidentiality; and public authorities where disclosure is required by law. We assess every request for validity and scope, decline requests lacking a lawful basis, disclose the minimum necessary, and notify the affected Customer unless legally prohibited.
12.6 Corporate transactions
In connection with a merger, acquisition, financing or sale of assets, data may be disclosed to prospective counterparties under confidentiality undertakings and, on completion, transferred to the successor entity subject to this policy or a successor policy no less protective.
12.7 Parties we do not share with
We do not sell or share personal data with advertising networks, data brokers, credit reference agencies or insurers for their own purposes. We do not participate in real-time bidding or cross-site advertising.
13. Commercial use of data
Creating value from the data the platform generates is a deliberate part of our business model. We describe it precisely rather than in general terms, because vagueness here is what makes privacy policies untrustworthy.
13.1 Anonymised and aggregated products
We produce and may license or sell: category and cuisine demand trends, regional and seasonal performance patterns, menu engineering benchmarks, price elasticity indicators, conversion and engagement benchmarks, and comparative venue performance indices. These are derived from pooled data across venues.
Before any such product leaves our control we apply an anonymisation standard requiring that: all direct identifiers are removed; no cohort smaller than a defined minimum threshold is reported; outliers capable of singling out an individual or an individual venue are suppressed; and the residual re-identification risk is assessed as remote taking account of data reasonably available to the recipient. Where that standard is met the output is not personal data and Chapter III GDPR rights do not attach to it. Where it cannot be met, the output is treated as personal data and section 13.2 applies instead.
13.2 Products containing personal or pseudonymised data
We will only license, sell or otherwise disclose a data product containing personal or pseudonymised data to a third party where the data subject has given specific, informed, freely given, granular and withdrawable consent to that disclosure, obtained separately from any other consent, and naming the categories of recipient. In the absence of such consent we do not carry out that processing. Consent is not a condition of using the platform and refusing it has no effect on service quality.
13.3 Absolute exclusions
The following are never included in any product disclosed outside Splitbite, in any form: Special Category Data; authentication credentials; access codes; profile photographs; contact details; free-text content capable of identifying an individual; and staff records.
13.4 Contractual controls on recipients
Every recipient of a data product is bound by written terms prohibiting re-identification, prohibiting combination with other datasets for the purpose of re-identification, prohibiting onward sale unless expressly permitted, requiring deletion on termination, and permitting audit. Breach terminates the licence immediately.
13.5 Venue data
A venue's own commercial data is used in pooled benchmarks only in a form that does not identify the venue, unless the venue agrees otherwise. Named comparative disclosure requires the venue's written consent.
14. Retention
Retention is enforced by automated expiry where the table supports it, and by scheduled review otherwise.
| Data | Retention | Mechanism |
|---|---|---|
| Behavioural event stream | 90 days from the event | Automated expiry |
| Venue analytics events | 90 days from the event | Automated expiry |
| Service request notifications | 24 hours | Automated expiry |
| Shared table state and carts | Session, then short-term expiry | Automated expiry |
| Agent-extracted operational data | 90 days | Automated expiry |
| Agent execution records | 90 days | Automated expiry |
| Onboarding uploads | 30 days | Storage lifecycle rule |
| Guest account and profile, including dietary selections | Life of the account, then 24 months after last interaction | Scheduled review and deletion |
| Profile photographs | Deleted with the account | Scheduled review and deletion |
| Order history | Reconstructed from the event stream, therefore effectively 90 days | Automated expiry |
| Staff records and access codes | Duration of employment as notified by the venue, then 12 months | Venue instruction and scheduled review |
| Administrator accounts | Duration of the Customer relationship, then 12 months | Scheduled review |
| Enquiry form submissions | 24 months | Scheduled review |
| Server and access logs | 90 days | Automated expiry |
| Billing, invoicing and statutory accounting records | As required by Romanian law, currently 10 years | Legal obligation |
| Consent records and processing logs | Retained while needed to evidence compliance, then 6 years | Scheduled review |
| Anonymised aggregates and model parameters | Indefinite, as these are not personal data | Not applicable |
On expiry or an accepted erasure request, data is removed from production systems within 30 days and from encrypted backups within 90 days, save where continued retention is required to comply with a legal obligation, to establish or defend a legal claim, or where the data has already been irreversibly anonymised. Anonymised derivatives and model parameters are not reversed, because they no longer constitute personal data and cannot be attributed to an individual.
15. Security
15.1 Technical measures
- Encryption in transit using TLS 1.2 or above for all connections.
- Encryption at rest for all databases, object storage and backups.
- Secrets and credentials held in a managed secrets service with envelope encryption; never in source code or configuration files.
- Least-privilege access policies scoped per service function.
- Network isolation between the public edge and data stores, with no direct public access to databases.
- Multi-factor authentication for administrative and infrastructure access.
- Content Security Policy, HTTP Strict Transport Security, frame denial, referrer restriction and content-type enforcement at the edge.
- Input validation and prompt-injection filtering on all text passed to language models.
- Centralised logging, retention of audit trails, and alerting on anomalous access patterns.
- Automated dependency and vulnerability scanning.
- Backups with tested restoration procedures.
15.2 Organisational measures
- Documented information security policy set, reviewed at least annually.
- Role-based access with formal joiner, mover and leaver procedures.
- Confidentiality obligations in all employment and contractor agreements.
- Security and data protection training on induction and periodically thereafter.
- Change management with peer review before production deployment.
- Documented incident response plan with defined roles and escalation paths.
- Vendor due diligence before engaging any sub-processor.
- Privacy by design and by default assessment for new features.
15.3 Independent assurance
We commission independent penetration testing of the platform and remediate findings on a risk-prioritised basis. Summary attestation letters are available to Customers under a Data Processing Agreement on request.
15.4 Honest statement of limitations
No system is perfectly secure. We do not represent that the platform is immune from compromise. We commit to the measures above, to prompt notification if something goes wrong, and to telling Customers the truth about what happened.
16. Compliance frameworks
We are precise about the difference between holding a certification and operating a control set aligned to a standard, because conflating the two would itself be a misrepresentation.
| Framework | Our position |
|---|---|
| GDPR (EU) 2016/679 | Directly applicable and complied with. Not a certification. We meet the obligations of a controller and of a processor as applicable. |
| Romanian Law 190/2018 | Directly applicable and complied with. |
| ePrivacy Directive 2002/58/EC | Directly applicable and complied with as implemented in Romanian law. |
| EU AI Act (EU) 2024/1689 | Compliance programme operating against the obligations applicable to our role and risk classification, ahead of and in step with the phased application dates. |
| SOC 2 (AICPA Trust Services Criteria) | Controls designed and operated in alignment with the Security, Availability, Processing Integrity, Confidentiality and Privacy criteria. We do not currently hold a completed SOC 2 Type I or Type II attestation report. We will state the date and auditor here once one is issued. |
| ISO/IEC 27001:2022 | Information security management system designed and operated in alignment with the standard, including risk assessment methodology, Statement of Applicability across Annex A, internal audit and management review. Not currently certified by an accredited body. |
| ISO/IEC 27701:2019 | Privacy information management practices aligned with the standard as an extension of the above. Not currently certified. |
| ISO/IEC 42001:2023 | AI management system practices aligned with the standard. Not currently certified. |
| ISO 9001:2015 | Quality management practices aligned with the standard: documented processes, customer focus, measurement and continual improvement. Not currently certified. |
| PCI DSS | Out of scope. We do not store, process or transmit cardholder data. Card acceptance occurs on the venue's own payment infrastructure. |
| NIS2 Directive (EU) 2022/2555 | Assessed. We do not currently fall within the essential or important entity categories. We monitor this as we scale. |
Customers requiring formal certification as a procurement condition should contact privacy@splitbite.ai. We will provide our control documentation, completed security questionnaires, penetration test summaries and our certification roadmap, and will not misdescribe our status.
17. International transfers
Our primary processing region is the European Union. The following transfers outside the EEA occur:
| Transfer | Destination | Data | Safeguard |
|---|---|---|---|
| Speech synthesis | United States | Text to be spoken, which may include guest-derived content | Standard Contractual Clauses; transfer impact assessment; no persistent storage by provider |
| Generative image processing | United States | Venue menu photographs | Standard Contractual Clauses; business terms excluding provider training on submitted content |
| Business listing, search and retrieval | United States | Venue business data, search queries | Standard Contractual Clauses |
| IP geolocation | Outside EEA | Guest IP address | Standard Contractual Clauses; single-purpose, no retention requested |
| Remote application streaming | United States | Session identifiers | Standard Contractual Clauses; intra-provider transfer |
| Venue-authorised connected systems established outside the EEA | United States | Venue operational data, which may include workforce records | Standard Contractual Clauses where we are the exporter; otherwise the venue's own arrangements as controller |
| Service delivery to venues located outside the EEA | Country of the venue | Data of guests at that venue | Standard Contractual Clauses; necessity for performance of the contract |
For each transfer we rely on an adequacy decision where one applies to the recipient, and otherwise on the Standard Contractual Clauses adopted by Commission Implementing Decision (EU) 2021/914, supported by a documented transfer impact assessment and supplementary measures. Supplementary measures include encryption in transit, minimisation of the payload to what the function strictly requires, avoidance of direct identifiers in transferred content, contractual prohibition on secondary use, and contractual commitments on government access requests. Transfer impact assessments are available to Customers on request. Where an assessment concludes that a transfer cannot be adequately protected, we do not make it.
18. Your rights
| Right | What it means | Limits |
|---|---|---|
| Access, Art. 15 | Confirmation of whether we process your data, a copy of it, and the information in this policy specific to you | Must not adversely affect the rights of others |
| Rectification, Art. 16 | Correction of inaccurate data and completion of incomplete data | Applies to facts, not to opinions or inferences you disagree with, though you may contest those too |
| Erasure, Art. 17 | Deletion of your data | Does not extend to data we must retain by law, data needed to defend a legal claim, or irreversibly anonymised aggregates |
| Restriction, Art. 18 | Suspension of processing while accuracy or a legitimate-interest objection is assessed | Storage may continue during restriction |
| Portability, Art. 20 | Your data in a structured, commonly used, machine-readable format, and transmission to another controller where technically feasible | Applies to data provided by you processed on consent or contract; does not cover our inferences |
| Objection, Art. 21 | Objection to legitimate-interest processing including profiling; absolute right to object to direct marketing | We may continue only on demonstrable compelling legitimate grounds, never for marketing |
| Withdraw consent, Art. 7(3) | Withdrawal at any time, as easily as it was given | Does not affect the lawfulness of prior processing |
| Human intervention, Art. 22(3) | Human review of, and the ability to contest, an automated output | Offered as policy; see section 10 |
| Complain, Art. 77 | Lodge a complaint with a supervisory authority | None |
| Judicial remedy, Arts. 79 and 82 | Effective judicial remedy and compensation for damage | None |
18.1 How to exercise a right
Write to privacy@splitbite.ai. Include enough information for
us to identify your records. For guests this normally means the email address or telephone number on the
account; if you used the application without registering, your Guest Identifier, which you can find in
your browser's local storage under splitbite-guest-id, is the only way we can locate your
events, and without it we may be genuinely unable to identify you.
We respond within one month. Where a request is complex or we receive a number of requests from you, we may extend by up to two further months and will tell you why within the first month. There is no charge unless a request is manifestly unfounded or excessive, in which case we will explain the basis for any fee or refusal. We may request proof of identity where necessary, and will not use it for any other purpose.
18.2 Requests about data held for a venue
Where we hold data as a processor for a venue, we will forward your request to that venue without undue delay and assist them in responding, and will tell you that we have done so. The venue is the appropriate controller for those records.
18.3 Current tooling
Access, export and erasure requests are currently fulfilled by our privacy team as a documented manual process rather than through a self-service control in the application. This does not reduce your rights or our response deadlines. Self-service controls are on our roadmap and this section will be updated when they ship. If your request is urgent, say so and we will prioritise it.
19. Cookies and local storage
The guest application does not set HTTP cookies for tracking. It stores values in browser local storage, which is functionally similar and is treated as within scope of the ePrivacy Directive.
| Key | Purpose | Category |
|---|---|---|
splitbite-guest-id | Pseudonymous identifier linking a session to behavioural events | Analytics |
splitbite-guest-name, splitbite-guest-color | Display identity on a shared table | Strictly necessary |
splitbite-session-start | Session boundary for event grouping | Analytics |
splitbite-cart | Cart contents across reloads | Strictly necessary |
splitbite-favorites | Saved items | Functional |
splitbite-active-table, splitbite-joined-table | Current table association | Strictly necessary |
splitbite-app-theme | Interface preference | Functional |
splitbite-auth-token, splitbite-auth-refresh, splitbite-auth-user | Authentication state | Strictly necessary |
splitbite-profile-trained, sb-item-notes | Personalisation state and item notes | Functional |
splitbite-cookie-consent | Records the consent decision | Strictly necessary |
sb-waiter-session, sb-waiter-lang, sb-waiter-last-tenant | Staff application session and preferences | Strictly necessary |
sb_admin_last_restaurant | Administrator convenience | Functional |
A service worker caches application assets to allow the interface to load quickly and to work through intermittent connectivity. It does not track browsing outside the application.
Consent. Strictly necessary storage is used without consent, as permitted. Analytics and functional storage require consent, which is requested on first use. Where consent is declined, analytics storage and behavioural event collection should not take place. We are in the process of completing the technical enforcement of that choice end to end; until that work is confirmed complete we encourage guests who do not wish to be measured to use the venue's conventional menu, and we will update this section, with a dated note, once enforcement is verified. Consent may be withdrawn at any time by clearing site data in your browser or by contacting us.
20. Children
The guest application is intended for use by adults and is not directed at children. We do not knowingly create accounts for individuals under 16, which is the age of digital consent in Romania. We do not require age verification, because doing so would require collecting more identity data than the service needs, and we consider that disproportionate for a digital menu.
We recognise that a child may use a device at a family meal. In that situation the interaction is recorded against the device's pseudonymous identifier in the same way as any other, and we do not knowingly build a profile of a child. Where we become aware that we hold the personal data of a child without a valid basis, we delete it promptly. A parent or guardian may contact privacy@splitbite.ai to request deletion, and we will action it without requiring proof beyond what is necessary.
We do not profile children for commercial purposes, do not include data known to relate to a child in any data product, and do not direct marketing at children.
21. Responsibilities of venues
Venues deploying Splitbite are controllers or joint controllers for the guest data they receive and for their workforce data. Under our Data Processing Agreement each venue undertakes to:
- Display a privacy notice at the point of collection, including on or adjacent to the QR code, identifying both the venue and Splitbite.
- Not use guest data received through the platform for purposes incompatible with those disclosed to the guest.
- Honour data subject requests it receives, and cooperate with us where a request reaches us first.
- Restrict staff access to guest records to those with an operational need.
- Ensure the accuracy of allergen and ingredient labelling in its menu, which remains the venue's legal responsibility.
- Inform its staff about any monitoring or performance measurement features it enables, and complete any consultation required by national employment law.
- Hold the necessary rights to authorise our access to its connected systems.
- Notify us without undue delay of any suspected personal data breach involving platform data.
Where Splitbite and a venue act as joint controllers, the essence of our arrangement under Article 26(2) is: Splitbite is responsible for the security of the platform, for responding to requests concerning data held in our systems, and for platform-level transparency; the venue is responsible for notice at the point of collection, for the lawfulness of its own use of the data, and for its staff. A data subject may exercise their rights against either of us regardless of that allocation.
22. Personal data breaches
We maintain a documented incident response process covering detection, containment, assessment, notification and post-incident review.
- Supervisory authority. Where a breach is likely to result in a risk to the rights and freedoms of individuals, we notify ANSPDCP without undue delay and in any event within 72 hours of becoming aware, in accordance with Article 33.
- Data subjects. Where a breach is likely to result in a high risk, we notify affected individuals without undue delay, in clear language, describing what happened, the likely consequences, the measures taken, and what they should do, in accordance with Article 34.
- Customers. Where we act as processor, we notify the affected Customer without undue delay and within 48 hours of confirmation, and provide the information they need to meet their own obligations.
- Record. Every incident is recorded with its facts, effects and remedial action, whether or not it is notifiable, in accordance with Article 33(5).
Suspected vulnerabilities may be reported to security@splitbite.ai. We will acknowledge within two working days, will not pursue legal action against good-faith researchers who follow responsible disclosure, and will credit reporters who wish to be credited.
23. Governance
- Records of processing. We maintain a record of processing activities under Article 30 covering purposes, categories, recipients, transfers and retention.
- Impact assessments. We carry out a Data Protection Impact Assessment under Article 35 before any processing likely to result in a high risk. Assessments completed or in scope cover: large-scale behavioural profiling of guests; processing of dietary Special Category Data; the cross-venue guest profile; AI-driven personalisation and suggestion; workforce measurement features; and any data product containing personal data.
- AI governance. We maintain an AI system inventory, per-system risk classification, data governance records, human oversight procedures, and post-market monitoring, and we assess new AI features before deployment.
- Privacy by design. New features are assessed for data minimisation, purpose limitation, default privacy settings and retention before release.
- Vendor management. Sub-processors are assessed before engagement and reviewed periodically.
- Training. Personnel with access to personal data receive data protection training on induction and periodically thereafter.
- Review. This policy and the underlying practices are reviewed at least annually and on any material change to the platform.
24. Complaints
If you are unhappy with how we have handled your data or your request, tell us first at privacy@splitbite.ai and we will investigate and respond substantively. You do not have to come to us first, and doing so does not affect your right to complain to a regulator or to go to court.
You may lodge a complaint with the supervisory authority in the EU member state of your habitual residence, place of work, or where the alleged infringement occurred. Our lead authority is:
Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal
B-dul G-ral. Gheorghe Magheru 28-30, Sector 1, 010336 Bucharest, Romania
www.dataprotection.ro
25. Changes to this policy
We may update this policy. Where a change is material — a new purpose, a new category of recipient, a new transfer, a longer retention period, or a change to the legal basis for existing processing — we will give notice at least 30 days before it takes effect, by email to registered users and by a prominent notice in the application and on this page. Where a change requires consent, we will ask for it rather than assume it. We keep prior versions and will provide any earlier version on request. The version number and effective date at the top of this page always reflect the current text.
26. Contact
Splitbite SRL
Bucharest, Romania
| Data protection and rights requests | privacy@splitbite.ai |
| Security and vulnerability reports | security@splitbite.ai |
| Legal notices | legal@splitbite.ai |
| General enquiries | info@splitbite.ai |