Headless im Zeitalter der KI: weniger Sonderansichten, besser bereitgestellte Daten

Das Problem der Sonderansichten

Jede Verwaltungsplattform sammelt mit der Zeit Ansichten und Berichte an. «Wie viele Aufgaben hat jeder Benutzer in diesem Monat erledigt?» wird zu einem Bildschirm. «Welche Vorgänge sind je Sitzung noch offen?» wird zu einem weiteren. Jede neue Frage erfordert einen Entwicklungsauftrag, einen Test und Wartung. Die tatsächlichen Fragen ändern sich jedoch schneller als die Software, und die Liste der Berichte ist nie vollständig.

Die Idee: Daten bereitstellen, nicht Antworten

Im Headless-Paradigma versucht die Plattform nicht, Fragen vorherzusehen. Sie stellt Rohdaten bereit, gut strukturiert und dokumentiert, über APIs. Ein KI-Assistent, der an diese APIs angebunden ist, liest die benötigten Module, setzt sie zueinander in Beziehung und beantwortet eine in natürlicher Sprache gestellte Frage.

Die Oberfläche für die Auswertung entsteht damit im Moment, aus der Frage der fragenden Person. Es gibt keine Ansicht, die im Voraus entworfen werden muss: Es entsteht eine Tabelle, eine Liste oder eine Zusammenfassung für genau diese Anfrage, die morgen möglicherweise nicht mehr gebraucht wird.

Was der Plattform bleibt

Die KI ersetzt das Verwaltungssystem nicht. Die Plattform bleibt:

• das Archiv, in dem die Daten aufbewahrt werden;
• das Register, in dem jede Änderung nachvollzogen wird;
• die massgebliche Quelle, auf die im Zweifelsfall zurückgegriffen wird.

Der Assistent interpretiert und fasst zusammen, ist aber nicht der Ort, an dem die Daten liegen. Weichen eine Antwort des Assistenten und die Daten im System voneinander ab, gilt das System.

Lesen ja, wirksame Handlungen nur nach Bestätigung

Ein Assistent kann eine Änderung vorschlagen: einen Status aktualisieren, eine Notiz erfassen, ein Dokument vorbereiten. Schreibvorgänge und wirksame Handlungen, etwa Versand, Genehmigungen oder wesentliche Statuswechsel, bleiben unter menschlicher Bestätigung. Eine Person sieht, was geschehen wird, und entscheidet. Bei rein lesenden APIs ist das Risiko gering; bei schreibenden APIs ist die Bestätigung Teil des Prozesses und keine Ergänzung.

Sicherheit und Datenschutz

Die Öffnung von APIs für einen Assistenten erfordert klare Regeln. Eine vernünftige Ausgestaltung sieht vor:

• Minimale Rechte: Token mit Berechtigungen, die pro Modul und pro Operation begrenzt sind. Ein Token, das Vorgänge liest, liest nicht die Buchhaltung.
• Ablauf und Widerruf: Jedes Token hat eine Laufzeit und kann jederzeit widerrufen werden.
• Löschen deaktiviert: Kein Token kann Daten löschen, auch nicht versehentlich.
• Aufrufprotokoll: Jede Anfrage wird aufgezeichnet, sodass sich nachvollziehen lässt, was gelesen wurde, wann und mit welchem Token.
• Sensible Daten ausgeschlossen: Felder, die die Plattform nicht verlassen dürfen, werden von der API nicht bereitgestellt und sind für den Assistenten somit nicht erreichbar.

Das Prinzip ist einfach: Der Assistent sieht nur, was die API zeigt. Der Schutz wird im Vorfeld festgelegt, im Entwurf der API, und nicht im Verhalten der KI.

Ehrliche Grenzen

Das Modell hat Kosten und Grenzen, die man offenlegen sollte.

• Wiederholtes vollständiges Lesen. Um bestimmte Fragen zu beantworten, muss der Assistent ein Modul vollständig lesen. Bei grossen Modulen ist die wiederholte Lektüre langsam und verbraucht Ressourcen. Nötig sind Filter, Seitenaufteilung und, wo erforderlich, Aggregations-Endpunkte.
• Nur bereitgestellte Felder. Der Assistent kann nicht verknüpfen, was die API nicht bereitstellt. Fehlt eine Angabe im Schema, bleibt die Frage unbeantwortet, bis das Schema erweitert wird.
• Wiederkehrende Abfragen. Wiederholt sich eine Frage jede Woche, ist eine feste Ansicht oder eine geplante Routine schneller, günstiger und berechenbarer als eine jedes Mal neu durchgeführte Auswertung.
• Überprüfung. Eine Antwort in natürlicher Sprache kann Interpretationsfehler enthalten. Bei wichtigen Entscheiden empfiehlt es sich, die Ausgangsdaten zu prüfen.

Der Ansatz schafft die Ansichten nicht ab: Er reduziert ihre Zahl auf jene, die tatsächlich dauerhaft genutzt werden.

Was sich für die Entwicklung ändert

Die Arbeit verlagert sich. Weniger Zeit für Bildschirme und Berichte je einzelne Anfrage, mehr Zeit für:

• ein sauberes und konsistentes Datenmodell;
• dokumentierte APIs mit klaren Feldnamen und sinnvollen Filtern;
• ein fein abgestuftes Berechtigungssystem;
• Protokolle und Audit-Werkzeuge;
• Tests für die Fälle, in denen die API zu viel oder zu wenig liefert.

Die Qualität der Daten und der Dokumentation wird zum Faktor, der die Qualität der Antworten des Assistenten bestimmt.

Was sich für den Softwareeinkauf ändert

Bei der Beurteilung einer Plattform lassen sich konkretere Fragen stellen:

• Deckt die API alle Module ab oder nur einzelne?
• Lassen sich Token pro Modul und pro Operation einschränken?
• Gibt es Ablauf, Widerruf und ein Aufrufprotokoll?
• Lässt sich das Löschen über die API deaktivieren?
• Welche Felder sind ausgeschlossen, und wer entscheidet darüber?
• Erfordern Schreibvorgänge eine menschliche Bestätigung?
• Bleiben die Daten in einem offenen Format exportierbar?

Ein geschlossenes System ohne API oder mit unvollständigen APIs begrenzt, was ein Assistent leisten kann. Ein offenes System ohne Berechtigungskontrollen setzt unnötigen Risiken aus. Es braucht beides: Offenheit und Kontrolle.

Zusammenfassung

Das Headless-Paradigma ist kein neuer Oberflächentrend, sondern eine andere Aufteilung der Arbeit. Die Plattform bewahrt auf, protokolliert und gewährleistet. Der Assistent liest, verknüpft und antwortet. Die Person entscheidet und bestätigt. Es funktioniert, wenn die APIs gut entworfen sind, die Berechtigungen eng gefasst sind und die Grenzen von Anfang an bekannt sind.