Data Processing Agreement

Version: 1.1 Effective: 21 October 2026

This Data Processing Agreement (the "DPA") forms part of the BoothApps.ai Terms of Service at /legal/terms and is accepted together with them. It governs the processing of Guest Data that we carry out on the Customer's behalf when the Customer uses the Services, and it does not govern the Customer Account Data we process as a controller in our own right.

1. Parties, roles, incorporation and acceptance

1.1 Parties. This DPA is concluded between:

(a) the business customer that has accepted this DPA when creating a BoothApps.ai account (the "Customer"); and

(b) Innova.uno Sp. z o.o., Byslawska 84, 04-993 Warsaw, Poland, entered in the register of entrepreneurs of the National Court Register kept by the District Court for the capital city of Warsaw, XIV Commercial Division, under KRS 0000417704, NIP PL5213629718, REGON 146081689, share capital PLN 5,000 ("BoothApps", "we", "us").

1.2 Roles. In relation to Guest Data, the Customer is the controller and BoothApps is the processor. The Customer determines the purposes and the essential means of the processing by choosing a Workflow, configuring the Purchase and running the booth in front of the Guest. BoothApps processes Guest Data only on the Customer's Instructions.

1.3 Data we control ourselves. Customer Account Data is outside the scope of this DPA. We process it as a controller, and the Privacy Policy describes that processing. Payment, billing and tax data collected at checkout is processed by our payment provider as an independent controller and merchant of record, not as our sub-processor. That data is collected on the provider's own hosted payment page, not on ours, and the provider's own privacy notice applies to it. Its entities and role are recorded in the Subprocessor Register.

1.4 Incorporation. This DPA is incorporated into the Terms of Service and forms an integral part of them. It is published at /legal/dpa in a versioned form and remains available there for the Customer to read, save and print at any time.

1.5 Acceptance and form. The Customer accepts this DPA by ticking, at registration, the unticked checkbox that refers to the Terms of Service and this DPA. The Parties agree that this constitutes conclusion of the contract required by Article 28(3) and Article 28(9) GDPR in writing, including in electronic form. We record the accepted version, the date and time of acceptance and the browser user agent; for acceptances of a later version made after first login we also record the IP address. A Customer that requires a separately signed copy may request one at support@boothapps.ai.

1.6 Authority. The person accepting this DPA warrants that they are authorized to conclude it on behalf of the Customer and to give Instructions on the Customer's behalf.

1.7 Customer acting as a processor. Where the Customer is itself a processor acting for an event host or another party that is the controller of the Guest Data, the Customer warrants that it has the controller's authorization to engage us as a sub-processor and that it has passed down to the controller obligations equivalent to those in this DPA. In that case this DPA is read as a sub-processing agreement, the Customer remains our sole counterparty, all Instructions reach us from the Customer alone, and we owe no duties directly to the event host.

2. Definitions

Terms used but not defined here have the meaning given to them in the GDPR or in the Terms of Service.

3. Scope, subject matter and duration

3.1 Subject matter. The subject matter of the processing is the operation of the Services for the Customer: receiving Guest sessions from the Customer's booth software, producing the Outputs the purchased Workflow defines, delivering them to the Guest on the Customer's Instruction, and making them available to the Customer in the dashboard.

3.2 Nature and purpose. The nature and purpose of the processing, the categories of data subjects, the categories of Guest Data, the frequency and the processing operations step by step are described in Annex 1, which forms part of this DPA.

3.3 Duration. Processing under this DPA begins when the Customer activates a Purchase and continues for as long as that Purchase is active and thereafter for as long as its Outputs and records are retained under clause 13. This DPA applies for the lifetime of the Customer's account and until all Guest Data has been deleted or returned under clause 12.

3.4 No processing before activation. A Purchase that has been paid for but not yet activated by the Customer does not process Guest Data. Payment unlocks setup; the Customer activates the Purchase in the dashboard once setup is complete.

