€300–€3,000: Line Items to Insist On for Lithuanian Agency Fees
September 16, 2026
AI can process medical data lawfully, but the deployment model decides everything. Public chatbots are off the table for identifiable patient records; a GDPR-contracted enterprise instance or on-premise deployment is the realistic starting point. Before any pilot, confirm a lawful basis, a secure processing environment and a clinical validation plan. The steps below cover exactly how to get each of those right.
TL;DR:
- Public chatbots are off-limits for identifiable patient data; deploying AI in healthcare requires GDPR-contracted or on-premise solutions to ensure lawful processing.
- Most clinical AI use cases focus on supporting pattern recognition in imaging, triage, lab result structuring, and administrative automation, not autonomous diagnosis.
- Compliance depends on getting deployment models right from the start, with on-premise or properly contracted private cloud solutions favored for risk-averse healthcare settings.
- Preparing for the European Health Data Space involves standardizing metadata, code mapping, and API readiness well before the 2029 and 2031 deadlines.
- Ongoing validation, bias mitigation, and detailed documentation are essential to keep clinical AI systems safe and compliant after deployment.
Table of Contents
- AI medicininiams duomenims: where it actually adds value in clinical work
- The rulebook: GDPR, the AI Act and the European Health Data Space
- Choosing a deployment model that keeps you compliant
- Your AI pilot checklist: governance to rollback
- Getting your systems EHDS-ready
- Keeping clinical AI safe once it’s live
- Our take: compliance is a design constraint, not a checklist
- A compliant path forward with Done
- Sources
- FAQ
AI medicininiams duomenims: where it actually adds value in clinical work
Most healthcare teams don’t need a grand AI strategy. They need three or four workflows that stop wasting clinician time. In our work advising data-sensitive sectors, the use cases that survive contact with real hospital IT are narrower and more boring than the marketing suggests, and that’s exactly why they work.
The clearest wins cluster around pattern recognition and paperwork, not decision-making:
- Diagnostic imaging support — flagging suspicious regions on scans for radiologist review, not replacing the read.
- Triage and prioritisation — sorting incoming cases or messages by urgency so clinicians see the sickest patients first.
- Lab result structuring and anomaly detection — pulling values out of unstructured reports and flagging results outside expected ranges before a human even opens the file.
- Clinical-document automation — drafting discharge summaries, suggesting coding, and cutting the administrative load that eats into consultation time.
- Population-health analytics — spotting trends across anonymised cohorts for research or resource planning.
Notice what’s missing: autonomous diagnosis. Every credible deployment we’ve seen keeps a clinician in the loop, using AI to surface patterns faster, not to make the final call. That distinction shapes almost every regulatory requirement that follows.
The rulebook: GDPR, the AI Act and the European Health Data Space
Three regimes govern this space, and they stack rather than replace one another. Getting the sequencing right matters more than memorising every clause.
GDPR treats health data as a special category, which means processing generally needs an explicit lawful basis such as explicit consent, a task carried out in the public interest for healthcare provision, or scientific research safeguards under Article 9. The EDPB’s opinion on AI models and GDPR draws a sharp line between developing an AI model and deploying it: data controllers carry accountability at both stages, and that includes documenting where training data came from and testing for bias before go-live.
The EU AI Act layers a risk classification on top. Many clinical-AI systems, particularly anything tied to diagnosis or treatment decisions, fall into the high-risk category, which triggers technical documentation, human oversight requirements, and post-market monitoring obligations.
The European Health Data Space adds a data-access timeline that changes what’s technically possible and when:
- March 2029 — initial rollout covering patient summaries and e-prescriptions across the EU.
- March 2031 — expanded categories including medical imaging and laboratory results become part of the EHDS framework for both primary care and secondary research use.
Pro Tip: Don’t wait for 2031 to start EHDS preparation. Metadata standardisation and code mapping take longer than most IT teams expect, and the systems you buy now should already be EHDS-aware.
Where clinical AI is integrated into a diagnostic device, MDR/IVDR obligations apply alongside the AI Act, which means Annex IV-style technical documentation for healthcare AI covers both regimes at once rather than two separate paperwork trails.
Choosing a deployment model that keeps you compliant
This is the decision that determines whether a project is legally viable before a single line of code gets written. Get it wrong and no amount of consent forms will fix it.
Public generative AI tools should be treated as off-limits for identifiable medical data. Practitioner guidance on generative AI use in health settings is blunt about this: assume a public model retains what you type into it unless you have a specific enterprise contract stating otherwise. Pasting a patient note into a consumer chatbot is very likely a GDPR breach the moment it happens, not a theoretical risk.
That leaves two realistic paths:
- A GDPR-contracted enterprise cloud instance. Acceptable when the vendor offers a proper data processing agreement, EU-based hosting, no training on your inputs by default, and a documented breach-notification SLA.
- A private, on-premise deployment. Data never leaves your infrastructure. Slower and more expensive to set up, but it gives you full auditability and removes the “where did our data actually go” question entirely.
For most clinics and hospital departments handling identifiable records, on-premise or a tightly contracted private instance wins on risk alone, even if it costs more upfront. Before signing with any vendor, demand answers on four points: where the training data came from, how long your data is retained, who has access and under what controls, and what the breach-notification timeline actually is in writing.
Your AI pilot checklist: governance to rollback
A pilot that skips steps here tends to get expensive later, either through a regulator’s questions or a clinician’s loss of trust in the tool. Six stages, roughly in order:
- Governance and inventory. Name a responsible person and map exactly which data flows into and out of the AI system.
- Legal basis and ethics review. Document the lawful basis in writing, secure consent or a research derogation where relevant, and get ethics committee sign-off before processing begins.
- Data minimisation and preparation. Pseudonymise wherever possible, track data provenance, and check whether your training or test data actually represents the population you’ll deploy on.
- Clinical validation plan. Set performance thresholds against a held-out test set and define exactly when a human must override the system.
- Security controls. Confirm a secure processing environment, full logging, encryption at rest and in transit, and an incident-response procedure that names who gets called first.
- Operational readiness. Train staff, write standard operating procedures, and set a monitoring and revalidation schedule with a clear rollback trigger.
A few of these deserve extra weight because teams routinely underestimate them:
- Ethics approval timelines often run longer than the technical build, so start that process early.
- Representativeness checks on training data matter more than model accuracy scores on paper.
- A rollback trigger without a named owner never actually gets used.
Lithuanian health data security guidance sets out the organisational and technical controls expected of healthcare institutions, including inventories, access control and processor contracts, which map directly onto stages one, three and five above.
Getting your systems EHDS-ready
EHDS readiness isn’t a single compliance task you tick off. It’s a multi-year infrastructure programme, and the earlier you start mapping your systems against it, the less disruptive the 2029 and 2031 deadlines will feel.
Existing infrastructure already hints at what’s coming. MyHealth@EU already supports cross-border exchange of e-prescriptions and patient summaries in some member states, and EHDS extends that same logic to a much wider set of data categories.
Practical preparation work falls into four buckets:
- Structured metadata aligned with the emerging European Electronic Health Record exchange format, so records aren’t locked in proprietary formats.
- Code mapping between local clinical coding systems and the standardised vocabularies EHDS expects.
- API readiness so your EHR can actually talk to national and cross-border exchange points when the time comes.
- Patient opt-out handling, since EHDS preserves a patient’s right to restrict secondary use of their anonymised or pseudonymised data for research.
None of this is glamorous work. It’s also exactly the kind of groundwork that determines whether your organisation can participate in EHDS-enabled research funding streams once secondary-use frameworks open up.
Keeping clinical AI safe once it’s live
Validation isn’t a one-off event before launch. It’s an ongoing discipline, and the systems that fail badly are usually the ones treated as “done” the day they go live.
Before deployment, build a test set that’s genuinely representative of the population the model will see, then report performance broken down by subgroup rather than a single blended accuracy figure. A model that’s 95% accurate overall but far weaker on one patient group is a bias problem hiding behind a good headline number.
Document intended use explicitly and define exactly where a human must intervene. Bias mitigation techniques like resampling underrepresented groups and running fairness metrics across subgroups aren’t optional extras; they’re the difference between a defensible deployment and one that quietly discriminates.
Pro Tip: Keep a change log every time the underlying model updates. Regulators and internal auditors will ask when a model’s behaviour shifted, and “we’re not sure” is not an answer you want to give.
- Log every prediction alongside the human decision that followed it.
- Re-run subgroup fairness checks after every model update, not just at launch.
- Set a defined incident-governance path for when the model gets something clinically wrong.
The EDPB’s opinion on AI models trained on personal data warns that models can retain extractable personal information even after supposed anonymisation, which is exactly why ongoing evaluation matters more than a one-time compliance sign-off.
Our take: compliance is a design constraint, not a checklist
Most vendors sell AI compliance as paperwork that happens after the technical work is finished. That order is backwards. The deployment model, the data flows, and the audit trail need deciding before a single model gets trained, because retrofitting compliance onto an architecture built for convenience is far more expensive than designing it in from day one.
In our experience with GDPR-sensitive AI projects, the organisations that move fastest aren’t the ones with the biggest AI ambitions. They’re the ones that scope a narrow pilot, keep identifiable data inside controlled infrastructure, and treat the audit trail as a product feature rather than an afterthought. That’s a smaller, less exciting story than most AI marketing tells. It’s also the one that survives a regulator’s questions.
— Thomas
A compliant path forward with Done
We serve healthcare organisations weighing up AI adoption in regulated sectors with a scoped audit followed by a pilot proposal you can evaluate on paper.
Our AI consulting work centres on exactly the questions raised above: which lawful basis applies to your data flows, whether a private or on-premise deployment makes sense for your budget, and what a vendor audit checklist should actually demand. A first engagement typically starts with a short audit of your current data flows and IT environment, followed by a roadmap and a concrete pilot proposal, not a slide deck of possibilities.
If you’re weighing a private AI deployment for patient data, read our guide on GDPR AI compliance for European SMEs and our breakdown of protecting confidential data in AI workflows. For organisations that also want the productivity case laid out plainly, this analysis of AI productivity gains for agencies is a useful outside reference point. When you’re ready to scope a project properly, book a consulting audit and get a roadmap built around your actual data, not a generic template.
This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.
Sources
- European Health Data Space (EHDS) regulation — European Commission
- EDPB opinion on AI models and GDPR — European Data Protection Board
- Asmens duomenų, tvarkomų sveikatos priežiūros įstaigose, saugumo užtikrinimo gairės — Lithuanian government guidance (VDAI)
FAQ
Can hospitals legally use public chatbots for patient notes?
No. Uploading identifiable patient data to a public generative AI tool is very likely a GDPR breach, since most public models retain or process inputs beyond what health data processing permits.
What is the EHDS deadline for imaging and lab data?
The European Health Data Space requires expanded categories, including imaging and laboratory results, to be exchangeable for primary and secondary use by March 2031.
Does the AI Act classify diagnostic AI as high risk?
Many clinical AI systems used in diagnosis or treatment fall into the AI Act’s high-risk category, which brings technical documentation and human oversight requirements, sometimes alongside MDR/IVDR obligations.
Is on-premise AI deployment always necessary for medical data?
Not always. A properly contracted, GDPR-compliant enterprise cloud instance can be acceptable, but on-premise deployment typically offers stronger auditability and data sovereignty for identifiable records.
How does Done help healthcare organisations start an AI project?
Done runs a short audit of existing data flows and systems, then delivers a roadmap and a concrete pilot proposal for AI consulting engagements scoped around each organisation’s actual compliance needs.
