10 Min. Lesezeit · KI · Juni 2026

KI per API in bestehende Software integrieren.

Die meisten Unternehmen brauchen keine eigene KI und auch kein neues Tool mit KI-Logo. Sie haben bereits funktionierende Software — ein ERP, ein CRM, ein Ticketsystem, eine interne Webanwendung — und wollen an genau einer Stelle eine intelligente Funktion ergänzen. Der Weg dorthin führt fast immer über eine API. Dieser Artikel zeigt, wie eine saubere KI-Integration aussieht, worauf es technisch ankommt und wo die ehrlichen Grenzen liegen.

Warum API-Integration der Normalfall ist.

Wenn man von „KI im Unternehmen“ spricht, denken viele an ein großes, eigenständiges System. In der Praxis ist das selten der richtige Schnitt. Sinnvoller ist es, eine bestehende Anwendung um eine konkrete Fähigkeit zu erweitern: einen Button, der einen Vertragsentwurf zusammenfasst; eine Funktion, die eingehende Support-Tickets vorsortiert; eine Maske, die eine Produktbeschreibung aus Stammdaten generiert.

Technisch heißt das: Ihre Software schickt einen Text (oder ein Bild) an die API eines KI-Anbieters, bekommt eine Antwort zurück und verarbeitet diese weiter. Das Sprachmodell läuft beim Anbieter, Sie zahlen pro Nutzung. Sie müssen kein Modell trainieren, keine Grafikkarten kaufen und keinen eigenen Serverpark betreiben. Diese Arbeitsteilung ist der Grund, warum KI-Funktionen heute für mittelständische Unternehmen überhaupt wirtschaftlich erreichbar sind.

Die typische Architektur einer Integration.

Ein häufiger Fehler ist, die KI-API direkt aus dem Browser oder der Endanwendung aufzurufen. Das ist aus Sicherheitsgründen falsch, weil dabei der API-Schlüssel offengelegt würde. Die saubere Architektur sieht eine Zwischenschicht im eigenen Backend vor:

Frontend / bestehende Anwendung: löst die Aktion aus (Klick auf „Zusammenfassen“) und schickt die Anfrage an das eigene Backend — nie direkt an den KI-Anbieter.
Eigenes Backend (Proxy-Schicht): hält den API-Schlüssel geheim, prüft Berechtigungen, baut den Prompt zusammen, ruft die KI-API auf und protokolliert die Nutzung.
KI-API des Anbieters: verarbeitet die Anfrage und liefert die Antwort.
Nachverarbeitung: das Backend validiert die Antwort, formatiert sie und gibt sie zurück an die Anwendung.

Diese Zwischenschicht ist nicht optional. Sie ist der Ort, an dem Sie Zugriffsrechte durchsetzen, Kosten begrenzen, Eingaben säubern und alle Aufrufe nachvollziehbar protokollieren. Ohne sie verlieren Sie die Kontrolle über das, was Ihre Nutzer an externe Dienste schicken.

Ein konkretes Integrations-Beispiel.

Der eigentliche Aufruf ist erstaunlich kompakt. Ein vereinfachtes Beispiel mit der Anthropic-API in Python zeigt das Grundmuster: Eingabe entgegennehmen, Modell aufrufen, Antwort zurückgeben — eingerahmt von Fehlerbehandlung und einem Timeout.

import anthropic
from anthropic import APIError, APITimeoutError

# Schluessel kommt aus der Umgebung,
# NIE im Code oder im Frontend.
client = anthropic.Anthropic()

def zusammenfassen(text: str) -> str:
    if len(text) > 50_000:
        raise ValueError("Eingabe zu lang")
    try:
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=600,
            timeout=30,
            system=("Fasse den folgenden Text sachlich "
                    "in maximal 5 Stichpunkten zusammen. "
                    "Erfinde nichts dazu."),
            messages=[{"role": "user", "content": text}],
        )
        return msg.content[0].text
    except APITimeoutError:
        # Anbieter antwortet nicht rechtzeitig
        return "Zeitueberschreitung, bitte erneut versuchen."
    except APIError as e:
        # z. B. Rate-Limit oder Serverfehler
        log.warning("KI-Aufruf fehlgeschlagen: %s", e)
        return "Dienst momentan nicht verfuegbar."

Wichtig ist nicht der glückliche Normalfall, sondern das Verhalten im Fehlerfall. Externe APIs antworten gelegentlich langsam, laufen in ein Rate-Limit oder fallen kurzzeitig aus. Eine Integration, die das nicht abfängt, lässt im Zweifel die ganze Anwendung hängen. Der Timeout und die abgestuften except-Zweige sind deshalb kein Beiwerk, sondern der eigentliche Produktionscode.

Authentifizierung, Schlüssel und Sicherheit.

Der API-Schlüssel ist Ihr Zugangstoken und damit ein Geheimnis ersten Ranges. Wer ihn besitzt, kann auf Ihre Kosten Anfragen stellen. Einige Grundregeln, die in keinem Projekt fehlen dürfen:

Schlüssel nie im Frontend. Niemals in JavaScript, das im Browser läuft, in einer Mobile-App oder in einem öffentlichen Repository.
Schlüssel aus der Umgebung laden. Über Umgebungsvariablen oder einen Secret-Manager, nicht hartcodiert.
Rechte und Limits trennen. Wenn der Anbieter projektgebundene Schlüssel und Ausgabengrenzen erlaubt, nutzen Sie das, damit ein Leck begrenzten Schaden anrichtet.
Eingaben begrenzen und prüfen. Länge deckeln, offensichtlich missbräuchliche Inhalte abweisen, Nutzeraktionen mit Rate-Limits versehen.
Rotation einplanen. Schlüssel müssen sich austauschen lassen, ohne dass die Anwendung umgebaut werden muss.

Synchron oder asynchron — die richtige Wahl.

Eine KI-Antwort dauert je nach Aufgabe von einer Sekunde bis zu einigen zehn Sekunden. Das ist für Software eine lange Zeit. Daraus ergeben sich zwei grundsätzliche Muster, die man bewusst wählen sollte:

Muster	Wann sinnvoll
Synchron (Nutzer wartet auf Antwort)	Kurze Aufgaben mit direkter Interaktion, z. B. „Diesen Absatz umformulieren“
Streaming (Antwort erscheint Stück für Stück)	Längere Texte, bei denen der Nutzer früh erste Wörter sehen soll
Asynchron (Auftrag in Warteschlange)	Massenverarbeitung, Hintergrundjobs, viele Dokumente auf einmal

Für Stapelverarbeitung — etwa „alle 4.000 Produkttexte überarbeiten“ — ist der synchrone Aufruf der falsche Weg. Hier gehört die Arbeit in eine Warteschlange, die im Hintergrund abgearbeitet wird, mit Wiederholungslogik bei Fehlern. Manche Anbieter stellen dafür eigene Stapel-Schnittstellen bereit, die günstiger sind, dafür aber nicht sofort antworten.

Kosten unter Kontrolle halten.

KI-APIs rechnen nach verarbeiteten Token ab — vereinfacht: nach Textmenge in Ein- und Ausgabe. Ein einzelner Aufruf kostet meist nur Bruchteile eines Cents bis wenige Cent. Das klingt harmlos, wird aber zum Problem, wenn eine Funktion versehentlich tausendfach aufgerufen wird oder ein Nutzer riesige Dokumente einreicht. Drei Hebel halten die Kosten beherrschbar:

Modellwahl. Nicht jede Aufgabe braucht das größte Modell. Für Klassifikation und einfache Umformulierungen reicht oft ein kleineres, deutlich günstigeres Modell.
Eingabe schlank halten. Nur den wirklich nötigen Kontext mitschicken. Jedes überflüssige Dokument im Prompt kostet bei jedem Aufruf erneut.
Caching und Limits. Wiederkehrende Anfragen zwischenspeichern, harte Obergrenzen pro Nutzer und pro Tag setzen, Ausgaben monitoren statt am Monatsende überrascht zu werden.

Ehrliche Grenzen der Integration.

Eine API-Integration macht Ihre Software nicht fehlerfrei klug. Drei Punkte gehören vor jedem Projekt offen ausgesprochen. Erstens: Das Modell kann sich irren und plausibel klingende, aber falsche Aussagen erzeugen. Überall, wo die Ausgabe automatisch weiterverarbeitet wird — etwa in eine Buchung oder eine E-Mail an Kunden — braucht es entweder deterministische Prüfungen oder einen Menschen, der gegenliest.

Zweitens: Sie machen sich von einem externen Dienst abhängig. Fällt der Anbieter aus, fällt Ihre Funktion aus. Das ist beherrschbar, muss aber eingeplant werden — mit sinnvollem Fehlerverhalten und der Frage, ob die Funktion geschäftskritisch ist oder nur eine Komfortverbesserung.

Drittens: Datenschutz und Vertraulichkeit. Sobald Eingaben das Haus verlassen und an eine Cloud-API gehen, stellt sich die Frage nach personenbezogenen Daten, Geschäftsgeheimnissen und dem Verarbeitungsstandort. Hier braucht es einen Auftragsverarbeitungsvertrag und eine bewusste Entscheidung, welche Daten überhaupt übermittelt werden dürfen. Für besonders sensible Fälle kann ein lokal betriebenes Modell die sauberere Wahl sein — zum Preis von mehr Aufwand und meist geringerer Modellqualität. Das ist keine Rechtsberatung; die konkrete Ausgestaltung gehört mit den zuständigen Fachleuten abgestimmt.

Was ich aus der Praxis mitgebe.

Klein und konkret starten. Eine einzige, klar umrissene Funktion integrieren und produktiv setzen, bevor das nächste Feature kommt. Eine fertige kleine Lösung schlägt zehn halbfertige.
Die Zwischenschicht ist Pflicht. Schlüssel, Rechte, Limits und Protokollierung gehören ins eigene Backend, nie ins Frontend.
Fehlerfall ist der Normalfall. Timeouts, Rate-Limits und Ausfälle gehören von Anfang an sauber behandelt, sonst reißt die KI-Funktion die ganze Anwendung mit.
Kosten messen, nicht schätzen. Ein kleines reales Volumen durchrechnen, Limits setzen und die Ausgaben beobachten — dann gibt es am Monatsende keine Überraschungen.

Sie wollen eine KI-Funktion sauber in Ihre bestehende Software integrieren — sicher, kostenkontrolliert und nachvollziehbar? Unverbindlich anfragen — wir prüfen den richtigen Schnitt, die Architektur, Datenschutz und einen realistischen ersten Anwendungsfall.