4. Processing on documented instructions

4.1 Instruction-only rule. We process Guest Data only on the Customer's documented Instructions, including as regards transfers to a third country, unless Union or Member State law to which we are subject requires otherwise. In that case we will inform the Customer of the legal requirement before processing, unless that law prohibits it on important grounds of public interest.

4.2 The instructions catalog. The following are the Customer's documented Instructions. Each of them is recorded in our systems at the moment it is given, and the catalog is set out in table form in Annex 1:

(a) the Purchase configuration chosen at checkout: the Workflow, the allowance, any video add-on pack and any top-up pack;

(b) the event details entered at checkout and in the dashboard;

(c) the guest delivery method and the SMS and email message templates the Customer sets, including the Customer's decision to deliver through its own SMS account or its own mail server;

(d) the overlay assets, logo and other branding the Customer uploads;

(e) activation and deactivation of a Purchase, and the booth connection details the Customer gives to its booth software;

(f) top-ups, which extend the number of Transformations available to a named active Purchase;

(g) actions the Customer takes in the dashboard, including viewing, downloading and exporting Outputs and delivery history; and

(h) support requests made in writing to support@boothapps.ai, including requests to delete, correct or export the Guest Data of a Purchase.

4.3 Processing without a specific instruction. Independently of clause 4.2 we may process Guest Data where this is necessary to secure the Services, to detect, prevent and respond to abuse, fraud and content that our providers' automated moderation rejects, to comply with a legal obligation, or to establish, exercise or defend legal claims. Where a legal obligation is the reason, we will inform the Customer unless the law forbids it. Such processing is limited to what the purpose requires and is never used to create profiles of Guests or for our own commercial purposes.

4.4 No independent purposes. We do not use Guest Data for our own purposes. We do not sell it, we do not use it for marketing, and we do not use it to train or improve any model of our own. Our contractual position with sub-processors on model training is described in clause 8.7.

4.5 Unlawful instructions. If we consider that an Instruction infringes Applicable Data Protection Law, we will inform the Customer without undue delay and may suspend the execution of that Instruction until the Parties have agreed a lawful one. We may refuse to execute an Instruction that would require us to act unlawfully.

5. The Customer's obligations as controller

5.1 Lawful basis. The Customer is responsible for establishing and documenting a lawful basis for every processing operation it instructs, for the duration of the event and for the retention of the Outputs it keeps.

5.2 Guest notice. Before a Guest's photograph is taken, the Customer must inform the Guest, in a way the Guest can understand at the booth, of the identity of the controller, of the purpose of the processing, of the fact that the resulting image and any report or video are generated by artificial intelligence, and of the fact that the system automatically estimates the Guest's apparent gender presentation and an age range from the photograph in order to select the matching artwork. The estimate must be described as an automated estimate and never as a certain finding. We provide suggested wording in our documentation; the notice itself remains the Customer's.

5.3 Consent to processing of the likeness. The Customer must obtain each Guest's explicit consent to the processing of their photograph for the purpose of producing an AI-generated image, and any permission required under local law for the use of a person's likeness.

5.4 Minors. The Customer must not submit photographs of persons under 18 without the consent of a parent or legal guardian, and must not run a Workflow at an event directed at children without safeguards appropriate to that audience, including an age-appropriate notice and a documented procedure for handling reports of missing consent. We may refuse or stop processing content on that basis.

5.5 Third parties in a photograph. The Customer must not submit photographs of persons who have not consented, including bystanders captured in the frame.

5.6 Accuracy of event details. The Customer is responsible for the accuracy of the event details, contact data and message templates it configures, and for making sure that the delivery address it collects belongs to the Guest who is to receive the Outputs.

5.7 Use of Outputs. The Customer must use the Outputs only within the scope of the Guest's consent, and must not publish or reuse a Guest's likeness beyond that scope.

