How it works
Built to keep your data in the EU. You choose where the model call goes.
Fundarem reads your systems into one map of your business, inside your own Azure, in an EU region. Agents and assistants work on that map. When they need an AI model, one call takes the route you chose: some keep it in the EU, the default is processed outside the EU.
How it works. For “Compliance”, this page shows where your data is kept and where each model call goes.
Your software systems
- Matching payments to open invoices
- Flagging a late-paying customer
- Drafting a payment reminder
Stays inside Azure
Leaves Azure
- Stored data: built to stay in the EUThe map of your business, its history, assistant threads and the audit log are built to live in your own Azure tenant, in an EU region.
- Only the model call travelsFor AI, only the prompt of one call goes to the model you chose.
- The default model: processed outside the EUIt runs inside Azure, but the prompt is processed outside the EU. Self-hosted models and models processed only within the EU keep it in the EU.
- Every step loggedEvery read, every model call and every change, in your own tenant.
Built so stored data always lives in the EU.
Fundarem is built so everything it keeps sits in your own Azure tenant, in the EU region you choose at setup. What can leave is an AI model call, and each route says where it is processed.
Built to be kept in your tenant, always
- The map of your business and its full history
- Assistant threads and memories
- Proposals, decisions and the audit log
- Connector keys, designed to sit in your own key vault
Can leave, one call at a time
- The prompt of one model call, on the route you chose
- Changes your admin allows, written back to your own systems
On the default route, that prompt is processed outside the EU. Choose a self-hosted model, or one processed only within the EU, to keep it in the EU.
From your systems to an answer, in six steps.
- 01
Your systems stay where they are
The software you already use keeps running as today. Nothing is migrated: Fundarem reads from it, and writes back only where you allow.
- 02
Connectors read them in
Each system comes in one of three ways: a ready connector from the library, a connection the system’s own maker already offers, or a custom connector built for it. Your admin tags which columns hold personal data before the first sync.
- 03
One map of your business
Every system is translated once into objects, links and actions. The same customer known under three ids in three systems becomes one object, and a person confirms the match before it counts.
- 04
Agents and assistants work on the map
Nothing on top talks to a system directly. Agents run on schedules and triggers, each person’s assistant sees what their role may see, and dashboards are built from the same map.
- 05
The model branch, and the anonymiser
When a task needs an AI model, the call goes to the model your IT admin picked for that kind of task, inside the frame chosen with us at setup. The anonymiser is on by default for every model: before a request goes to a model, it replaces the values in the columns your admin marks for masking, and the names and patterned values it recognises, such as Norwegian national ID numbers, phone numbers and IBANs, with placeholders. Your admin can switch it off per kind of personal data, one model route at a time; every other kind stays masked. The model keeps nothing between calls.
- 06
Changes written under your settings, every step logged
An agent’s change is a proposal, written back only under the write settings your admin chose. Every read, every model call and every change is logged.
Where the model call goes.
Most routes stay inside Azure. One, a model vendor’s own API, leaves Azure. Which of them you may use, the frame, is chosen with us at setup, and your IT admin cannot change it; inside it, your admin picks which model takes which kind of task. Stored data is built to stay in your tenant.
Stays inside Azure
- Processed in your own region
Self-hosted
The model runs on servers in your own Azure, in your region. Nothing is sent to an outside provider. The anonymiser runs here too by default; your admin can switch it off for this model.
- Processed only within the EU
EU-only models
A model run inside Azure, with the prompt processed only within EU member countries.
- Inside Azure, processed outside the EU
The default model
The default runs inside Azure, but the model is served by a third party and the prompt is processed outside the EU. Your stored data does not take this branch.
Leaves Azure
- Outside Azure
Model vendors’ own APIs
Your IT admin can pick a model vendor’s own API, outside Azure, once the vendor’s API key is added to your installation. The prompt is then processed by that vendor outside Azure; the anonymiser, on by default, masks it before it leaves.
What an open-source model is, and why it matters
An open-source model, also called open weights, is one whose maker publishes the model files, so anyone may download and run them under the model’s licence. A closed model can only be used through its maker’s service or a cloud that sells it.
You can run it yourself
The same model can run on Azure or on a machine you own, so you can move it later without changing how you work.
No lock-in
If a provider raises its price or stops offering the model, another host, or your own machine, can run the same files.
Your prompts can stay with you
On your own machine, no model maker ever sees a prompt.
Read the licence
Each model has its own licence. Most open ones here use a permissive licence such as Apache-2.0 or MIT; some add conditions. Every model’s licence is listed next to it.
After go-live, in your own installation.
What your company has once Fundarem is running.
- Your own company brainEach company has its own company brain: what Fundarem learns about how your company works, approved by a manager and built to be kept in your own installation.
- An assistant that knows the manualThe product’s manual is inside your installation, for the version you run. Your own people ask the assistant how something works or where to find it, and it answers from the manual with a link to the screen. Parts written for admins are for admins and managers; a member does not get them.
- Activity and spend you can seeEvery model call is logged with the model used and what it cost, and you set what the AI may spend per request and per day. Your admin sees each user’s activity and what their model calls cost. For billing we receive counts only, such as the number of active users, never names or content.
- Billing from us, in plain viewIn your installation your IT admin sees this month’s estimate of our bill: the monthly fee plus the active users times the price per user, worked out from your installation’s own count. The estimate uses our list price until the prices in your contract are set in your installation; if a configured price is invalid, the page says the price is not set.
- Updates your admin approvesWhen we publish a new version, your admin panel shows it with its change log, and your admin approves it or sets an automatic window for it, and the installation installs the approved version by itself.
- More connectors, whenever you need themYour admin adds more connectors from the library at any time, and new ones reach the library with software updates. Missing one? Request a connector and we send a quote.
- Our access is your choiceOur access is limited to the one resource group Fundarem is built to run in. After go-live your admin chooses whether we stay in to monitor and assist, or keep limited access only: the change is a proposal approved in the admin panel, and your admin then makes the matching change in your own Azure. Fundarem then checks that step in your Azure.
- How your data flowsYour admin sees what leaves your systems for the AI model, and what the anonymiser masks first, drawn from your own settings.
- More columns marked as personal dataYour admin marks more columns as personal data at any time, on any data type. Each change is a proposal, approved before the anonymiser uses it.
From your first call to running, in nine steps.
The six steps under How it works show how the software works. These nine show how you get from a first call to Fundarem running in your own Azure.
01Contact us
Tell us about your business, the systems you use and the AI model you prefer. It takes a few minutes.
02The call and the contract
We call you, talk through your systems and your compliance needs, and agree the contract.
03Your onboarding profile
We make your company’s profile: the systems to connect, the AI models it may use, your region and your plan.
04One software, with a setup code
Every company gets the same signed software, a setup code its install can verify, and a written guide. Your settings are data, not code.
05Set it up, your way
You choose who sets it up in your Azure.
You set it up yourselves
With our steps: a form in the Azure portal creates the one resource group Fundarem runs in, with the rights it needs. A setup code your install can verify lets you finish without us.
orWe set it up for you
You give us access to one resource group through Azure Lighthouse, and we set it up.
06The software builds itself in your Azure
It builds its services, its database, its Key Vault, its file storage and your own company sign-in inside your Azure.
07Your preferences and your credentials
Your IT admin sets your preferences in first-run setup and enters the connector credentials. They go into your own Key Vault: Fundarem keeps only each secret’s name, never its value. The connectors in your plan are already listed.
08Our final checks
We check the installation in your Azure before it goes live.
09Live
Your company starts working with Fundarem.
Finally, once you are live: the access we keep
Your admin chooses how much access we keep, in the admin panel, and can switch it later.
We stay in
We monitor the installation and assist.
Limited access
We keep only the access needed to run it.
Updates you approve
When we publish a new version, your admin approves it in the admin panel, and the installation installs it by itself.
Next in the story
Choose the AI model that suits your needs.
Compare the models on each route: where the prompt is processed, how well each one does, and what it costs.