Die Kernaussage gleich vorweg: Integrationsqualität entscheidet, ob Ihre KI-Lösung produziert oder nur experimentiert. Was viele vergessen, ist: Schnittstellen, Fehlerhandling und Retries sind keine technische Zusatzaufgabe. Sie sind die Betriebsbasis. In meiner Beratungspraxis erlebe ich oft, dass ein einmaliges Trainingstool scheitert, nicht wegen des Modells, sondern wegen schlechter Integrationsqualität. Kennen Sie das Gefühl, wenn alles in Tests gut läuft und in Produktion die Fehler anfangen zu stapeln
Schnittstellen sind nicht nur APIs
Haben Sie das schon erlebt, dass eine API zwar funktioniert, aber inhaltlich ständig falsch interpretierte Daten liefert Frage ich meine Kunden, ob sie wirklich die Semantik der Daten definiert haben. Was ich dabei sehe: Teams dokumentieren Endpunkte, aber nicht die genauen Datenkontrakte, Erwartungswerte oder Nebenwirkungen. Resultat sind versteckte Fehler, sobald ein Frontend oder ein anderes System leicht abweicht. Ein sauberer Schema-Vertrag, klare Validierung und Versionshaltung sind oft unterschätzt. Wenn Sie Schnittstellen auditierbar machen wollen, muss jede Änderung nachvollziehbar und rückverfolgbar sein. Sonst haben Sie zwar Logs, aber keine Antwort auf die Frage: Warum ist genau dieser Datensatz schiefgelaufen
Fehlerhandling als Business-Funktion
Fehlerbehandlung wird gerne als Entwickleraufgabe abgeschoben. Mich interessiert dann: Was passiert im Fehlerfall aus Sicht des Geschäftsprozesses Was ich sehe: Fehlende Fehlerklassifikation führt dazu, dass alles als "Systemfehler" landet und niemand weiss, welche Fehler kritisch sind. Ein auditierbares Fehlerhandling trennt Transientfehler, Datenfehler und Logikfehler. Dokumentiert ist nicht genug; es braucht Automatisierung, die Fehler kategorisiert, eskaliert und im besten Fall automatisch korrigiert oder kompensiert. Fragen Sie sich, wie Sie die Ursachen eines Fehlers auch nach Wochen noch eindeutig nachweisen können
Retries richtig denken statt blind wiederholen
Viele setzen Retries einfach drauf, weil es bequem ist. Haben Sie schon erlebt, dass ein Exponential-Backoff ein Intervallproblem kaschiert, aber den eigentlichen Fehler verschleiert In einem Projekt beobachtete ich, wie aggressive Retries ein downstreames System überlasteten und schliesslich einen Totalausfall auslösten. Retries müssen kontextbewusst sein: Welche Art von Fehler kann durch Wiederholung gelöst werden, welche muss gemeldet werden Welche maximale Gesamtdauer ist akzeptabel, bevor ein manueller Eingriff nötig wird Die Policy für Retries gehört zur Integrationsqualität und muss auditierbar dokumentiert sein, damit Sie später prüfen können, ob das System korrekt reagiert hat
Drei typische Fehler aus der Praxis
Ein häufiger Fehler ist fehlende Schema-Validierung: Ein Feld ändert spontan Typ oder Format, und das System stürzt oder liefert falsche Empfehlungen. Ein zweiter Fehler ist unklassifiziertes Fehlerlogging: Tausende Logzeilen ohne Priorisierung blockieren das Incident-Management. Ein dritter Fehler ist einheitlich konfigurierte Retries für alle Endpunkte: Diese Einheitslösung führt zu Überlastung und verdeckt latente Probleme. Diese konkreten Probleme sehe ich regelmässig in KMU-Projekten, weil Zeitdruck und Legacy-Systeme Kompromisse erzwingen
Wie Sie Integrationsqualität auditierbar machen
Was ich empfehle ist weniger ein Regelsatz als eine Denkweise: Beurteilen Sie Integrationen aus Betreibersicht und dokumentieren Sie jede Annahme, Validierung und Policy so, dass ein externer Auditor die Entscheidungswege nachvollziehen kann. Bauen Sie automatisierte Tests, die nicht nur happy-path prüfen, sondern auch fehlerhafte Formate, fehlerhafte Sequenzen und Lastspitzen. Protokollieren Sie nicht nur Fehlermeldungen, sondern auch Entscheidungen, die daraus entstanden sind, zum Beispiel automatisierte Retrys, Eskalationen und manuelle Eingriffe. Wenn Sie das tun, wird aus einer blackbox eine nachvollziehbare Betriebsumgebung
In den nächsten 14 bis 30 Tagen prüfen Sie Ihre kritischsten Integrationspunkte: Identifizieren Sie zwei Schnittstellen mit dem höchsten geschäftlichen Risiko und lesen Sie gemeinsam mit Ihrem Team die aktuellen Datenkontrakte. Ergänzen Sie für diese Schnittstellen eine klare Fehlerklassifikation und definieren Sie eine Retry-Policy, die auf Fehlerart und Geschäftsanforderung reagiert. Implementieren Sie einfache automatisierte Tests für fehlerhafte Eingaben und dokumentieren Sie alle Entscheidungen in einem leicht zugänglichen Change-Log, so dass Sie nach einem Monat messbar bessere Beobachtbarkeit und ein auditierbares Fehlermanagement haben