5.8 The Customer's own accounts. Where the Customer connects its own SMS account or its own mail server, that provider acts as the Customer's own processor under the Customer's direct agreement with it, and not as our sub-processor. We hold the connection credentials encrypted and send on the Customer's Instruction. The Customer is likewise responsible for its booth software, its booth hardware, the network at the venue, and for keeping the booth connection details confidential.

5.9 Special categories of data. The Services are not configured to process data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, health data, or data concerning a person's sex life or sexual orientation, beyond what a photograph of a person inherently conveys. The Customer must not configure a booth survey, a prompt or a message template that collects such data, and must not instruct us to process it.

5.10 Our position on Article 9. Within the current functionality, a Guest photograph is used to produce an artistic AI-generated image. It is not used to identify or authenticate anyone, it is not compared with any other image or reference set, no template is created or stored, and no Guest is matched across sessions or events. The automated estimate of apparent gender presentation and of an age range exists only to build the generation prompt and to select the matching artwork; it is used within the generation step and is not stored as an attribute of an identified person in our database. On these functional assumptions the processing does not involve special categories of data within the meaning of Article 9 GDPR. This assessment is made at company level and is re-assessed if any of the following is introduced: use for identification or authentication, creation or storage of a template, one-to-one or one-to-many matching, deduplication by face, matching across frames, recordings or events, linking with a reference database, inference of a special category of data, or entry into a market whose law treats such processing differently. The Customer, as controller, makes its own assessment for its own events.

5.11 Prohibited content. The Customer must observe the acceptable use rules in the Terms of Service. We may refuse or stop processing content that our providers' automated moderation rejects or that breaches those rules. Refusals of individual photographs are normal operation and are not a defect in the Services.

6. Confidentiality of personnel

6.1 We ensure that every person we authorize to process Guest Data is bound by an appropriate obligation of confidentiality, whether contractual or statutory, and that the obligation survives the end of their engagement.

6.2 Access to Guest Data is limited to the persons who need it to operate, support or secure the Services, and is granted on a need-to-know basis.

6.3 Personnel with access receive guidance on data protection and on the security measures in Annex 2.

7. Security of processing

7.1 We implement and maintain the technical and organizational measures set out in Annex 2, which are designed to ensure a level of security appropriate to the risk, taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of the processing, as required by Article 32 GDPR.

7.2 We may change the measures in Annex 2 over time. A change will not reduce the overall level of security. The current version of Annex 2 is the one published with this DPA.

7.3 The Customer is responsible for the security of what it controls: access to its dashboard account, the confidentiality of its booth connection details and output links, the configuration of its own SMS and mail accounts, the security of its booth software and hardware, and the physical control of the booth at the venue.

7.4 Outputs are served to Guests over unguessable HTTPS links without a login, because a Guest must be able to open them from an SMS or an email. Anyone who has a link can open the file it points to. The Customer must take this into account when it decides what to deliver and to whom.

8. Sub-processors

8.1 General authorization. The Customer grants us a general written authorization to engage sub-processors for the provision of the Services, on the conditions in this clause.

8.2 The Register is the list. The sub-processors we engage are listed in the Register at /legal/subprocessors. The Register is public, requires no login, is dated and versioned, keeps a change log, and states for each sub-processor its legal entity, its role, the function it performs and the data it touches, the region of processing, the transfer mechanism where the region is outside the EEA, its contractual status, and what it retains. The Register is part of this DPA by reference. Annex 3 describes the categories it covers.

8.3 Notice of changes. We announce a new or replacement sub-processor at least 30 days before it processes Guest Data, by updating the Register and by email to the address on the Customer's account.

8.4 Objection. The Customer may object in writing within that 30-day period on reasonable grounds relating to data protection. We will discuss the objection in good faith and look for an alternative. If no reasonable alternative is available, the Customer may terminate the affected Purchases, and we will refund, pro rata, the Transformations bought and not used on those Purchases.

