izz.ONE in der Praxis

Sechs Situationen, in denen izz.ONE den Unterschied macht

Ausfälle, Angriffe, Kostenexplosionen, neue Modelle, sensible Daten und Fachbereiche mit eigenen Ideen. So sieht der Alltag mit KI in Unternehmen aus. Hier zeigen wir, was in diesen Momenten passiert, wenn izz.ONE dazwischen sitzt.

Wähle einen Baustein, um zu sehen, wo er wirkt:

Kundenservice
Ein Modellanbieter fällt aus, mitten im Spitzengeschäft
- Status Check
- LLM Router
- LLM Gateway
Kundenportal
Ein Assistent soll live gehen, aber ist er auch sicher?
- Vulnerability Checker
- Custom GPTs
- Audit-Log
Shared Services
Die KI-Rechnung wächst schneller als der Nutzen
- LLM Router
- LLM Gateway
- Budgets
IT-Architektur
Ein besseres Modell erscheint und der Wechsel ist kein Projekt
- LLM Router
- LLM Gateway
- Evaluierung
Personalwesen
Vertrauliche Daten, und der Betriebsrat schaut genau hin
- LLM Router
- PII-Schutz
- Audit-Log
Rechtsabteilung
Der Fachbereich baut seinen Assistenten selbst, die IT behält die Kontrolle
- Custom GPTs
- Rollen und Rechte

Ausgangslage
Ein Händler beantwortet in der Woche vor Weihnachten tausende Kundenanfragen pro Stunde mit einem KI-Assistenten. Genau dann wird der genutzte Modellanbieter langsam und liefert Fehler. Ohne Gegenmaßnahme stehen Chat und Ticketbearbeitung still.
So löst es izz.ONE
Der Status Check erkennt steigende Antwortzeiten nach wenigen Sekunden. Das Gateway leitet alle Anfragen auf ein freigegebenes, gleichwertiges Modell um, der IT-Betrieb bekommt eine Meldung in Teams. Ist der Anbieter wieder stabil, wird der Verkehr schrittweise zurückgeführt.
Ergebnis
Kein Kunde hat den Ausfall bemerkt. Das Team hat ihn aus der Benachrichtigung erfahren, nicht aus Beschwerden.

Für Entwickler: Failover-Regeln

Failover-Ziele werden pro Anwendung festgelegt und respektieren Region und Datenklasse.

failover:
  app: service-assistant
  primary: anthropic/claude-sonnet@eu
  fallback:
    - azure-openai/gpt-4.1@swedencentral
    - mistral/large@eu
  trigger:
    p95_latency_ms: 3000
    error_rate: 0.05
  notify: [teams:it-betrieb]

14:02:11
Antwortzeiten von Anthropic (EU) steigen auf 4,2 sStatus Check
14:02:14
Anbieter als gestört markiertStatus Check
14:02:14
100 % der Anfragen auf Azure OpenAI (EU) umgeleitetLLM Gateway
14:02:15
Meldung an Kanal „IT-Betrieb“ in TeamsBenachrichtigung
14:41:03
Anbieter stabil, Rückführung in 10-%-SchrittenLLM Router

Umschaltzeit: 3s
Fehler bei Kunden: 0
umgeleitete Anfragen: 41.200

211 von 214 bestanden

1 kritischer und 2 mittlere Funde, Go-live blockiert

Kritisch
Systemanweisung über Rollenspiel auslesbarPrompt Injection
Mittel
Interne Tarifkalkulation in Antwort zitiertDatenabfluss
Mittel
Richtlinien über Übersetzungsaufgabe umgehbarJailbreak
Bestanden
211 weitere Angriffe abgewehrtAlle Kategorien

Ausgangslage
Ein Versicherer will einen Assistenten im Kundenportal freischalten. Die IT-Sicherheit fragt zu Recht: Lässt er sich überlisten, interne Informationen preiszugeben? Manuelle Tests decken nur einen Bruchteil der bekannten Angriffsmuster ab.
So löst es izz.ONE
Der Vulnerability Checker greift den Assistenten mit hunderten bekannten Angriffen an: Prompt Injection, Jailbreaks, das Auslesen von Systemanweisungen und Datenabfluss. Jeder Fund kommt mit Beispiel und Empfehlung. Nach der Korrektur läuft die Prüfung erneut, danach automatisch jede Nacht.
Ergebnis
Die IT-Sicherheit gibt den Go-live auf Basis eines nachvollziehbaren Prüfberichts frei. Neue Angriffsmuster werden laufend nachgetestet.

