

This Tech Assistant is designed to support you with clear insights into our company, our work, our services and the people behind our progress.
Powered by CorLab Tech © 2025
The most useful question anyone asked me about analytics did not come from a data person. It came from an IT lead at a hospital, halfway through a meeting about something else, and it was four words long: “Does it leave here?”
I said what everybody in this market says. It is encrypted in transit. It is hosted in the European Union. The provider is certified. He listened politely and then said the thing I have thought about ever since: “That is not what I asked.”
He was right, and he was right earlier than most. Since then, three separate pieces of European law have arrived at the same conclusion he reached on his own in a meeting room — and one of them takes effect on 27 September, three weeks from now.
So this is the story of CoRLab BI: what it does, what actually crosses the boundary when you ask it a question, and why the answer to “does it leave here?” is now a design constraint rather than a marketing line.
You connect it to your databases. You ask a question in plain language. It writes the query, runs it, shows you the result, and builds a chart or a report out of it. If you would rather not trust a sentence, there is a visual query builder and a raw editor sitting right next to the chat, and you can move between them mid-thought.
The part that is unusual is where all of that runs: on your servers, inside your network, under your credentials. There is no CoRLab-hosted copy of your data, because there is no CoRLab-hosted anything. We ship containers.
Three things landed this year, and they point the same direction.

The dates that are already fixed. Two of them bite before the end of this year.
The one with a deadline. France's Décret n° 2026-209 of 24 March 2026 takes effect on 27 September. From that date, personal health data must be stored inside the EU or EEA — full stop. Remote access from a third country is still possible, but only under an adequacy decision or Article 46 safeguards. Hosting contracts must now name the foreign legislation that could compel a transfer, state whether an adequacy decision applies, and describe the mitigation and the residual risk. Providers must publish and maintain a public map of every transfer outside the EEA and every remote access point.
The one everybody is getting wrong. You will read that the EU AI Act was postponed. Half of it was. Regulation (EU) 2026/1744 — the AI Omnibus — moved the Annex III high-risk obligations from 2 August 2026 to 2 December 2027, and Annex I to August 2028. It did not move Article 50. Transparency obligations have applied since 2 August 2026. If a clinician or an administrator types a question into a box and an AI system answers, you have to tell them that is what happened. That is a cheap thing to get right and an embarrassing thing to get wrong.
The one that will matter most, later. Under the European Health Data Space, every hospital and every insurer becomes a health data holder. From 26 March 2029 that means three concrete obligations: a catalogue of your datasets, published to the access body and updated at least annually; a documented position on the quality and utility of that data; and the ability to hand over a defined dataset within three months of a request. The implementing acts that say exactly how are due 26 March 2027. Nobody builds that capability in the last quarter before a deadline.
This is the distinction the hospital IT lead was making, and it is the one that most procurement documents still blur.
Where a server physically sits is a fact about geography. Who can be legally compelled to hand over what is on it is a fact about corporate control. Those two facts come apart. France's own national health data platform is the clearest illustration: the Health Data Hub is migrating off Microsoft Azure to Scaleway, announced in February 2026, precisely because the concern was never latitude and longitude. And in March 2024 the European Data Protection Supervisor found that the European Commission's own use of Microsoft 365 infringed the data protection rules for EU institutions, ordering it to suspend data flows to non-adequate third countries.
If the Commission and the French health ministry both had to redo this, a hospital in Chișinău or Cluj is not being paranoid for asking.

The comparison we now put in front of every prospect — including the cases where the answer is not us.
I want to be honest about that table. Options A and B are legitimate, and for plenty of organisations they are the right call — cheaper, faster to start, someone else's problem to patch. What they cost is paperwork, every year, forever. Option C moves that cost to the beginning.
“Self-hosted AI” is a phrase that can hide a lot. So here is the honest version of the architecture, including the part that does leave.

