In an AI health project, the model is the part everyone can see. It produces the prediction, classification, simulation, summary, or recommendation that gives the proposal its technical edge.
It is also often the smallest part of the delivery problem.
The difficult work sits around it: obtaining usable data from several institutions, agreeing what the data means, preserving provenance, defining the intended use, connecting the output to a real decision, validating the full workflow, and leaving behind something that can still operate after the grant ends.
This does not mean model choice is trivial. A weak model cannot be rescued by good infrastructure. It means that a strong model is only one component in a multi-part research system. When a project treats the model as the product and the surrounding work as support, delivery risk accumulates everywhere else.
Horizon Europe funds outcomes, not isolated model performance
The current Horizon Europe Health Work Programme for 2026-2027 gives AI a prominent role. It also places AI inside a much broader system of health data, research collaboration, user involvement, impact, and implementation.
That distinction matters. A model can perform well on a curated research dataset while the project still struggles to answer basic delivery questions:
Can every partner obtain the data needed for its task?
Do partners interpret the same variables in the same way?
Can the team reproduce an output months later?
Does the result reach the professional who is expected to use it?
Can performance be evaluated across institutions and populations?
Who operates the system when the original development team moves on?
These questions are not peripheral to the scientific contribution. They determine whether the contribution can be tested, trusted, transferred, and used.
The real AI system crosses several work packages
An AI task may sit inside one technical work package, but the system it depends on usually crosses the whole consortium.
One partner may recruit participants or hold clinical records. Another may manage imaging or laboratory data. A technical partner prepares data and trains the model. A clinical partner evaluates the output. A separate team leads ethics, dissemination, exploitation, or coordination.
The model therefore depends on a chain of promises between institutions. Data will arrive in a usable format. Identifiers will match. Access decisions will be completed. Annotations will be consistent. The target outcome will remain stable. Evaluation cohorts will be available. The output will fit the intended workflow.
If those promises remain in meeting notes rather than technical interfaces and acceptance criteria, the model team inherits the uncertainty. It spends its time reconciling fields, chasing approvals, rebuilding extracts, and explaining why a result cannot yet be reproduced.
The architecture of the project is therefore not the architecture of the model. It is the architecture of the agreements, data flows, controls, and decisions that allow the model to function.
Seven problems are usually larger than model selection
1. A precise intended use
“Use AI to improve care” is not a system specification. A credible use case identifies the decision being supported, the user, the timing, the available evidence, the action that follows, and the consequence of an incorrect output.
The intended use determines everything downstream. It changes which data is relevant, what level of uncertainty is acceptable, how human oversight should work, which comparison is meaningful, and where the result must appear.
If the intended use is vague, model evaluation becomes detached from project impact. The team can optimize a metric without knowing whether the improvement changes any real decision.
2. Lawful and practical data access
A dataset can exist, be scientifically relevant, and still be unavailable to the project in the form or timeframe the model needs. Different institutions may have different access processes, technical environments, consent boundaries, security controls, and rules for moving or processing sensitive data.
The European Health Data Space framework is designed to support secure and trustworthy reuse of health data for research and innovation. Its application is phased, however, and a future access framework does not remove the need to engineer the access path for a project today.
A proposal should therefore distinguish between data that has been identified, data that has an agreed access route, and data that has been technically tested in the intended environment. Those are three different levels of readiness.
3. Shared meaning across institutions
Connecting files is easier than reconciling meaning. Two partners may both provide a diagnosis, intervention, image, observation, or outcome while using different identifiers, units, coding systems, time windows, and missing-value conventions.
The consortium needs shared definitions for its core entities, explicit mappings from local sources, and versioned rules for transformation. It also needs a process for changes. A silent update to a source schema or coding practice can alter the model input without changing a single line of model code.
This is why FAIR data needs an implementation layer. A data management plan records important commitments, but reusable data also needs metadata, pipelines, interfaces, tests, and owners.
4. Reproducible data and model pipelines
A research output is difficult to trust if the team cannot reconstruct how it was produced. The path should connect source versions, inclusion and exclusion rules, transformations, feature logic, training data, model version, configuration, evaluation code, and the resulting output.
The current Horizon Europe Programme Guide treats research data management and reproducibility as early project concerns. It also makes clear that restricted health data can still follow FAIR principles. Controlled access and reusable research are not opposites.
For AI projects, reproducibility is not achieved by depositing a final model file. It requires the executable chain that produced and evaluated that file, together with enough context to interpret the result.
5. Evaluation that reflects the real setting
Internal model performance answers a narrow question: how did the model behave on the selected data under the selected conditions?
A health project usually needs broader evidence. Performance may need to be examined across sites, equipment, languages, demographic groups, disease stages, or collection periods. The team may also need to measure calibration, failure modes, uncertainty, human override, processing time, and the effect on the decision or workflow the model is intended to support.
A 2025 health-data governance brief connects trustworthy AI with interoperability, data quality, representativeness, privacy, and responsible access. The implication for a consortium is practical: evaluation must cover the data and operating context, not only the algorithm.
6. Integration with a human workflow
A useful result delivered to the wrong place is still a failed integration.
The project should map the full path from trigger to action. What starts the process? Which systems provide the input? Where does the model run? Where does the result appear? Who reviews it? Where is the response recorded? What happens when data is missing, the model is uncertain, or a service is unavailable?
Human oversight should be designed as part of this path. It needs a defined role, information, interface, escalation route, and record of the decision. A generic statement that a professional remains “in the loop” does not explain how oversight works.
This is also the difference between a successful pilot and an operational capability. A pilot can tolerate manual exports and a separate review queue. A durable system needs the output, decision, and feedback to move through a controlled workflow. The same problem appears when healthcare AI moves from pilot to production.
7. Ownership beyond the funded period
Many technical decisions are postponed because the project is temporary. Yet a result cannot create lasting impact if no one owns its operation, maintenance, documentation, support, and controlled evolution.
The consortium should decide which assets will remain reusable, where they will run, who can access them, who pays for operation, how changes will be approved, and what happens when a key partner leaves. This is not only an exploitation question. It shapes architecture during the project.
A prototype built around one developer's environment is cheap to start and expensive to transfer. A documented service with defined interfaces, deployment automation, monitoring, and a handover path takes more effort early but has a credible route beyond the final deliverable.
The best first milestone is a thin, complete system
Consortia often plan horizontally: first collect all data, then harmonize it, then train models, then validate, then integrate. This creates long dependencies and delays the moment when the team discovers whether the whole path can work.
A safer approach is a thin vertical slice. Choose one intended use, one defined user, the minimum necessary data from a small number of partners, one reproducible pipeline, one model baseline, one evaluation route, and one place where the output is reviewed.
The first slice does not need the most advanced model. Its purpose is to expose the hardest dependency early. The bottleneck may be access, identifiers, annotation consistency, compute location, workflow integration, evaluation design, or ownership. Finding that constraint in the first months is more valuable than optimizing a model against data the project may never be able to use operationally.
This sequence is particularly important for complex systems such as virtual human twins and multimodal health models, where scientific ambition increases the number of interfaces that must remain coherent.
A proposal-stage readiness test
Before assigning most of the technical effort to model development, a consortium should be able to answer ten questions:
What exact decision or research action will the model support?
Who will use the output, and where will it appear?
Which minimum datasets are essential for the first end-to-end test?
Has the access path for each dataset been agreed and technically tested?
Which shared definitions, identifiers, and quality rules are required?
Can an output be traced back to source data, transformations, code, and model version?
How will performance and failure be evaluated across relevant settings and groups?
What happens when an input, interface, model, or partner changes?
Who owns data, pipelines, model releases, workflow integration, and exceptions?
What can still be operated and reused after the funded period?
If several answers depend on future workshops, unnamed owners, or manual reconstruction, the main project risk is already visible. It is not the model.
Design the delivery system before optimizing the algorithm
The strongest AI health proposals do not reduce technical ambition. They put that ambition inside a delivery system that can support it.
They define the intended use before the metric, test data access before promising scale, turn semantic agreements into versioned mappings, make provenance automatic, validate the complete workflow, involve users early, and give post-project operation an owner.
A model may be the most novel component. Novelty is not the same as difficulty, and it is not the same as impact. In a multi-institution health project, the larger challenge is making the entire path from source data to accountable use coherent.
That is the system the consortium is really building.