Data Processing Agreement (DPA)

This Data Processing Agreement ("DPA") forms an integral part of the Terms of Service (/terminos) and governs the obligations of AIGiner S.L. (the "Processor") when it processes personal data on behalf of the Customer (the "Controller") under Article 28 of Regulation (EU) 2016/679 (GDPR). In the event of any conflict between the Terms and this DPA as regards the processing of personal data, this DPA prevails.

How this document is structured: the DPA has three annexes. Annex I describes the nature of the processing (operations, data, data subjects); Annex II lists the sub-processors (with a link to the public list); Annex III sets out the technical and organisational measures applied under Article 32 GDPR.

1. Parties and acceptance

Controller: the Customer contracting the Service.

Processor: AIGiner S.L., tax ID B93819753, Gran Via de Carles III, 98, 08028 Barcelona, Spain.

Data protection contact: [email protected]. AIGiner has not appointed a Data Protection Officer under Article 37 GDPR because its processing does not fall within the cases that require one; that address is the mailbox through which the Controller’s formal requests and the notices under this DPA are channelled.

This DPA is deemed accepted by the Controller upon contracting the Service. For customers who require a specific signature (Max plans, Concerto Local, regulated sectors), an equivalent PDF version will be signed with evidentiary value.

2. Subject matter and duration

The Processor will process personal data on the Controller’s behalf solely for the purpose of providing the Service described in the Terms. The duration of the processing matches the term of the contract plus the data return period (30 days) and the minimum statutory retention periods where these apply.

3. Annex I, Details of the processing

4. Processor obligations (Article 28 GDPR)

The Processor undertakes to:

• Process the data only on documented instructions from the Controller, including those set out in the Terms, in this DPA, and any the Controller subsequently gives through formal channels.
• Ensure that persons authorised to process the data have committed themselves to confidentiality or are under an equivalent statutory obligation of confidentiality.
• Apply the technical and organisational measures in Annex III.
• Comply with the sub-processing conditions in section 5 (Annex II).
• Assist the Controller, insofar as possible and by appropriate technical and organisational measures, in fulfilling its obligation to respond to requests from data subjects exercising their rights.
• Assist the Controller in ensuring compliance with the obligations in Articles 32 to 36 GDPR (security, breaches, impact assessments, prior consultation).
• At the Controller’s choice, delete or return all personal data once the provision of services ends, and delete existing copies unless applicable law requires them to be kept.
• Make available to the Controller all information necessary to demonstrate compliance with the obligations in Article 28, and allow for and contribute to audits under section 7.
• Immediately inform the Controller if, in its opinion, an instruction infringes the GDPR or other data protection law.

5. Annex II, Sub-processing

The Controller gives general authorisation to the sub-processors published at /sub-encargados. The public list is incorporated into this DPA by reference and is updated as the product evolves. The table below is a summary; in the event of any discrepancy the public list prevails, as that is the one kept up to date.

5.1 Current summary list

5.2 Processor undertakings regarding sub-processors

• To give notice of any change (addition or replacement) at least 30 days in advance, by email to the Controller’s administrator account and by updating the public sub-processors page.
• To grant the Controller a right of reasoned objection within that period. If the objection cannot be resolved, the Controller may terminate the contract without penalty with effect at the end of the current cycle.
• To impose on each sub-processor, by written contract, the same data protection obligations assumed under this DPA, in particular sufficient guarantees to implement appropriate technical and organisational measures.
• To remain fully liable to the Controller for the sub-processors’ performance.

6. Annex III, Security measures (Article 32 GDPR)

These are the technical and organisational measures we apply, reviewed periodically and proportionate to the risk of the processing. They describe what is done today, not what is planned.

6.1 Encryption at rest

• AES-256-GCM with data keys wrapped by a master key managed by the product’s key custody layer.
• Periodic rotation of the master key, retaining previous keys so pre-existing data can still be decrypted.
• Secrets held in dedicated stores, never in the code.

6.2 Encryption in transit

• TLS 1.2 as a minimum (TLS 1.3 preferred) and modern cipher suites.
• HSTS enabled with a one-year max-age, including subdomains.
• Server certificate pinning in the agent installed on Customer servers, so an intermediary cannot observe or tamper with its credentials.