The whole platform runs inside the customer's perimeter. Only the question and a masked sample cross the line.
The model is the only thing not running on your hardware, and that is a deliberate trade. Running a frontier model on-premise means either a much weaker model or a much larger budget, and most of the organisations I am describing have neither. So instead of pretending, we made the model interchangeable: 30+ models through OpenRouter, or Azure OpenAI, or your own endpoint — your key, your contract, your choice of jurisdiction. An Azure private endpoint inside your own tenant is a supported deployment, and for the strictest customers that is the one we recommend.
What crosses out is the question, an anonymised description of the schema, and a masked sample of results. What comes back is a query and an explanation of how it was reasoned. The rows, the credentials and the exports stay put. The chart you end up looking at is drawn from the full result set inside your perimeter, not from the sample the model saw.
The masking step is where most “private AI” claims quietly fall apart, so it is worth being concrete.

The same result set on both sides of the anonymisation step. Fictitious data — no real record appears here.
We use Microsoft Presidio to detect and mask personal identifiers before anything enters the model's context. Names, identifiers and dates are replaced with placeholders; the columns the question is actually about survive intact, because otherwise the model has nothing to reason over.
And masking a column is not the end of it. The EDPB's draft guidelines on anonymisation — in public consultation until 30 October 2026 — ask for a documented re-identification risk assessment against three cumulative criteria: singling out, linkability and inference. They also ask for that assessment to be repeated as the data changes. A sufficiently narrow aggregate can identify one person without a single name in it. We built the mechanism; the assessment is a joint exercise with the customer, and we say so in writing.
Three roles. A superadmin manages accounts, datasources and users. A user can query, build dashboards and write reports. A viewer can look. Accounts are scoped, so one tenant never sees another's datasources, and every mutation lands in an audit log — which matters more than it sounds, because “who asked the system that question, and when” is going to be an audit question, not a curiosity.
Sharing is deliberately narrow: public share links and embeddable views, token-based, with expiry dates. If a link has no expiry, someone will eventually find it in an email from 2027.
One connector was the wrong shape. The first version reached the databases through a single generic layer. It worked until it had to be correct: a MongoDB aggregation pipeline and a ClickHouse analytical query are not two dialects of the same thing, and a generic layer ends up being bad at both. Splitting them into separate MCP servers cost a week and removed an entire category of wrong answers.
Natural language over a document store is its own problem. Almost everything published about “text-to-SQL” quietly assumes a relational schema you can read off a catalogue. Collections do not work like that. Fields are optional, nested, and inconsistently typed across documents that arrived in different years. Most of the work in the MongoDB connector is schema inference, not query generation, and none of the public benchmarks measure it.
Benchmarks are not evidence. The public leaderboards sit in the low eighties. Evaluations on private, real warehouses land in the low tens. A CIDR 2026 paper then found that more than half the questions in one widely-cited benchmark are annotated incorrectly — fixing the annotations moved model rankings by up to three positions. We stopped quoting anyone's score, including our own, and started building a harness that runs against the customer's schema during the pilot. That is the only number that means anything to them.
Reports needed to be templates. The first version generated a beautiful one-off document that nobody could reproduce next month. Reports are now Markdown templates with {{VARIABLE}} placeholders and a draft/published/archived workflow, which turned a demo into something a controller actually uses on the first of the month.
“We use MCP” stopped being a differentiator halfway through. When we started, an open connector protocol felt like a position. By April, Metabase had shipped a self-hosted MCP server with bring-your-own-key, and Databricks, Snowflake, ClickHouse and Teradata all had one. The protocol is table stakes now. What is still ours is where the connector runs, whose credentials it holds, and whether anyone audited it — which, given how many public MCP servers turn out to have no authentication at all, is not a small thing.
A semantic layer. This is the honest gap. When dbt re-ran a well-known benchmark this year, a governed semantic layer answered 100% of in-scope questions correctly and text-to-SQL managed 64.5% — and the two fail differently, which is the part that matters. Text-to-SQL returns something plausible and wrong; a semantic layer refuses. For a board KPI you want the refusal. We are building toward that, and until it exists I tell customers to use the chat for exploration and a reviewed saved query for anything that goes in front of a regulator.
Also missing: more database connectors, a published evaluation harness, and any certification. We have the architecture that makes those audits pass; we do not yet have the certificates, and I would rather say so than imply otherwise.
There is a number I keep coming back to. In Eurostat's 2025 figures, 16.28% of EU enterprises with ten or more employees use business intelligence software. In Romania it is 8.15%. In Bulgaria, 6.84%. Among large enterprises across the EU it is 69.24%; among small ones, 11.45%.
That is not a digitalisation gap — ERP is at 46% and CRM at 28%, so these companies do have systems. It is an analytics gap, and it has three causes: per-seat pricing built for large firms, an assumption that somebody on staff writes SQL, and, for anyone handling health or public data, a policy that forbids the cloud outright. A self-hosted platform you talk to in plain language removes all three at once.
It also happens to describe the institutions I have spent a decade building software for. CoRLab Tech built and maintains SIA eRețeta, Moldova's national e-prescription and reimbursement system — more than 15 million electronic prescriptions in two years, reaching over 900,000 unique beneficiaries, roughly 38% of the population. We maintain the DRG case-mix system and SIRSM for CNAM, and we are building the national medicines stock system now. On all of those, we are the software contractor and not the data owner: CNAM owns the prescription and dispensing data, hospitals own theirs, USMF owns its research data. We can tell you what it is like to build systems around data like that. We cannot, and do not, offer you access to it.
That distinction is exactly why CoRLab BI is shaped the way it is. When you have spent years working next to data you are not allowed to take home, an architecture where nothing leaves the building is not a compliance feature. It is just the only design that was ever going to work.
The most useful question anyone asked me about analytics did not come from a data person. It came from an IT lead at a hospital, halfway through a meeting about something else, and it was four words long: “Does it leave here?”
I said what everybody in this market says. It is encrypted in transit. It is hosted in the European Union. The provider is certified. He listened politely and then said the thing I have thought about ever since: “That is not what I asked.”
He was right, and he was right earlier than most. Since then, three separate pieces of European law have arrived at the same conclusion he reached on his own in a meeting room — and one of them takes effect on 27 September, three weeks from now.
So this is the story of CoRLab BI: what it does, what actually crosses the boundary when you ask it a question, and why the answer to “does it leave here?” is now a design constraint rather than a marketing line.
You connect it to your databases. You ask a question in plain language. It writes the query, runs it, shows you the result, and builds a chart or a report out of it. If you would rather not trust a sentence, there is a visual query builder and a raw editor sitting right next to the chat, and you can move between them mid-thought.
The part that is unusual is where all of that runs: on your servers, inside your network, under your credentials. There is no CoRLab-hosted copy of your data, because there is no CoRLab-hosted anything. We ship containers.
Three things landed this year, and they point the same direction.

