Data Processing Agreement (DPA)

This Data Processing Agreement ("DPA") forms an integral part of the Terms of Service (/terms/) 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: dpo@aiginer.com. 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, including transfers to third countries, only with the sub-processors and safeguards in section 5.
• 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.
• Inform the Controller without delay 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 /es/subprocessors/ (in Spanish). 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

Telegram (Telegram FZ-LLC): internal operational alerts to the AIGiner team, with no personal data of the Controller or of the Users. Not a sub-processor.

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, proportionate to the risk of the processing. They describe what is done today, not what is planned.

6.1 Encryption of secrets and credentials

• The secrets and credentials the service holds on the Controller’s behalf (for example, the integrations’ access tokens) are encrypted in the application with AES-256-GCM; each credential has its own key, wrapped by a master key, and is bound to the company: copied to another, it does not decrypt.
• The master key lives outside the code and the database, in the server’s protected configuration. It can be rotated without decrypting the data and without stopping the service: during the change, the application reads with both the old and the new key.

6.2 Encryption in transit

• TLS 1.2 as a minimum (TLS 1.3 preferred) and modern cipher suites.
• HSTS enabled for two years, with preload and subdomains included.
• The server agent only talks to the API and to the update service if the certificate is issued by one of the root authorities pinned in the agent (Cloudflare’s); the signature of every link in the chain is checked and, if it does not match, it sends nothing. The pinning cannot be turned off in production.

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. Anyone who has the second factor turned on needs it (or a passkey sign-in) across the whole application: on every request, on the real-time channel, in connector settings and when approving actions. If the Controller requires it company-wide, it is required of all its members, including when they sign in from another company. Anyone who does not have it on, and whose company does not require it, signs in with a password.
• After five failures, each attempt from that address is delayed by up to 5 s, against brute force and user enumeration; five wrong 2FA codes lock that factor for ten minutes.
• Least privilege for internal access, with revocation when the relationship ends.

6.4 Separation between customers

• Every query filters by your company, checked against the database and not against whatever the request claims.
• In thirteen areas (model consumption, billing, approvals, memory —read—, runs, flows, integrations, HR, projects, support, tax invoicing, document templates and customers, the CRM) Postgres row-level policies also act as a second barrier: 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. Everywhere else, isolation is the per-company filter. Extending the policies is pending.
• 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 designed to remove references 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, 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), in which the database only allows lines to be added (modifying, deleting or emptying the log is rejected, even for the application itself), chained with SHA-256 and verifiable from the application, which detects the alteration of an intermediate record. In addition, every hour a signed copy of the last line of each company’s chain is stored in storage with a 30-day deletion lock, outside the database, and every day the database is checked against those copies, so that a rewrite of the log by someone with maximum privileges over the database would be detected.
• Human approvals recorded with the identity of the approver and a timestamp.
• Automatic deletion by age is on. The owner of each company chooses in Settings the retention period for conversations and runs (30, 60, 90, 180 or 365 days; 90 by default) and every night anything older is deleted. Technical logs are deleted after 90 days. The audit log, billing (6 years, art. 30 of the Commercial Code), memory (deleted by the Customer) and configuration are never deleted by age; they are deleted when the contract ends, as set out in section 11 of this DPA (Return and deletion of data at the end). Backups keep the data until they expire (35 days).

6.8 Backups and continuity

• Four daily copies of the database, encrypted (AES-256, GPG) and kept off the server, retained for 35 days with a 30-day deletion lock.
• A real test restore every week.
• Attached files do not have their own backup yet.
• Daily monitoring that the copy was made and that it left the server, with an alert if either fails.

6.9 Key management

• The master key lives outside the code and the database, in the server’s protected configuration.
• The master key can be rotated without decrypting the data and without stopping the service: during the change, the application reads with both the old and the new key.
• Backups: they are encrypted with AES-256 before they leave the server. The encryption key is kept on the server itself, because the nightly encryption and the automatic restore drills need it; for that reason the custody of these keys is not separate from the production infrastructure. A copy of the key is also held outside the server, in the company’s encrypted secrets vault.
• Access to the keys is restricted to AIGiner’s authorised operators.

6.10 People and process

• Those with production access are bound to confidentiality by contract or, as directors, by art. 228(b) of the Spanish Companies Act.
• Two AIGiner staff administer the platform and have technical access to the database, including Users’ memory; they access it only for support, incidents or legal obligation, under confidentiality.
• Revocation of credentials when the employment or contractual relationship ends.
• A documented breach management procedure, using the notification template in section 10.

6.11 Agents with access to devices and servers

• Access exclusions: AIGiner has configured the desktop agents so that they do not access password stores or system keychains (Windows Credential Manager and DPAPI, macOS Keychain, gnome-keyring, KWallet), the browser’s cookies or saved credentials, or SSH or GPG private keys. The server agents do not read /etc/shadow, private keys or Docker secrets.
• Server changes need approval: no change on a server (restarting, installing, editing) is carried out without the approval of a Controller administrator in Shara. It is run with the exact command approved, with system administrator privileges (root) through systemd-run, and is audited in the audit log in section 6.7.
• Recovery and confirmations: what the desktop agent deletes with its own tools goes to the system Recycle Bin; this does not extend to what a program or script run by the agent deletes. Writing system shortcuts (.lnk, .url, .scf, desktop.ini) and reading the clipboard require the User’s confirmation.
• Activity log: every action of an agent (what, when and with what result) is recorded in a log visible to the Controller in the application.
• Personal scope: the desktop an agent acts on is always that of the person talking to it.
• Scope of these measures: they are controls of AIGiner’s software. They do not replace the Controller’s operating system permissions or security policies (least-privilege accounts, backups, separate custody of secrets), which remain the Controller’s responsibility.

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 and the application servers (Contabo, Lauterbourg, France), authentication (Supabase, Ireland · eu-west-1) and inference and voice transcription (TensorX Ltd., in EU data centres: Ireland and Finland). Prompts, model responses and voice recordings are not transferred outside the European Union. The relationship with TensorX is governed by an Article 28 processing agreement; TensorX does not store or log request content or use it for training.

One caveat, the AI operator’s: when AIGiner administers its systems with Claude Code (Anthropic), the output of servers and of secret stores that the operator consults travels to Anthropic and may incidentally contain Customer data. How training on that data is configured in AIGiner’s account is to be confirmed.

Three 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; and payment data at Stripe, in Ireland and the United States. All three 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 model 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 48 hours of detection, so that it has margin over the period the Regulation gives it vis-à-vis the authority. 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, including that relating to the deployment of agents with access to devices and servers.
• Article 36 (Prior consultation): documentary assistance where the Controller must consult the supervisory authority.

The Controller’s formal requests sent to dpo@aiginer.com are handled without undue delay, so that the Controller can reply in time.

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 48 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 export the data in a structured format (a .zip with one NDJSON file per table plus a manifest.json, from Settings; CSV on request).
• 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 (backups are kept for 35 days), unless there is a legal obligation to retain it.
• Before deleting, the Processor cancels the subscription and any pending charges. After the export, it deletes the company’s data and gives the Controller a signed deletion certificate.
• Only what the law requires to be kept is retained: billing, for 6 years (art. 30 of the Commercial Code). Backups keep the data until they expire, after 35 days.

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 dpo@aiginer.com.

• 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.