Im Kern eines souveränen KI-Assistenten steckt ein Spannungsfeld. Das gesamte Versprechen lautet: Ihr Wissen bleibt in Ihrem Haus — Ihr Modell läuft auf Ihrer eigenen Hardware, Ihre Daten verlassen das Gebäude nie. Doch ein Assistent, der mit Ihrer Kundschaft spricht, muss aus dem öffentlichen Internet erreichbar sein: jederzeit verfügbar, überall schnell und gehärtet gegen genau die Angriffe, die jeder öffentliche Endpunkt anzieht. Erreichbar und privat ziehen in entgegengesetzte Richtungen.
Cloud Shield ist Wegentys Antwort auf dieses Spannungsfeld. Es ist eine hochverfügbare Cloud-Edge, die öffentliche Verbindungen zu den AI-Cores vermittelt, die innerhalb der Netze unserer Kundinnen und Kunden laufen — ohne einen Core jemals direkt offenzulegen und ohne dass die Kundschaft auch nur einen einzigen Teil dieser öffentlich zugewandten Arbeit selbst betreiben muss. Dieser Beitrag führt durch die Architektur für den technisch interessierten Entscheider: nicht das tiefe Betriebshandbuch, aber genug von der Gestalt, dass Sie erkennen, warum eine öffentliche KI souverän bleiben kann.
Der eine Gedanke, den Sie mitnehmen sollten: Der Core ist von außen niemals erreichbar. Alles Folgende steht im Dienst dieser Aussage.
Das Problem des naheliegenden Wegs
Der naheliegende Weg, einen privaten Server online zu stellen, ist das Öffnen eines Ports. Sie stellen den AI-Core ins Netz, schlagen ein Loch in die Firewall, legen eine eingehende Regel an, richten eine Domain darauf aus — und hoffen, dass Ihre Abwehr hält. Jeder einzelne dieser Schritte ist ein neuer Weg hinein. Ein offener eingehender Port ist eine stehende Einladung — er existiert, ob ihn jemand nutzt, dem Sie vertrauen, oder nicht, und genau danach sucht ein Angreifer.
Cloud Shield macht das Gegenteil. Das Netz der Kundschaft öffnet überhaupt keine eingehenden Ports. Es gibt keinen öffentlichen Endpunkt am Core, keine eingehende Firewall-Regel, nichts, das ein Angreifer finden könnte. Der Core bleibt so privat wie am Tag, bevor Sie ihn angebunden haben. Wie das funktioniert, ist der erste und wichtigste Baustein der Architektur.
Der Connector-Tunnel: die Box wählt sich nach außen
Innerhalb des Kundennetzes betreibt jeder AI-Core einen kleinen Connector-Daemon. Statt darauf zu warten, erreicht zu werden, wendet sich der Connector nach außen. Er wählt eine dauerhafte, verschlüsselte Verbindung zu Cloud Shield und hält sie offen — dasselbe Muster, das Werkzeuge wie Cloudflare Tunnel und Tailscale auch hinter einer geschlossenen Firewall sicher betreibbar macht.
Das ist der Connector-Tunnel, und die Richtung ist der entscheidende Punkt:
- Nur ausgehend. Die Verbindung wird vom Kundennetz aus aufgebaut. Cloud Shield initiiert niemals eine Verbindung in dieses Netz hinein. Die Deny-by-default-Firewall der Kundschaft bleibt geschlossen — ausgehender Verkehr ist normal und erwartbar; gefährlich sind die eingehenden Löcher, und davon gibt es keine.
- Verschlüsselt und beidseitig authentifiziert. Der Tunnel läuft über QUIC mit TLS 1.3. Jeder Connector trägt sein eigenes Zertifikat, gebunden an einen Mandanten und einen Core. Der Tunnel ist nachweisbar genau einem Core genau einer Kundin oder eines Kunden zugeordnet — Cloud Shield weiß präzise, wer am anderen Ende ist, und ein Fremder kann sich nicht als Core ausgeben.
- Selbstheilend. Connectors senden regelmäßig ein Heartbeat-Signal. Geht ein Core offline, wird sein Tunnel geleert und es wird kein Verkehr mehr zu ihm geleitet. Die Erreichbarkeit folgt den Cores, die tatsächlich gesund sind.
Die Eigenschaft, die das sicher macht, ist beinahe langweilig einfach: Erreichbarkeit wird vom Core angeboten, nie auf ihn aufgezwungen. Es ist immer die Kundschaft, die sich nach außen wählt. Es gibt keine Tür, die man unverschlossen lassen könnte, weil es keine Tür gibt.
Mehrere Cores je Mandant
Eine einzelne Kundin ist nicht auf einen Core beschränkt. Ein Mandant kann viele Connectors registrieren, und Cloud Shield kann sie so behandeln, wie es die Kundschaft braucht:
- Als Hochverfügbarkeits-Pool. Mehrere austauschbare Cores teilen sich die Last, und fällt ein Connector aus, schaltet Cloud Shield automatisch auf die übrigen um. So erhalten Sie Redundanz und Durchsatz, ohne dass eine einzelne Maschine zum Single Point of Failure wird.
- Als individuell adressierbare Cores. Jeder Core kann eine eigene, stabile Identität tragen — etwa ein Core in einer Region gegenüber einer anderen oder einer, der auf ein anderes Modell oder eine andere Anforderung an die Datenresidenz abgestimmt ist — sodass ein Aufruf genau den Core ansprechen kann, den er meint.
- Als Mischung aus beidem. Das Routing wird an der Edge aus einer aktuellen Registry aufgelöst: Mandant, dann die Menge der Cores, dann eine Auswahlrichtlinie — wobei ungesunde Cores automatisch ausgeleitet werden.
Das passt natürlich zum Verbindungsartefakt — der kleinen Datei, die eine Instanz und ihre Geltungsbereiche benennt. Das Artefakt sagt, welche Instanz; der Tunnel ist, wie diese Instanz tatsächlich erreicht wird.
Die öffentliche Edge: AWS, gehärtet
Auf der öffentlichen Seite trifft der Verkehr auf eine Cloud-Edge, die auf AWS aufsetzt und darauf ausgelegt ist, die Feindseligkeit des Internets aufzufangen, bevor irgendetwas einen Core erreicht. Eine Anfrage landet zunächst auf einer Schicht aus Content-Delivery und Firewall — einem CDN, einer Web Application Firewall und einem verwalteten DDoS-Schutz —, dort wird TLS terminiert, und erst dann darf sie tiefer. Öffentlicher Verkehr und Kundenverwaltung laufen als zwei getrennte Ebenen, mit eigenem Zugang, eigenen Identitäten und eigenen Berechtigungen, sodass die Menschen, die einen Mandanten verwalten, und die Endnutzer, die mit dessen Assistenten sprechen, niemals denselben Pfad teilen.
Im Inneren ist die Architektur in Zonen geteilt: eine öffentliche Zone, die nur die Edge-Loadbalancer enthält, eine private Compute-Zone ganz ohne Route ins Internet und eine private Datenzone für den Zustand. Die Compute-Schicht, die Anfragen tatsächlich bearbeitet, kann von sich aus nicht ins offene Internet greifen — sie kann nur ihre Aufgabe erfüllen und durch den Tunnel zurückantworten.
Scale-to-Zero: Sie zahlen, wenn genutzt wird
Hier kommt der Teil, der für die Wirtschaftlichkeit entscheidend ist. Die anfragenbearbeitende Compute-Schicht läuft in Containern und skaliert auf null. Ist ein Mandant inaktiv — spricht gerade niemand mit seinem Assistenten —, sinkt seine Compute-Last auf nichts. Die erste Anfrage fährt sie bei Bedarf wieder hoch. (Das ist es, was Scale-to-Zero in der Praxis bedeutet.)
Die Wirkung: Ein inaktiver Mandant verursacht im Wesentlichen keine Compute-Kosten. Sie mieten keinen Server, der nachts warm und unbeschäftigt vor sich hin läuft; die Kapazität folgt der tatsächlichen Nachfrage, Anfrage für Anfrage. Nur die minimale Verbindungsschicht — der Tunnel-Zugang, der die Cores verbunden hält, auch wenn niemand etwas fragt — bleibt warm, und das ist bewusst günstig gehalten. Es ist der Preis für jederzeit verfügbar, und er ist klein.
Für eine Vielzahl von Kundinnen und Kunden, die jeweils zu unterschiedlichen Zeiten aktiv werden, ist das der Unterschied zwischen Kosten, die mit der Nutzung wachsen, und solchen, die mit der Zahl der offen gelassenen Türen wachsen. Cloud Shield wächst mit der Nutzung.
Jederzeit verfügbar, auch wenn etwas ausfällt
Souverän und rechtskonform sind die Grundvoraussetzung; ein Assistent, den Ihre Kundschaft erreicht, muss zudem verfügbar bleiben. Cloud Shield läuft aktiv-aktiv über mehrere Availability Zones hinweg — mindestens zwei voneinander unabhängige Rechenzentrumszonen, ohne Single Point of Failure auf dem Anfragepfad. Die Proxys, die den Verkehr leiten, halten keinen eigenen Zustand, weshalb die Wiederherstellung augenblicklich erfolgt: Hat eine Zone ein Problem, fließt der Verkehr einfach über die anderen. Der Zustand liegt in verwalteten, replizierten Speichern. Und die Ebenen sind bewusst voneinander isoliert, sodass ein Problem in der Kundenverwaltungs-Ebene niemals den laufenden Assistenten lahmlegen kann, mit dem Ihre Kundschaft spricht.
Die Standardheimat all dessen ist eine EU-Region — und genau das ist der Punkt. Die Geschichte der Ausfallsicherheit und die Geschichte der Souveränität sind dieselbe Geschichte: Ihr Assistent bleibt verfügbar, und er bleibt innerhalb der Rechtsordnung, die Sie gewählt haben.
Zero-Trust und ein Nachweis jeder Verbindung
Cloud Shield behandelt jede Anfrage als nicht vertrauenswürdig, bis sie das Gegenteil beweist. Die Kontrollen sind geschichtet, von der öffentlichen Edge bis hinunter zum Tunnel: eine Firewall und DDoS-Schutz am Perimeter; Authentifizierung und Autorisierung für jeden Nutzer und jede Administratorin; beidseitiges TLS auf dem Pfad zum Core; eine mandantenweise Isolierung, sodass der Verkehr, die Identitäten, die Schlüssel und die Geheimnisse einer Kundin niemals die einer anderen erreichen können.
Und jede öffentliche Verbindung wird protokolliert — wer sich verbunden hat, unter welcher Identität, was entschieden wurde und wohin geleitet wurde. Dieser Nachweis ist kein nachträglicher Einfall; er ist das Audit-Fundament, auf dem die gesamte Compliance-Geschichte ruht. Er ist es, der einer Kundin erlaubt, mit Belegen die Frage zu beantworten, die Aufsichtsbehörden zunehmend stellen: Wer hat Ihre KI erreicht, und wann? Das Kontrollset bildet sauber die Rahmenwerke ab, die Auditoren anerkennen, und es ergänzt die Ausrichtung der Plattform an der DSGVO und der EU-KI-Verordnung (AI Act).
100 % Infrastructure-as-Code
Eine letzte Eigenschaft, denn sie ist es, die alles Übrige im Maßstab vertrauenswürdig macht. Cloud Shield wird vollständig als Infrastructure-as-Code bereitgestellt — es gibt keine von Hand zusammengeklickten Änderungen in irgendeiner Konsole. Die gesamte Edge, jedes Sicherheitsmodul, jede mandantenweise Grenze ist in versionierten Definitionen beschrieben, wird vor der Auslieferung geprüft und automatisch gegen Richtlinien kontrolliert. Eine neue Kundin anzubinden ist ein parametrisierter, wiederholbarer Vorgang — kein maßgeschneidertes Projekt, das jemand auf subtile Weise falsch machen könnte.
Für einen Entscheider bedeutet das praktisch: Konsistenz. Die Isolierung und die Kontrollen, die Ihnen zugesichert wurden, sind keine händische Checkliste, die jemand jedes Mal abarbeitet und hofft, sie richtig zu treffen. Sie sind kodifiziert, geprüft und für jeden Mandanten identisch reproduziert.
Zurück zur Vertrauensgrenze
Treten Sie einen Schritt zurück, und die Gestalt wird klar. Cloud Shield gibt der Kundschaft eine öffentliche, rechtskonforme, jederzeit verfügbare Edge für ihren KI-Assistenten — ohne dass die Kundschaft diese Arbeit selbst betreiben muss und ohne ein einziges Loch in ihrem Netz. Der Core bleibt privat. Die Verbindung wird nach außen gewählt. Die öffentliche Edge fängt die Feindseligkeit ab, isoliert jeden Mandanten, protokolliert jede Verbindung — und kostet nur dann Geld, wenn tatsächlich jemand bedient wird.
Nichts davon ändert, was der Assistent sagen darf. Das wird an anderer Stelle gesteuert, durch die gesteuerte Projektion, die den öffentlichen Agenten zu einer strikten, einseitig gerichteten Teilmenge Ihres internen Wissens macht. Cloud Shield ist das Gegenstück dieser Grenze auf der Verbindungsebene: Die Projektion entscheidet, was gesehen werden darf; Cloud Shield macht das Erreichen zugleich öffentlich und sicher. Zusammen sind sie der Grund, warum eine öffentlich zugängliche KI dennoch eine souveräne sein kann.
Wenn Sie das größere Bild davon möchten, wie Governance von Anfang bis Ende fließt, zeigt es die Plattform-Seite. Wenn Sie lieber die offenen Teile lesen und die Grenze im Quellcode verifizieren möchten, beginnen Sie mit der Open-Source-Übersicht — Cloud Shield ist die eine geschlossene, betriebene Komponente über einem System, das im Übrigen Ihnen zum Auditieren offensteht. Und wenn Sie durchsprechen möchten, wie eine Bereitstellung für Ihr Netz aussieht, nehmen Sie Kontakt auf; wir führen Sie hindurch.