KBA-Schnittstellenintegration für Automobilhersteller: So bleibt eine Legacy-SOAP-Verbindung stabil

Das KBA bestimmt Schema, Dokumentation, Zugangsdaten und Fristen. Weil all das in einer Integrationsschicht lag, musste eine Überarbeitung der KBA-Schnittstelle mit zwei Monaten Frist nur dort umgesetzt werden, nicht in den eigenen Systemen des Herstellers.

Die KBA-Schnittstelle ist schwer zu integrieren, weil der Hersteller keinen ihrer Parameter beeinflussen kann. Das KBA legt das Schema fest, schreibt die Dokumentation, bestimmt, wann Zugangsdaten erneuert werden müssen, und entscheidet, wann sich die Schnittstelle ändert. Jeder dieser Punkte kann den Prozess stoppen, wenn die Integration ihn nicht auffängt.

Das Schema ist fest. Es hat keine Erweiterungspunkte und keinen Platz für ein Feld, das dem Hersteller nützen würde. Die internen Daten müssen sich der Struktur der Behörde anpassen, nie umgekehrt.

Die offizielle Spezifikation war unvollständig, und der technische Support des KBA war begrenzt. Wie sich der Endpunkt in manchen Fällen verhält, zeigte sich erst im Test mit echten Nachrichten.

Der Zugang hängt an Passwörtern, die regelmäßig erneuert werden müssen. Wird eine Erneuerung verpasst, ist der Benutzer gesperrt und die Kommunikation mit dem KBA bricht ab.

Und wenn das KBA die Schnittstelle überarbeitet, bestimmt die Behörde die Frist, nicht der Release-Kalender des Herstellers. In diesem Projekt kündigte das KBA umfangreiche Änderungen an und ließ zwei Monate für die Umsetzung.

Fällt die Verbindung aus, stehen Produktion, Fahrzeugzulassung und Compliance-Reporting still.

Genau diese Bündelung machte die kurze Umsetzungsfrist beherrschbar. Statt Änderungen über mehrere Backend-Systeme und deren Release-Zyklen abzustimmen, passte das Team Mappings und Servicemodelle in Scheer PAS an. Alle Änderungen wurden fristgerecht umgesetzt, und der Hersteller musste keines seiner eigenen Systeme anpassen.

Auch komplexe Antwortnachrichten des KBA werden zurückübersetzt, in ein Format, das die Prozesse des Herstellers verstehen. Interne Systeme verarbeiten das XML der Behörde nie direkt.

Der Nachteil ist, dass die Integrationsschicht zu eigener Software wird, die betreut, versioniert und getestet werden muss. Für eine Schnittstelle, die sich nach fremdem Zeitplan ändert, ist das trotzdem die günstigere Lösung.

Ablaufende KBA-Passwörter sind kein Risiko mehr, sobald die Integrationsschicht sie überwacht und rechtzeitig erneuert. Ein Kalendereintrag reicht dafür nicht. In diesem Projekt prüft ein automatisierter Prozess in Scheer PAS laufend, ob die Zugangsdaten noch gültig sind, und erneuert Passwörter, bevor sie ablaufen. Benutzerkonten werden nicht gesperrt, und Geschäftsprozesse laufen weiter.

Das klingt nach einem Detail. In der Praxis sind abgelaufene Zugangsdaten aber einer der wenigen Fehler, die eine korrekt gemappte, vollständig getestete Schnittstelle über Nacht stoppen können.

Ein KI-Agent sollte nicht direkt an das KBA melden, weil das KBA jede Meldung erfasst und sich eine falsche nur über einen Verwaltungsvorgang korrigieren lässt, nicht per Rollback. Ein Sprachmodell kann XML erzeugen, das gültig aussieht und trotzdem einen Code verwendet, den die Behörde nicht akzeptiert, oder ein Feld weglässt, das der Endpunkt erwartet.

Die Schicht, die diese Anbindung zuverlässig gemacht hat, ist dieselbe, die ein Agent bräuchte. Der Agent kann entscheiden, dass ein Datensatz gemeldet werden muss, die Daten zusammentragen und die Anfrage vorbereiten. Scheer PAS mappt sie dann, prüft sie gegen das Schema, nutzt Zugangsdaten, die der Agent nie sieht, und sendet sie.

Der Agent berührt weder den SOAP-Envelope noch die Endpunktadresse noch die Zugangsdaten. Er ruft eine Operation mit definierter Ein- und Ausgabe auf.

In diesem Projekt wurden keine KI-Agenten eingesetzt. Die hier beschriebene Integrationsschicht ist die Voraussetzung für ihren späteren Einsatz.

Meldungen, die ein Agent vorbereitet, müssen geprüft werden, bevor sie das Unternehmen verlassen. Sobald eine Meldung beim KBA ankommt, ist sie erfasst. Drei Prüfungen sind spezifisch für diese Schnittstelle. 

Schema-Prüfung gegen die aktuelle KBA-Schemaversion, dazu Plausibilitätsprüfungen gegen interne Stammdaten. Eine Meldung, die hier durchfällt, erreicht die Behörde nie. 

Getrennte Zugangsdaten. Der Agent fordert eine Operation an, die Integrationsschicht hält und erneuert die Zugangsdaten. Der Agent sieht oder speichert sie nie. 

Freigabe vor dem Senden für alles, was einen behördlichen Datensatz verändert. Abfragen können automatisch laufen. Meldungen warten auf eine Person.

Die allgemeinen Anforderungen an die Governance von KI-Agenten, von Validierung und Berechtigungen bis hin zu Protokollierung und menschlicher Freigabe, werden in diesem Artikel.

Behandeln Sie die KBA-Schnittstelle als etwas, das sich ändert, ohne Sie zu fragen. Alles, was KBA-spezifisch ist, gehört an einen Ort, und dieser Ort ist nicht das ERP-System. 

Automatisieren Sie die Erneuerung der Zugangsdaten, bevor Sie sie brauchen. Das ist die günstigste Maßnahme im ganzen Projekt und die, die am ehesten vergessen wird. 

Rechnen Sie mit Lücken in der Dokumentation, verlassen Sie sich nicht auf den Support der Behörde und planen Sie Zeit für Tests gegen den echten Endpunkt ein. 

Und wenn KI-Agenten auf der Roadmap stehen, brauchen sie genau diese Schicht darunter. Bauen Sie sie zuerst für die Schnittstelle auf. 

Behördenschnittstellen gelten meist als Pflichtübung. Projekte wie dieses zeigen, dass sich eine Integrationsschicht gerade hier bezahlt macht und dass ein KI-Agent ohne diese Schicht genau hier zuerst scheitern würde.