Inhalt: Ausgangslage · Entscheidungsmatrix · Governance · Rollout · Mac-Abnahme · Kennzahlen · Kaufempfehlung
Drei Enterprise-Engpässe ohne Harness
1. Unkontrollierte Wirkung: Agenten mit Shell-, Ticket- oder Repo-Zugriff ohne Human Gate verletzen schnell Datenschutz und Change-Management. 2. Nicht auditierbare Läufe: Wenn Trace-ID, Tool-Exit-Code und Freigabeprotokoll fehlen, ist kein Incident reproduzierbar — ein No-Go für ISO- und SOC-Reviews. 3. Kosten ohne Lane-Budget: Parallele Nachtläufe auf geteilten Macs oder Cloud-GPUs erzeugen Token- und Hardware-Spitzen, die keinem Team zugeordnet sind.
Entscheidungsmatrix: Framework, eigener Harness, Managed Gateway
Deutsche Enterprise-Architektur bewertet drei Wege nüchtern: Integrationsaufwand, Policy-Tiefe und Betriebsstabilität. Die Matrix dient als Abnahmegerüst im Architekturboard — keine Feature-Liste.
| Kriterium | Nur Framework (SDK) | Eigener Harness | Managed Gateway |
|---|---|---|---|
| Time-to-Production | 2–6 Wochen Pilot | 8–16 Wochen mit Security-Review | 4–10 Wochen inkl. Policy-Templates |
| RBAC / Tenant-Trennung | Manuell im Code | Vollständig selbst definiert | Zentral, oft UI-gesteuert |
| Tool-Sandbox | Pro Team unterschiedlich | Einheitliches Manifest | Whitelist + Rate Limits |
| Observability | OTel optional | Pflichtschema im Harness | Integrierte Dashboards |
| Mac / Xcode-Lanes | Extern anbinden | Dedizierte Runner-Knoten | Oft nur Cloud-LLM |
Governance- und Sicherheitsspezifikation
Ein Enterprise-Harness braucht vor dem ersten Produktivlauf feste Grenzen. Die folgende Spezifikation ist bewusst knapp — sie lässt sich in Runbooks und Ticket-Templates übernehmen.
| Kontrollfeld | Zielwert 2026 | Stabilitäts- / Sicherheitsnotiz |
|---|---|---|
| Human Gate | 100 % schreibende Tools | Freigabe protokolliert mit User-ID und Zeitstempel |
| Tool-Timeout | 30–120 s je Klasse | Kill-Pfad und Circuit Breaker getestet |
| Secrets | 0 Klartext in Traces | Vault/ENV nur im Harness-Adapter |
| Fehler-Envelope | code, phase, retryable, artifact_uri | Scheduler kann ohne Chat-Verlauf entscheiden |
| Lane-Budget | Token + Mac-Minuten pro Team | Hard-Stop bei 110 % Monatsbudget |
Rollout in sechs Schritten
1. Definieren Sie Agent-Lanes (z. B. Code-Review, Ticket-Triage, Release-Notes) mit Owner, Repo-Scope und Eskalationskontakt. 2. Veröffentlichen Sie ein Tool-Manifest mit JSON-Schema, erlaubten Pfaden und Timeouts — lesende und schreibende Tools strikt trennen. 3. Implementieren Sie Observability: Trace-ID, Modell-Fingerprint, Tool, Exit-Code, Dauer, redigierte Prompts. 4. Führen Sie Human Gates für alle Seiteneffekte ein und dokumentieren Sie sie im Change-System. 5. Starten Sie Nachtläufe auf einem isolierten Mac mini M4 (SSH für Builds, VNC für Signing-UI) und messen Sie p50/p95 sowie Retry-Dichte. 6. Freigabe für Produktion erst nach drei reproduzierbaren Läufen mit identischen Artefakt-Hashes und stabiler Fehlerklassen-Verteilung.
Zwischen Schritt vier und fünf empfiehlt sich ein kurzes Red-Team: Versuchen Sie absichtlich verbotene Pfade, überlange Shell-Befehle und doppelte Schreib-Tools. Der Harness muss jeden Versuch mit einem strukturierten Fehler-Envelope stoppen, nicht mit einem generischen Modelltext. Erst wenn diese Negativtests dokumentiert sind, lohnt sich die Mac-Abnahme — sonst messen Sie nur Happy-Path-Latenz.
Mac-Abnahme parallel zum Harness-Rollout
Viele Enterprise-Harnesses binden Apple Silicon: Xcode-Builds, Notarisierung, lokale Embeddings oder On-Device-Evals. LlmMac stellt gemietete Mac mini M4 Knoten bereit, sodass Agent-Lanes nicht mit Entwickler-Laptops konkurrieren. Typisches Muster: Der Harness orchestriert Plan und Tools; der Mac-Knoten führt Shell, Compiler und Simulator aus — getrennte OS-Benutzerkonten pro Lane verhindern DerivedData-Leaks.
Planen Sie die Abnahme wie ein kleines Release: Freeze der Harness-Version, festes macOS-Image und dokumentierte Umgebungsvariablen. Jeder Nachtlauf erhält dieselbe Eingangsdatei und denselben Erfolgs-Hash — Abweichungen werden Incident, nicht A/B-Raten. Für Signing-Workflows bleibt VNC sinnvoll, während SSH für headless Builds und Log-Sammlung reicht. So trennen Sie menschliche Freigaben von automatisierten Tool-Ketten ohne zwei getrennte Betriebsmodelle.
| Abnahmefeld | Prüfung | Grenzwert |
|---|---|---|
| Wall-Clock p95 | End-to-End pro Lane-Aufgabe | < 20 min Dauerbelegung |
| Tool-Retry-Rate | 30-Tage-Fenster | < 3 % pro Nachtlauf |
| RAM-Stufe | 24 GB vs. 32 GB Unified Memory | Kein Swap-Spike unter Last |
Zitierbare Kennzahlen für Architektur-Reviews
Erstens: Ab etwa fünf produktiven Agent-Lanes lohnt sich ein zentraler Harness statt fünf SDK-Kopien — Audit und Kostenkontrolle amortisieren den Aufbau oft innerhalb eines Quartals. Zweitens: Ein Mac mini M4 mit 24 GB Unified Memory reicht für viele Review- und Build-Lanes; parallele lokale Modelle oder Eval-Suites planen Sie eher mit 32 GB. Drittens: Rechnen Sie Lane-Kosten als Token plus Mac-Minuten: Eine Stunde Queue pro Tag über zwanzig Entwickler übersteigt häufig die Miete eines dedizierten Knotens. Viertens: Planen Sie eine siebentägige Messphase mit täglichem Export von Trace-Samples — ohne diese Serie ist jede Kaufentscheidung für Hardware oder Lizenz spekulativ.
Fazit: Enterprise-Harness braucht Messphase auf echter Hardware
AI Harness im Enterprise ist Betriebsinfrastruktur — nicht ein Demo-Chat. Die richtige Reihenfolge 2026: Policy und Tool-Verträge festlegen, auf isoliertem Mac messen, dann Lanes freischalten. Kaufen lohnt sich erst bei stabiler Auslastung über Wochen; für Pilot, Audit und Nachtläufe ist LlmMac-Miete die risikoärmere Eintrittsschicht.
Kaufempfehlung: Starten Sie mit einem Miet-Tarif, der Unified Memory für Ihre schwerste Lane abdeckt. Dokumentieren Sie jeden Abnahmelauf mit Datum, macOS-Version, Modell-Fingerprint und Harness-Konfiguration. Steigen p95-Laufzeit und Retry-Rate stabil, erweitern Sie RAM oder separieren Sie Knoten — nicht beides blind in einem Big-Bang. Mac mini M4 bei LlmMac mieten, Harness messen, dann skalieren: so bleiben Budgets monatlich steuerbar und Compliance nachvollziehbar.