Your data stays yours — and here is the paperwork.

Last reviewed: 2026-09-25 · Version: 1.0

This is the path business data takes in foundAItion, 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.

In short: your systems are read into a model of your business that lives in your tenant. Personal data is swapped for pseudonyms before any AI model sees it. 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

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 code only (for example 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 a US-region host 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. Details: Sub-processors.

Last reviewed: 2026-09-25 · Version: 1.0

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 foundAItion. 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. Datatilsynet publishes guidance on when a DPIA is required in Norway.

1. Description of the processing

• Controller: the customer. Processor (where we operate or support the installation): [legal entity: to be set], contact [contact email: to be set].
• Nature: foundAItion 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. Every change is proposed, approved and then committed.
• 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: Norwegian and 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). AI models are deployed through Azure AI Foundry in the customer's subscription, EU data zone. An EU region is used only when the operator configures an EU FOUNDRY_REGION; otherwise the route is refused by name 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. Under the tenant's instance mode (its AI policy; hybrid unless the policy says otherwise), payroll, health and banking-credential data never leave the installation: such a prompt goes only to a model the installation serves itself, configured by the operator with LOCAL_MODEL_ENDPOINT, LOCAL_MODEL_API_KEY (optional) and LOCAL_MODEL_NAME (optional), or it is refused by name model_residency_denied. A managed model service, even in the customer's own subscription, never counts as local. frontier lets every class go to an allowed external model (still pseudonymised); local keeps every prompt inside. The mode changes only through propose, approve, commit.

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

4. Residual risk and conclusion

With the measures above, we assess the residual risk of the product itself as low. The customer's overall 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

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.

Last reviewed: 2026-09-25 · Version: 1.0

These are the processor terms under GDPR Article 28 that we put in place with each customer before any processing starts. Status: draft, not yet reviewed by a lawyer. It is not legal advice and not an offer to sign; the agreement signed with a customer is the binding version.

Parties. The customer is the controller. [legal entity: to be set] (contact: [contact email: to be set]) 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 or Norwegian 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 GDPR or Norwegian 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 Datatilsynet (art. 33) and the people affected (art. 34); we help.

3. International transfers

• The product runs in the customer's own Azure tenant in an EU/EEA region the customer chooses (default Norway East), with AI models deployed in the EU data zone. We do not transfer the customer's data outside the EU/EEA.
• This public website and its demo are hosted in the United States, 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 by Postgres row-level security inside the database, not only in application code.
• Pseudonymisation of names, national ids, emails and phones before any AI model call; a call carrying 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.
• Deploys designed to use GitHub Actions with OIDC, with no stored deploy password.
• 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; every write goes through propose → approve → commit, with four-eyes approval for sensitive actions.
• 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 [period: to be 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.

Last reviewed: 2026-09-25 · Version: 1.0

A sub-processor is another company we engage that processes personal data on the customer's behalf. Today there are two, and both serve only this public website and its demo, which hold fictional data. We tell customers in advance before we add or change a sub-processor.

Why Microsoft Azure is not on this list

The product is installed in the customer's own Azure tenant, on the customer's own Microsoft agreement and bill. Microsoft is the customer's own provider under that agreement (including the Microsoft Products and Services Data Protection Addendum), not a sub-processor we engage. The same holds for AI models deployed through Azure AI Foundry in the customer's subscription.

Changes

Last reviewed: 2026-09-25 · Version: 1.0

The customer is the controller and sets the retention periods for its own data. The product stores everything in the customer's own tenant, so those periods are applied there. Norwegian law sets some minimums that the customer must follow, for example the bookkeeping rules (bokføringsloven) for accounting records.

What the product keeps, and for how long

What is not built yet

There is no automatic deletion job in the product today. Retention periods are applied by the customer's administrator, with our help. An automatic retention setting per object type is on the roadmap; until it ships, this page will not claim it.

Last reviewed: 2026-09-25 · Version: 1.0

GDPR Articles 15 to 22 give people rights over their personal data. The customer, as controller, answers these requests within one month (art. 12(3)), extendable by two further months for complex requests. Because the data sits in the customer's own database, the customer can always act on it; as processor we help.

The rights, and how the product supports each

A self-service export and delete screen is on our roadmap. Until then, we do it together with the customer.

How to exercise a right

• If you are a customer's employee, customer or supplier: contact that business. It is the controller of your data.
• If you want to contact us (as processor, or about this website): [contact email: to be set]. We pass requests about a customer's data to that customer without delay.

Complaints

You can complain to Datatilsynet, the Norwegian Data Protection Authority, or to the supervisory authority where you live or work in the EU/EEA. Datatilsynet: datatilsynet.no.

Last reviewed: 2026-09-25 · Version: 1.0

Which law applies

• GDPR — Regulation (EU) 2016/679 (EUR-Lex). It applies in Norway through the EEA Agreement (EEA Joint Committee Decision No 154/2018).
• Personopplysningsloven — the Norwegian Personal Data Act, LOV-2018-06-15-38 (Lovdata), which makes GDPR Norwegian law and adds national rules, for example on national identity numbers and on employee monitoring.
• The supervisory authority in Norway is Datatilsynet.

The legal basis for the product

The customer, as controller, chooses and documents the legal basis for each purpose. For the typical uses of foundAItion:

National identity numbers (fødselsnummer) may only be processed where there is an objective need for secure identification (personopplysningsloven § 12). The product pseudonymises them before any AI model call, but whether to hold them at all is the customer's decision.

Our own processing

As processor, we process customer data only on the customer's instructions (see Data processing agreement). For this public website, we rely on art. 6(1)(f) for ordinary request logs needed to run and secure the site.

Last reviewed: 2026-09-25 · Version: 1.0

The EU Artificial Intelligence Act, Regulation (EU) 2024/1689 (EUR-Lex), sets rules for AI systems in the EU and phases in from 2025. In Norway it applies once it is incorporated into the EEA Agreement and Norwegian law.

What foundAItion is under the AI Act

foundAItion is a general-purpose integration tool: it connects business systems, models their data, and lets AI agents and an assistant work on it under human control. It is not built or marketed for any high-risk use listed in the AI Act (Annex III), such as recruitment and selection, credit scoring or access to essential services. The AI models it uses are general-purpose models from third parties; foundAItion does not train models.

The customer's obligations for high-risk uses

If a customer uses foundAItion for a purpose the AI Act treats as high-risk — for example, ranking job applicants or deciding on credit — the customer becomes a deployer of a high-risk AI system for that use, and must among other things:

• use it according to its instructions and assign human oversight to competent people;
• keep the automatically generated logs it controls;
• inform workers' representatives and affected workers before using it at work;
• carry out a fundamental-rights impact assessment where the Act requires one, next to its DPIA.

Tell us before starting such a use. We help document it, and the product's controls below support it.

Transparency and human control, built in

• Labelled: every action an AI agent proposes is recorded as coming from that agent: the agent kind and run are stored with the proposal.
• Logged: every tool call an agent makes is recorded: who, what, when, the outcome and a hash of the output.
• Approved: agents only propose. A person approves every write, unless the customer chooses an autonomy mode for low-risk actions; sensitive actions always need a person, and a second person (four-eyes).
• Checked twice: permissions are checked when the agent proposes, and again under the approver's identity before anything runs.
• Stoppable: a tenant kill switch stops all new proposals.
• Transparency to people (art. 50): people who interact directly with the assistant or an agent must be told it is an AI system. The product shows the assistant in its own labelled panel; the customer confirms that the wording fits its users.