Legal/Data Processing Agreement

Data Processing Agreement

Version 1.0 · 27 October 2026

This Data Processing Agreement ("DPA") forms part of the agreement between Bineric AS (org. no. 926 115 626, Pilestredet 52, 0167 Oslo, Norway, "Bineric") and a business customer ("Customer") that uses the Bineric API, Zuse or a Bineric business account (the "Services") under our Terms of Use or a separate order.

It applies automatically when the Customer uses the Services to process personal data, and meets Article 28 of the EU General Data Protection Regulation ("GDPR") as it applies in Norway. Nothing needs to be signed; for a countersigned copy, write to support@bineric.com.

1. Roles and scope

For personal data in the content the Customer sends to the Services (documents, questions, prompts, files and the outputs returned, together "Customer Content"), the Customer is the controller and Bineric is the processor. For account, billing and usage data that Bineric needs to run its business, Bineric is the controller, as described in its Privacy Policy.

The subject matter, duration, nature and purpose of the processing, and the types of personal data and data subjects, are set out in Annex 1. If this DPA and the Terms disagree on the protection of personal data, this DPA prevails.

2. Instructions

Bineric processes Customer Content only on the Customer's documented instructions. Those instructions are this DPA, the Terms, and the Customer's use of the Services, including each API request. Bineric tells the Customer without delay if it believes an instruction breaks data protection law, and processes Customer Content otherwise only where the law of the EEA or Norway requires it, after telling the Customer unless that law forbids it.

Bineric does not use Customer Content to train, fine-tune or evaluate any model, and does not sell it or use it for its own purposes.

3. Confidentiality and security

Everyone at Bineric authorised to process Customer Content is bound by confidentiality. Staff do not read Customer Content in the normal course of operating the Services; access is limited to automated processing, except where the Customer asks for support or where it is needed to investigate a security incident or to comply with the law.

Bineric keeps the technical and organisational measures in Annex 2 in place, appropriate to the risk as required by Article 32 GDPR, and may improve them as long as the overall level of protection does not fall.

4. Subprocessors

The Customer gives Bineric general authorisation to use subprocessors. The current list, with what each one does and where, is at bineric.com/legal/subprocessors. Bineric binds each subprocessor by written contract to data protection obligations at least as protective as this DPA, and remains responsible to the Customer for its subprocessors' performance.

Bineric notifies the Customer by email at least 30 days before a new subprocessor begins processing Customer Content. The Customer may object on reasonable data protection grounds within that period. If Bineric cannot reasonably accommodate the objection, the Customer may terminate the affected Services and receive a refund of any prepaid, unused fees for them.

5. Where data is processed

Zuse requests and the Customer's stored data are processed in the EEA (Sweden). Some chat models and tools in the Services run in the United States; Customer Content goes there only for requests to those models or tools, which are labelled with their hosting location. Any transfer outside the EEA is covered by an adequacy decision (such as the EU-U.S. Data Privacy Framework) or the European Commission's Standard Contractual Clauses, which are incorporated by reference where needed.

6. Helping the Customer

Taking into account the nature of the processing, Bineric helps the Customer, by appropriate technical and organisational measures, to respond to requests from data subjects exercising their rights, and to meet its obligations under Articles 32 to 36 GDPR (security, breach notification, impact assessments and prior consultation). If Bineric receives a request from a data subject about Customer Content, it passes it to the Customer and does not answer it itself unless the Customer asks.

7. Personal data breaches

Bineric notifies the Customer without undue delay, and in any case within 48 hours, after becoming aware of a personal data breach affecting Customer Content. The notice describes, as far as then known, the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed. Bineric adds information as it becomes available and takes reasonable steps to contain the breach and limit its effects.

8. Deletion and return

Zuse requests are not stored: the document and questions are discarded once the answer is returned. Other Customer Content is kept until the Customer deletes it or the agreement ends. Within 30 days after the agreement ends, Bineric deletes the remaining Customer Content, unless the law requires it to be kept, and on request before then makes it available for export. Copies in backups are overwritten in the normal backup cycle.

9. Information and audits

Bineric makes available the information needed to show compliance with this DPA, including its security documentation, and answers reasonable written questions. Where that is not enough, the Customer, or an independent auditor bound by confidentiality, may audit Bineric once a year on 30 days' written notice, during business hours, at the Customer's cost and without access to other customers' data. A supervisory authority may audit at any time as the law allows.

10. Term, liability and law

This DPA lasts as long as Bineric processes Customer Content for the Customer. Each party's liability under it is subject to the limits in the Terms, except where the GDPR does not allow liability to be limited. This DPA is governed by Norwegian law, and the Oslo District Court has jurisdiction, as in the Terms.

Annex 1: Details of the processing

  • Subject matter and duration: providing the Services to the Customer, for the term of the agreement and until deletion under section 8.
  • Nature and purpose: receiving Customer Content, running AI models on it, and returning the result. For Zuse: reading a document and returning, for each question the Customer asks, the probability of each option the Customer set.
  • Personal data: whatever the Customer chooses to include in Customer Content, such as names, contact details and the contents of messages, claims, contracts or case notes. The Customer should not send special categories of personal data (Article 9 GDPR) unless it has a lawful basis and has assessed the processing.
  • Data subjects: the people Customer Content is about, such as the Customer's customers, applicants, employees and end users.
  • Zuse: processed in memory on servers in Sweden; not stored, not written to logs, not used for training. Bineric keeps only metadata for billing and security: time, model, token counts, cost and the API key used.
  • Other Services: stored chats, files and memory are kept in Sweden until the Customer deletes them; requests to a model or tool are processed where that model or tool is hosted, as labelled in the Services.

Annex 2: Technical and organisational measures

  • Hosting: Amazon Web Services data centres in Stockholm, Sweden, for the API, Zuse, the database and backups.
  • Network: the Zuse model servers have no public endpoint; they are reachable only from the Bineric API over a private network.
  • Encryption: TLS for all traffic over public networks; stored chats encrypted at rest with AES-256; API keys and third-party credentials stored encrypted.
  • Logging: request metadata only (time, route, status, model, token counts); no Zuse request content in application, server or load-balancer logs. Server logs are kept 14 days.
  • Access control: access to production systems limited to named staff with individual accounts; access to production data only for support the Customer asked for, incident response or legal obligations.
  • Abuse protection: per-key and per-IP rate limits, and bot protection on public forms.
  • Monitoring and resilience: health checks, alerting on availability, errors and load, and database backups.
  • People: confidentiality obligations for all staff and contractors with access to production systems.
  • Incidents: a documented process to investigate, contain and notify breaches within the time in section 7.