Vertragsbasierter AI-Framework: Wie Traverse Business-Funktionen auf WASM für Browser, Edge und Cloud bereitstellt

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. Ich leite das DennisCraft AI Studio und arbeite mit Claude, Supabase, n8n, Doppler und selbst gehostetem Postgres. In den letzten Monaten musste ich für einen DACH-B2B-Kunden dieselbe KI-Scoring-Logik gleichzeitig im Browser (Privacy), am Edge (geringe Latenz) und in der Cloud (Skalierung) bereitstellen. Unterschiedliche Implementierungen für jede Umgebung führen zu Inkonsistenz, Risiken bei der Validierung und Compliance-Problemen – ein echtes Produktionsproblem.

Vertragsgetriebener Ansatz: Traverse in der Praxis

Im Zentrum steht ein klar definierter Vertrag (Contract) zwischen Eingaben, Logik und Ausgaben jeder Business-Funktion. Keine YAML-Beschreibung, sondern typisierte Schemata (z.B. als TypeScript-Interfaces oder OpenAPI), die zur Build- und Testzeit geprüft werden. Dadurch bleibt jede Business Capability konsistent und testbar – egal ob im Browser, Edge oder in der Cloud.

Warum klassische KI-Pipelines im Multi-Umfeld versagen

• Business-Logik verteilt sich auf Backend, Frontend, Edge – Verhalten driftet auseinander.
• Tests decken selten alle Umgebungen ab – Edge-spezifische Fehler tauchen erst im Produktivbetrieb auf.
• Updates sind riskant: Änderungen für eine Umgebung können andere brechen.

TypeScript-Vertrag als Beispiel

export interface ScoringInput {
  dealId: string;
  features: Record<string, number>;
}

export interface ScoringOutput {
  score: number;
  riskLevel: 'low' | 'medium' | 'high';
}

Jede KI-Komponente akzeptiert und liefert genau diese Strukturen, geprüft durch TypeScript-Tools wie tRPC oder Zod.

WebAssembly (WASM): Einheitliche Logik für alle Plattformen

Mit WebAssembly kann Business-Logik (z.B. in Rust, Go, AssemblyScript) zu einem universellen Binärformat kompiliert werden. Dieses läuft im Browser, auf Edge-Plattformen (Cloudflare Workers) und in der Cloud (Supabase Edge Functions). In meinen Projekten hat die Migration auf WASM folgende Vorteile gebracht:

• Kein Code-Duplikat – eine Codebasis für alle Umgebungen.
• Konsistentes Verhalten und Testbarkeit: ein Binärpaket, eine Fehlerquelle.
• Einfachere Sicherheitsprüfung und Compliance – relevanter Punkt für DSGVO und NIS2.

Rust-WASM-Modul (Minimalbeispiel)

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn score_deal(features: &JsValue) -> JsValue {
    // Deserialisierung, Scoring, Serialisierung
}

Mit wasm-pack build entsteht ein Modul, das im React-Frontend, als Edge-Worker oder in Cloud Functions genutzt werden kann.

Test und Compliance: Was in der Praxis wirklich Fehler findet

Produktionsreife KI erfordert mehr als Unit-Tests: Statische Analyse und Laufzeitbeschränkungen sind entscheidend. In drei meiner letzten Agent-Deployments haben semgrep und bandit CWE-89-Muster (SQL-Injection) im von LLM generierten Postgres-Code detektiert. Ohne vertragsbasierten, einheitlichen Runtime-Ansatz hätten diese Schwachstellen Edge-Umgebungen erreicht – mit erhöhtem Risiko für DSGVO- oder BSI-Verstöße.

CI/CD-Integration (z.B. mit Supabase)

semgrep --config=auto src/
bandit -r src/
docker build -t dealscore:wasm .
supabase functions deploy dealscore

Nur Binärpakete, die alle Tests und Checks bestehen, gelangen in Edge- und Cloud-Umgebungen.

Vergleich: Browser, Edge, Cloud

Mit Vertragslogik und WASM kann dieselbe Business-Funktion ohne Anpassungen überall laufen – ein Vorteil bei Audits und für die Einhaltung der DSGVO.

FAQ

Welcher Stack eignet sich für WASM-Business-Funktionen?

Ich setze auf Rust wegen der Stabilität und statischen Typisierung. AssemblyScript ist für Frontend-Teams leichter zugänglich, benötigt aber mehr manuelle Validierung.

Laufen LLMs direkt im WASM?

Nur kleine Modelle oder inferenzielle Aufrufe via API. Große Modelle (GPT-3+) sind für Browser/Edge zu groß.

Wie werden Verträge validiert?

tRPC, Zod oder OpenAPI – Schemata bleiben synchron, Fehler werden beim Build gefunden.

Wie werden Security-Risiken bei LLM-Generierung adressiert?

semgrep, bandit und gitleaks sind Pflicht in der CI. Kein auto-generierter Code ohne Analyse. In meinen Pipelines hat bandit SQL-Injections im LLM-Output vorab erkannt.

Was tun bei Vertragsänderungen?

Vertragsversionierung (z.B. v1/v2 Endpunkte), gestaffelter Rollout, niemals Schnittstellen direkt brechen – Edge- und Browser-Clients aktualisieren sich asynchron.

Haben Sie bereits Business-Logik, die identisch in Browser, Edge und Cloud laufen muss? Wo treten Inkonsistenzen auf – in CI, Tests oder erst im Feld? Ich biete DACH-Unternehmen einen kostenlosen 30-min Stack-Audit für KI in regulierten Märkten an. Kontaktieren Sie mich via LinkedIn oder @ger_dennis_ai.