8.5 Emergency replacement. Where a security incident, the failure of a provider or a legal requirement makes it necessary, we may replace a sub-processor immediately. We will update the Register and notify the Customer promptly afterwards, and the objection right in clause 8.4 then applies from the date of that notice.

8.6 Flow-down and our liability. Subject to clause 8.9, we impose on each sub-processor, by contract, data protection obligations that are in substance equivalent to those in this DPA, in particular as to security, confidentiality, sub-processing and assistance. Where a sub-processor has not yet executed data processing terms with us, the Register states that expressly in that sub-processor's row, together with the terms we rely on in the meantime. We remain fully liable to the Customer for the performance of each sub-processor's obligations.

8.7 Model training. Our standard for sub-processors that receive Guest Data is that the data must not be used to train or improve their models. Where a provider offers a contractual or account-level control for this, we use it. The training position of each provider is described in the Register, provider by provider, in the terms that provider actually gives us, and not as a blanket statement.

8.8 Photo-generation providers and zero data retention. Zero data retention is our standard for the providers that receive a Guest photograph for image generation. For the primary photo-generation provider it is contractually agreed and enabled on our account, and the provider's confirmation of that status is recorded in the Register with its date. Re-verification is part of our annual vendor review, and the Register carries the current status. We do not check the provider's retention status inside each individual call, and we do not claim to.

8.9 Fallback image generation. A second image-generation provider is enabled as a fallback and receives a Guest photograph when the primary provider fails. Its contractual status is standard vendor terms; an enterprise data processing agreement has been requested and is not yet executed. This is stated in the Register as it stands.

8.10 Not our sub-processors. The Customer's own SMS account and the Customer's own mail server are not our sub-processors; see clause 5.8. Our payment provider is an independent controller; see clause 1.3.

9. International transfers

9.1 Where we are. We are established in Poland. Our own processing of Guest Data, and the processing carried out on the servers we operate, takes place in the European Economic Area.

9.2 No transfer between the Parties. For a Customer established in the EEA, and for a Customer established in the United Kingdom, providing Guest Data to us is not a transfer to a third country. Transfers from the United Kingdom to Poland are covered by the United Kingdom's adequacy regulations for the EEA.

9.3 Transfers to sub-processors. Some sub-processors process Guest Data outside the EEA. Those transfers are made by us, as processor, under Article 28(4) and Chapter V GDPR. For each such sub-processor the Register states the transfer mechanism relied on, which is ordinarily the European Commission's standard contractual clauses adopted by Implementing Decision (EU) 2021/914, in Module 2 or Module 3 as the chain requires, together with the supplementary technical, organizational and contractual measures we have assessed for that vendor. Where no written transfer basis is yet in place with a sub-processor, the Register says so in that sub-processor's row rather than implying a safeguard we do not hold. The Customer authorizes those transfers by accepting this DPA and the Register.

9.4 Copy of the safeguards. The Customer may obtain a copy of the safeguards in place for a given sub-processor, or information on where they are available, by writing to support@boothapps.ai.

9.5 UK controllers. Where the Customer's processing is subject to the UK GDPR, this DPA is read as applying to it, references to the GDPR are read as references to the UK GDPR, references to a supervisory authority include the Information Commissioner's Office, and onward transfers from the United Kingdom to a third country are made under the UK International Data Transfer Addendum to the standard contractual clauses or another mechanism recognized under UK law, as stated in the Register.

9.6 Customers outside the EEA and the United Kingdom. A Customer established elsewhere, including in the United States, acknowledges that the Services are operated from the European Economic Area and that Guest Data is processed there and by the sub-processors listed in the Register. Nothing in this clause creates a transfer restriction on the Customer's side that its own law does not impose.

10. Assistance to the Customer

10.1 Guest requests that reach us. If a Guest contacts us directly about Guest Data, we do not answer on the merits. We tell the Guest that the request must be addressed to the controller, and we forward the request to the Customer within 3 business days of receiving it, unless the law requires otherwise.

