Data Spaces and LLMs: our workshop at sTARTUp Day 2026

In January Digiotouch took part in sTARTUp Day in Tartu and ran a local workshop on the DS2 project. The plan was simple: explain what a data space actually is, show what Digiotouch was building within DS2, and discuss next steps. The room was a good mix of founders, developers, and people from the public sector and academia, and the questions went somewhere we had not fully planned for. Within about ninety minutes, the discussion had settled on one topic and stayed there, namely how teams building large language models get hold of training data without breaking privacy rules or giving up control of their own data assets.

Starting with what a data space is not

DS2 is a Horizon Europe project building an Inter-sectoral Data Space Toolkit, a set of modules that let organisations in different sectors share data under clear and enforceable rules. The technical base is the Eclipse Dataspace Connector, which follows the IDSA Dataspace Protocol and the GAIA-X trust framework. The short version we gave the room was that a data space is neither a database nor a data lake. The data stays where it is. What moves is a negotiated agreement about who may use it, for what purpose and for how long, together with an audit trail of what actually happened. Sovereignty is the whole point, and the connector enforces usage policies technically rather than leaving them in a contract nobody reads.

Why the LLM builders in the room stayed

Foundation models need training corpora far larger than any single company can assemble alone, and the genuinely useful data usually sits inside other organisations that have good reasons not to hand it over. Centralising it raises privacy concerns, creates a single point of failure, and cuts against the sovereignty rules those organisations already work under. That is precisely the gap a data space is meant to close, so it became the thread for the rest of the session. We walked through three parts of the DS2 work that speak to it.

• Moving very large volumes. Standard connectors are built for secure exchange, not for shifting hundreds of gigabytes quickly. DS2 extends the data plane with chunked transfer using content defined boundaries, so repeated content across dataset versions is not sent twice, parallel transfer across multiple network paths, native integration with cloud object storage so data can be staged close to GPU clusters, and checkpointing, so a transfer that fails at 80 percent resumes instead of starting over.

• Keeping data flowing. The streaming extension turns a connector into an event driven source that a Kafka style pipeline can consume directly. It handles backpressure so a fast producer cannot overwhelm a training job, preserves ordering and exactly once delivery for reproducibility, and evaluates policy per event, which means sampling rates, time windows and anonymisation rules apply to a live stream and not only to a file at rest.

• Training without moving the data. In federated setups the data never leaves its home jurisdiction, and only model updates cross the border. Providers can attach policies covering which algorithms may run and how results may be used, so an organisation with strict governance can still take part.

What we took away

The most useful part was hearing where the scepticism sits. Nobody doubted the value of shared data. The doubts were about integration effort, latency, and who carries the compliance risk when something goes wrong. Those are fair questions, and they are the ones the toolkit must answer in practice rather than on a slide. We left Tartu with a sharper sense of what a small AI team in Estonia actually needs from a data space, and with several conversations still running. More about the project at www.dataspace2.eu.

Written by Digiotouch OÜ