for your technical team

An AI platform
your engineers will love.

For the people who will run it — architects, security engineers, platform teams. A current open-weight stack on your hardware or our European cloud. Default-deny egress at the network layer, EU jurisdiction by design, and real customers running it in production today.

Reference architecture→Compliance matrix
open weights · default-deny egress·european jurisdiction·no CLOUD Act exposure
arkintel · production
live

$

// example shape — customer details redacted.

showcase · the node

Every engagement
ships one node.

An Arkintel deployment is a self-contained AI platform that lives inside your perimeter. Models run next to your data. Answers come out. Nothing else does. Here’s what that looks like when it’s running.

// the same shape, whether it runs in your server room, a European private cloud, or a site with no internet at all.

fig 01 · your arkintel nodelocation: your buildingdata leaving: none

  1. Sovereignty perimeter

    A security boundary your team controls end-to-end. Configured to match your rules — European residency, fully offline, or anywhere in between.

    the dashed ring

  2. AI running on your hardware

    The latest open AI models, running on servers you own. No license lock-in. No per-call billing. If we disappear tomorrow, your AI keeps working.

    the rack in the centre

  3. Data comes in. Nothing goes out.

    Connect the systems you already run — case files, tickets, documents, citizen records. Answers come back inside your walls. Nothing ever leaves.

    the teal pips

  4. Your deployment map

    Already live inside the Municipality of Delft, the City of Rotterdam, TU Delft, JustAskMomo and Schuldhulpje. Every client gets their own private system.

    the orbiting chips
See how we deploy→Jump to reference architecture→typical deployment: 6–10 weeks · no lock-in

01reference architecture

Three topologies.
Pick the one that matches your risk profile.

Same platform, three deployment shapes. All single-tenant, all open-weight models by default, all default-deny egress enforced at the network layer — not just in application policy.

topology 01

On your hardware

In your server room or your data centre.

The full Arkintel stack runs inside your perimeter, on hardware you own. We don’t sell servers — we help you spec what you need given the models you actually want to run, then we deploy and operate the platform on top of it. Inference scales with the GPUs you put in; CPU-only is possible for smaller workloads.

  • GPU sizing scoped to the models you want to run — we consult, you buy
  • Hybrid CPU/GPU topologies supported for cost-sensitive builds
  • Kubernetes (preferred) or docker-compose for smaller installs
  • Default-deny egress enforced on your network, not just in our app

topology 02

Our European cloud

Hetzner EU regions, operated by us.

If running hardware isn’t your fight, we deploy and operate the same stack for you on Hetzner’s European data centres. A Dutch company managing a German-headquartered EU provider — outside the reach of the US CLOUD Act and any foreign subpoena. Same APIs, same models, same audit story as the on-prem path.

  • Hetzner EU regions — Falkenstein, Helsinki, Nuremberg
  • Operated end-to-end by Arkintel (Dutch entity)
  • Same default-deny egress, same model menu, same APIs
  • Easiest path for teams without their own data centre

topology 03

Air-gapped, on request

Fully disconnected. Scoped per customer.

For customers whose policy or threat model requires no internet at all, the platform ships as offline install bundles applied via removable media — updates the same way. A scoped engagement we walk through with your security team up front.

  • Zero outbound network requirements once installed
  • Signed offline install + update bundles
  • Local-only authentication and PKI
  • Scope and timeline agreed up-front with your team

02the stack

Open source, top to bottom.

Nothing proprietary inside the platform itself. Every layer is open-weight or open-source. You keep running it if we disappear.

Models

open-weight, auditable
  • Llama 4 ScoutGeneral chat, reasoning, tool useLlama community
  • Gemma 4 31BStrong general open-weightGemma terms
  • Ministral 3 14BSmaller, faster, cheap to runMistral open
  • Nemotron 3 SuperReasoning-leaning open-weightNVIDIA open
  • GPT-OSS 120BLargest open-weight optionOpen weights
  • Custom fine-tunesOn your data, in your environmentYours
  • Frontier (via Privacy Gate)Claude 4.7 / GPT 5.5 / Gemini 3.1 Pro — gated, opt-inProvider terms

Runtime

inference serving
  • vLLMInference serving for the open-weight models
  • llama.cppCPU / smaller-rig fallback
  • Privacy GateRoutes & redacts before any frontier call

Storage

state & retrieval
  • PostgreSQL + pgvectorMetadata, audit log, retrieval index
  • S3-compatible object storageDocuments, transcripts, model weights
  • RedisSessions, rate-limits, ephemeral cache

Orchestration

platform plane
  • Kubernetes 1.28+Primary deployment target
  • docker-composeSingle-node / small deployments
  • Prometheus + OpenTelemetryMetrics, traces, logs
  • OpenAPI 3.xPlatform APIs are spec-documented

03arkintel cli

You run it the way
you run everything else.

arkintel is the operator surface — deploys, audit, day-to-day. Two examples below show the shape.

Deploy a model
example
# pin a model on your cluster
arkintel models deploy llama-4-scout \
  --replicas 2 \
  --gpus 2

arkintel models list
  NAME              STATUS  REPLICAS
  llama-4-scout     ready   2
  gemma-4-31b       ready   1
  ministral-3-14b   ready   1
Audit a conversation
example
# every call is logged inside your perimeter
arkintel audit trace conv-01JEF9...
  user:    alice@delft.nl   role: caseworker
  model:   llama-4-scout    retrieval: 3 chunks
  egress:  0 attempts        latency:   1.82s
  tokens:  412               policy:    5 checks pass