The dates that are already fixed. Two of them bite before the end of this year.
The one with a deadline. France's Décret n° 2026-209 of 24 March 2026 takes effect on 27 September. From that date, personal health data must be stored inside the EU or EEA — full stop. Remote access from a third country is still possible, but only under an adequacy decision or Article 46 safeguards. Hosting contracts must now name the foreign legislation that could compel a transfer, state whether an adequacy decision applies, and describe the mitigation and the residual risk. Providers must publish and maintain a public map of every transfer outside the EEA and every remote access point.
The one everybody is getting wrong. You will read that the EU AI Act was postponed. Half of it was. Regulation (EU) 2026/1744 — the AI Omnibus — moved the Annex III high-risk obligations from 2 August 2026 to 2 December 2027, and Annex I to August 2028. It did not move Article 50. Transparency obligations have applied since 2 August 2026. If a clinician or an administrator types a question into a box and an AI system answers, you have to tell them that is what happened. That is a cheap thing to get right and an embarrassing thing to get wrong.
The one that will matter most, later. Under the European Health Data Space, every hospital and every insurer becomes a health data holder. From 26 March 2029 that means three concrete obligations: a catalogue of your datasets, published to the access body and updated at least annually; a documented position on the quality and utility of that data; and the ability to hand over a defined dataset within three months of a request. The implementing acts that say exactly how are due 26 March 2027. Nobody builds that capability in the last quarter before a deadline.
This is the distinction the hospital IT lead was making, and it is the one that most procurement documents still blur.
Where a server physically sits is a fact about geography. Who can be legally compelled to hand over what is on it is a fact about corporate control. Those two facts come apart. France's own national health data platform is the clearest illustration: the Health Data Hub is migrating off Microsoft Azure to Scaleway, announced in February 2026, precisely because the concern was never latitude and longitude. And in March 2024 the European Data Protection Supervisor found that the European Commission's own use of Microsoft 365 infringed the data protection rules for EU institutions, ordering it to suspend data flows to non-adequate third countries.
If the Commission and the French health ministry both had to redo this, a hospital in Chișinău or Cluj is not being paranoid for asking.