6.3 Authentication and identities

• Passwords stored with a salted derivation function (bcrypt), never in the clear.
• TOTP second factor available for every account, with recovery codes. The Controller may require it across its whole company from the account settings; in that case anyone without it configured is locked out.
• Per-IP and per-account attempt limits with progressive slowdown, against brute force and user enumeration.
• Least privilege for internal access, with role review and immediate revocation when the relationship ends.

6.4 Separation between customers

• Every query filters mandatorily by the requester’s company, verified against their membership as recorded in the database and not against whatever the request claims. This is the layer that guarantees isolation today.
• As a second layer, Postgres row-level security is enabled and forced in the domains where the money path and consumption live: model consumption, billing and approvals. In those domains the query drops privileges before running, so it is restricted to the rows of the requester’s organisation even if the application had a logic flaw. Extending that second layer to the remaining domains is in progress; until then, isolation there is guaranteed by the mandatory filtering of the previous layer. An automated check prevents shipping a release if a new table in the already-covered domains goes out without a policy.
• Concerto Local: a separate Postgres database, deployed on the Customer’s infrastructure, with no resources shared with anyone else.

6.5 Robustness against model manipulation

• A battery of adversarial tests covering the OWASP LLM Top 10 plus cases specific to the product: directly injected instructions, injection through documents, data exfiltration, disclosure of sensitive information and others.
• A threshold that blocks release: if less than 95% of the attacks are neutralised, the version does not ship.
• An output filter that strips any reference to the real model, to the system instructions, to the agent’s identity card or to internal configuration.
• Reinforcement in the system instructions to treat external content as material to be processed, never as orders to be executed.

6.6 Web application hardening

• HSTS, a ban on embedding the site in third-party frames, and blocking interpretation of content types other than the one declared.
• A content security policy with own-origin by default and an explicit list of exceptions. Blocking inline scripts is pending because of a limitation of the network provider, which injects an edge script with a random nonce that does not accept a hash.
• Restricted browser permissions: geolocation and camera disabled; the microphone is enabled only inside the application and at the user’s request.
• Session cookies with the Secure, HttpOnly and SameSite flags.

6.7 Logs, audit and traceability

• An agent-execution log that cannot be modified after the fact, with identifier, agent, model alias, prompt fingerprint, tokens consumed, latency, saving mode and outcome.
• A separate audit log for administrative events (changes to an agent’s identity card, production access, configuration changes).
• Human approvals recorded with the identity of the approver and a timestamp.
• Retention: executions and audit, 365 days; operational logs, 90 days; logs of a security incident, until it is resolved plus one year.

6.8 Backups and continuity

• A daily copy of the database and of the production configuration, encrypted with AES-256 before it leaves the server: the destination storage never sees anything in the clear.
• The 3-2-1 rule: three copies, two different media and one off-site, in storage under European Union jurisdiction.
• Retention: seven daily copies and four weekly ones, rotated automatically.
• Daily monitoring that the copy was made and that it left the server, with an alert if either fails.
• A monthly restore drill that recovers the copy into a temporary environment, compares the contents of the critical tables and verifies the audit log chain.

6.9 Key management

• Master key rotation at least annually, and immediately if exposure is detected.
• Retention of previous master keys for the lifetime of the data encrypted with them.
• Key custody kept separate from the production infrastructure.

6.10 People and process

• A signed confidentiality undertaking from everyone with production access, whether staff or contracted.
• Access on a strict need-to-know basis, with no standing access to the Customer’s production data; one-off accesses are logged.
• Immediate revocation of credentials when the employment or contractual relationship ends.
• A documented breach management procedure, using the notification template in section 10.
• Security and data protection training for staff with production access, with the practices applied reviewed at least annually.

7. Audits

Before listing the routes, one fact the Controller needs in order to choose one: AIGiner S.L. holds no ISO/IEC 27001 or ISO/IEC 27701 certification and no SOC 2 Type I or II report, and is not in a certification process as at the date of this document. If it ever obtains them, they will be announced on this page and may be provided as evidence. In the meantime, the right to audit is exercised through the remaining two routes.