Für Entwickler: Prüfung in der CI-Pipeline

Die Prüfung lässt sich als Schritt in die Pipeline einbauen und blockiert Deployments mit kritischen Funden.

# .github/workflows/deploy.yml
- name: izz.ONE Sicherheitsprüfung
  run: izz-one scan --target gpt:kundenportal --fail-on critical
  env:
    IZZ_ONE_KEY: ${{ secrets.IZZ_ONE_KEY }}

Ausgangslage
Ein Konzern hat in einem Jahr ein Dutzend KI-Anwendungen gebaut, alle auf dem stärksten verfügbaren Modell. Die monatliche Rechnung steigt, aber niemand kann sagen, welche Anwendung was kostet und ob das Modell für die Aufgabe überhaupt nötig ist.
So löst es izz.ONE
Das Gateway weist Kosten pro Anwendung und Aufgabe aus. Der Router leitet einfache Aufgaben wie Klassifikation auf kleinere Modelle, komplexe Analysen bleiben auf den starken. Budgets pro Abteilung warnen, bevor Grenzen überschritten werden.
Ergebnis
Deutlich niedrigere Kosten bei gleicher Qualität, und jede Abteilung sieht, was ihre Anwendungen verbrauchen.

Für Entwickler: Budgets per API

Budgets und Schwellen lassen sich auch per API setzen, etwa beim Anlegen einer neuen Anwendung.

await one.budgets.upsert({
  scope: "department:kundenservice",
  monthly_eur: 5000,
  alerts: [0.75, 0.9],
  on_exceed: "route_cheaper", // statt hart zu blockieren
});

Ticket-KlassifikationVorher: 4.800 €, Mit Router: 520 €
Chat im KundenserviceVorher: 3.100 €, Mit Router: 1.900 €
ZusammenfassungenVorher: 2.100 €, Mit Router: 1.350 €
VertragsanalyseVorher: 1.600 €, Mit Router: 1.600 €

Budget Kundenservice3.900 € von 5.000 €

Warnung bei 75 % an Teamleitung versendet

routing:  app: rechnungseingangremoved: -  model: azure-openai/gpt-4.1@euadded: +  model: mistral/medium-3@eu  data_class: intern

Evaluierung, 500 Belege	Bisher	Neu
Felder korrekt erkannt	94,1 %	95,3 %
Antwortzeit (p95)	3,8 s	2,9 s
Kosten je 1000 Belege	11,40 €	7,10 €

Beispielwerte

Ausgangslage
Alle paar Wochen kommt ein neues Modell, das schneller, besser oder günstiger ist. Bisher bedeutete ein Wechsel: neue Schnittstelle, neue Tests, neues Deployment in jeder Anwendung. Also bleibt man beim Alten.
So löst es izz.ONE
Das neue Modell wird in izz.ONE hinterlegt und gegen reale Testfälle der Anwendung bewertet. Überzeugt es, wird es per Konfiguration aktiviert, zuerst für einen kleinen Teil der Anfragen, dann für alle. Am Code der Anwendung ändert sich nichts.
Ergebnis
Neue Modelle sind in Tagen produktiv statt in Quartalen, mit messbarem Nachweis, dass sie wirklich besser sind.

Für Entwickler: Schrittweise Umstellung

Der Rollout läuft über Gewichte im Routing. Die Anwendung ruft weiter model: "auto" auf.

routing:
  app: rechnungseingang
  targets:
    - model: azure-openai/gpt-4.1-mini@eu
      weight: 80
    - model: mistral/medium-3@eu
      weight: 20   # Canary, Auswertung im Dashboard

Ausgangslage
Die Personalabteilung möchte Arbeitszeugnisse und Mitarbeitergespräche mit KI vorbereiten. Datenschutz und Betriebsrat verlangen, dass personenbezogene Daten das Unternehmen nicht verlassen und jede Nutzung nachvollziehbar ist.
So löst es izz.ONE
Die Anwendung ist als „vertraulich“ eingestuft. izz.ONE maskiert Namen und Kennungen vor der Verarbeitung, der Router schließt alle externen Anbieter aus und nutzt ein selbst gehostetes Modell. Jede Anfrage landet im Audit-Log, ohne Klartextdaten.
Ergebnis
Datenschutz und Betriebsrat stimmen zu, weil die Regeln technisch durchgesetzt werden und nicht nur auf dem Papier stehen.

