Technical specification · version of 14 October 2026
LEX SUPREMA — full specification
Architecture, sizing, security, administration and prerequisites of the on-premises AI platform. Written for CISOs, IT managers, data protection officers and procurement.
01 — Product definition and scope
An AI working environment, not a decision system
The platform produces substantiated drafts and analyses which a qualified professional reviews and settles. It brings four layers together on one managed infrastructure: a reasoning layer with locally hosted language models and a version-controlled instruction set, a knowledge layer holding all documents and sources with source references down to the passage, an access layer that determines who may consult which file and which functions, and a management layer for monitoring, audit logging, backup and model management.
| Use | Case analysis, evidence matrices, procedural audits, case law research, GDPR access requests, DPIA support, knowledge retrieval |
| Primary audience | Law firms (criminal defence), in-house legal departments, privacy and DPO practices, municipalities, the healthcare and public safety domain |
| Data residency | 100% on your own equipment; egress closed by default at firewall level |
| Models | Open-weight LLMs (70B–235B class) plus embedding, reranker, OCR and optionally speech models, locally hosted |
| Scale | Tier 1: 5–15 concurrent users · Tier 2: 25–75 · Tier 3: 100–500+ |
| Lead time | 6–12 weeks from delivery to production, depending on the number of data sources |
System boundaries
| Boundary | How it is handled |
|---|---|
| Network | Isolated VLAN segment; outbound internet traffic refused by default. Updates via a controlled, authorised artefact mirror or physical media. |
| Data | Documents, derived indexes, prompts, answers and logs remain within the organisation’s managed storage. |
| Models | Open-weight models only, with a licence permitting local deployment; no calls to external model providers. |
| Users | Only authenticated staff and, optionally, explicitly invited external parties in a walled-off workspace. |
| Responsibility | The system delivers drafts; settling, filing and advising remain with the qualified professional. |
Expressly out of scope
The system is not a lawyer and claims no legal professional privilege or duty of confidentiality in its own right — that rests with the lawyer handling the matter. It takes no legal decisions, files nothing, and does not communicate on the organisation’s behalf with courts, the prosecution service or opposing parties. It generates no probability figures or case outcome predictions without a substantiated statistical basis. Without internet access it cannot verify external sources live: case law and statutory texts come from a periodically updated local source library, and unverified references are labelled as such.
02 — Functional capabilities
Five version-controlled knowledge layers, thirteen modules
The substantive behaviour sits in instruction layers that are activated automatically per question; the platform picks the layer based on the area of law, the procedural stage and the type of data.
| Layer | Domain | Activation |
|---|---|---|
| I | Substantive criminal law and working method | Every criminal law question |
| II | Case analysis and litigation strategy | On delivery of a case file or court document |
| III | Specialised offences and liberty-restricting measures | Stalking, threat, assault, coercion, trespass, criminal damage, restraining and exclusion orders |
| IV | Cassation, Supreme Court and the ECHR | Cassation questions, human rights review |
| V | Privacy: GDPR, Wpg, Wjsg | Personal data, access requests, surveillance, police data, compensation |
Modules and their output
| # | Module | What the module delivers |
|---|---|---|
| 1 | Adversarial Legal Reasoning | Analysis from the defence, the prosecution and the bench, merged into one realistic strategy |
| 2 | Deep Case Analysis | Document inventory, completeness check, chronology, suspicions per charge, investigation plan |
| 3 | Evidence Matrix | Per element of the offence: the evidence, its source, the prosecution’s position, the defence’s position, reliability, probative weight, gaps |
| 4 | Contradiction Detection | Contradictions in time, place, statements and digital data, classified by legal weight |
| 5 | Procedural Defense Audit | Checks on arrest, detention, the caution, legal assistance, powers, warrants and time limits |
| 6 | Jurisprudence Intelligence | Relevant rulings with court, date, ECLI, legal rule, similarities and differences |
| 7 | Strategic Defense Engine | Scenarios for acquittal, partial acquittal, discharge from prosecution, procedural defence and sentence reduction, each with a risk profile |
| 8 | Forensic Investigation Protocol | Checks on provenance, integrity, hash values, metadata, time synchronisation and chain of custody of digital evidence |
| 9 | Witness Examination Strategy | An examination plan per witness with neutral, targeted questions |
| 10 | Red Team Legal Review | Independent counter-analysis before any final advice |
| 11 | Professional Legal Drafting | Court documents following Dutch conventions, always marked as a draft |
| 12 | Continuous Legal Quality Control | Checks on the version of the statute, the validity of legal rules, the accuracy of ECLIs and internal consistency |
| 13 | Final Defense Advisory | Conclusion, strongest defence, greatest risk, strategy, actions, open questions, source check |
Layer V — privacy and data protection
Determining the applicable regime before any conclusion: GDPR, the Wet politiegegevens, the Wet justitiële en strafvorderlijke gegevens, or a specific sectoral regime. Access, rectification and erasure requests with admissibility, time limits, grounds for exemption, redaction policy and an assessment of completeness. Analysis of privacy intrusions and surveillance, including legal basis, necessity, proportionality and subsidiarity. Support for DPIAs, records of processing activities, processing agreements and data breach assessments. Non-material damages with legal basis, substantiation and relevant case law. And combined analyses where criminal and privacy law tracks meet, for instance with unlawfully obtained evidence or police data in a criminal file.
03 — AI architecture
A local inference server with routing per task type
The core serves several open-weight models at once: a large reasoning model for analysis, smaller models for classification and extraction. Model choice is a decision per implementation and per release moment — the inference layer is model-independent, and models are pinned, tested and released per version.
| Role | Model class | Size | Why |
|---|---|---|---|
| Main reasoning model | Open-weight instruct model, dense or mixture-of-experts | 70B–235B | Multi-step legal reasoning and long context |
| Workhorse model | Open-weight instruct model | 8B–32B | Summarising, extraction, classification, routing; far higher throughput |
| Embedding model | Multilingual, strong in Dutch | 300M–600M | Semantic search across Dutch-language case files |
| Reranker | Cross-encoder | 300M–600M | Raises retrieval precision considerably at low cost |
| OCR / document | Vision or layout model | 1B–8B | Scanned police reports, handwritten notes, tables |
| Optional: speech | Automatic speech recognition | 1B–2B | Transcription of interviews, intercepted calls, hearing recordings |
Inference stack
Serving
A production inference server with continuous batching, paged attention and tensor parallelism across multiple GPUs. This is the difference between one user and fifty concurrent users on the same hardware.
Quantisation
FP8 or 4-bit weight quantisation where the quality impact is demonstrably acceptable, measured on an in-house legal evaluation set. A trade-off, not an automatism: in legal analysis precision outweighs speed.
Context window
128k tokens as a workable floor for case work; larger contexts only where the hardware can carry the KV cache budget. Very large files go through retrieval and hierarchical summarisation, not into one context.
Routing
A gateway picks the right model, the right layer instruction and the right authorisation filter per request, and enforces quotas and priorities per user group.
Agentic execution
Multi-step tasks run as controlled workflows with explicit intermediate steps that land in the audit log — not as one opaque prompt.
Fine-tuning
Optional and strictly local: LoRA or QLoRA adapters on anonymised or pseudonymised documents, with an explicit legal basis and a recorded assessment. In most cases better retrieval yields more quality than fine-tuning, at a fraction of the risk.
Hallucination control — five overlapping measures
- Grounding in sources. Answers are generated on retrieved passages; every assertion carries its source, page and passage.
- Citation verification after the fact. A separate checking step tests whether every quotation and every ECLI appears in the indexed source. References that cannot be verified are removed or flagged.
- Counter-analysis. The Red Team module asks a fixed set of questions about missing facts, unproven assumptions and over-confident conclusions.
- Refusing over guessing. Where source material is insufficient, the system names the gap instead of filling it.
- Continuous evaluation. A growing evaluation set of Dutch legal questions with answers checked by a lawyer runs at every model change; results are retained so that quality regression becomes visible.
04 — Document pipelines
The source system’s authorisation travels with the document
Source connectors
| Source | Integration method | Notes |
|---|---|---|
| Network drives (SMB/NFS) | Read-only mount, incremental scan | The most common starting point |
| Document management system | API or database replica | ACLs are read along and retained |
| Email (Exchange, IMAP) | Read-only mailbox connection | Attachments are indexed separately |
| Practice or matter system | API or read replica | Supplies the file structure and matter IDs |
| Object storage (S3-compatible) | Native, locally hosted | The recommended target storage for working duplicates |
| Statutory and case law sources | Periodic, controlled import | Updated offline; version date recorded |
| Scanners and multifunction devices | Watched folder | Supplies scanned police reports |
Ten processing steps
Retrieval
Hybrid retrieval is the norm: vector search catches the meaning, lexical search catches what lawyers actually type — article numbers, ECLIs, names, references. The results are merged and passed through a reranker. Metadata filters on matter, period, document type and sensitivity. The authorisation filter sits before the rerank step, so a user never sees a snippet of a document they are not allowed to view: a hard requirement, not a setting. Citation coordinates run back to the document, the page and the text position.
Reindexing and version control
The pipeline is idempotent: every document can be reprocessed without duplicates, and the index records which embedding model version produced each chunk. On a model change, reindexing can be selective instead of redoing everything. Allow a night to several days for a full reindex of 10 million pages, depending on the size.
05 — IAM and authorisation
The authorisation model determines which documents enter the model’s context at all
That is the difference between an AI tool and a data breach with a chat window.
Identity management
A central identity provider on-premises with OIDC and SAML 2.0, so that existing accounts from Active Directory, LDAP or Entra ID can be connected without passwords ever reaching the platform. SCIM provisioning follows the HR or AD change: a departing employee loses access the moment they leave, not at the next audit. Mandatory multi-factor authentication, with a preference for phishing-resistant methods (WebAuthn/FIDO2) for administrators and sensitive matters. Session policy with short token lifetimes, re-authentication on sensitive actions and automatic sign-out on inactivity.
Three stacking layers
| Layer | What it governs | Example |
|---|---|---|
| RBAC — role-based | What a role may do | A trainee lawyer may not manage models |
| ABAC — attribute-based | What the context permits | Sensitivity level 3 only from a managed device on the office network |
| ReBAC — relationship-based | What the relationship to the object permits | Only members of matter team X see matter X |
The relationship-based layer is the most important one for law firms: access depends on involvement in the matter, not on job title. A policy engine evaluates every retrieval question against this model before a single chunk is fetched.
Functions legal organisations specifically need
06 — Security architecture
Seven zones, deny by default, egress refused at firewall level
| Zone | Contents | Permitted traffic |
|---|---|---|
| User zone | Workstations, office network | HTTPS to the application gateway only |
| Application zone | Gateway, web interface, IAM, policy engine | To the inference and data zones; no internet |
| Inference zone | GPU nodes, model servers | Inbound from the application zone only; no outbound traffic |
| Data zone | Vector database, object storage, relational database, index | From the application and processing zones only |
| Processing zone | Ingestion, OCR, embedding workers | Read-only to source systems; writes to the data zone |
| Management zone | Monitoring, logging, backup, secrets, OOB management | Separate VLAN, separate authentication |
| Airlock zone | Controlled update and import facility | The only place with limited, authorised external access — or entirely physical, via removable media |
Controls per layer
Network
Microsegmentation with deny-by-default between zones. Outbound traffic from the inference and data zones is blocked and alarmed. DNS filtering through an internal resolver with no external forwarders. Network IDS on the zone boundaries.
Storage
Full disk encryption (LUKS2 or equivalent) with keys held in an HSM or TPM with measured boot. Encrypted backups under a separate key hierarchy. Object storage with object lock for immutable audit trails.
Transport
TLS 1.3 everywhere, including between internal components; mutual trust through mutual certificate authentication with an internal, short-lived certificate authority.
Host
Secure Boot, measured boot through TPM 2.0, minimal installation, mandatory access control at kernel level (SELinux or AppArmor), no interactive login on nodes except through a managed bastion, automatic security updates from an internal mirror.
Workload isolation
Containers without elevated privileges, read-only file systems, enforced resource limits. For code execution or untrusted files, an additional sandbox runtime in its own network segment with no access to the data zone.
Secrets and supply chain
A central secrets vault issuing dynamic, short-lived credentials; no passwords in configuration files or images. All container images and model files come from an internal registry, are signed, and have a recorded provenance and hash; model weights are checked against their hash at every start.
AI-specific risks
| Risk | Control |
|---|---|
| Prompt injection through document content | Document content is treated as data, never as instruction; instructions come solely from the recorded layers and the logged-in user |
| Data exfiltration through model output | Egress closed; no outbound hyperlinks or resource fetching from generated content |
| Unauthorised retrieval | Authorisation filter applied before retrieval, not after |
| Memory leakage between users | No shared conversation state; context is assembled per session and cleared afterwards |
| Model theft | Weights encrypted at rest, readable only by the inference server’s service account |
| Unwanted training on client data | No training by default; fine-tuning only on explicitly designated datasets with a recorded legal basis |
07 — Modularity and extensibility
Four extension points on a stable base
A new application is a configuration change, not a new project.
| Extension point | What you add | What you need not touch |
|---|---|---|
| Model registry | A new language model, embedding model or vision model | Gateway, IAM, pipelines, UI |
| Source connectors | A new source system or database connection | Models, authorisation model, infrastructure |
| Knowledge layers | A new area of law or professional domain as an instruction layer | Everything beneath it |
| Workspaces | A standalone AI project with its own data, model and users | The rest of the platform |
Knowledge layers: which legislation can be added
Not exhaustive. Any corpus that can be supplied as statutory text, decisions, guidance and case law can be indexed and built into the working method as a version-controlled instruction layer. Layers are selected and costed individually; no layer is included in the delivery by default.
| Cluster | Sources |
|---|---|
| Codes | Grondwet · Burgerlijk Wetboek, books 1–10 · Wetboek van Strafrecht · Wetboek van Strafvordering, old and new · Wetboek van Burgerlijke Rechtsvordering · Algemene wet bestuursrecht · Algemene wet inzake rijksbelastingen · Wetboek van Koophandel · Faillissementswet |
| Criminal and sanctions law | Opiumwet · Wet wapens en munitie · Wegenverkeerswet 1994 · Wet op de economische delicten · Penitentiaire beginselenwet · Wet forensische zorg · Wet DNA-onderzoek bij veroordeelden · Wet internationale misdrijven · WETS and WOTS · Sanctiewet 1977 |
| Data protection | GDPR and UAVG · Directive 2016/680 · Wet politiegegevens · Wet justitiële en strafvorderlijke gegevens · Telecommunicatiewet · Wiv 2017 · Archiefwet · Wet open overheid · Wet digitale overheid · Wabvpz |
| Government and public administration | Gemeentewet · Provinciewet · Omgevingswet and its implementing decrees · Participatiewet · Aanbestedingswet 2012 · municipal and provincial by-laws · mandate and delegation decisions · policy rules |
| Healthcare and social domain | Wmo 2015 · Jeugdwet · Wvggz · Wet zorg en dwang · Wet BIG · Wkkgz · Wgbo · Zorgverzekeringswet · Wlz |
| Employment and migration | Civil Code book 7 title 10 · WAB · Arbowet · Wet arbeid vreemdelingen · Vreemdelingenwet 2000 · Wet arbeidsmarkt in balans and implementing regulations |
| Financial services and supervision | Wet op het financieel toezicht · Wwft · Pensioenwet · Wet toezicht trustkantoren · DORA · MiCA · policy rules of DNB and the AFM |
| European law | ECHR and the Charter · AI Act · NIS2 and the Cyberbeveiligingswet · CER and the Wwke · Data Act · Data Governance Act · DSA and DMA · e-Privacy · EUR-Lex sources |
| Professional conduct and disciplinary law | Advocatenwet · Verordening op de advocatuur and the conduct rules · Wet op het notarisambt · Gerechtsdeurwaarderswet · disciplinary case law · the Public Prosecution Service’s Aanwijzingen and Richtlijnen voor strafvordering · LOVS sentencing guidelines |
| Case law and standards | Supreme Court, courts of appeal and district courts on ECLI · Council of State · CRvB and CBb · ECtHR and CJEU · decisions of the Dutch DPA · parliamentary history · Staatsblad and Staatscourant · BIO, NEN 7510, ISO 27001 · collective labour agreements |
| Your own material | Internal guidelines, templates and decision trees · house conventions for court documents · tender conditions · earlier opinions and pleading notes · non-legal corpora for a standalone workspace |
Lead time for an extension
| Extension | Typical lead time | Depends on |
|---|---|---|
| New workspace for a separate project | days | Authorisation group and retention period established |
| Source connector on a known system type | 1–2 weeks | API access and the ACL structure of the source system |
| Your own guideline or template set as a layer | 1–2 weeks | Material supplied and up to date |
| New area of law including source import | 2–6 weeks | Size of the corpus and the subject-matter validation |
| New model in production, tested and released | 1–3 weeks | Evaluation set and available GPU memory |
These are lead times after the platform has been delivered, with sources supplied, and without re-indexing the entire archive. They follow from the modular design, not from a measured average across implementations. The subject-matter validation — an evaluation set compiled and checked by a specialist in that area of law — runs in parallel and in practice determines the end date; that effort is costed separately.
Supported data types besides documents
Relational databases through read replicas with schema-aware querying. Time-series and log data for forensic and operational analysis. Audio and video through local transcription, with timecodes usable as source references. Images with local OCR and object recognition, without external image-processing services. Geospatial structure and timelines for chronology reconstruction.
Open standards as a precondition for exit
An OpenAI-compatible inference API, S3-compatible object storage, PostgreSQL or another open database as the system of record, OIDC/SAML for identity, OpenTelemetry for telemetry, and container images on an open registry. Documents remain in their original format; the index can always be rebuilt from the source. On termination the organisation keeps hardware and data under its own control, without a supplier holding a key.
08 — Hardware sizing model
It is not model size but the KV cache that determines how many users a machine can carry
Machine size follows from three quantities: how much GPU memory the model plus the concurrent conversations demand, how many pages must be processed per 24 hours, and how many users are active at the same time. If you want many concurrent users on long case-file contexts, you buy GPU memory, not compute.
VRAMtotal ≈ W + Nconcurrent × Ctokens × kKV × 1.15
W is the weight memory, C the context window, k the KV-cache consumption per token, and 1.15 the headroom for activations and fragmentation.
Step 1 — GPU memory
| Item | Rule of thumb |
|---|---|
| Weights FP16 | 2 GB / billion |
| Weights FP8 | 1 GB / billion |
| Weights 4-bit | approx. 0.6 GB / billion |
| KV cache per token (70B, GQA, FP16) | approx. 0.3 MB |
| KV cache per token, FP8 | approx. 0.15 MB |
| Activations and fragmentation | +15% |
Worked example: a 70B model in FP8 with a 128k context and an FP8 KV cache requires roughly 70 GB of weights and roughly 20 GB of KV cache per fully populated session. A single 96 GB GPU runs the model but barely one long session; two cards give 192 GB and with it room for five to six concurrent long sessions, or several dozen short ones.
Step 2 — Concurrency
Legal use is bursty: someone asks a question, reads for two minutes, asks the next one. Reckon with 12–20% concurrency in normal use and a peak factor of about three. Batch processing is scheduled outside office hours and does not count towards the peak.
| Named users | Concurrently active | Peak |
|---|---|---|
| 15 | 2–3 | 6 |
| 50 | 6–10 | 18 |
| 150 | 18–30 | 50 |
| 500 | 50–90 | 150 |
Step 3 — Storage, per million pages
| Source documents, scanned | 150–300 GB |
| Source documents, born digital | 20–60 GB |
| Extracted text | 3–5 GB |
| Chunks and metadata | 5–10 GB |
| Vector index (1024 dim., HNSW) | 8–15 GB · 2–4 GB with int8 |
| Lexical index | 10–20% of the text |
| Audit logs | 1–5 GB / month / 100 users |
Multiply the total by three for working space, snapshots and re-indexing, and reserve backup capacity separately. A firm with a 10-million-page case-file archive thus arrives at 8–12 TB of usable primary storage.
Step 4 — Ingestion throughput
| Processing method | Pages/sec |
|---|---|
| OCR on GPU, modern models | 5–20 |
| OCR on CPU, classic engine | 0.2–0.5 per core |
| Embedding on GPU | 200–1,000 chunks |
| Text extraction without OCR | 50–200 |
OCR is the slowest link and the reason the first indexing run can take weeks when capacity is short. An initial indexing of 5 million scanned pages costs roughly three to eleven days of uninterrupted running on a single GPU. Plan temporary extra capacity for it, or accept a phased roll-out per case-file archive.
Step 5 — CPU, memory and network
09 — Hardware configurations per tier
Three standard configurations, delivered complete
The hardware is supplied, installed, hardened and configured by us; the amounts below are turnkey, including installation and implementation. Individual component prices are not listed because they vary per quotation — the specification per component is, so you can have the configuration reviewed or priced elsewhere.
What the delivery covers
Included: hardware and transport · rack mounting, cabling and commissioning · operating system, hardening and secure boot · network segmentation and firewall rules including the egress block · platform configuration with IAM, storage, monitoring and backup · connection of the agreed source systems including ACLs · activation of the agreed knowledge layers · construction of the evaluation set · acceptance tests · training for users, case-file owners, administrators and the DPO · the complete documentation package · handover to your administrator.
Not included: the server room or a colocation contract · power and cooling · any conversion of the technical room · ongoing operations after handover, whether self-managed or as a separate management contract · maintenance contracts from the hardware supplier · software licences with a subscription model of their own · the annual penetration test.
Tier 1 — Starter · one server · 5–15 users
| Component | Specification |
|---|---|
| Chassis | 2U GPU server, NVIDIA-certified, redundant power supply (2× 2,000–2,700 W, titanium) |
| GPU | 2× NVIDIA RTX PRO 6000 Blackwell Server Edition, 96 GB GDDR7, PCIe 5.0 x16, passively cooled, 600 W per card |
| CPU | 1× AMD EPYC 9004/9005 series, 32 cores, or an Intel Xeon 6 equivalent |
| Memory | 512 GB DDR5 ECC RDIMM |
| Storage | 2× 960 GB NVMe M.2 in RAID 1 (system) · 4× 7.68 TB NVMe U.2 mixed use in RAID 10, approx. 15 TB usable |
| Network | Dual 25 GbE SFP28 + 1 GbE out-of-band |
| Security | TPM 2.0 module, Secure Boot, chassis intrusion detection |
| UPS | 3 kVA online double conversion, rack-mounted |
Indicative order of magnitude, delivered and implemented complete: € 60,000 – € 95,000, of which € 36,000 – € 55,000 is hardware. No high availability: if the server fails, the system is down. For a first implementation that is often acceptable, provided it is discussed explicitly.
Tier 2 — Professional · small cluster · 25–75 users
| Component | Specification |
|---|---|
| GPU nodes | 2× 4U server, each with 4× RTX PRO 6000 Blackwell Server Edition (96 GB) — 768 GB of GPU memory in total; per node 2× EPYC with 48–64 cores per socket and 1 TB DDR5 ECC |
| Storage and database nodes | 3× 2U server, each with 2× 32 cores, 512 GB RAM, 8× 7.68 TB NVMe — a cluster with approx. 60 TB usable |
| Management node | 1× 1U server for IAM, monitoring, logging and secrets |
| Network | 2× 100 GbE switch (redundant), 1× 1 GbE management switch, cabling |
| Rack, PDU and UPS | 42U rack, 2× switched PDU with metering (32 A per feed), UPS 10–15 kVA with bypass |
| Backup system | A separate node with 100 TB gross, immutable storage |
Indicative order of magnitude, delivered and implemented complete: € 270,000 – € 450,000, of which € 206,000 – € 326,000 is hardware. Runs several models at once: a 70B primary model with ample concurrency, a 32B workhorse, embedding and OCR, alongside capacity for a second AI project. Nodes are redundant.
Tier 3 — Enterprise · 100–500+ users
| Component | Specification |
|---|---|
| GPU platform | HGX platform with 8× H200 (141 GB HBM3e) or 8× B200, NVLink-coupled; or 4× server with 8× RTX PRO 6000 Blackwell |
| Secondary inference | 2× server with 4× RTX PRO 6000 Blackwell for embedding, OCR and small models |
| Storage cluster | Distributed file system, 300–500 TB usable, an NVMe tier plus a capacity tier |
| Control plane | 3× node for the Kubernetes control plane, IAM and the policy engine, in HA |
| Network | Redundant 100/400 GbE spine-leaf, a separate storage network, a separate management network |
| Racks, PDU, UPS | 2–3 racks, redundant power, 40–60 kVA UPS |
| Backup and DR | A second site with asynchronous replication |
Indicative order of magnitude, delivered and implemented complete: from approximately € 900,000, of which € 775,000 – € 1,680,000 is hardware. At this size the spread is largely determined by the size of the storage cluster and the number of data sources; a range means little here without a preliminary study.
GPU selection logic
| Option | Memory | Power draw | When to choose it |
|---|---|---|---|
| RTX PRO 6000 Blackwell Server Edition | 96 GB GDDR7 | 600 W | Best memory per euro for inference; passively cooled, for server chassis |
| H200 NVL / SXM | 141 GB HBM3e | 600–700 W | Very high memory bandwidth; needed for large models and high concurrency |
| L40S | 48 GB GDDR6 | 350 W | Cheaper per card, but the memory quickly becomes the bottleneck |
| Consumer cards (RTX 5090 and similar) | 32 GB | 575 W | Not advised for production: no ECC, no passive cooling, licence restrictions, no server support |
A caveat on all amounts
The amounts given are indicative orders of magnitude based on public list prices. Street prices vary widely between individual cards and OEM-integrated servers, where the same card can cost a multiple. A binding price follows from a current supplier quotation on the configuration finally chosen. Model names are used in this document as a class, not as a product: the model choice per tier is recorded per implementation with name, version, licence and a benchmark of our own.
10 — Data centre preconditions
This is where on-premises AI projects most often run aground
The servers will fit in the utility cupboard; the heat and the noise will not. All electrical power drawn comes back out as heat: 1 kW consumed is 1 kW to be cooled. A standard office server room rarely handles more than 3–5 kW per rack.
| Tier | Peak power | Heat output | Supply | UPS runtime |
|---|---|---|---|---|
| Tier 1 | 2.0–2.5 kW | approx. 8,500 BTU/h | 1× 16 A, preferably 2 separate circuits | 10–15 min, enough for an orderly shutdown |
| Tier 2 | 10–14 kW | approx. 45,000 BTU/h | 2× 32 A, separate phases | 15–30 min; consider a generator |
| Tier 3 | 35–60 kW | 120,000–205,000 BTU/h | A/B feeds, three-phase, distribution at data centre level | Full redundancy, generator required |
Cooling
Tier 1 can sit in a well-cooled server room with its own air-conditioning unit and separated cold and hot sides. Tier 2 requires a purpose-built server room with redundant cooling, hot/cold aisle separation and temperature monitoring with alarms. Tier 3 requires a genuine data centre environment; above 30 kW per rack, liquid cooling becomes more realistic than air cooling. Configure a hardware-level shutdown when a temperature threshold is exceeded: GPUs that throttle thermally quietly deliver less performance, which presents itself as a “slow system”.
Space and noise
Passively cooled server cards are cooled by chassis fans that produce 70–85 dB(A) under load. That cannot be placed in or next to an office space: reckon with a separate, acoustically isolated technical room with its own access control. Footprint: Tier 1 needs 4–6 rack units in an existing rack, Tier 2 a full 42U rack, Tier 3 two to three racks plus space for cooling and distribution.
Physical security
On-premises moves the risk from the cloud to the building. A lockable technical room with electronic access control and per-person logging. Camera surveillance on the entrance, with its own retention period and its own legal basis in the processing register. Locked racks. A procedure for disposing of storage media: physical destruction or certified erasure, with a certificate. Fire detection and an extinguishing provision suitable for electronics. Intrusion detection, linked to the building’s existing security system.
A decision point: your own room or colocation
For Tier 2 and Tier 3, a colocation rack in a Dutch data centre is often cheaper and more reliable than converting a room of your own. The data stays under your own control and on your own equipment; only floor space, power and cooling are bought in. It does change the legal analysis: physical access by third parties calls for contractual and technical safeguards, and must land explicitly in the DPIA.
Management access. Out-of-band management (BMC, iDRAC, iLO) sits on its own VLAN that routes neither to the office network nor to the internet. Default passwords on BMCs are one of the most exploited weak points in server environments; they are replaced at installation and stored in the secrets vault.
11 — Availability, backup and recovery
Availability is a procurement decision, not a product feature
| Tier | Set-up | Design target | On failure |
|---|---|---|---|
| Tier 1 | One server, redundant power and disks | 99.0–99.5% during office hours | The system is down until the component is replaced; spare parts on site recommended |
| Tier 2 | Several nodes, replicated storage | 99.5–99.9% | Capacity halves, the service stays available |
| Tier 3 | HA clusters, redundant network, second site | 99.9%+ | Automatic failover; fallback on loss of a site |
These figures are design targets, not guaranteed service levels. A hard SLA calls for measurable definitions, measured over an agreed period.
What is backed up
| Data | Method |
|---|---|
| Source documents and working duplicates | Incremental backup with immutable retention |
| Vector and lexical index | Snapshot; on loss, re-index from the source |
| Relational database | Continuous log archiving, point-in-time recovery |
| Audit logs | Append-only, object lock, out of reach of administrators |
| Configuration and policy | Version-controlled in a repository, as code |
| Model weights | A hash list plus a copy on cold storage |
Strictly speaking the index need not be backed up because it is rebuildable from the source — but rebuilding takes days. A snapshot is therefore a matter of recovery time, not of data loss.
RPO and RTO
| Tier | RPO | RTO |
|---|---|---|
| Tier 1 | 24 hours | 1–5 working days |
| Tier 2 | 1–4 hours | 4–8 hours |
| Tier 3 | 15 minutes | 1–2 hours |
Ransomware and internal error
3-2-1-1: three copies, two media, one off site, one immutable or offline. Object lock with a retention period that not even an administrator can shorten. Separate administrator accounts for backup and for the platform. Recovery drills at least twice a year, recording the measured recovery time — a backup that has never been restored is an assumption.
Maintenance and life cycle
| Component | Expected service life | Planning point |
|---|---|---|
| GPUs | 4–5 years | The fastest-ageing element; plan replacement or expansion in year 3–4 |
| Servers and CPU | 5–7 years | Weigh a warranty extension year by year |
| NVMe storage | 5 years or the written-data limit | Monitor the wear indicator actively |
| UPS batteries | 3–5 years | A fixed replacement arrangement |
| Network equipment | 7–10 years | Watch for firmware end-of-support |
Build in a maintenance window from day one: one evening a month for patches and one longer window per quarter for model changes and larger upgrades.
12 — Observability, audit and evidential value
Reconstructable after the fact: which user, which model, which source, which answer
| Type of record | Purpose | Retention period | Who may access it |
|---|---|---|---|
| Operational telemetry | Performance, capacity, faults | 30–90 days | Infrastructure operations |
| Security logging | Detection, incident investigation | 6–24 months | Security and the CISO |
| Legal audit trail | Accountability and reconstruction | Equal to the case-file retention period | The audit and privacy function; not administrators |
The separation is not cosmetic: infrastructure administrators must be able to resolve faults without access to case-file content, and the audit trail must lie outside their reach to change if it is to retain evidential value. Entries are chained with a hash chain and written to immutable storage.
What the audit trail records per request
- A timestamp from a reliable, synchronised time source
- The identity of the user and the authentication means used
- The case file or workspace within which the request fell
- The question asked
- The documents and chunks retrieved, with source ID and hash
- The model used, the model version and the instruction-layer version
- The authorisation policy applied and whether anything was refused
- The answer generated and the source references it contains
The five audit questions
These five make a workable acceptance test at delivery: if the system cannot answer them within a few minutes, the logging is not finished.
- Which staff have consulted case file X in the AI environment, and when?
- On which passages did the system base that conclusion, and are those passages unaltered?
- Which model version was running on the day this opinion was drafted?
- Has an attempt ever been made to reach a restricted case file?
- Which documents have been exported, by whom, and to where?
Monitoring and alerting
| Signal | Threshold | Response |
|---|---|---|
| An outbound connection attempt from the inference or data zone | Every attempt | Immediate alarm, traffic blocked |
| A failed authorisation on a restricted case file | 1 attempt | Notification to security and the case-file owner |
| Bulk export or download | Above the configured daily norm | Block plus four-eyes review |
| GPU temperature or thermal throttling | Above the manufacturer’s threshold | Capacity alarm |
| Model answers without a source reference | Above 2% of answers | Quality investigation |
| Latency per request | Above the agreed norm | Capacity alarm |
| A change in authorisation policy | Every change | Notification plus mandatory second approval |
13 — Legal and compliance framework · position as at 14 October 2026
On-premises simplifies compliance, but does not remove it
| GDPR obligation | What on-premises solves | What the organisation must do itself |
|---|---|---|
| Art. 5 — principles | Data minimisation enforceable through retrieval scoping | Establish the legal basis, purpose limitation and retention periods per processing operation |
| Art. 25 — privacy by design | Egress block, need-to-know, pseudonymisation in the pipeline | Actually choosing restrictive default settings |
| Art. 28 — processors | No processor for the inference itself | Processor agreements are still needed with suppliers of maintenance, colocation and support |
| Art. 30 — register | A technical description per pipeline is available | Updating the register itself with the new processing operations |
| Art. 32 — security | Encryption, segmentation, logging, access management | Periodic review and penetration tests |
| Art. 35 — DPIA | The documentation package as a basis | Carrying out and adopting the DPIA; with AI on special categories of data, nearly always mandatory |
| Art. 44 et seq. — transfers | No transfer outside the EEA | Watch for remote support by non-EEA suppliers |
Leaving out a cloud processor reduces the risk of an unlawful transfer, but makes none of the obligations above redundant.
EU AI Act — timeline after the Digital Omnibus
The Digital Omnibus on AI was published as Regulation (EU) 2026/1744 and entered into force on 27 July 2026. It moves the obligations for high-risk AI under Annex III from 2 August 2026 to 2 December 2027, and those for high-risk AI embedded in regulated products under Annex I from 2 August 2027 to 2 August 2028.
| Obligation | Status |
|---|---|
| Prohibited AI practices | In force since 2 February 2025 |
| AI literacy (art. 4) | In force since 2 February 2025 |
| Providers of GPAI models | In force since 2 August 2025 |
| Transparency (art. 50) | In force since 2 August 2026; not postponed |
| High-risk, Annex III | Postponed to 2 December 2027 |
| High-risk, Annex I | Postponed to 2 August 2028 |
Whether the system is itself high-risk depends on the concrete deployment. Annex III covers law enforcement and the administration of justice, among other things; a system supporting a judicial authority in researching and interpreting facts and law falls under it more readily than a tool in the hands of a defence team. This calls for an explicit classification under Article 6 per client. That classification cannot be postponed: the postponement concerns the obligations, not the question of whether the system falls under them.
Wpg and Wjsg
Police data and judicial and criminal-procedure data are not governed by the GDPR but by a regime of their own, with its own legal bases, retention periods, disclosure rules and audit obligations. The platform determines per data collection which regime applies and enforces the corresponding policy. Two common mistakes the system actively prevents: applying GDPR access rules to Wpg data, and mixing both regimes in a single index.
Cybersecurity Act (NIS2)
The Dutch Cyberbeveiligingswet entered into force on 15 August 2026, at the same time as the Critical Entities Resilience Act. There is no general transition period. Its core obligations are registration with the supervisory authority, a duty of care for risk management, and a reporting duty with an early warning within 24 hours and an incident report within 72 hours. Organisations in the designated sectors therefore have an obligation already running, which the platform can plug into; through supply-chain responsibility their suppliers face the same requirements indirectly.
Legal professional privilege and professional rules
Professional secrecy and legal professional privilege rest on the lawyer, not on the system. An AI tool that processes client data falls within the lawyer’s practice and therefore under their duty of care and the professional rules on confidentiality and outsourcing. On-premises processing makes it considerably easier to meet that duty of care, because there is no third party with actual access to the data. It does not relieve the lawyer of their own assessment.
14 — Implementation, operations and SLA
Eight phases, and what is expected of the client
| Phase | Duration | What happens | What the client provides |
|---|---|---|---|
| 0. Preliminary study | 1–2 weeks | Inventory of data sources, user numbers, space, power; choice of tier | Access to IT, the DPO and a subject-matter end user |
| 1. Design | 1–2 weeks | Architecture, authorisation model, DPIA input, acceptance criteria | Approval of the architecture and the authorisation matrix |
| 2. Delivery and installation | 3–8 weeks | Hardware ordered, installed, connected, hardened | Server room, power, network ports |
| 3. Base platform | 1–2 weeks | Orchestration, IAM, storage, monitoring, backup | Identity provider connection |
| 4. First pipeline | 1–2 weeks | One source fully indexed, including ACLs | Test case files and a subject-matter reviewer |
| 5. Subject-matter calibration | 2–3 weeks | Layers activated, evaluation set built, quality tested | Legal assessment of the outcomes |
| 6. Pilot | 2–4 weeks | A limited group of users, measurement and adjustment | 5–10 users who genuinely free up time |
| 7. Roll-out | 2–4 weeks | Remaining sources, all users, training | Communication and training time |
| 8. Handover | 1 week | Documentation, operational handover, acceptance | An administrator appointed |
Training
| Audience | Length | Contents |
|---|---|---|
| End users | 2 × 2 hours | Framing questions, checking source references, the limits of the system, when not to use it |
| Case-file owners | 2 hours | Authorisations, restriction, workspaces |
| Administrators | 2 days | Platform operations, model deployment, monitoring, incident handling |
| DPO and privacy officer | 0.5 day | Logging, DPIA, access requests on the system itself |
The AI-literacy obligation in Article 4 of the AI Act has applied since February 2025; this training component is therefore not an extra but the fulfilment of an existing duty.
Operating models
| Model | Suitable for |
|---|---|
| Self-managed | Organisations with an infrastructure team of their own; support on call |
| Managed remotely | Medium-sized firms without in-house Linux expertise; over a secured, logged connection, without access to case-file content |
| Fully managed on site | Organisations with the strictest requirements; fixed maintenance days, no external access |
SLA structure
| Level | Response | Resolution | Window |
|---|---|---|---|
| Basic | 8 working hours | Best effort | Working days 9–17 |
| Business | 4 working hours | 1 working day | Working days 8–18 |
| Critical | 1 hour | 4 hours | 24/7, spare parts on site |
Hardware replacement within four hours requires a maintenance contract from the hardware supplier itself, or spare parts held in-house. That is a separate cost item, shown separately in the quotation.
15 — Total cost and comparison with cloud
The case for buying is not “cheaper”, but manageable risk at predictable cost
Cost structure over five years — worked example, Tier 2
| Item | Year 1 | Years 2–5 p.a. | Five years |
|---|---|---|---|
| Hardware (depreciated purchase) | € 265,000 | — | € 265,000 |
| Implementation and configuration | € 60,000–120,000 | — | € 90,000 (midpoint) |
| Energy (12 kW at 60% average load, € 0.20/kWh) | € 12,600 | € 12,600 | € 63,000 |
| Cooling (approx. 35% on top of energy) | € 4,400 | € 4,400 | € 22,000 |
| Colocation or premises costs | € 12,000 | € 12,000 | € 60,000 |
| Hardware maintenance contracts | € 18,000 | € 18,000 | € 90,000 |
| Operations (0.5 FTE internal or a management contract) | € 55,000 | € 55,000 | € 275,000 |
| Software licences and support | € 25,000 | € 25,000 | € 125,000 |
| GPU replacement or expansion in year 4 | — | — | € 80,000 |
| Total | approximately € 1,070,000 |
At 60 active users that works out at roughly € 3,570 per user per year, or € 297 a month. At 120 users on the same hardware it halves. This is a calculation structure based on assumptions that differ per client, intended as the basis for a quotation — not a price list.
Axes of comparison against cloud AI
| Axis | On-premises | Cloud AI service |
|---|---|---|
| Cost structure | Large investment up front, low marginal cost | No investment, costs grow with use |
| Predictability | Fixed; usage does not affect the bill | Variable; intensive use shows up immediately |
| Break-even point | More favourable from roughly 40–80 intensive users | More favourable at low or irregular volumes |
| Data residency | Entirely under your own control | Depends on the contract and the provider’s place of establishment |
| Model acceleration | An upgrade is a project of your own | New models available immediately |
| Top-end model quality | The best open-weight models | Generally a step ahead of open-weight |
| Demand peaks | Bounded by the capacity purchased | Virtually unbounded |
| Exit | Hardware and data remain the organisation’s | Depends on export facilities |
| Operational burden | Your own responsibility | With the provider |
Market benchmark per user per month
| Option | Pricing model | Per user per month | Files are held by |
|---|---|---|---|
| Legal AI assistant, Dutch market | Per-seat subscription | around € 59 | the provider |
| Legal AI platform, Dutch market | Per-seat subscription | € 175 – € 200 · market-wide € 100 – € 300 | the provider |
| International platforms | Per seat, minimum 10–25 seats | estimates $ 250 – $ 1,200+ | the provider |
| LEX SUPREMA Tier 2 | Owned outright, fixed cost | approx. € 297 at 60 · approx. € 149 at 120 | the organisation itself |
Two things stand out here. First, owning outright costs per user in the same order as a platform subscription once the number of users approaches sixty, and below it once it goes beyond that. Second, the amount is fixed: the market is moving towards billing on actual consumption — Legora announced that shift in June 2026 for its most advanced product, and firms are budgeting for AI costs two to three times higher if they want to keep using the best models. On your own hardware you buy capacity, not tokens.
Sources: rate indications per user per month from research by ICTRecht, as reported by Mr. Online; the € 100 – € 300 range and the announced move to consumption billing from reporting by the FD, 29 June 2026. Amounts for international providers are third-party estimates; those parties do not publish their rates. The amounts for LEX SUPREMA follow from the cost model above and are not a price list.
The cost items that usually get forgotten
- Operations: structurally 0.3–1.0 FTE, depending on tier. This is the largest item after the hardware.
- The initial indexing: temporary compute capacity or a few weeks of waiting.
- End users’ training time, measured in billable hours.
- GPU replacement around year four; the hardware cycle of AI is shorter than that of ordinary servers.
- The annual penetration test and review of the controls.
- Conversion of the server room, if no suitable room exists.
16 — Risks and limitations
What every buyer runs into within three months
Substantive limitations
| Limitation | What it means | Control |
|---|---|---|
| Open-weight models trail the best closed models | On the hardest reasoning tasks the difference is noticeable | People in the loop; the system delivers drafts, not finished products |
| Hallucinations are limited, not excluded | An incorrect assertion can look convincing | Mandatory sourcing, citation verification, counter-analysis, mandatory review by a lawyer |
| Dutch legal language is a niche | Less training material than for English-language law | An evaluation set of your own, retrieval over verified Dutch sources |
| Case law ages | An offline source library is by definition behind | A fixed update cycle with a recorded cut-off date, visible in every answer |
| Quality depends on case-file quality | Poorly scanned documents give poor analyses | OCR quality control with flagging of unreliable pages |
Technical and operational risks
| Risk | Impact | Control |
|---|---|---|
| Dependence on a single GPU supplier | Lead time and price outside your own influence | Order early; alternative configurations in the quotation |
| The client lacks operational capacity | The system ages and becomes insecure | A management contract as a condition at Tier 1 and 2 |
| The server room turns out to be unsuitable | The project runs months late | A site survey in phase 0, before the quotation |
| Initial indexing takes longer than expected | A disappointing start | A phased roll-out per archive; expectations recorded in advance |
| Authorisations in the source system are a mess | AI makes existing access problems visible and worse | Authorisation clean-up as an explicit project phase, before indexing |
| Low adoption | The investment does not pay off | A pilot with real case files and a subject-matter champion |
The fifth risk deserves particular attention. Many organisations have worked for years with open network drives on which everyone can see everything. A search system makes that mess usable, and therefore dangerous. Authorisation clean-up is thus not optional preparation but a precondition.
Quotation and preliminary study
A quotation starts with a site survey, not with a configuration
Give us the number of users, the size of the document archive, the source systems and a description of the available server room, and you will get a substantiated configuration with a range — plus an honest answer to the question of whether on-premises is the right choice in your situation.
Privacy Solid
Daniel de Rijk — CDPO, Data Protection Officer and cybersecurity consultant.