10.2 Assistance with Guest rights. Taking into account the nature of the processing, we assist the Customer by appropriate technical and organizational measures, insofar as this is possible, in fulfilling its obligation to respond to requests under Chapter III GDPR. In practice this means: the dashboard shows the Outputs and the delivery history of a Purchase, which covers most access and portability requests; Guest contact details are masked in those views as a security measure, and where a request needs the unmasked value our support team supplies it on the Customer's written Instruction; corrections and deletions that the dashboard does not offer are executed by our support team on the Customer's written Instruction; and we confirm to the Customer what was done.

10.3 Assistance with Articles 32 to 36. Taking into account the nature of the processing and the information available to us, we assist the Customer in ensuring compliance with its obligations on security of processing, notification of a Personal Data Breach, communication of a breach to data subjects, data protection impact assessments and prior consultation with a supervisory authority. For a data protection impact assessment we provide the description of the processing in Annex 1, the measures in Annex 2 and the Register, and we answer reasonable written questions about them.

10.4 Records. We maintain a record of the categories of processing carried out on behalf of the Customer, as required by Article 30(2) GDPR, and make the relevant part of it available to the Customer or to a supervisory authority on request.

10.5 Costs. Assistance under this clause is included in the price of the Services where the effort involved is reasonable. For repeated, extensive or unusually complex requests we may agree reasonable remuneration with the Customer in advance.

11. Personal data breaches

11.1 Notification. We notify the Customer of a Personal Data Breach affecting Guest Data without undue delay and in any event within 48 hours of becoming aware of it. Notice is sent to the email address on the Customer's account.

11.2 Content. The notification contains, to the extent available at the time, a description of the nature of the breach including, where possible, the categories and approximate number of data subjects and records concerned, the name and contact details of a contact point, a description of the likely consequences, and a description of the measures taken or proposed. Where the information is not all available at once, we provide it in phases without further undue delay.

11.3 Cooperation. We investigate the breach, take reasonable steps to contain it, mitigate its effects and prevent recurrence, keep the Customer informed of material developments, and cooperate with the Customer and with a supervisory authority as required.

11.4 No admission. A notification under this clause is not an admission of fault or of liability.

11.5 The Customer's own duties. Notification to the competent supervisory authority under Article 33 GDPR and, where required, to data subjects under Article 34 GDPR is the Customer's obligation as controller. We do not make those notifications on the Customer's behalf unless the Parties agree otherwise in writing in a specific case.

12. Deletion and return

12.1 During the term. The Customer may instruct us at any time to delete Guest Data relating to one of its Purchases. The instruction is given as a written support request to support@boothapps.ai; where the dashboard offers a deletion control, using it is also an instruction. We execute the deletion without undue delay and confirm it.

12.2 At the end of the services. At the Customer's choice, we delete or return all Guest Data within 30 days after the end of the provision of the Services relating to that data, and delete existing copies, unless Union or Member State law requires us to keep it. If the Customer makes no choice within that period, we delete.

12.3 Deletion is from our active systems. Deletion removes the data from our live systems and instructs our sub-processors to do the same. Encrypted off-site backups are kept on a rotating schedule and a copy of deleted data may remain in them for up to 6 months until the rotation overwrites it. Backups are not accessed or processed for any purpose other than disaster recovery and the verification of backup integrity, and the obligations of this DPA continue to apply to them.

12.4 Deletion certificate. We provide written confirmation of deletion on the Customer's request.

12.5 What may remain. After deletion, the following may remain: aggregate statistics that do not permit a person to be identified or singled out; and records we hold as a controller in our own right, in particular accounting records and a limited record needed to establish, exercise or defend legal claims, which are described in the Privacy Policy and are kept separately, with restricted access, and are not reused for any other purpose.

13. Retention during the term

