01
Sovereignty
The system runs on the organization's own infrastructure. In local mode the data stays where it was created and there is no third-party processor; the choice of model stays open, with no lock-in to a single vendor.
SLAVKO · sovereign AI
AI that remembers. Runs where the data lives.
Sovereign AI for organizations: persistent memory on the organization's own infrastructure, the model of choice — local or cloud — and answers checked before delivery.
In production for institutions and schools. A product of Metatron Production.
Transparent AI: the interface always makes it clear when the other party is not a human.
What SLAVKO is
One core, many applications.
SLAVKO is sovereign AI: one core that runs on any model. The model can be local — on the institution's own equipment or in a national data centre, where the data never leaves — or in the cloud, with personal data removed when the organization requires it.
The system drives the model. A model's output is a candidate, not a result: it is checked before delivery, and an answer that fails the check goes back for repair instead of reaching the user.
Memory lives in files, outside the model, so it survives a model swap. Every user works in a separate space of their own: a job runs under their name and opens only their data. Every application is added to that core as one more layer — a single program instead of ten separate tools, one memory and one set of rules.
Why it is different
Three pillars.
02
Persistent memory
A session is temporary; memory is permanent. Knowledge is kept in readable files outside the model: the model gets swapped, while context, work history and rules remain.
03
Domain depth
The same foundation, adapted to each field separately: institutions, schools, finance, healthcare. In healthcare with a clear boundary: support for the physician, with the decision staying with the physician; the foundation is designed by a physician.
Applications
The core in practice.
Each card carries a maturity label.
Maturity labels: in production · in development · concept
Personal assistant
A personal assistant for an individual or a small team: conversation by text or voice message, in Serbian, with an answer that can also be listened to. It remembers what was agreed, keeps files and returns finished work — every user in a separate space of their own, invisible to any other.
More about the personal assistantPortal for institutions
An operations portal that turns every request into a recorded job, with a one-click report for the authorities. AI prepares, a human decides — the same team handles more requests.
Education assistant
Sovereign AI for the classroom: an assistant to the teacher and the school. Children's data stays in the country, and the system works even where the internet is unreliable.
More about the school assistantUlaz — homeowners association portal
A private portal for a single building: a wall and notice board, one vote per apartment, a register of decisions with deadlines — whatever is late stays on top until done — repairs, documents and funds. Sign-in with a Google account from the list, in four languages, installable on a phone. Next phase: AI as an assistant to the building manager.
More about the portal and the AI managerZDRAVKO clinical support
Structured clinical decision support on the same core: it organizes reference information, guidelines and literature for qualified healthcare professionals. It assists the physician, and the physician makes the decision — a research prototype, not a medical device. The first phase is in production with a limited circle of physicians; the second phase, with more users, is in preparation.
More about ZDRAVKOE-invoicing
A deadline tracker and error interpreter for the national e-invoicing system, in Serbian: it follows changes, explains errors against the official guidance and raises a flag before a problem occurs. It also runs on a local model, so financial data never leaves the company. The first phase is in production: the knowledge base from official sources; the answering layer and channels are the second phase, in preparation.
More about e-invoicingToken savings
An optimization layer that combines several methods — caching, request batching, routing to cheaper models, progressive disclosure of context, local models — so the same work gets done at a markedly lower cost. The first phase is in production, in daily use within the system itself; the offer for organizations — a usage review, a plan and guided optimization — is the second phase, in preparation.
Model router
A single point of access for other systems: the integration is done once, and behind it the most suitable model — local or economical — is chosen for each request, with usage metering. The first phase is in production within our own systems; the commercial layer for other organizations (keys, billing) is the second phase, in preparation.
Portable migration device
A portable, local AI device that connects read-only to an institution's legacy system, reads it — programs, databases, dependencies, configuration — and prepares a migration plan, so the engineer receives a finished analysis.
How it works
The path of a single request.
From question to verified answer, in six steps.
Request
A question or task arrives through a channel already in use — a web app, Telegram or e-mail — as text or a voice message. Speech is turned into text on the organization's own infrastructure, not at a third party.
Who is asking, and what is allowed
The system first establishes who sent the request and opens the job under that person's name, in their own separate space. For that job it knows how much may be spent and which tools may be run.
Context
The system assembles context from persistent memory: rules, work history and the data that belongs to that person or organization — not just from one session.
Candidate
The chosen model — local on the graphics card or in the cloud — proposes an answer. Calls to models go through a single point of access that alone holds the keys and keeps the usage ledger. That proposal is only a candidate.
Check
The candidate is checked: structure, rules and an independent review. An answer that fails goes back for repair or is discarded. An action that cannot be undone waits for a human to confirm.
Delivery and memory
The verified answer reaches the user — as text, or as Serbian speech synthesized on the organization's own infrastructure. What was learned along the way is written to memory, so the next session starts where the previous one stopped.
Comparison
Local mode versus a cloud assistant.
| Criterion | SLAVKO, local mode | Typical cloud assistant |
|---|---|---|
| Where the data is | Stays on the organization's infrastructure, with no third party. | Goes to a third party that processes it (a processor in the sense of GDPR Art. 28). |
| Memory | Persistent; survives closing the session and swapping the model. | Tied to the session or to an account with a single vendor. |
| Model | Any — local or cloud; swappable without losing knowledge. | One vendor; the model version is the vendor's choice. |
| Answer verification | The model's output is checked before delivery. | The model's answer reaches the user directly. |
| Voice | Speech transcription and Serbian speech synthesis run on the organization's infrastructure. | The voice recording goes to the vendor. |
| Cost | A fixed cost for the organization's own hardware. | Grows with usage. |
| Control | The organization chooses the model, the version and the rules. | Rules and version are set by the vendor. |
The comparison is qualitative and refers to local mode. The GDPR reference is general information and not legal advice; compliance is confirmed by the organization's legal team.
About the author
The system is authored by a physician.
SLAVKO is designed by Dr Ognjen Vučurević — a medical doctor and radiology resident who, since late 2024, has led the AI domain at an IT company in Belgrade: system architecture, specifications, acceptance criteria and the bridging of clinical, business and engineering teams.
Clinical discipline — differential diagnosis and the checks that must never be skipped — has been carried over into software architecture, where the same things are called validators, safety gates and the rule that a model's output is a candidate for a result.
The role is architectural: frame the problem, design the system, define the acceptance criteria and prove that it works. Implementation is carried out by agents and teams, to specification and sign-off.
Frequently asked questions
Direct answers.
Answers to the questions asked most often.
What is SLAVKO?
SLAVKO is sovereign AI for organizations: one core that runs on any model, keeps persistent memory and checks answers before delivery. It runs on the organization's infrastructure or, at the organization's choice, with a cloud model.
Does the data leave the organization?
In local mode it does not: the model runs on the organization's infrastructure and the data stays where it was created. In cloud-model mode a request goes to the model vendor, with personal data removed when the organization requires it; the choice of mode rests with the organization.
What is ZDRAVKO, and does it replace a doctor?
ZDRAVKO is clinical decision support for qualified healthcare professionals and does not replace a physician. It organizes references and guidelines, while the diagnosis and every decision are made and independently verified by the physician; it is a research prototype that is not a medical device.
Can the model be swapped?
Yes, the system does not depend on a single model vendor. The model is changed through configuration, while accumulated knowledge, work history and rules remain intact, because they are kept outside the model.
How does the system handle model errors?
A model's output is treated as a candidate and is checked — for structure, rules and by an independent review. An answer that fails goes back for repair or is discarded, instead of reaching the user.
Does the system understand and speak Serbian?
Yes. A voice message is transcribed into text, and the answer can also be spoken in Serbian. Both transcription and speech synthesis run on the organization's infrastructure, so the voice recording does not go to a third party.
How do users access the system?
Through the channels in production: a web app or Telegram, by text or voice, from a computer or a phone. The next step, in preparation, is a single app for phone and web — files, conversation, voice messages and calls in one place: the decision has been made, the build is under way.
How do SLAVKO, Metatron and Metatron Production relate?
Metatron Production is the company that designs, builds and runs the systems; SLAVKO is its product. Within the product, Metatron is the operating layer, SLAVKO is the assistant the user sees, and ZDRAVKO is the same core applied to healthcare. Ulaz is a homeowners association portal on the same foundation. Each application has its own public site — the family of sites is listed at the bottom of this page.
How does a collaboration start?
With a conversation, by e-mail. By arrangement, a demonstration of the system follows, on infrastructure of the organization's choosing.
Contact
A conversation is the first step.
For questions and to arrange a demonstration: e-mail below. The company behind the product: Metatron Production.
ognjen.vucurevic@gmail.com