Planned feature
This feature is not available yet. Here is what is planned, so you can tell whether it will cover your need — and tell us if it will not.
Status — design settled
Planned availability — server mode only
Summary
The assistant ships with no model of its own: the institution decides which one drives it. A local model keeps everything inside; a remote one sends requests out and sits behind two independent locks. Configuration is reserved to the workspace owner, and an access key, once saved, is never handed back.
Why the choice is yours
Linkr does not offer “its” model. The assistant’s requests concern health data: deciding where they go amounts to deciding how confidential they are. That decision belongs to your institution, not to the software vendor.
A model provider is therefore a configuration you add: an address, a model name, possibly an access key. It belongs to the workspace, and only its owner can create or change it.
Local or remote
The whole question rests on the address of the endpoint.
Local model
A model running on your own machines — Ollama, vLLM, or any compatible endpoint.
Requests never leave the institution. The assistant can then work on clinical data without particular restriction: the safeguard is where the model runs.
Remote model
A service hosted by a third party — Mistral, OpenAI, or another.
Requests leave the institution. Data rows are not sent: only structure and aggregates are, and an External API badge stays visible wherever the model appears.
Being local is not declared by whoever configures it: Linkr derives it from the address. An address on localhost, on 127.0.0.1 or on a private network is local; everything else is remote. So an external service cannot be passed off as internal by ticking a box, nor can a local provider be quietly walked over to remote afterwards.
Which data, which model
The choice does not come down to preference, but to what the instance holds.
An instance with no sensitive data — a remote model is conceivable
Nothing stops you installing Linkr on your own computer to develop, learn or work out a method, provided it holds only synthetic or public data — no patient data at all. In that case, a third-party model only ever sees code and structures.
An instance with patient data — the model must be local
The model then becomes a component of the health-data processing chain. It falls under the same security level as the data itself and as the environments used to reach it: hosted within the same perimeter, subject to the same rules.
Working across two instances is therefore a perfectly legitimate setup: one on your machine for development, one inside the institution for real data. The method travels between them — which is exactly what exporting a project allows.
The two locks
A remote model is protected by two independent mechanisms, which do not replace one another because they guard against different things.
The instance lock
A server-level setting forbids remote models outright, and it is on by default. The administrator shuts the door once and for all: nobody can then enable an external model, even by mistake. This is the strongest guarantee in the design.
The explicit acknowledgement
If the instance allows it, creating a remote provider requires a named confirmation, recorded with its author and date. Someone takes responsibility, and it leaves a verifiable trace.
The first protects the institution — a policy, not good intentions. The second identifies the person who made the call. Either one alone would leave a gap.
Approving a model per use
The same model is not equally good everywhere: a compact model may be enough to compose a dashboard and weak at writing code.
Approval therefore happens per surface: for each model you state where it may be offered — dashboards, the IDE, and so on. Users only see the models approved for wherever they are working.
The access key never comes back out
A saved key is encrypted and is never handed back, not even to whoever entered it: the interface only shows that a key exists. To replace it, enter a new one; to keep it, leave the field empty.
What is not settled yet
- Letting the user pick a model among the approved ones, rather than one imposed per surface.
- What to do when a model becomes unavailable mid-conversation.
Going further
- Agents — what the assistant does with that model, and what it will never be able to do.
- Configuration — instance settings, including forbidding remote models.