13.1 What we describe here. This clause describes the retention rules our systems enforce today. Where no automated rule exists for a category, we say so rather than state a period we do not keep.

13.2 Outputs. Outputs are kept for at least 365 days after the event date so that the Customer can use them, unless the Customer instructs us earlier to delete them. After that period they may be deleted.

13.3 Original captures. The original capture is deleted once processing completes, unless the Workflow the Customer purchased keeps it as an Output. In two Workflows that deletion runs only on a successful run, so where a run fails part-way the capture may remain in our storage until the Purchase's Guest Data is deleted under clause 12. The dashboard shows which Outputs a Workflow stores.

Producing a result also creates temporary working copies of the capture and of intermediate results, for example the normalized copy prepared for the generation step and the cover frame built for a video. They are created in a temporary storage area during processing and are removed by our cleanup processes.

13.4 Enforced rules. The following are enforced automatically:

13.5 Categories without an automated rule. Guest delivery records, media job records, callback and usage logs, automation engine execution history, error-tracking events, and the temporary working copies described in clause 13.3 are retained for the life of the Purchase and are subject to the retention limits we publish as they are introduced. They are deleted on the Customer's Instruction under clause 12.1 and at the end of the Services under clause 12.2.

13.6 Legal holds. Where a legal obligation, a claim or an investigation requires it, we may suspend deletion of the data concerned for the duration of the hold, with access strictly limited to that purpose.

14. Audits and information

14.1 Information. We make available to the Customer the information reasonably necessary to demonstrate compliance with Article 28 GDPR and this DPA. In the first instance this is the description of the processing in Annex 1, the measures in Annex 2, the Register, and written answers to a reasonable security questionnaire.

14.2 Audit. The Customer, or an independent auditor it mandates who is not our competitor and who is bound by confidentiality, may audit our compliance with this DPA on 30 days' written notice, no more than once in any 12-month period. An additional audit may be conducted where a Personal Data Breach affecting the Customer's Guest Data has occurred, or where a supervisory authority requires it.

14.3 Reports first. The Parties agree that the information under clause 14.1 will ordinarily satisfy the audit right. An on-site inspection may be conducted only where that information is demonstrably insufficient to answer the Customer's specific question, and is limited to what is necessary to answer it.

14.4 Conduct. An audit takes place during normal business hours, must not disrupt our operations or affect other customers, and must not give access to the data, systems or information of any other customer, or to information covered by our confidentiality obligations to third parties.

14.5 Costs. Each Party bears its own costs. Where an audit requires effort from us that goes materially beyond answering the Customer's questions, we may agree reasonable remuneration with the Customer in advance.

14.6 Findings. Where an audit shows a material non-compliance with this DPA, we remedy it at our own cost without undue delay and provide evidence of the remedy.

15. Liability

15.1 Cap. The aggregate liability of each Party arising out of or in connection with the Terms of Service, including this DPA and including claims under clause 15.4, is limited to the greater of (a) the amounts paid by the Customer for the Purchase to which the claim relates together with any other Purchases made in the 12 months preceding the event giving rise to the claim, and (b) USD 500.

15.2 Excluded loss. Neither Party is liable to the other for indirect or consequential loss, for lost profits, or for loss of business, revenue or anticipated savings.

15.3 Carve-outs. The limitations in clauses 15.1 and 15.2 do not apply to: intentional misconduct; liability that cannot be limited or excluded under mandatory applicable law; a breach of clause 6 or of the confidentiality obligations in the Terms of Service; the unlawful use of the other Party's intellectual property; and the Customer's obligation to pay for the Services.

15.4 Third-party claims. A Party compensates the other Party for loss caused by a justified third-party claim only where that loss results from the first Party's culpable and unlawful act or omission and stands in adequate causal connection with it. There is no broader indemnity between the Parties.

