Sovereignty

The construction industry runs on documents that do not belong in just any cloud: bids, contracts, drawings, calculations, cost data. The buyers who own this data, public clients under national procurement rules such as Germany’s VOB, firms under GDPR, anyone preparing for the EU AI Act, are increasingly required to know exactly where it is processed and to keep it inside the EU. A provider that cannot guarantee that is a provider they cannot use.

That is the first thing flinq is for. It is a small, efficient model, hosted entirely on EU infrastructure.

What EU-hosted deployment means here

• EU data residency. flinq runs on EU infrastructure. Your data, and the inference over it, never leave the EU. This is the posture buyers under GDPR, the EU AI Act and national procurement rules such as VOB need their vendors to demonstrate.
• Modest hardware. The model serves in under 8 GB of VRAM, so it runs efficiently on a single commodity GPU rather than a fleet of accelerators.
• Low latency. Roughly 85 ms per query, fast enough to sit inline in an interactive matching or search workflow.
• Low serving cost. A fraction of the cost of a large hosted model, because it is small enough to run efficiently.

Why EU hosting matters most

Most embedding quality lives behind an API with no data-residency guarantee. For AEC buyers, that makes the strongest hosted model a non-starter regardless of its leaderboard score. flinq inverts the constraint: a construction- specialized model that performs strongly on an open benchmark, hosted entirely on EU infrastructure. The benchmark evidence earns the technical trust; EU data residency is what makes it usable for the customers who actually own the data.

See the benchmark for how we measure flinq. Runnable integration patterns that keep the rest of your stack inside infrastructure you already operate, including a pgvector pattern, are in progress. See Examples.