Agent-Architektur: Warum wir auf eigene Hardware setzen

Kein AWS. Kein Azure. Deutsche Rechenzentren, eigene Server, volle Kontrolle.

Jeder, der heute ein KI-Startup gründet, bekommt denselben Rat: „Geh in die Cloud. AWS, Azure, GCP — warum solltest du dich mit Hardware rumschlagen?" Wir haben diesen Rat gehört. Und dann das Gegenteil getan.

Heute betreibt nAIce eigene Server in zwei deutschen Rechenzentren. Keine US-Cloud. Kein Drittland-Transfer. Keine geteilte Infrastruktur mit wer-weiß-wem. Das war teuer. Es war kompliziert. Es war die beste Entscheidung, die wir getroffen haben. Hier ist warum.

Grund #1: Souveränität

Wenn ein KI-Agent Kundendaten verarbeitet, dann verarbeitet er alles. E-Mails, CRM-Einträge, Support-Tickets, interne Dokumente, manchmal Finanzdaten. Diese Daten in eine US-Cloud zu schieben, ist für europäische Unternehmen keine technische Entscheidung — es ist eine existenzielle.

Selbst mit Standardvertragsklauseln und allen Compliance-Versprechen der Hyperscaler bleibt ein Restrisiko: Der Cloud Act. US-Behörden können unter bestimmten Umständen Zugriff auf Daten verlangen, die auf US-Infrastruktur liegen — egal wo die Rechenzentren physisch stehen. Das ist keine Theorie, das ist geltendes Recht.

Für unsere Kunden — mittelständische Unternehmen, die zum Teil kritische Infrastruktur betreiben — ist das ein No-Go. Sie brauchen die Garantie, dass ihre Daten Deutschland nie verlassen. Nicht „wahrscheinlich nicht", nicht „mit Zusatzvereinbarungen". Sondern: physikalisch nicht.

Datensouveränität ist keine juristische Spitzfindigkeit. Sie ist der Grund, warum unsere Kunden nachts schlafen können.

Grund #2: Latenz und Kontrolle

KI-Agenten, die Tickets bearbeiten oder auf Kundenanfragen reagieren, brauchen Antwortzeiten im Sekundenbereich. Jede zusätzliche Netzwerk-Hop, jede Load-Balancer-Weiterleitung, jede geteilte Ressource in einer Cloud-Umgebung addiert Millisekunden. Und Millisekunden addieren sich zu Sekunden.

Mit eigener Hardware wissen wir exakt, was unter der Haube passiert. Kein „Noisy Neighbor"-Problem, bei dem ein anderer Tenant plötzlich die IOPS frisst. Keine unerklärlichen Latenzspitzen, deren Ursache im AWS-Support-Ticket verschwindet. Wir messen, wir optimieren, wir entscheiden.

Dazu kommt: Wir können Hardware genau auf unsere Workloads zuschneiden. Inference braucht GPU-RAM und schnelle Speicheranbindung, nicht 64 vCPUs und Petabyte-Blob-Storage. In der Cloud zahlen wir für Standardkonfigurationen, die immer irgendwo überdimensioniert sind. Auf eigener Hardware bauen wir genau das, was wir brauchen.

Warum teurer — und trotzdem wertvoll

Ja, eigene Hardware ist teurer im CapEx. Ein Server mit GPU-Kapazität kostet im Einkauf. Colocation im Rechenzentrum kostet monatlich. Remote-Hands für Wartung kosten pro Eingriff. Auf den ersten Blick rechnet sich das nicht gegen Cloud-Credits und Pay-as-you-go.

Aber die Rechnung ändert sich, wenn man das Gesamtbild betrachtet:

• Keine versteckten Cloud-Kosten: Data-Transfer-Gebühren, die in der Monatsabrechnung explodieren. Managed-Service-Kosten für Dienste, die man nie wirklich brauchte. Das sind keine Einzelfälle, das ist die Realität jeder Cloud-Rechnung ab einer gewissen Skalierung.
• Planbare Kosten: Ein Server kostet jeden Monat dasselbe, egal ob die Agenten 100 oder 10.000 Tasks ausführen. Keine Überraschungen.
• Vertrauen als Asset: Der Satz „Ihre Daten liegen auf Servern in Frankfurt, die uns gehören" schließt mehr Deals als jedes Cloud-Compliance-Zertifikat. Das ist schwer in Euro zu messen — aber spürbar in der Pipeline.

Unsere 3-Schichten-Architektur

Für die technisch Interessierten: So ist unsere Infrastruktur aufgebaut.

Schicht 1 — Hardware: Dedizierte Server mit NVIDIA-GPUs (L40S und A100), lokalem NVMe-Storage, ECC-RAM. Keine Virtualisierung auf dieser Ebene. Bare Metal. Zwei redundante Standorte in deutschen Rechenzentren, Dark Fiber zwischen den Standorten, Failover unter 30 Sekunden.

Schicht 2 — Orchestrierung: Auf der Hardware läuft unser Orchestration-Layer. Kubernetes für Container-Workloads, eigenes Scheduling für GPU-Jobs, Message Queue für Agent-Task-Verteilung. Hier passiert die Magie der Lastverteilung: Welcher Agent läuft auf welcher GPU, wann wird ein Task queued, wann braucht es Priorität.

Ein kritischer Punkt ist das Context-Management. Jeder Agent-Task braucht Kontext — vorherige Interaktionen, CRM-Daten, Dokumente, Entscheidungshistorie. Diesen Kontext zwischen GPU-Wechseln konsistent zu halten, ohne die Latenz zu killen, ist eines der härtesten Engineering-Probleme, die wir gelöst haben. Unsere Lösung: ein eigener Context-Cache auf NVMe, der innerhalb von unter 5ms geladen wird und Task-Übergänge ohne Datenverlust ermöglicht.

Schicht 3 — Anwendung: Die Agenten selbst. Jeder Agent läuft in einer isolierten Umgebung mit eigenem Kontext-Fenster, eigenem Memory-Management, eigenen API-Keys. Kein Agent sieht die Daten eines anderen. Isolation ist hart verdrahtet, nicht per Konfiguration.

Für wen das passt — und für wen nicht

Eigene Hardware ist nicht für jeden die richtige Antwort. Wenn du drei Agenten für interne Tests betreibst, ist Cloud der schnellere Weg. Wenn deine Kunden keine DSGVO-Bedenken haben, spar dir den Aufwand. Wenn du keine Engineers hast, die einen Server debuggen können — bleib bei Managed Services.

Aber wenn du eine Plattform baust, auf die Unternehmen ihre sensibelsten Prozesse verlagern sollen, dann gibt es keinen Shortcut. Souveränität muss man sich leisten wollen. Und die Kunden, die sie brauchen, sind auch bereit, dafür zu zahlen.

Unsere Architektur-Entscheidung war unbequem. Sie hat unseren Start um Monate verzögert. Sie hat Kapital gebunden, das wir anderswo gebraucht hätten. Aber jedes Mal, wenn ein Datenschutzbeauftragter nach der Infrastruktur fragt und wir antworten können: „Eigene Server, Frankfurt, kein Drittland" — dann wissen wir, dass es richtig war.