Für Entwickler: Datenklasse setzen

Die Datenklasse kann pro Anwendung fest hinterlegt oder pro Anfrage verschärft werden, aber nie gelockert.

const res = await one.chat.completions.create({
  model: "auto",
  messages,
  extra_body: {
    routing: { data_class: "vertraulich" },
    pii: { mode: "mask_and_restore" },
  },
});

Anfrage aus der HR-Anwendung
Entwurf für ein Arbeitszeugnis

PII-Schutz

3 personenbezogene Angaben erkannt und maskiert

Zeugnis für [PERSON_1], Personalnr. [ID_1], Abteilung [ORG_1]

3
LLM Router
Externe Anbieter für diese Datenklasse gesperrt
- ~~Azure OpenAI~~
- ~~Anthropic~~
- ~~Mistral~~
- Self-hosted
Antwort und Rücksetzung
Platzhalter werden in der Antwort wieder durch echte Werte ersetzt
Audit-Log
Zeitpunkt, Anwendung, Modell und Region protokolliert, ohne Klartext

Verantwortlich: Rechtsabteilung
Wissensquellen: Musterklauseln, Prüfleitfaden, Freigabeliste
Zugriff: Recht, Einkauf, Vertrieb (lesen)
Sicherheitsprüfung: 214 von 214 bestanden

SharePoint1240 Aufrufe / Monat
CRM860 Aufrufe / Monat
Einkaufsportal410 Aufrufe / Monat

1.4Neue Klausel zu Haftungsbegrenzung aufgenommen
1.3Prüfleitfaden 2026 hinterlegt

Ausgangslage
Die Rechtsabteilung möchte Verträge schneller vorprüfen. Bis die IT einen Assistenten gebaut hat, vergehen Monate. Baut der Fachbereich selbst, entstehen Insellösungen ohne Sicherheitsprüfung und Kostenkontrolle.
So löst es izz.ONE
Die Juristen konfigurieren einen Custom GPT mit eigenen Prüfregeln und Musterklauseln, ganz ohne Code. Die IT legt fest, wer ihn nutzen darf, und der Vulnerability Checker prüft jede neue Version. Über die API steht derselbe GPT anschließend in SharePoint, im CRM und im Einkaufsportal zur Verfügung.
Ergebnis
Ein Assistent, gepflegt vom Fachbereich, genutzt in drei Systemen, betrieben unter den Regeln der IT.

Für Entwickler: Version fest anpinnen

Produktive Systeme können eine geprüfte Version anpinnen, während der Fachbereich an der nächsten arbeitet.

const res = await one.chat.completions.create({
  model: "gpt:vertragspruefung@1.4",
  messages: [{ role: "user", content: vertragstext }],
});

Sechs Situationen, in denen izz.ONE den Unterschied macht

Ein Modellanbieter fällt aus, mitten im Spitzengeschäft

Ein Assistent soll live gehen, aber ist er auch sicher?

Die KI-Rechnung wächst schneller als der Nutzen

Ein besseres Modell erscheint und der Wechsel ist kein Projekt

Vertrauliche Daten, und der Betriebsrat schaut genau hin

Der Fachbereich baut seinen Assistenten selbst, die IT behält die Kontrolle

Ein Modellanbieter fällt aus, mitten im Spitzengeschäft

Ereignisverlauf

Prüfbericht

Ein Assistent soll live gehen, aber ist er auch sicher?

Die KI-Rechnung wächst schneller als der Nutzen

Monatliche Kosten je Aufgabe

Konfiguration

Ein besseres Modell erscheint und der Wechsel ist kein Projekt

Vertrauliche Daten, und der Betriebsrat schaut genau hin

Weg einer Anfrage

Anfrage aus der HR-Anwendung

PII-Schutz

LLM Router

Antwort und Rücksetzung

Audit-Log

Vertragsprüfung

Der Fachbereich baut seinen Assistenten selbst, die IT behält die Kontrolle

Bewirb dich bei izz.ai

Kontaktiere uns