15.5 Each Party answers for its own breaches. Each Party is liable for its own infringements of Applicable Data Protection Law. Where one Party has paid compensation or a fine for damage caused wholly or partly by the other Party's infringement, it may claim back from that Party the part corresponding to that Party's responsibility, in line with Article 82(5) GDPR. Each Party bears its own administrative fines except to that extent.

15.6 Separation from the rights of data subjects and authorities. Clauses 15.1 to 15.5 regulate the liability of the Parties between themselves only. They do not limit the rights of any data subject or the powers of any supervisory authority, and the liability of each Party toward data subjects and authorities is determined directly by law.

15.7 Limitation periods. Nothing in this DPA shortens a limitation period provided by law.

16. Term, termination, precedence, changes, law and contact

16.1 Term. This DPA takes effect on acceptance and remains in force for as long as we process Guest Data on the Customer's behalf, and thereafter for as long as any obligation in clause 12 is outstanding.

16.2 Termination. This DPA ends when the Terms of Service end. Clauses 6, 11, 12, 14, 15 and this clause 16 survive to the extent needed to give them effect. Termination of the Terms of Service does not by itself delete Guest Data; clause 12 governs that.

16.3 Precedence. If this DPA conflicts with the Terms of Service on a question of data protection, this DPA prevails. In all other respects the Terms of Service prevail.

16.4 Changes. We may update this DPA. A material change is notified to the Customer at least 30 days before it takes effect, which is a longer period than the Terms of Service require for their own changes, by email and in the dashboard, and the Customer may terminate the affected Purchases before the effective date if it does not accept it. A change required by law, or one that only reflects a new feature without reducing the protection given here, may take effect on publication. Every version is published at /legal/dpa with its version number and effective date. A change to the Register is not a change to this DPA and follows clause 8.

16.5 Governing law. This DPA is governed by Polish law. Disputes between the Parties are subject to the courts competent for Warsaw, without prejudice to the rights of data subjects under Article 79 GDPR and to any mandatory rights of a Customer that qualifies as a consumer under its local law.

16.6 Severability. If a provision of this DPA is invalid or unenforceable, the remaining provisions continue in force and the invalid provision is replaced by one that comes closest to its purpose.

16.7 Contact. Questions about this DPA, requests under it and requests for a copy of transfer safeguards go to support@boothapps.ai, or by post to Innova.uno Sp. z o.o., Byslawska 84, 04-993 Warsaw, Poland. We have not appointed a data protection officer; the assessment under Article 37 GDPR was made at company level and is reviewed as the Services grow. Our competent supervisory authority is the President of the Personal Data Protection Office (Prezes Urzędu Ochrony Danych Osobowych), ul. Stawki 2, 00-193 Warsaw, Poland.

Annex 1: Description of the processing and instructions catalog

A1.1 Subject matter and duration

The subject matter is the operation of the Services for the Customer's events, as described in clause 3. The duration is the life of each Purchase and of the Customer's account, and thereafter until clause 12 has been performed.

A1.2 Nature and purpose of the processing

To receive a Guest session from the Customer's booth software, to produce from it the Outputs that the purchased Workflow defines, to deliver those Outputs to the Guest on the Customer's Instruction, to make them available to the Customer, and to keep the records the Customer needs to operate and account for its Purchase.

A1.3 Categories of data subjects

Guests attending the Customer's events. Where a booth survey asks for it, a Guest may also provide the name of another person; that person is then a data subject as well.

A1.4 Categories of Guest Data

Special categories of data: none intended. See clause 5.9 and clause 5.10.

A1.5 Frequency

Continuous while a Purchase is active, on each Guest session sent by the Customer's booth software. Volume follows the Customer's event: typically tens to a few hundred sessions per event.

A1.6 Processing operations, step by step