The comparison we now put in front of every prospect — including the cases where the answer is not us.
I want to be honest about that table. Options A and B are legitimate, and for plenty of organisations they are the right call — cheaper, faster to start, someone else's problem to patch. What they cost is paperwork, every year, forever. Option C moves that cost to the beginning.
“Self-hosted AI” is a phrase that can hide a lot. So here is the honest version of the architecture, including the part that does leave.

The whole platform runs inside the customer's perimeter. Only the question and a masked sample cross the line.
The model is the only thing not running on your hardware, and that is a deliberate trade. Running a frontier model on-premise means either a much weaker model or a much larger budget, and most of the organisations I am describing have neither. So instead of pretending, we made the model interchangeable: 30+ models through OpenRouter, or Azure OpenAI, or your own endpoint — your key, your contract, your choice of jurisdiction. An Azure private endpoint inside your own tenant is a supported deployment, and for the strictest customers that is the one we recommend.
What crosses out is the question, an anonymised description of the schema, and a masked sample of results. What comes back is a query and an explanation of how it was reasoned. The rows, the credentials and the exports stay put. The chart you end up looking at is drawn from the full result set inside your perimeter, not from the sample the model saw.
The masking step is where most “private AI” claims quietly fall apart, so it is worth being concrete.

The same result set on both sides of the anonymisation step. Fictitious data — no real record appears here.
We use Microsoft Presidio to detect and mask personal identifiers before anything enters the model's context. Names, identifiers and dates are replaced with placeholders; the columns the question is actually about survive intact, because otherwise the model has nothing to reason over.
And masking a column is not the end of it. The EDPB's draft guidelines on anonymisation — in public consultation until 30 October 2026 — ask for a documented re-identification risk assessment against three cumulative criteria: singling out, linkability and inference. They also ask for that assessment to be repeated as the data changes. A sufficiently narrow aggregate can identify one person without a single name in it. We built the mechanism; the assessment is a joint exercise with the customer, and we say so in writing.
Three roles. A superadmin manages accounts, datasources and users. A user can query, build dashboards and write reports. A viewer can look. Accounts are scoped, so one tenant never sees another's datasources, and every mutation lands in an audit log — which matters more than it sounds, because “who asked the system that question, and when” is going to be an audit question, not a curiosity.
Sharing is deliberately narrow: public share links and embeddable views, token-based, with expiry dates. If a link has no expiry, someone will eventually find it in an email from 2027.
One connector was the wrong shape. The first version reached the databases through a single generic layer. It worked until it had to be correct: a MongoDB aggregation pipeline and a ClickHouse analytical query are not two dialects of the same thing, and a generic layer ends up being bad at both. Splitting them into separate MCP servers cost a week and removed an entire category of wrong answers.
Natural language over a document store is its own problem. Almost everything published about “text-to-SQL” quietly assumes a relational schema you can read off a catalogue. Collections do not work like that. Fields are optional, nested, and inconsistently typed across documents that arrived in different years. Most of the work in the MongoDB connector is schema inference, not query generation, and none of the public benchmarks measure it.
Benchmarks are not evidence. The public leaderboards sit in the low eighties. Evaluations on private, real warehouses land in the low tens. A CIDR 2026 paper then found that more than half the questions in one widely-cited benchmark are annotated incorrectly — fixing the annotations moved model rankings by up to three positions. We stopped quoting anyone's score, including our own, and started building a harness that runs against the customer's schema during the pilot. That is the only number that means anything to them.
Reports needed to be templates. The first version generated a beautiful one-off document that nobody could reproduce next month. Reports are now Markdown templates with {{VARIABLE}} placeholders and a draft/published/archived workflow, which turned a demo into something a controller actually uses on the first of the month.
“We use MCP” stopped being a differentiator halfway through. When we started, an open connector protocol felt like a position. By April, Metabase had shipped a self-hosted MCP server with bring-your-own-key, and Databricks, Snowflake, ClickHouse and Teradata all had one. The protocol is table stakes now. What is still ours is where the connector runs, whose credentials it holds, and whether anyone audited it — which, given how many public MCP servers turn out to have no authentication at all, is not a small thing.
A semantic layer. This is the honest gap. When dbt re-ran a well-known benchmark this year, a governed semantic layer answered 100% of in-scope questions correctly and text-to-SQL managed 64.5% — and the two fail differently, which is the part that matters. Text-to-SQL returns something plausible and wrong; a semantic layer refuses. For a board KPI you want the refusal. We are building toward that, and until it exists I tell customers to use the chat for exploration and a reviewed saved query for anything that goes in front of a regulator.
Also missing: more database connectors, a published evaluation harness, and any certification. We have the architecture that makes those audits pass; we do not yet have the certificates, and I would rather say so than imply otherwise.
There is a number I keep coming back to. In Eurostat's 2025 figures, 16.28% of EU enterprises with ten or more employees use business intelligence software. In Romania it is 8.15%. In Bulgaria, 6.84%. Among large enterprises across the EU it is 69.24%; among small ones, 11.45%.
That is not a digitalisation gap — ERP is at 46% and CRM at 28%, so these companies do have systems. It is an analytics gap, and it has three causes: per-seat pricing built for large firms, an assumption that somebody on staff writes SQL, and, for anyone handling health or public data, a policy that forbids the cloud outright. A self-hosted platform you talk to in plain language removes all three at once.
It also happens to describe the institutions I have spent a decade building software for. CoRLab Tech built and maintains SIA eRețeta, Moldova's national e-prescription and reimbursement system — more than 15 million electronic prescriptions in two years, reaching over 900,000 unique beneficiaries, roughly 38% of the population. We maintain the DRG case-mix system and SIRSM for CNAM, and we are building the national medicines stock system now. On all of those, we are the software contractor and not the data owner: CNAM owns the prescription and dispensing data, hospitals own theirs, USMF owns its research data. We can tell you what it is like to build systems around data like that. We cannot, and do not, offer you access to it.
That distinction is exactly why CoRLab BI is shaped the way it is. When you have spent years working next to data you are not allowed to take home, an architecture where nothing leaves the building is not a compliance feature. It is just the only design that was ever going to work.
Our Best Insights
Want to know what’s trending in the tech world? Our articles break it all down - quickly and clearly.
November 4th, 2024
AI and ML are at the forefront of healthcare transformation—automating tasks, unlocking insights from data, and enabling next-gen treatment breakthroughs.
October 3rd, 2024
From clinics to enterprise systems, digital transformation is making healthcare software more accessible, efficient, and patient-focused.