Part of the DEPLOY Method — Engineer phase
This is not the private-sector Domain-Expert LLM Lab. It is the public-sector adaptation of it. A ministry, a regional health authority, a defence agency, a national rail operator, or a smart-city programme cannot use the standard engagement because the standard engagement assumes public-cloud flexibility and a commercial data processing agreement. The public-sector variant does not. Every phase of the engagement runs on sovereign infrastructure — Scaleway, OVHcloud, Bleu, S3NS, or the buyer's own on-premise GPUs. No data leaves EU soil. No US hyperscaler is in the critical path. Training corpora remain in-country throughout the engagement and afterwards. The timeline extends to twelve weeks because four of those weeks are the sovereignty audit, the data processing agreement negotiation, the Annex IV documentation work, and the on-premise provisioning that the private-sector engagement skips. The deliverable pack is built to be procurement-ready: the model, the weights, the eval harness, the on-premise deployment, and the full Annex IV technical documentation hand over to the buyer as a single procurement-compatible artefact. The private-sector Lab is faster and cheaper; if your use case can tolerate a public-cloud deployment and a commercial DPA, that engagement is the correct choice and this one is not.
The procurement gate cannot approve a frontier-API deployment. The standard commercial answer — wrap a frontier API, sign a DPA, deploy — does not clear public-sector procurement in most EU member states. The data residency, the sub-processor chain, the transfer-impact assessment, and the Schrems II exposure on US-hosted inference combine into a procurement risk that the buying authority cannot absorb. The project stalls in the compliance review, often for quarters, and the eventual answer is either a sovereignty carve-out the vendor will not accept or a complete redesign on EU-only infrastructure. Starting on sovereign infrastructure from day one is the shorter path.
EU AI Act obligations are now operative and the documentation burden is real. High-risk AI systems under the Act — which covers most ministry, healthcare, and critical-infrastructure use cases — require Annex IV technical documentation, conformity assessment, post-market monitoring, and a registration in the EU database. Producing that documentation retrospectively, after a model has been trained and deployed, is expensive and often incomplete. Integrating it into the engagement from day one is materially cheaper and produces a documentation trail that survives a regulator audit. Most private-sector engagements do not need this; public-sector engagements almost always do.
The proprietary corpus is the whole point and cannot leave the jurisdiction. The reason a public-sector body is doing a domain model at all is that the corpus — classified ministry archives, national health records, defence technical manuals, procurement law precedent, rail operational telemetry — is exactly the asset that cannot be sent to a US cloud for training. A generic API wrapper was never going to use this corpus; a fine-tuned model on sovereign infrastructure is the only architecture that makes the corpus deployable. If the corpus can leave the jurisdiction, the project is probably not large enough or sensitive enough to justify the sovereign variant, and the private-sector Lab is the right engagement instead.
The internal team is strong on domain but thin on production ML. Public-sector technical teams are usually deep on the domain — epidemiologists at the health ministry, rail traffic engineers at the operator, legal scholars at the justice department. They are rarely deep on production ML: fine-tuning pipelines, eval harness construction, quantization for on-premise inference, Annex IV documentation at the level the Act now requires. The engagement is structured to respect the domain expertise — the buyer's team owns the corpus and the acceptance criteria — while providing the production ML layer the Act and the procurement gate both require.
The engagement is the ENGINEER phase of the DEPLOY Method, extended to twelve weeks by the sovereignty audit, the data processing framework, the on-premise provisioning, and the Annex IV documentation track that runs in parallel to the technical work. The engagement operates under a data processing agreement that specifies EU-sovereign infrastructure for every phase and prohibits any data transfer to a non-EU jurisdiction at any point. The buyer's procurement and legal teams are involved from week one, not at the end.
Written sovereignty posture: which workloads run where, which provider (Scaleway, OVHcloud, Bleu, S3NS, or on-premise), which jurisdictions the data will and will not touch, which sub-processors are in scope and which are specifically excluded. The data processing agreement is drafted and negotiated with the buyer's legal team, and the sovereign-cloud or on-premise training environment is provisioned under it. Annex IV documentation begins in parallel — the technical file, the risk management framework, the data governance section. By end of week three the engagement has an approved legal and infrastructural posture that procurement can stand behind.
The proprietary corpus is audited for coverage, quality, provenance, and lawful basis for use under the relevant sectoral regulation — GDPR, public records law, defence classification, healthcare data governance. The eval harness is built against the task definition the buyer's domain experts have signed off on, and a baseline is run — where legally permissible — against an EU-hosted frontier API for comparison. The evaluation criteria become part of the Annex IV documentation, not a separate artefact.
Base model selection across Llama 3, Mistral, and Qwen — all open-weight, all legally deployable on sovereign infrastructure without a vendor relationship that reintroduces the data residency problem. Training runs on the provisioned sovereign GPUs. We run structured experiments — LoRA versus full fine-tune, data mix ablations — and we evaluate every run against the week-five baseline. The Annex IV technical file is updated with every material decision: base model choice, data mix, training hyperparameters, evaluation results. The documentation is not a post-hoc reconstruction; it is the record of the engagement as it happens.
Inference is stood up on the buyer's designated infrastructure — on-premise GPUs, a dedicated sovereign-cloud tenant, or an air-gapped environment for classified workloads. The Annex IV technical documentation is finalised, conformity assessment evidence assembled, post-market monitoring plan written, and the EU AI Act database registration prepared. The buyer's internal team is walked through the eval harness, the training pipeline, and the documentation framework so they can operate the system and extend the documentation when the model is retrained. The model, the weights, the eval, the deployment, and the full conformity pack hand over as a single procurement-ready artefact.
Ministries, regional governments, national health authorities, defence agencies, rail and transport operators, energy grid operators, and smart-city programmes with a domain use case that requires a model trained on a corpus the buyer is legally or operationally unable to send outside EU jurisdiction. Buying authorities whose procurement process has already identified a public-cloud or frontier-API dependency as a disqualifying risk. Programmes where EU AI Act high-risk classification applies and Annex IV technical documentation has to be produced to a standard a regulator can audit. This is not for public-sector buyers whose use case can tolerate a public-cloud deployment and a commercial data processing agreement — the private-sector Domain-Expert LLM Lab is the correct entry point at that risk posture, at a shorter timeline and lower cost. It is also not for programmes without a proprietary corpus; without the data asset, the sovereign engagement has no advantage a frontier API cannot match at a fraction of the cost.
Either, depending on the buyer's operational posture. On-premise is the right answer for classified workloads, air-gapped environments, and programmes where the buyer already operates a GPU cluster. Sovereign-cloud — Scaleway, OVHcloud, Bleu, S3NS — is the right answer for buyers who want EU-jurisdictional handling without the CapEx and operational burden of owning GPUs. The engagement scope does not change; only the provisioning work in weeks one to three changes. The sovereignty posture document records which choice was made and why, for the procurement and audit trail.
The Annex IV file is the AI-specific layer; your sectoral regulator — healthcare, finance, transport, defence — will usually have additional documentation and governance requirements that sit alongside it. The engagement builds the Annex IV file to the Act's standard and the data governance, risk management, and evaluation sections are structured to be reused in your sectoral submission rather than rewritten. I do not provide sectoral legal advice — your internal compliance counsel owns that — but I have built the technical documentation that goes underneath enough regulator-facing submissions to know what evidence the regulators actually want, which is usually different from what the guidance documents suggest.
The engagement runs under whichever procurement vehicle the buyer requires — direct contract, DPS framework, UGAP in France, EU-wide framework agreements. The commercial structure does not change the technical scope or the twelve-week timeline, though the procurement process itself can extend the lead time before the engagement starts. Where the buyer's procurement team does not have an existing vehicle that fits, I can work with them to structure one; this is part of what the France Num AI Ambassador credential was specifically built for.
The DPA explicitly covers it. Training happens on EU-sovereign infrastructure under a data processing agreement that specifies the lawful basis, retention, and access controls for personal data throughout the engagement. A DPIA is produced as part of the Annex IV documentation pack and reviewed with your DPO. Where the corpus requires pseudonymisation or redaction before training — which it often does — that work is part of the week-four data curation phase, not an afterthought. The engagement is designed to produce a GDPR-compliant training process, not just a GDPR-compliant deployed model.
No. The deliverable pack is deliberately complete: the weights, the eval harness, the training pipeline, the deployment runbook, and the Annex IV documentation framework are all yours to operate. Your internal team is walked through each of them in weeks eleven and twelve so the handoff is not theoretical. Some public-sector buyers choose a scoped refresh engagement when a materially better base model ships — Llama 5, a stronger Mistral release — but that is optional and priced separately. The engagement exits cleanly; it does not convert into an indefinite retainer.
Ας συζητήσουμε πώς αυτή η υπηρεσία μπορεί να αντιμετωπίσει τις συγκεκριμένες προκλήσεις σας και να φέρει πραγματικά αποτελέσματα.