Data Processing Agreement

This Data Processing Agreement (the “DPA”) forms part of, and is incorporated by reference into, the AiPricingLab Terms of Service (the “Terms”). It governs the processing of personal data carried out by the Provider (defined below) on behalf of the Customer in the course of providing the Service, and is concluded between:

• Salvatore Castellitti, an individual sole trader established in Italy, operating under the trade name “AiPricingLab” (the “Provider” or “Processor”); and
• the legal entity or natural person identified as the account holder on the AiPricingLab dashboard (the “Customer” or “Controller”).

Acceptance of the Terms constitutes acceptance of this DPA. No physical signature is required for this DPA to bind the parties; the Customer may, however, request a countersigned PDF copy by writing to s.castellitti.dev@gmail.com.

1. Definitions

Capitalised terms not defined here have the meaning given to them in the Terms or in the GDPR. For ease of reference:

• “GDPR” means Regulation (EU) 2016/679 of the European Parliament and of the Council on the protection of natural persons with regard to the processing of personal data.
• “Applicable Data Protection Law” means the GDPR, the Italian Privacy Code (D.Lgs. 196/2003 as amended by D.Lgs. 101/2018), and any other data-protection or privacy law applicable to the processing carried out under the Terms.
• “Customer Personal Data” means personal data, within the meaning of art. 4(1) GDPR, that the Provider processes on behalf of the Customer in connection with the Service, including the categories described in Schedule 1.
• “Sub-processor” means any third party engaged by the Provider to process Customer Personal Data, as listed in Schedule 3.
• “Standard Contractual Clauses” or “SCCs” means the Standard Contractual Clauses approved by Commission Implementing Decision (EU) 2021/914 of 4 June 2021, in their applicable modules.

2. Roles of the parties

With respect to Customer Personal Data, the Customer is the controller (or, where the Customer is itself a processor of an upstream controller, the relevant processor) within the meaning of art. 4(7) GDPR. The Provider is the processor (or sub-processor, as the case may be) within the meaning of art. 4(8) GDPR.

Personal data that the Provider processes about the Customer's own personnel for the Customer's account, billing and support relationship is processed by the Provider as an independent controller, on the terms of the Privacy Policy, and falls outside the scope of this DPA.

3. Subject-matter, duration, nature, purpose and types of data (art. 28(3) GDPR)

The required elements of art. 28(3) GDPR are set out in Schedule 1 (“Processing details”) and form an integral part of this DPA.

4. Customer instructions and lawful basis

The Provider will process Customer Personal Data only on documented instructions from the Customer, including with regard to transfers of Customer Personal Data to a third country or to an international organisation, unless required to do so by Italian or EU law. In such a case, the Provider will inform the Customer of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.

The Customer's documented instructions include: (i) the Terms and this DPA; (ii) the configuration the Customer maintains in the AiPricingLab dashboard (including which Optional Content Features it has enabled per app); (iii) the API calls the Customer's application makes to the Service; and (iv) any additional written instructions reasonably given by the Customer.

The Customer represents and warrants that: (a) it has identified a valid legal basis under articles 6 and, where applicable, 9 GDPR for each category of personal data it transmits to the Provider; (b) it has provided to data subjects all information required by articles 13–14 GDPR, including the identification of the Provider as a recipient and sub-processor as required by Terms §4a; (c) it has obtained any consent required by law (including under art. 7 of the Italian Privacy Code, any sectoral rules, and — where its end-users include children — any parental or guardian consent required by article 8 GDPR and applicable national law); (d) it has carried out any data-protection impact assessment required by article 35 GDPR; and (e) the instructions it gives the Provider are lawful.

The Provider will promptly notify the Customer if, in its opinion, an instruction infringes the GDPR or other Applicable Data Protection Law.

5. Confidentiality

The Provider ensures that any natural person acting under its authority who has access to Customer Personal Data is bound by an obligation of confidentiality, whether by contract or by a statutory obligation, and processes that data only on instructions from the Provider, except where required by Italian or EU law.

6. Security (art. 32 GDPR)

Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the Provider implements the technical and organisational measures described in Schedule 2 to ensure a level of security appropriate to the risk.

The Provider may update Schedule 2 from time to time, provided that the level of security is not materially reduced. Material reductions will be notified to the Customer in advance.

7. Sub-processors (art. 28(2) and 28(4) GDPR)

