Dillenburg
← Zurück zum Journal
AI Ops3 Min.

Wo soll die AI laufen?

Vier Betriebsmodelle für AI in Firewall & IP Connectivity – und warum der Ort des Modells nicht automatisch der Ort der Kontrolle ist.

Die Frage „Cloud oder On-Premises?“ ist für AI-Shored Operations zu klein. Ein produktiver AI Workflow besteht mindestens aus vier Komponenten: Model, Agent, Policy Engine und Execution Layer. Diese Komponenten müssen nicht am selben Ort laufen – und sie sollten nicht dieselben Rechte besitzen.

Model Location ist nicht Control Location. Intelligence kann verteilt sein; Operational Authority muss bewusst gestaltet werden.

Vier Betriebsmodelle

1. Provider-operated Platform

Modell, Agent und Orchestration laufen in der Plattform des Providers. Das ermöglicht schnellen Start und Skalierung. Gleichzeitig sind Data Governance, Transparenz, Auditability, Portability und Lock-in besonders kritisch.

Dieses Modell passt nur, wenn Datenflüsse, Model Changes, Logging, Exit und ein Manual Fallback vertraglich sowie technisch belastbar geregelt sind.

2. Customer-operated In-house

Alle Komponenten laufen in der eigenen Umgebung. Das bietet maximale Kontrolle über Daten und Integration, verlangt aber Fähigkeiten für Model Operations, Security, Evaluation, Lifecycle und 24/7-Betrieb.

Volle technische Kontrolle ist nur dann ein Vorteil, wenn sie auch organisatorisch ausgefüllt wird.

3. Provider-operated in Customer Environment

Der Provider betreibt die Lösung in einer vom Kunden kontrollierten Cloud- oder On-Premises-Umgebung. Daten und Execution bleiben näher an den Systemen; der Provider bringt Plattform- und Engineering-Fähigkeit ein.

Die Verantwortungsteilung muss besonders präzise sein: Wer kontrolliert Images, Identities, Network Paths, Updates, Logs und Incident Response?

4. Hybrid Intelligence with Local Control

Model und ein Teil des Reasoning können extern laufen. Policy Engine, Secrets und Execution bleiben in der kontrollierten Umgebung des Kunden. Nur notwendiger, minimierter Kontext verlässt die Zone.

Ein typischer Flow:

  1. Ein Request wird intern normalisiert.
  2. Der Agent erhält freigegebenen, minimierten Kontext.
  3. Das Modell erzeugt einen strukturierten Change Plan.
  4. Eine lokale Policy Engine prüft Regeln und Risk Thresholds.
  5. Menschliche Freigabe erfolgt abhängig von der Autonomy Class.
  6. Eine lokale, deterministische Automation führt aus und verifiziert.

Für sensible Infrastruktur ist dieses Modell häufig ein guter Ausgangspunkt: verteilte Intelligence, aber lokale Operational Authority.

Architecture Accountability bleibt beim Kunden

Unabhängig vom Modell behält der Kunde Verantwortung für Target Architecture, Trust Boundaries, Risk Acceptance, Datenklassifikation, erlaubte Autonomie und die Fähigkeit zum Exit. Ein Provider kann Komponenten betreiben, aber nicht die Accountability des Betreibers übernehmen.

Dafür braucht es eine interne Operational Design Authority. Sie definiert:

  • erlaubte Use Cases und Datenquellen,
  • verbindliche Policies und Architecture Patterns,
  • Autonomy Levels und Approval Paths,
  • Evaluation, Monitoring und Incident Handling,
  • Anforderungen an Portability und Manual Fallback.

Nicht verhandelbare Controls

Für alle Modelle gelten einige Grundsätze:

  • Least Privilege und getrennte Identities für Analyse und Execution,
  • keine Secrets im Prompt oder in Provider Logs,
  • vollständige Audit Trails und Versionierung,
  • deterministic Policy Gates vor jeder kritischen Aktion,
  • getesteter Stop, Rollback und Manual Fallback,
  • kontrollierte Model- und Agent-Changes,
  • regelmäßige Red Teaming- und Failure-Tests,
  • exportierbare Knowledge Bases, Policies und Evidence.

Entscheidungskriterien

Bei der Auswahl helfen konkrete Fragen:

  1. Welche Daten dürfen die kontrollierte Umgebung verlassen?
  2. Welche Aktionen benötigen lokale Echtzeitdaten?
  3. Wie kritisch sind Latenz und Offline-Fähigkeit?
  4. Kann das interne Team Model Operations sicher betreiben?
  5. Wie werden Model, Agent, Policy und Execution unabhängig aktualisiert?
  6. Kann der Service ohne Provider und ohne Modell in einen sicheren Zustand gebracht werden?

Die richtige Antwort ist selten „alles intern“ oder „alles beim Provider“. Sie ist eine bewusst entworfene Verteilung von Intelligence und Control.

Quellen und Vertiefung

  • NIST: Zero Trust Architecture
  • NIST: AI Risk Management Framework
  • EU: DORA
  • EU-Durchführungsverordnung 2024/2690 zu NIS2
  • OWASP: Top 10 for Large Language Model Applications

Ursprünglichen Beitrag auf LinkedIn öffnen