04integrations

It plugs into what you already run.

No rip-and-replace. Identity, data, APIs and observability wire into your existing systems on day one.

Identity & access

  • SAML 2.0 and OIDC via a Keycloak instance we deploy alongside the platform
  • Plays with Azure AD, Okta, ADFS — anything Keycloak can speak to
  • Standard RBAC inside the platform

APIs

  • OpenAI-compatible /v1/chat/completions and /v1/embeddings
  • OpenAPI 3.x spec for the rest of the platform surface
  • Webhooks delivered inside your network, never out

Data sources

  • S3 / MinIO / any S3-compatible object store
  • PostgreSQL for structured data
  • Bring-your-own connectors for systems we haven’t covered yet — scoped per project

Observability

  • Prometheus metrics for the platform and model serving
  • OpenTelemetry traces and logs
  • Audit-log stream you can ship into your existing log pipeline

05compliance matrix

Designed for European regulation.
From the architecture up.

Two frameworks govern every European deployment we ship: GDPR and the EU AI Act. The matrix below shows how each one maps onto the platform — controls, procedures and the operational shape, every deployment.

GDPR — aligned

5 mapped controls

  • Data minimisation (Art. 5)

    Only data you explicitly ingest is indexed. No background collection.

  • Purpose limitation

    Per-dataset purpose tags; retrieval is policy-bounded.

  • Right to erasure (Art. 17)

    Per-record deletion: vector + metadata purge in the retrieval index.

  • Processor / controller

    Arkintel is processor for the managed-cloud path; on your own hardware (or air-gap), we don’t process at all — you do.

  • EU residency

    Data stays in the EU — on your hardware, or on Hetzner EU regions when we host.

EU AI Act — aligned

4 mapped controls

  • Transparency (Art. 13)

    Per-conversation log: user, model, prompt, response, citations.

  • Human oversight (Art. 14)

    Human-in-the-loop is supported at the workflow level for higher-risk use cases.

  • Logging (Art. 12)

    Every call is audit-logged inside your environment, on your retention schedule.

  • Robustness & cybersecurity (Art. 15)

    Encryption in transit and at rest, default-deny egress, signed builds.

// happy to walk through our actual security posture, DPA and architecture with your team — contact security@arkintel.com.

06security posture

No hand-waving.

Concrete security controls. Specific versions, specific cryptography, specific processes.

Encryption

AES-256 at rest. TLS 1.3 in transit. Mutual TLS between internal services where it matters.

Egress

Default-deny at the network layer (firewall / NetworkPolicy), not just inside the application. The allowlist is what you say it is — by default, empty.

Authentication

SAML 2.0 and OIDC via a Keycloak instance we deploy alongside the platform. Plugs into your existing IdP — Azure AD, Okta, ADFS, anything Keycloak speaks to.

Audit log

Every conversation is logged: user, model, prompt, response, latency, egress attempts. Stored where you tell us, retained as long as you say.

Vulnerability hygiene

Container images and dependencies scanned in CI and during operation. Critical issues prioritised, patched, redeployed — a working process, not a contractual SLA.

Verifiable

Every property on this page is enforced by configuration your team can audit, not by vendor promise. Bring your security team and an NDA — we walk through the architecture and the operational details, end to end.

07deployment runbook

Six to ten weeks, end to end.

A typical deployment. Your timeline will differ depending on topology, data volume and compliance scope — but this is the shape.

  1. phase 01

    Week 0–1

    Kick-off & sizing

    Workshop with your team. Use cases, data, hardware sizing (we don’t sell hardware — we help you spec it), topology choice, success criteria.

  2. phase 02

    Week 2–3

    Provisioning

    Either we bring up your Hetzner deployment, or we install onto hardware you already have. Identity, networking, storage and observability wired in.

  3. phase 03

    Week 4–5

    Platform deploy

    Arkintel installed. Models loaded for the GPUs you provisioned. SSO via Keycloak, default-deny egress, audit stream pointed at your log pipeline.

  4. phase 04

    Week 6–7

    Data & integrations

    Document sources connected. Retrieval index built. Workflow integrations wired. Internal benchmarks pass.

  5. phase 05

    Week 8–10

    Training & go-live

    Train-the-trainer sessions. Phased rollout. Runbook handover. Real timeline depends on topology and scope — this is the shape of a typical mid-sized engagement, not a contract.

// taking it further

Curious where it actually runs?Self-hosted topologies & live deployments

08see also

Where the architecture lives in the rest of the site.

The reader profile flips here from security/SRE to budget holder. Same product, different framing.

solution

where it runs

Self-hosted deployment

Run the platform on your own hardware, your VPC, or air-gapped — already live inside the Municipality of Delft.

solution

solutions

For regulated industries

Government, healthcare, legal, finance, family offices — sovereign AI under European law.

page

the suite

All apps & customer builds

Five apps side by side, plus the four customer systems we've already shipped from them.

app

policy as code

Try Privacy Gate

Compliance writes routing rules; the gate enforces them everywhere chat lives. Local classification under 50 ms.

next step

Bring your security team
to the next call.

We work with security teams, architects and procurement up-front, not as an afterthought. Send us a questionnaire or a diagram of what you'd plug us into, and we'll come back with the matching architecture for your environment.

Request a technical eval