Personuppgiftsbiträdesavtal

Last reviewed: 2026-10-29 · Version: 1.6

This is our data processing agreement under GDPR Article 28. Each customer signs it with us before any processing starts, and the agreement signed with a customer is the binding version.

Parties. The customer is the controller. Seginus AS, org. nr. 924 867 558 (contact: the address given in the agreement we sign with you) is the processor where it operates or supports the customer's installation.

1. Processor obligations

1. We process personal data only on the controller's documented instructions, including on transfers, unless EU/EEA law or the applicable national law requires otherwise (then we tell the controller first, unless the law forbids it).
2. Everyone we authorise to process the data is bound by confidentiality.
3. We apply the security measures in Annex 2 (art. 32).
4. We engage a sub-processor only with the controller's prior written authorisation, and tell the controller in advance of any change so it can object (art. 28(2) and (4)). The list is in Annex 3.
5. We help the controller answer data-subject requests (Chapter III) and meet its duties under art. 32–36, including DPIAs and prior consultation.
6. On termination, we delete or return the data at the controller's choice (see Annex 4).
7. We make available the information needed to show compliance, and allow and contribute to audits, including inspections, by the controller or an auditor it mandates.
8. We tell the controller at once if we think an instruction breaks the GDPR or the applicable national data protection law.

2. Personal data breaches

We notify the controller without undue delay, and in any case within 72 hours, after becoming aware of a personal data breach affecting its data, with what we know: the nature of the breach, the categories and approximate numbers of people and records, the likely consequences, and the measures taken or proposed. The controller decides on notifying its supervisory authority (in Norway, Datatilsynet; each country's authority is on its country page) (art. 33: without undue delay and, where feasible, within 72 hours of becoming aware of the breach) and the people affected (art. 34); we help.

3. International transfers

• The product is designed to run in the customer's own Azure tenant in an EU/EEA region the customer chooses (default Norway East), and all stored customer data is designed to stay there. Where an AI model processes a request is the customer's choice: the customer selects one of the model frameworks, and each framework states where it processes. Foundry Azure, open source (the default): outside the EU/EEA, and with its default model the prompt, with columns tagged for masking replaced by placeholders, is processed in the US (a third-party-hosted model on Azure AI Foundry, Global Standard deployment, outside Microsoft's EU Data Boundary, with the AI-policy residency tag global, never customer-cloud). Foundry Azure EU, open source: only within the EU (an EU Data Zone deployment). Frontier models in Foundry: in any Azure region, including outside the EU/EEA. Self-hosted VM in your Azure: on the customer's own machine, in its EU/EEA region. Direct access: on the model vendor's own service, outside Azure and outside the EU/EEA. We do not transfer stored customer data outside the EU/EEA.
• This public website and its demo are hosted on Vercel, whose server functions run in Washington, D.C. (United States, Vercel region iad1), and the demo's Ask bar may send the visitor's question to a US model provider. That covers fictional demo data and ordinary web request logs only, never customer data. See Annex 3.
• Any future transfer outside the EU/EEA needs the controller's instruction and a Chapter V safeguard (an adequacy decision or standard contractual clauses).

Annex 1 — Description of the processing

Annex 2 — Security measures (art. 32)

Technical

• Tenant isolation inside the database, not only in application code.
• Pseudonymisation: The anonymiser is on by default: it runs before every model call, on every route, and masks the columns tagged for masking plus the names and patterned values it recognises (presets Strict / Standard). Your admin can switch it off per sensitive column class (person name, national id, email, phone, organisation number, bank account) per model route, as a logged change that follows your approval rule: on that route the switched-off classes are sent as they are, every other class stays masked, and every other route is unaffected. For a model inside the installation it can also be switched off entirely (the Standard preset). Masked names, national ids, emails and phones become pseudonyms, and a call that still carries an unprotected value is refused. The pseudonym map stores keyed hashes, never raw values.
• Credentials and secrets designed to be held in the customer's Azure Key Vault, never printed or logged.
• Audit: every agent tool call is recorded (who, what, when, outcome, a hash of the output); every change to an object keeps an append-only history; write control is set per action by the customer's admin.
• Connections from outside AI tools to the product are designed to use OAuth 2.1 with PKCE; authorisation codes and refresh tokens are stored hashed.
• A fault log that records codes only, and cost caps on AI use.

Organisational

• Access on a need-to-know basis, confidentiality commitments, and access removed when no longer needed.
• Every code change is reviewed before release, and releases are traceable to a reviewed change.
• An incident procedure that meets the 72-hour notification in section 2.

Annex 3 — Sub-processors

By reference to Sub-processors. The controller is told in advance of any change.

Annex 4 — Deletion and return on termination

The customer's data lives in the customer's own Azure subscription, so it stays with the customer: there is nothing of ours to hand back. On termination we remove all access we had to the tenant, and delete any copy we made while supporting it (for example, a support extract) within the period agreed in the signed agreement, unless law requires us to keep it. On request we confirm the deletion in writing.

Annex 5 — Audit rights

The controller may audit our compliance with these terms once a year, or after a breach, on reasonable notice, itself or through an independent auditor bound by confidentiality. We provide the information and access needed.