The Customer grants the Provider general written authorisation to engage the Sub-processors listed in Schedule 3 to carry out specific processing activities on behalf of the Customer.

Where the Provider engages a new Sub-processor, or replaces an existing one, with respect to Customer Personal Data, it will give the Customer prior written notice (which may be by email or by an update to Schedule 3 with notice in the dashboard) of at least fourteen (14) days before the new Sub-processor begins processing. Within that notice period, the Customer may object on reasonable data-protection grounds by writing to s.castellitti.dev@gmail.com. The parties will seek a workable resolution; if no resolution can be reached, the Customer's sole remedy is to terminate the affected portion of the Service for convenience, without refund of pre-paid fees beyond what the Terms allow.

The Provider remains fully liable to the Customer for the performance of any Sub-processor's data-protection obligations. The Provider imposes by contract on each Sub-processor data-protection obligations that are no less protective than those set out in this DPA, in accordance with art. 28(4) GDPR.

8. Assistance with data-subject rights (arts. 12–23 GDPR)

Taking into account the nature of the processing, the Provider will assist the Customer by appropriate technical and organisational measures, insofar as this is possible, in fulfilling the Customer's obligation to respond to requests by data subjects exercising their rights under articles 12–23 GDPR.

Where the Provider receives a data-subject request relating to Customer Personal Data directly (for instance, from an end-user of the Customer's application), it will, without undue delay and unless prohibited by law, forward the request to the Customer and will not action it independently. Privacy Policy §10a describes the corresponding flow as seen from the data subject's perspective.

9. Assistance with art. 32–36 obligations

Taking into account the nature of the processing and the information available to it, the Provider will assist the Customer in ensuring compliance with the obligations pursuant to articles 32–36 GDPR, including by:

• providing the information necessary for the Customer to carry out a data-protection impact assessment (art. 35);
• providing the information necessary for the Customer to consult the competent supervisory authority where required (art. 36);
• notifying the Customer without undue delay (and in any event within seventy-two (72) hoursof becoming aware) of any personal-data breach affecting Customer Personal Data, together with all information reasonably available to the Provider to enable the Customer to meet its own notification obligations under articles 33–34 GDPR.

10. Deletion or return at end of services (art. 28(3)(g) GDPR)

On termination or expiry of the Customer's account, the Provider will, at the Customer's choice expressed in writing within thirty (30) days of termination, either delete or return all Customer Personal Data and delete existing copies, unless Italian or EU law requires storage of the data.

Where the Customer does not make an election within that thirty (30) day window, the Provider may delete Customer Personal Data in accordance with the standard retention rules described in Privacy Policy §9, save where law requires storage. Deletion may be propagated asynchronously through backups, replicas, and storage tiers, on a commercially reasonable basis.

11. Audits and inspections (art. 28(3)(h) GDPR)

The Provider will make available to the Customer all information necessary to demonstrate compliance with the obligations laid down in this DPA, and will allow for and contribute to audits, including inspections, conducted by the Customer or another auditor mandated by the Customer.

In practice, given the Service's scale and architecture, the Provider will, on reasonable advance written request and no more than once per twelve (12) month period:

• provide updated documentation of its security and operational practices (an updated Schedule 2 and any relevant procedures);
• respond in writing to a reasonable security questionnaire submitted by the Customer; and
• where the Customer has a substantiated and specific concern that cannot be addressed through the above, cooperate with a remote audit conducted by the Customer or an independent third-party auditor (under appropriate confidentiality obligations) at the Customer's expense.

The Provider may, in lieu of an on-site or remote audit, rely on industry-standard third-party audit reports (e.g. SOC 2, ISO 27001) covering the relevant Sub-processors, once available.

12. International transfers

Some Sub-processors operate from countries outside the EU/EEA. Where the Provider, acting as a processor, transfers Customer Personal Data to a Sub-processor outside the EU/EEA and outside the scope of an adequacy decision under art. 45 GDPR, the parties agree that the EU Standard Contractual Clauses (Module 3, processor-to-processor) approved by Commission Implementing Decision (EU) 2021/914 are hereby incorporated by reference into this DPA and made effective, with the following selections:

• Optional docking clause (Clause 7): incorporated.
• Option 2 in Clause 9(a): general written authorisation for sub-processors (see Section 7 above), with a fourteen (14) day notice period.
• Option in Clause 11(a): the optional independent dispute-resolution mechanism is not incorporated.
• Clause 17 (governing law): the law of the Republic of Italy.
• Clause 18(b) (forum): the courts of Rome, Italy.
• Annex I.A (parties): the Customer (data exporter) and the relevant Sub-processor (data importer), as listed in Schedule 3 with contact details.
• Annex I.B (description of transfer): as set out in Schedule 1 of this DPA.
• Annex I.C (competent supervisory authority): the Italian Garante per la protezione dei dati personali.
• Annex II (technical and organisational measures): as set out in Schedule 2 of this DPA.
• Annex III (list of sub-processors): as set out in Schedule 3 of this DPA.

Where the Provider itself, in its capacity as data importer, signs SCCs directly with a Sub-processor (Module 3), it does so in addition to and without prejudice to the SCCs incorporated above. Where the EU–US Data Privacy Framework or any successor adequacy decision applies to a given Sub-processor, the parties will rely on it in lieu of the SCCs.

13. Liability

Each party's liability arising out of or in connection with this DPA is subject to the limitation-of-liability provisions of the Terms (Terms §17). Nothing in this DPA limits or excludes either party's liability that cannot be limited or excluded under Applicable Data Protection Law, including liability to data subjects under articles 82–84 GDPR.

14. Order of precedence and term

In the event of any conflict between this DPA and the Terms, this DPA prevails to the extent of the conflict, but only with respect to Customer Personal Data and only to the extent required by Applicable Data Protection Law.

This DPA enters into force when the Customer accepts the Terms, and remains in force for as long as the Provider processes Customer Personal Data on behalf of the Customer.

15. Contact

Any matter relating to this DPA can be sent to s.castellitti.dev@gmail.com.

Schedule 1 — Processing details (art. 28(3) GDPR)

Subject-matter of the processing. Provision of the AiPricingLab Service: usage metering, quota enforcement, plan/subscription management, analytics, and the Optional Content Features (Prompt Logging, Media Uploads) when enabled by the Customer.

Duration of the processing.For the term of the Customer's AiPricingLab account, plus the retention periods set out in Privacy Policy §9.

Nature and purpose of the processing. Receiving, validating, storing, counting, aggregating, querying, deleting, and exposing through API and dashboard the metering events, behavioral analytics events, and (where enabled) the content described below, for the sole purpose of operating the Service for the Customer.

Types of personal data. Customer Personal Data may include:

• opaque end-user identifiers (end_user_id) chosen by the Customer;
• event types, quantities, timestamps, and the custom metadata fields the Customer attaches to each event;
• subscription state and history (plan, period boundaries, counters, plan-change history);
• request metadata (IP address, user-agent, request timing) for security, billing and debugging on the identified surfaces;
• where the Customer uses the behavioral analytics features: product-usage events (e.g. screen/page views, onboarding steps, feature-engagement events) keyed to a Customer-chosen behavioral identifier (distinct_id), together with the person-profile properties the Customer attaches through those features;
• where the Customer uses the behavioral analytics features in the default hybrid mode for pre-authentication traffic: anonymous aggregate events carrying no behavioral identifier and no stored IP. At ingest, the client IP and the full User-Agent are folded into a one-way salted hash (sha256(ip + ua_class + per-app daily salt)) and discarded before any row is written. Only the resulting 24h-scoped daily_session_hash, the ISO country code, the device class (mobile/desktop/tablet), and any UTM source/medium/campaign tags the Customer attaches reach storage; referrer values are reduced to host only; utm_term / utm_content are dropped. Anonymous aggregate rows are not linked to any individual and cannot be re-identified by the Provider;
• where consent-gated operations are performed (anonymous→identified merging on identify / alias; opt-out, erasure, export, opt-in): an append-only audit-log row recording the action, the affected person, the calling origin and the Customer's declaration of consent, retained 5 years as legal evidence;
• when Prompt Logging is enabled by the Customer: free-form prompt and response strings (including system prompts, retrieved context, conversation history and any tool-call payloads the Customer chooses to serialise into those fields);
• when Media Uploads are enabled by the Customer: images, audio, video and other binary artefacts produced by the Customer's AI generation flow.

The Customer is responsible for ensuring that no special-category data (art. 9 GDPR) or criminal-conviction data (art. 10 GDPR) is transmitted to the Provider without an appropriate legal basis and the consents required by law.

Categories of data subjects.End-users of the Customer's applications. Where Optional Content Features are enabled, this may also extend to any natural persons whose personal data appears within the Customer-submitted prompts, responses or media (for example, named individuals referenced in chat messages or depicted in uploaded images).

Frequency of the processing.Continuous, for as long as the Customer's application makes API calls to the Service.

Retention. As described in Privacy Policy §9 (default retention windows for events, prompts, media, billing records and logs) and as further configured by the Customer in the dashboard.

Schedule 2 — Technical and Organisational Measures (art. 32 GDPR)

The Provider implements the following measures, which may be updated from time to time provided the overall level of security is not materially reduced:

• Encryption in transit.All traffic to the Service's API and dashboard is served over TLS 1.2+; insecure protocols are disabled at the edge.
• Encryption at rest. Application data is stored in managed databases and object storage that provide encryption at rest by default (Turso libSQL, Cloudflare R2).
• Credential storage. Customer passwords are stored using bcrypt or equivalent one-way hashes (where password authentication is used); API keys are stored as one-way SHA-256 hashes and cannot be retrieved from the Service.
• Pseudonymisation. End-user identifiers used in Media Uploads object-key paths are HMAC-SHA-256 pseudonymised with a workspace-scoped secret, so that the raw identifier is not exposed in the storage layer (Privacy Policy §4a).
• Source-IP minimisation for anonymous analytics. Pre-authentication analytics events in the default hybrid mode are dedeplicated via a one-way SHA-256 hash of (client_ip, ua_class, per-app daily_salt); the raw client IP and full User-Agent are discarded before any database write. The per-app daily salt is regenerated every 24 hours and pruned after 48 hours by a scheduled job, so the same visitor produces a different hash across days and no cross-day correlation is possible.
• Right-to-object / right-to-erasure gating. Once a person is opted out or pending deletion, every subsequent capture() for that identifier is silently dropped at the application layer; no row is written, and the SDK response shape is indistinguishable from a recorded event so the controller cannot probe opt-out status by call shape.
• Data-subject export tokens. The Art. 15 / 20 data-portability surface returns HMAC-SHA-256 signed download URLs bound to a 24-hour expiry; the payload is recomputed on each download and is never staged in object storage.
• Audit log of privileged privacy operations. Every opt-out, opt-in, deletion-enqueue, export and consent-gated merge is recorded in an append-only audit table with timestamp, action, affected person and calling origin; retained for 5 years as legal evidence.
• Access control. Administrative access to production data is restricted to authorised Provider personnel under a least-privilege principle; authentication uses strong credentials and, where supported by the relevant provider, multi-factor authentication.
• Network isolation and rate-limiting. The API enforces per-key rate limits and request validation; the application runs on a managed edge platform (Vercel) with platform-level DDoS protection.
• Logical isolation of test and live data. Test-mode data is stored in dedicated test_* tables; the partition is enforced by table name rather than by predicate, so a logic bug cannot leak live data into test paths or vice versa.
• Audit logging. Authentication events, key creation and revocation, plan changes, and other security-sensitive actions are logged with timestamps.
• Vulnerability management. Dependencies are tracked through the package-lock; security advisories are reviewed and patched as part of the normal release cadence.
• Backup and recovery. Database providers offer point-in-time recovery and automated backups on the plan tiers the Provider has subscribed to. Backups for content stored through the Optional Content Features are not warranted (Privacy Policy §12).
• Personal-data breach process. Any suspected breach is investigated internally without undue delay; affected Customers are notified within 72 hours of the Provider becoming aware of a breach affecting Customer Personal Data.
• Personnel. All persons acting under the authority of the Provider who have access to Customer Personal Data are bound by confidentiality obligations.
• Data minimisation by design. The Service is designed to require only an opaque end_user_id from Customers. The Optional Content Features are off by default; activation is a deliberate per-app dashboard action by a workspace member.
• Deletion. Account deletion triggers removal of Customer Personal Data in accordance with the retention rules in Privacy Policy §9 and any election made under Section 10 of this DPA.

Schedule 3 — Sub-processors

As of the “Last updated” date at the top of this DPA, the Provider engages the following Sub-processors to process Customer Personal Data:

The list above is updated as Sub-processors change. The Customer may request the current list at any time at s.castellitti.dev@gmail.com. New Sub-processors are subject to the prior-notice and objection mechanism in Section 7.