Regelefterlevnad
Dokument om regelefterlevnad: DPIA
Dokument om regelefterlevnad
DPIA
Det här dokumentet är publicerat på engelska.
(engelskt original)
Last reviewed: 2026-10-29 · Version: 1.4
A data protection impact assessment (DPIA) under GDPR Article 35 is the controller's document: the customer carries it out for its own use of Fundarem. This is the template we provide, filled in with what the product itself does. Every fact that depends on how a customer deploys and uses the product is marked in the customer's tenant and must be completed by the customer. Each country's data protection authority publishes guidance on when a DPIA is required there (in Norway, Datatilsynet) — see our country notes, sent on request.
1. Description of the processing
- Controller: the customer. Processor (where we operate or support the installation): Seginus AS, org. nr. 924 867 558, contact the address given in the agreement we sign with you.
- Nature: Fundarem connects the customer's business systems, describes their data as one ontology (objects, properties, links, actions), shows it in dashboards, and lets AI agents and an assistant read it and propose changes. Write control is set per action by the customer's admin.
- Scope: the data held in the connected systems — typically customers and their contact persons, employees, suppliers, invoices, orders, messages and time entries. Which systems are connected is decided in the customer's tenant.
- Context: European small and medium businesses. Data subjects are the customer's staff, its customers' and suppliers' contact persons, and people named in messages or documents.
- Purposes: running and overseeing the business: a single view across systems, reports, and assisted or automated routine work under human control.
- Where: the customer's own Azure tenant, in an EU/EEA region chosen at install (default Norway East). Built so Fundarem and all stored data stay there. The AI model is the customer's choice, deployed through Azure AI Foundry in the customer's subscription or self-hosted; each choice states where the prompt, with columns tagged for masking replaced by placeholders, is processed (the default model: Global Standard, outside the EU, residency tag
global; EU Data Zone models: in the EU, tageu; self-hosting: in the customer's own region, tagcustomer-cloud). An EU region is used only when the operator configures an EUFOUNDRY_REGION; otherwise the route is refused by name as model residency denied. Same rule as Data flow, step 5. - Data flow: see How data flows.
- Sensitive data classes and the local model: each object type declares a data class. Payroll, health and banking-credential data never leave the installation by default: such a prompt goes only to a model the installation serves itself, or it is refused. A managed model service, even in the customer's own subscription, never counts as local. The customer's admin sets this policy and can change it.
2. Necessity and proportionality
- Lawful basis: set by the controller per purpose; see Legal basis.
- Data minimisation: each connector maps only declared fields. The ontology exposes only whitelisted properties, and each role sees only the object types its gate allows.
- Purpose limitation: agents and the assistant work only through the ontology's declared tools and actions. They cannot reach a system or table directly.
- Storage limitation: the product keeps no copy outside the customer's tenant. Retention periods are set by the controller; see Retention.
- Transparency and rights: see Data-subject rights and EU AI Act.
- Processors and transfers: the product runs in the customer's own tenant; see Sub-processors.
3. Risks to data subjects, and the measures against each
| Risk | Likelihood before measures | Measures built into the product | Residual |
|---|---|---|---|
| Personal data sent to an AI model and exposed or reused | Medium | 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; a call carrying an unprotected value is refused; per-model policy (required by default), and a model weaker than the tenant's policy is refused by name. For the model inside the installation, the tenant's approved choice alone decides (the Standard preset switches it off there); for a model outside the installation it is skipped only when both the tenant's setting and the model's own record say optional, and no seeded record does. When it is skipped, the anonymiser proof records the decision bypassed (optional). Choosing optional is the controller's decision: not for a model that may receive special-category data (art. 9) or personal data in free text (subjects, notes, message text). Same rule as Data flow, step 4; open-weight models in the customer's subscription; the model keeps no state | Low |
| One customer's data seen by another | Low | Each company's data is kept separate, enforced inside the database; every query is scoped to one company | Low |
| An AI agent changes or sends something wrongly | Medium | Agents only propose. Write control is set per action by your admin, and every write is re-checked against the permissions of the person it acts for. Tenant kill switch. Every tool call is audited | Low |
| Logs become a second copy of personal data | Medium | The fault log stores a short reason only, never a prompt or message. The tool-call audit stores a hash of the output, not the output. The anonymiser proof stores counts and a hash, never the request | Low. The audit does store call parameters, which may include identifiers; its access is limited in the customer's tenant |
| Re-identification from the pseudonym map | Low | The map stores a keyed hash (HMAC) of each value under a secret, never the raw value; rows are kept separate per company in the same way | Low |
| Runaway cost or automated loop | Low | Cost caps per call and per day; agent runs have a turn limit, a lease and back-off | Low |
| Credentials for connected systems leak | Low | Designed to be held in the customer's Key Vault and never printed | Low |
| Automated decisions with legal or similar effect (art. 22) | Depends on use | The product proposes; a person decides. Whether a use case falls under art. 22 is assessed in the customer's tenant | Assessed by the customer |
4. Residual risk and conclusion
The residual risk in the table above is what the product's measures are designed to achieve; it is a starting point for the customer's own assessment, not a conclusion of ours. The customer's conclusion depends on which systems it connects, which agents it enables, which autonomy mode it chooses and who can approve, all decided in the customer's tenant. If the customer's assessment finds a high residual risk, GDPR Article 36 requires prior consultation with Datatilsynet.
5. Sign-off
| Role | Name | Date | Decision |
|---|---|---|---|
| Controller (customer) | to be completed in the customer's tenant | ||
| Data protection officer, if appointed | to be completed by the customer | ||
| Processor (Seginus AS, org. nr. 924 867 558) | to be completed |
Review this assessment when a new system is connected, a new agent kind is enabled, the autonomy mode changes, or a model outside the EU data zone is considered.