JiCoRedact. Approve. Document.
Local first, cloud as an option
The model is interchangeable. What JiCo starts with when nobody does anything is not interchangeable by accident.
Background · 2026-09-19 · 5 min read
A default is what happens when nobody makes a decision
There is a difference between an option and a default that product descriptions like to blur, but that decides everything in practice: an option is something you can actively choose. A default is what happens when nobody chooses anything — the state in which the system comes out of the box, before anyone has touched a single setting.
JiCo starts with a local model via Ollama, running directly on your own machine. Anyone who would rather use the Claude API can do so — but explicitly as an opt-in that has to be deliberately enabled, not as a second, equally ranked default that one picks casually during onboarding. The difference sounds like a detail of wording. It is not: it decides what happens on the first day, when an IT department installs the tool and then has other priorities than going through every single setting. For JiCo that means, concretely: no flow of data to a cloud provider unless somebody has actively and deliberately enabled that step.
Why a rigid rule with no way out would still be the wrong answer
One could argue at this point that the most consistent solution would be a fixed, unalterable rule: always local, no exception, no discussion. That stance would be easier to communicate and would look good in any marketing presentation. But for some real tasks it would simply be too weak.
A local model on ordinary office hardware is not in every respect as capable as a current cloud model — with more complex summaries, with multilingual tickets, with tasks that have to keep a lot of context in view at once, that becomes noticeable. And some companies already have a vetted, contractually secured cloud connection that they want to use anyway and for which internal approval has long been in place. A rigid default with no way out would make JiCo unusable in exactly those cases — at the very point where it ought instead to pass the decision on to the right person, namely the one who actually carries the risk in the end.
What stays technically unchanged in both cases
Whichever model is in use — local on your own machine or as a vetted cloud option — the redaction of personal data runs before it in both cases, not after. In both constellations the model sees only the placeholder, never the plain text behind it. The difference between the two routes does not lie in what is redacted or how thoroughly — that stays identical. It lies solely in where the already redacted, cleaned text is finally sent: to the same machine that also holds the Jira data, or across the open internet to a third party's data centre.
This consistency is not an accident but a deliberate architectural decision: the redaction sits structurally before the question of which model is used at all, not after it as a retrospective adjustment to whichever model route was chosen.
An intermediate stage that is easily overlooked
Between "entirely local" and "fully in the cloud" there is an intermediate stage that easily slips through on a superficial look: some models that can be run locally now offer a cloud variant of their own, running under the same familiar name but performing the actual computation on the model provider's infrastructure instead of on your own machine. Anyone looking only at the model name could easily assume they are still working "locally", when in reality the request has long since left the building.
This distinction is therefore not left to chance: an execution of the same model labelled as a cloud variant counts technically as a remote model, with the same consequences as any other external model route — it falls under the same opt-in requirement and the same logging, regardless of how familiar or "local" the name may sound.
Why this choice has to remain traceable afterwards
Switching between the model routes in a way that nobody can trace afterwards would amount to almost no control at all — it would be a one-off decision that disappears into a configuration file at some point and that nobody can later say with certainty when it was actually made. That is why the model actually used appears in every single audit entry, not merely as a global, hidden setting somewhere in the system.
That is not an additional feature that could be left out without anything essential being missing. It is the actual reason why switching is defensible in the first place: a decision to use a cloud model instead of a local one for a particular assignment can be traced afterwards for exactly that one assignment — not just as a vague global setting that nobody remembers in detail six months later. Anyone checking later what a model actually saw does not additionally have to reconstruct laboriously which model that was in this specific case — the answer already stands in the same place as everything else that belongs to this operation.