1. The Customer's booth software posts the Guest capture and the survey answers to the booth connection endpoint of the Purchase, over HTTPS with the connection password set at activation.
2. The capture is stored in EU-jurisdiction object storage so that the processing steps can read it. Temporary working copies of the capture and of intermediate results, for example the normalized copy prepared for generation and the cover frame built for a video, are created in a temporary storage area during processing and are removed by our cleanup processes.
3. Where the Workflow needs it and the booth survey has not supplied the answer, the image is passed to an image-analysis sub-processor, which returns an estimated apparent gender presentation and an estimated age range. The call is transient and the result is used only within the processing run; it is not stored as a separate record by us.
4. A normalized copy of the capture and a generation prompt are sent to the photo-generation sub-processor, which returns the AI-generated image.
5. Where the Workflow produces written advice derived from the photograph itself, the photograph and an analysis prompt are sent to a vision-capable language model of the image-generation sub-processor, which returns text only.
6. Where the Workflow personalizes text, the survey answers, the Guest's first name and the estimated attribute are sent as text, without the photograph, to a text-generation sub-processor.
7. Where the Workflow uses branded overlays, the generated image and the text labels are sent to the overlay rendering sub-processor.
8. Where the Workflow includes video, a cover frame built from the generated image is sent to the video generation sub-processor, and the result is composited with the overlay on our own servers in the EEA.
9. The Outputs are written to EU-jurisdiction object storage and are served over unguessable HTTPS links without a login, so that the Guest can open them from a message.
10. Short links to the Outputs are created, and the delivery message is sent: by SMS through the Customer's own SMS account, or by email through the Customer's own mail server, or, where the Customer has not connected a verified mail server, by email through our transactional email sub-processor.
11. The Transformation is counted against the allowance of the Purchase, and a delivery record and processing record are written.
12. The original capture is deleted once processing completes, unless the Workflow keeps it as an Output. In two Workflows that deletion runs only on a successful run, so where a run fails part-way the capture may remain in storage until the Purchase's Guest Data is deleted under clause 12.
13. The Customer views, downloads and exports the Outputs and the delivery history in the dashboard.

A1.7 Instructions catalog

Annex 2: Technical and organizational measures

These are the measures we apply under clause 7 and Article 32 GDPR. They describe what is implemented, not what is planned.

A2.1 Access control

A2.2 Encryption

A2.3 Network and application security

A2.4 Logging and monitoring

A2.5 Vendor management

A2.6 Backups and resilience

A2.7 Data minimization and deletion

A2.8 Incident response

A2.9 Personnel

We do not claim any security certification, and we have not commissioned an independent penetration test. If that changes, this Annex and the Register will say so.

Annex 3: Sub-processors

A3.1 The Register. The authoritative list of our sub-processors is the Sub-processor Register at /legal/subprocessors. It is public, needs no login, is dated and versioned, keeps a change log, and keeps its editorial history so that a copy of any earlier version can be obtained on request. No vendor is named in this document: a vendor change updates the Register, not this DPA. The conditions on which we may change a sub-processor, and the Customer's right to object, are in clause 8.

A3.2 What the Register states for each sub-processor. The legal entity as published by that vendor; whether it acts as our sub-processor for Guest Data or as a processor for Customer Account Data; the function it performs and the data it touches; the region of processing; the transfer mechanism and the supplementary measures where the region is outside the EEA; its contractual status, including whether data processing terms are executed; its position on the use of data for model training; and what it retains.

A3.3 Categories covered. The Register covers at least the following categories of sub-processor:

A3.4 Providers deliberately not listed. The Register has a section for providers that are configured but disabled, or that appear only in a legacy component that no purchasable Workflow uses, and it explains why they receive no Guest Data. That section is part of the Register, not of this document.

A3.5 Not sub-processors. The Customer's own SMS account and the Customer's own mail server are the Customer's processors, not ours. Our payment provider is an independent controller for payment, billing and tax data. Neither appears in the Register as a sub-processor.

Innova.uno Sp. z o.o., Byslawska 84, 04-993 Warsaw, Poland. Questions: support@boothapps.ai.