• Through reasonable security questionnaires, which we answer with the corresponding technical evidence.
• Through a remote or on-site audit, once a year, on 30 days’ notice, during business hours, at the Controller’s cost and subject to a confidentiality agreement. After a confirmed breach, frequency is not limited and the cost is shared between the parties in proportion to their share of responsibility. Frequency may also increase if a data protection authority requires it.
• Through the provision of independent reports or certifications once these come to exist, without their absence limiting the two routes above.

8. Where each thing is processed

The Customer content the agents process is processed inside the European Union: the database (Supabase, Ireland · eu-west-1), the application servers (Contabo, Lauterbourg, France) and inference and voice transcription (a provider on sovereign EU infrastructure, 100% EU processing). There is no international transfer of prompts, of model responses or of voice recordings. The relationship with the inference provider is governed by an Article 28 processing agreement with zero retention and a commitment not to use the data for training.

Four ancillary processing activities do involve processing outside the EU, and the Controller needs to know about them: the service’s transactional email, sent through Resend from the United States, which includes the recipient’s name and address and the content of the notice; the traffic metadata Cloudflare processes on its global network, which also acts as a TLS proxy and sees the content in transit; payment data at Stripe, in Ireland and the United States; and the ticket-based support channel on Telegram, outside the EEA, which contains the name and address of the person writing and the content of the message. All four rely on the European Commission’s Standard Contractual Clauses (Decision 2021/914) and on each provider’s DPA or terms.

8.1 Concerto Local

Where the Controller contracts Concerto Local, the Service is deployed on its own infrastructure: the database and the Concerto models run on its own servers and AIGiner does not access that content in the normal course of providing the Service. Processing as a Processor is limited, in that case, to account and licence data and to the tasks the Controller expressly delegates to the cloud orchestration allowance, which is an option it switches on and off.

Support requiring access to the Controller’s installation is provided only at its request, with the scope it authorises, and the access is logged.

9. Assistance to the Controller (Articles 32-36 GDPR)

The Processor will give the Controller the assistance reasonably necessary to meet its obligations, in particular:

• Article 32 (Security): applying and demonstrating the measures in Annex III; answering questionnaires; joint review after material changes.
• Article 33 (Notification to the authority): notice to the Controller without undue delay and, in any event, within a period that allows it to meet the 72 hours. Minimum information template in section 10.
• Article 34 (Notification to the data subject): providing the information the Controller needs to assess the obligation and, if it decides to notify, to draft the communication.
• Article 35 (Impact assessment): information on the nature of the processing, the measures and the risks at the Controller’s request, within a reasonable period.
• Article 36 (Prior consultation): documentary assistance where the Controller must consult the supervisory authority.

The target response time for the Controller’s formal requests sent to [email protected] is 5 business days.

10. Breach notification (Article 33 GDPR)

In the event of a security breach affecting the Controller’s data, the Processor will notify it without undue delay and, at the latest, within 72 hours of detection. The initial communication will include, as a minimum, the following template:

Where it is not possible to provide all the information within the initial period, it will be provided in phases, documenting the reasons.

11. Return and deletion of data at the end

• The Controller has 30 calendar days after termination to download the data in a structured format (JSON / CSV).
• On a reasoned request, the period may be extended by a further 30 days.
• Once the period has elapsed, the Processor will delete all of the Controller’s data from its production environment and, through the natural rotation of backups, from those within a maximum of 60 further days, unless there is a legal obligation to retain it.
• A deletion certificate will be provided if the Controller requests one.

12. Liability regime

A failure by the Processor to meet its obligations does not release the Controller from its own. Each party answers to the supervisory authorities for the infringements attributable to it, and administrative fines cannot be transferred by contract. As regards compensation to data subjects, Article 82 GDPR applies, including the right of recourse in Article 82(5) according to each party’s share of responsibility for the damage caused.

13. Final provisions

For any question about this DPA, write to [email protected].

• This DPA is governed by Spanish law and the mandatory rules of the GDPR.
• The partial invalidity of any clause does not affect the validity of the rest.
• The prevailing language of the DPA is Spanish; versions in other languages are courtesy translations only.