Zgodność
Jak przepływają dane
Dokument zgodności
Jak przepływają dane
Ten dokument jest opublikowany w języku angielskim.
(oryginał angielski)
Last reviewed: 2026-10-29 · Version: 1.8
This is the path business data takes in Fundarem, from your own systems to a screen and back. It describes the product as it is designed to run: installed in the customer's own Microsoft Azure tenant, in an EU/EEA region the customer chooses (the install template defaults to Norway East). The public website and its demo are different; see Sub-processors.
The law that actually applies depends on the customer's own country. Country-specific detail (bookkeeping-act retention, the national data-protection act, e-invoicing mandates, employee-monitoring rules) lives in our country notes, sent on request, one page per country — start at the country index or go straight to Norway.
In short: your systems are read into a model of your business that lives in your tenant. 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). Nothing is written back to your systems until a person (or a rule you set) approves it, and every step is logged.
Step by step
| # | Step | What data | Where it is processed | Who controls it | Legal basis | Retention |
|---|---|---|---|---|---|---|
| 1 | Source systems — the software systems your business already uses | Whatever those systems hold: customers, contacts, employees, invoices, messages | Where each system already runs, under your contract with its provider | You (controller) | Your existing basis for those systems | Your existing policy for those systems |
| 2 | Connector — reads each system through its MCP server or REST API. A connector writes only where your admin allows it, and only as step 7. Foreign MCP tools are admitted only when the server marks them read-only. | The records the connector maps, field by field, to the ontology | Your Azure tenant (the API container) | You. Connector credentials are designed to be held in your Key Vault, never printed or logged | Art. 6(1)(b) or 6(1)(f), set by you; see Legal basis | Not stored by the connector itself |
| 3 | Ontology store — one model of your business: objects, properties, links, actions | The mapped objects, plus an append-only history of every change | The database, built to sit in your Azure tenant and region, which keeps each company's data separate | You | As step 2 | Until you delete it; see Retention |
| 4 | Anonymiser — on by default: the anonymiser runs before every model call, on every route, and masks the columns tagged for masking (presets Strict / Standard): personal data is replaced with pseudonyms (like P-qbvfhz); after the call, pseudonyms in the answer are turned back into real values. What is caught: values in columns you tagged as personal; in free text, the names of people your system has on record (your roster and names met in records), common Nordic and English first names and surnames from a bundled name list, and Norwegian national id numbers, organisation numbers, IBANs, email addresses and phone numbers. A hyphenated first name (like "Anne-Lise" or "Kjell-Magne") is caught when any part of it is a first name on the list. What is not caught: a name that is in neither your records nor the name list, nicknames and misspelled names, a lone name that is also an ordinary word (like "Bo" or "May"), and personal data in images or PDFs. 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) | The request text and context for one call | In your tenant, in the process that makes the call | You set the policy per model category: required (default) or optional. For a model that runs inside your own installation (the local model server), your approved choice alone decides (the Standard preset switches it off there); for a model outside the installation it is skipped only when both your 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). A managed model in your own cloud is not inside your installation. Per column you also choose send, mask or never send. A never-send column is removed from every request, whether the anonymiser runs or not. Every change is a proposal that a second person approves. Choosing optional is your decision as controller: do not choose it for a model that may receive special-category data (art. 9) or personal data in free text (subjects, notes, message text). When the anonymiser runs, a call carrying an unprotected value is refused. Same rule as DPIA, section 3 | As step 2; pseudonymisation is a safeguard under art. 25 and 32 | The pseudonym map is stored per tenant as a keyed hash (HMAC) of each value, never the raw value |
| 5 | AI model — answers a question or plans an agent's next step | The prompt and the context for that one call, with columns tagged for masking replaced by placeholders. Apart from that prompt and context, the system is built so nothing else leaves the tenant | Built so Fundarem and all stored data stay in your tenant, in the EU/EEA region you chose at install. Where the 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): its default open-weights model on Azure AI Foundry is served by a third party outside Microsoft's EU Data Boundary, and the prompt, with columns tagged for masking replaced by placeholders, is processed outside the EU, in the US (a Global Standard deployment, AI-policy residency tag global). Foundry Azure EU, open source: an EU Data Zone deployment, processed only within the EU. Frontier models in Foundry: in any Azure region, including outside the EU. Self-hosted VM in your Azure: on your own machine, in your own region. Direct access: on the model vendor's own service, outside Azure and outside the EU. An EU region is used only when the operator configures an EU FOUNDRY_REGION; otherwise the route is refused by name as model residency denied. A model outside your allowed regions is refused by name. Same rule as DPIA, section 1 | You choose which models may be used; the router refuses a model weaker than your policy | As step 2 | The model keeps no state between calls. We retain nothing. Provider-side handling follows your agreement with the provider |
| 6 | Widgets, agents and the assistant — dashboards, scheduled or event-driven agents, the side-panel assistant | Objects the person's role may see; agents read and propose only | Your tenant | You decide who sees what (roles) and which agents run | As step 2 | Screens hold no copy. Assistant threads and memories are stored pseudonymised in your tenant |
| 7 | Write back — a change is written back only where your write settings allow it | The proposed change and its input | Your tenant, then the target system through its connector | Write control is set per action by your admin, and every write is re-checked against the permissions of the person it acts for | As step 2 | Proposals, their decisions and the object history are kept for audit, in your tenant |
What is logged, and what is not
- Tool-call audit: who, what, when, the outcome and the call's parameters, with a hash of the output. The output itself is never stored.
- Fault log: a short reason only (for example model not configured) with the model or object it concerns. Never a prompt, a message or personal data.
- Anonymiser proof: for each model call, counts of pseudonyms and of any real values left in the outgoing request, and a hash of the request. Never the request itself.
- Cost caps: a limit per call and per day on AI spend, so a runaway agent stops.
The public website is not the product
This website and its clickable demo run on Vercel, whose server functions run in Washington, D.C. (United States, Vercel region iad1), and use fictional data about a made-up company. The demo's Ask bar may use a US model provider when no EU model is configured. Please do not type personal data into the demo. The website's question chat is a feature of our own website, not of the service we deliver to customers. It sends a visitor's question through Vercel's AI Gateway to Alibaba Cloud, running an Alibaba Qwen model; the calls are not pinned to an EU region, so they can run outside the EU. It answers only from the website's public content, and visitors are asked not to enter personal or customer data. Every call asks for zero data retention (the gateway then routes it only to providers it has zero-data-retention agreements with); we do not store questions or answers, only a count of questions per day. Details: Sub-processors.