API-Schnittstelle für KI-Dienste und Modelle

Eine API-Schnittstelle ist eine vereinbarte Zugangsstelle, über die ein Programm Daten oder Rechenleistung eines anderen Programms nutzt, ohne dessen Innenleben zu kennen. Für KI-Vorhaben ist sie der Normalfall: Modelle, Spracherkennung und Fachsysteme werden über solche Zugänge angesprochen, nicht über Kopien ihrer Datenbestände.

API-Schnittstelle: die Zusage zwischen zwei Programmen

Wer den Zugang bereitstellt, beschreibt drei Dinge verbindlich: was abgefragt werden darf, in welcher Form die Antwort kommt und wie sich das System bei einem Problem meldet. Diese Beschreibung wirkt wie eine Zusage an alle Aufrufer. Ändert der Anbieter sie ohne Vorlauf, stehen die angebundenen Abläufe still, ohne dass jemand im eigenen Haus etwas falsch gemacht hätte.

Deshalb ist die Dokumentation Bestandteil der Sache selbst und nicht ihre Beilage. Fehlt zu einem Feld die Bedeutung, raten Entwickler, und Geratenes wird später zu einem Fehler in den Zahlen. Vor dem ersten Aufruf lohnt zudem der Blick in die Nutzungsbedingungen des Anbieters: Wer darf die Daten weiterverarbeiten, wie lange bleibt eine Fassung erreichbar, was geschieht bei Kündigung.

Abgrenzung zu Dateiaustausch und Datenbankzugriff

Zwei ältere Wege lösen dieselbe Aufgabe schlechter. Beim Dateiaustausch legt ein System nachts eine Ausgabe ab, das andere liest sie am Morgen: Der Stand ist immer alt, eine Störung fällt erst am Folgetag auf, und niemand bekommt eine Rückmeldung. Beim unmittelbaren Zugriff auf die fremde Datenbank verschwindet sogar die Trennlinie zwischen den Systemen — jede interne Umstellung des Anbieters legt die eigene Auswertung lahm, und Rechte lassen sich kaum abstufen.

Ein Zugang über HTTPS hält diese Trennlinie: Er nennt die erlaubten Vorgänge, prüft die Berechtigung bei jedem Aufruf und meldet einen Fehler als Fehler. Welche Wege sich in einem größeren Vorhaben sinnvoll kombinieren lassen, ordnet der Beitrag zur Systemintegration ein.

Adresse, Methode, Format, Rechte, Fehler, Fassung

Eine API-Schnittstelle besteht aus sechs Festlegungen, und alle sechs gehören in die Beschreibung des Anbieters:

• Adresse. Jeder Vorgang hat einen festen Endpunkt, unter dem er erreichbar ist.
• Methode. Lesen, Anlegen, Ändern und Löschen werden unterschieden, damit ein Aufruf nicht versehentlich schreibt.
• Format. Meist JSON, mit festgelegten Feldnamen, Zeitzonen sowie Zahl- und Datumsformaten.
• Rechte. Ein Zugang darf nur das, wofür er ausgestellt wurde — getrennt nach Umgebung und nach Zweck.
• Fehler. Vorgesehene Fehlerfälle mit eindeutiger Kennung sind mehr wert als eine allgemein gehaltene Meldung.
• Fassung. Änderungen laufen als neue Fassung an, die alte bleibt eine Zeit lang erreichbar und ihr Ende wird angekündigt.

Schlüssel, Aufrufgrenzen und Wiederholversuche

Der Zugang wird über einen Schlüssel oder ein zeitlich begrenztes Token nachgewiesen. Ein Schlüssel gehört nicht in den Quelltext und nicht in eine Tabelle, sondern in die Konfiguration der Umgebung, und er wird getauscht, sobald jemand das Haus verlässt. Tokens werden erneuert, bevor sie ablaufen, nicht erst dann, wenn der erste Aufruf scheitert.

Fast jeder Anbieter begrenzt, wie viele Aufrufe er in einem Zeitraum annimmt. Wird die Grenze überschritten, kommt keine Antwort, sondern eine Abweisung. Dagegen helfen zwei Vorkehrungen: Wiederholversuche mit wachsendem Abstand und Wiederholbarkeit — derselbe Auftrag zweimal geschickt darf nur einmal wirken. Ohne diese Eigenschaft erzeugt jede Störung der Leitung Doppelbuchungen, die anschließend von Hand gesucht werden.

API-Schnittstelle zu Modellen und KI-Diensten

Beim Anbinden eines Sprachmodells verschieben sich die Prüfpunkte. Eine Antwort kommt nicht in Millisekunden, sondern spürbar später, und die Dauer schwankt mit Länge und Auslastung. Ein Ablauf, der auf sie wartet, blockiert deshalb schnell den ganzen Vorgang; tragfähiger ist eine Warteschlange, aus der Ergebnisse nachgereicht werden. Was ein Large Language Model überhaupt liefern kann, entscheidet dabei über den Zuschnitt des Ablaufs.

Vier Punkte kommen hinzu, die es bei klassischen Fachsystemen so nicht gibt:

• Verhalten bei Nichterreichbarkeit. Fällt der Dienst aus, braucht der Ablauf einen festgelegten Rückfall: warten, auf ein kleineres Modell ausweichen oder den Vorgang an einen Menschen geben.
• Abrechnung je Aufruf. Anders als eine Datenbankabfrage wird jeder Aufruf nach Umfang abgerechnet. Eine Kostengrenze je Vorgang und je Tag gehört von Beginn an in den Aufbau.
• Schwankende Antworten. Dieselbe Anfrage liefert nicht zwingend denselben Text. Prüfregeln auf Form und Pflichtfelder ersetzen die Annahme, das Ergebnis sei stabil.
• Protokoll der Antworten. Anfrage, Antwort, Fassung des Modells und Zeitpunkt werden gespeichert, sonst lässt sich eine spätere Beschwerde nicht mehr nachvollziehen.

Personenbezug, Protokolle und unsere Arbeitsweise

Die Grenze der Datenverarbeitung verläuft dort, wo Inhalte das eigene Haus verlassen. Enthält ein Text Namen, Anschriften oder Vertragsdaten, ist der Aufruf eine Verarbeitung im Sinne der DSGVO: Es braucht einen Auftragsverarbeitungsvertrag mit dem Anbieter, einen Eintrag im Verarbeitungsverzeichnis und eine belastbare Antwort auf die Frage, ob Inhalte zum Training verwendet werden. Häufig genügt es, den Text vor dem Aufruf vom Personenbezug zu befreien; Näheres dazu im Beitrag DSGVO und KI.

Wir behandeln jeden Zugang wie ein eigenes Bauteil: eigener Schlüssel je Umgebung, Prüflauf gegen die Testumgebung des Anbieters, eine Kostengrenze für Aufrufe und ein Protokoll, das eine Antwort später nachvollziehbar macht. Ein eigenes Gateway führt bei uns alle Aufrufe an Modelle zusammen und begrenzt sie. Wie ein solcher Zuschnitt in einem Vorhaben aussieht, steht auf der Seite KI-Implementierung.