Apriko – eine durchgängig KI‑agenten­fähige Plattform, die das Branchen­regelwerk kennt

Wer im PersonalverleihGlossar eine Auswertung braucht, kennt den Ablauf: Maske öffnen, Filter setzen, Spalten wählen, Zeitraum eingrenzen, exportieren. Die Fachlichkeit ist dabei selten das Problem. Das Problem ist die Übersetzung der eigentlichen Frage in die Bedienung eines Systems. Genau diese Übersetzung übernehmen Sprachmodelle heute zuverlässig. Vorausgesetzt, sie wissen, welche Daten es gibt, welche Aktionen erlaubt sind und unter welchen Bedingungen.

Für eine Plattform wie Apriko ist ein KI-Agent deshalb keine neue Oberfläche, sondern ein neuer Konsument bestehender technischer Verträge. Und dafür haben wir eine ungewöhnlich gute Ausgangslage: Unsere Domäne liegt maschinenlesbar vor. Dieselbe Beschreibung, aus der seit Jahren die Benutzeroberfläche generiert wird, erzeugt nun auch die Werkzeuge des KI-Agenten.

Und genau hier liegt der Türöffner in die AI- und Agenten-Ära, mit enormer Hebelwirkung. Sprachmodelle verstehen heute Absichten, stellen Zusammenhänge her, lesen Dokumente und formulieren Ergebnisse. Trifft diese Fähigkeit auf eine maschinenlesbare Domäne mit Rechten, Zuständen und geprüften Schreibpfaden, vervielfacht sich ihr Nutzen. Aus einem Assistenten, der Texte schreibt, wird eine Arbeitskraft, die Vorgänge vorbereitet, hinterfragt oder autonom entscheidet und erledigt.

Apriko ist modellgetrieben aufgebaut. Jeder Fachservice beschreibt seine Entitätstypen nicht in Dokumentation, sondern deklarativ am Modell: Feldtypen und Pflichtangaben, Wertebereiche und Auswahllisten, Zustände und die Übergänge zwischen ihnen, die verfügbaren Aktionen und die Rechte, die sie voraussetzen. Über einen Endpunkt je Service, ../api/{service}/serviceinfos, steht diese Beschreibung zur Laufzeit jedem Konsumenten zur Verfügung.

Der erste Konsument war unsere eigene Frontend-Engine. Sie baut daraus die vollständige Progressive Web App (UI): Masken, Spalten, Filter, Validierungsmeldungen, Aktionen und alles Weitere, also die komplette Benutzeroberfläche. Eine neue Entität erscheint in der Oberfläche, ohne dass jemand eine Maske programmiert. Wie das im Detail funktioniert, haben wir in einem früheren Beitrag zur Plattformarchitektur beschrieben.

Der zweite Konsument ist nun der KI-Agent. Das ist mehr als eine hübsche Symmetrie: Es bedeutet, dass die Fähigkeiten des KI-Agenten nicht separat gepflegt werden. Sie entstehen aus derselben Quelle wie die Oberfläche und veralten deshalb nicht gegenüber der Fachlichkeit.

Eine Frage wie «welche Kandidaten mit Gipser-Qualifikation sind nächste Woche frei» betrifft mehrere Fachservices gleichzeitig. In einer Microservice-Architektur ist das die unangenehme Klasse von Fragen: Niemand besitzt die Antwort allein.

Dafür haben wir den Model Service. Jeder Fachservice veröffentlicht seine Änderungen als Nachricht auf dem Event Bus, und der Model Service schreibt sie in einen Leseindex, als JSONB-Fragmente mit Volltextindex und Rangfolge. Mitgeschrieben werden dabei nicht nur die Datensätze, sondern auch ihre Beziehungen. Eine einzige Abfrage kann damit über alle Entitätstypen hinweg filtern, sortieren und gewichten, ohne dass der Aufrufer wissen muss, welcher Service welchen Datensatz besitzt.

Der Index ist bewusst nicht die Wahrheit, sondern eine Ableitung davon. Die Fachservices bleiben die Eigentümer ihrer Daten und ihrer Regeln. Der Model Service folgt ihnen ereignisgetrieben nach. Das kostet eine kurze Verzögerung und erspart uns Verbundabfragen über Servicegrenzen hinweg, die eine Microservice-Architektur sonst schleichend zu einer verteilten Datenbank machen.

Für einen KI-Agenten ist dieser Index der entscheidende Baustein. Er muss keine Verbundabfragen erfinden und keine Servicegrenzen kennen. Er stellt eine typisierte Abfrage an eine Stelle und erhält ein gewichtetes Ergebnis, gefiltert auf das, was die anfragende Person sehen darf.

Weil die Beziehungen mitgeführt werden, sind auch Graphabfragen über mehrere Sprünge möglich: von der Person über die Platzierung zum Einsatzbetrieb, weiter zur Rechnung und zum Zahlungseingang. Genau solche Pfade beantworten die interessanten Fragen. Es geht um Korrelationen, nicht um Filter.

Dasselbe Vorgehen wenden wir auf Daten an, die nicht bei uns entstehen. Ein Beispiel dafür sind Finanzdaten aus einem Buchhaltungssystem: Konten, Buchungen, Kostenstellen. Bemerkenswert ist dabei nicht der Import, sondern dass es keinen Sonderweg brauchte: Die Entitätstypen sind deklarativ beschrieben, genau wie unsere eigenen, mit den Bordmitteln der Plattform. Feldtypen und Beziehungen, Rechte, Zustände.

Ab diesem Moment verhalten sich diese Daten wie native Daten. Sie erscheinen in der Oberfläche, im Leseindex und im Werkzeugkatalog des KI-Agenten, ohne dass jemand ihn davon in Kenntnis setzen musste. Damit werden Fragen beantwortbar, die Finanzzahlen mit operativen Daten verbinden, und zwar in derselben Abfrage.

Übertragen lässt sich das auf jedes System, dessen Daten man beschreiben kann, etwa ein Schichtplanungstool oder ein Bewerbermanagement. Jede solche Beschreibung erweitert den Index und damit die Menge an Korrelationen, die sich daraus ableiten lassen.

Mit den Schichtdaten des Einsatzbetriebs wird sichtbar, welche geplanten Schichten unbesetzt geblieben sind und wo zweifach disponiert wurde. Mit dem Bewerbermanagement lässt sich die Zeit von der Bewerbung bis zur Platzierung je Rekrutierungskanal auswerten und damit erkennen, welcher Kanal die Kandidaten liefert, die tatsächlich im Einsatz landen. Mit den Finanzdaten schliesslich verbinden sich Marge, Zuschläge und Zahlungseingang mit den Stunden, aus denen sie entstanden sind.

Der Aufwand liegt dabei einmalig in der Beschreibung und nicht in der Anbindung jedes einzelnen Konsumenten. Oberfläche, Index und KI-Agent folgen daraus von selbst.

Damit ein Sprachmodell etwas tun kann, braucht es Werkzeuge mit klar beschriebenen Parametern. Das Model Context Protocol, kurz MCP, ist der Standard dafür. Ein MCP-Server veröffentlicht eine Werkzeugliste, das Modell wählt daraus aus, der Server führt aus.

Der Unterschied zu einer klassischen Schnittstelle ist grundsätzlich. Eine API verbindet System A mit System B, und für jede dieser Verbindungen muss Code entwickelt werden. MCP verbindet System A mit einem Sprachmodell und weitere MCP-fähige Systeme. Die Verknüpfung und Orchestrierung übernimmt das Sprachmodell (LLM), ohne dass dafür zusätzliche Codegenerierung entsteht.

Diese Werkzeugbeschreibung entsteht bei uns deklarativ, wie alles andere. Sie wird am Modell erklärt und nicht in einem separaten Katalog gepflegt: Ein Feld bringt seinen Typ, seine Pflichtangabe und seine Grenzen mit, eine Auswahlliste ihre Werte, eine Aktion ihre Vorbedingung und ihr Recht. Aus diesen Deklarationen wird die Beschreibung erzeugt: aus einer Feldbeschreibung ein JSON-Schema, aus einer Auswahlliste ein enum, aus Zustandsübergang und Rechteangabe annotations.

Entscheidend ist, dass dieselben Metadaten zur Laufzeit zugänglich bleiben. Denn das Wichtigste steht nicht im Voraus fest: Welche Werkzeuge eine Sitzung sehen darf, hängt an den Rechten der angemeldeten Person. Ob eine Aktion gerade möglich ist, hängt am Zustand des Datensatzes. Unser MCP-Server löst die Beschreibung deshalb je Sitzung auf und filtert sie. Er bleibt dabei zustandslos.

In einer stark regulierten Domäne ist Sprachverstehen die einfachere Hälfte. Die schwierigere ist die Frage, was passiert, wenn das Modell sich irrt. Hunderte Gesamtarbeitsverträge, Swissdec-konforme Lohnbuchhaltung, Quellensteuer: Ein falscher Zuschlag ist kein Anzeigefehler, sondern ein finanzieller Schaden.

Unsere Antwort ist keine Sorgfaltsermahnung an das Modell, sondern eine Eigenschaft der Plattform. Jede Schreiboperation in Apriko kennt einen Probelauf. Der Vorschlag läuft vollständig durch Validierung, Zustandsprüfung und Fachregeln, ohne ausgeführt zu werden. Zurück kommt, was passieren würde: die betroffenen Felder, der greifende Zuschlag, die verletzte Regel. Erst nach ausdrücklicher Bestätigung folgt die Ausführung. Wo ein Vorgang für die autonome Ausführung freigegeben ist, entfällt die Rückfrage, die Prüfung nicht.

Ein regelwidriger Vorschlag erreicht die Datenbank damit nie. Er wird zu einer begründeten Rückfrage. Die Rechteprüfung liegt dabei nicht im Prompt, sondern dort, wo sie schon immer lag: in der Command-Pipeline. Der KI-Agent arbeitet mit dem delegierten Token der angemeldeten Person und kann nichts tun, was diese Person nicht auch von Hand dürfte. Jede Aktion steht anschliessend im Protokoll, mit Person, Kanal, Zeitpunkt und Einzeländerungen.

Damit wird der erste Anwendungsfall sehr direkt. «Welche Gipser mit gültigem Ausweis sind nächste Woche verfügbar und wohnen höchstens zwanzig Kilometer von Wangen entfernt?» ist keine Maske, sondern eine Abfrage über Qualifikationen, Verfügbarkeiten, Dokumentfristen und Adressen.

Der KI-Agent rät dabei nicht. Er kennt aus den Metadaten die Feldnamen und deren Typen und setzt daraus eine typisierte Abfrage an den Model Service zusammen. Was zurückkommt, ist bereits auf den Berechtigungsumfang der fragenden Person reduziert. Ein Filialleiter erhält andere Treffer als eine Sachbearbeiterin, ohne dass der KI-Agent das verhandeln müsste.

Sind fremde Daten beschrieben, wird daraus eine Korrelationsfrage: «Zeig mir alle Einsätze im Mai, bei denen die gebuchten Stunden um mehr als eine halbe Stunde von der Buchung in der Finanzbuchhaltung abweichen, und dazu die betroffene Rechnung.» Das ist ein Pfad über vier Entitätstypen aus zwei Systemen und genau die Sorte Abfrage, für die man sonst einen Export und eine Tabellenkalkulation braucht.

Interessant wird es, wenn aus der Frage ein Auftrag wird. «Zeig mir die Bruttomarge je Einsatzbetrieb im letzten Quartal, absteigend» ist eine Aggregation über denselben Index. Vorgeben lässt sich dabei mehr als das Thema: Gruppierung, Spalten, Sortierung, Zeitraum, Rundung und Format sind Teil des Auftrags. Weil daraus eine reguläre Auswertung im System entsteht, kann sie gespeichert, geteilt und beim nächsten Mal ohne Dialog erneut ausgeführt werden.

Noch nützlicher ist der Fall, für den es nichts Vorbereitetes gibt. Du brauchst ein Dokument, das Apriko noch nicht kennt: eine Bestätigung für eine Behörde, eine Aufstellung für einen Einsatzbetrieb, ein Formular in einem ungewohnten Aufbau. Dann beschreibst du es: welche Angaben, welche Struktur, welcher Empfänger, welche Sprache. Der KI-Agent sucht die Daten über den Index zusammen, erzeugt das Dokument und legt es nach deiner Freigabe dort ab, wo es hingehört, an der Platzierung, am Vertrag oder an der Person.

Das Ergebnis ist dabei ein Artefakt der Plattform mit Berechtigung, Versionierung und Protokoll. Es verlässt das System nicht und muss nicht von Hand nachgetragen werden.

Agentic AI heisst für uns nicht ein Assistent, sondern mehrere KI-Agenten mit klarem Auftrag. Weil alle über dieselben Werkzeuge arbeiten, ist der Kanal austauschbar. Interessant ist nicht, wo gefragt wird, sondern welche Aufgabe ein KI-Agent übernimmt. Was die Basis eröffnet, ist ein ganzes Feld an Möglichkeiten, und wir bauen es laufend aus. Drei davon zeigen, welches Potenzial darin steckt.

Ein CFO-Agent verbindet Planzahlen, operative Daten und Finanzzahlen, dazu die gesetzlichen Grundlagen. «Warum liegt die Bruttomarge in Bern zwei Punkte unter Plan?» ist keine Kennzahl, sondern eine Erklärung: Einsatzstunden, Zuschläge aus dem einschlägigen GAV, Ausfallzeiten, Debitorenfristen. Genauso lässt sich vorwärts rechnen: Was passiert mit der Marge, wenn die Zulagen im Bau um zwei Prozent steigen? Die Antwort kommt mit Herkunft und geprüfter Regel, nicht als Schätzung.

Ein Inbox-Agent übernimmt die eingescannte Post. Quellensteuerkorrekturen, Pfändungsanzeigen, Taggeldabrechnungen, Zulagenentscheide: Er liest das Schreiben, kategorisiert es, ordnet es der Person und der Abrechnungsperiode zu und erfasst den Vorgang im zuständigen Service, und zwar als Vorschlag mit Vorschau, der geprüft, korrigiert oder abgelehnt werden kann. Das Original legt er als Dokument an der Person ab. Aus Sortieren und Abtippen wird Kontrollieren.

Und für Mitarbeitende im Einsatz ist der Messenger der richtige Ort. Ein 60-jähriger Bauarbeiter hat keine digitale Routine, füllt auf der Baustelle keine Formulare aus und spricht häufig kein Deutsch. Für ihn ist keine Maske die Lösung, sondern gar keine Maske: Der Zeitrapport wird nicht erfasst, sondern fotografiert oder gesprochen. Das System liest ihn, prüft ihn gegen Einsatz und GAV und legt die Einträge zur Freigabe vor.

Alle drei KI-Agenten teilen denselben Werkzeugkatalog, dieselbe Rechteprüfung und dasselbe Protokoll. Was sie unterscheidet, ist der Auftrag und die Auswahl an Vorgängen, die für ihre Aufgabe freigegeben ist.

Dieses Feld ist nicht auf uns beschränkt. Über MCP steht derselbe Werkzeugkatalog auch unseren Kunden offen. Wer eigene Abläufe automatisieren will, baut seinen eigenen KI-Agenten darauf und entscheidet selbst, welche Vorgänge er ihm überlässt. Rechte, Vorbedingungen und Probelauf gelten dabei unverändert, denn sie stecken nicht im KI-Agenten, sondern in der Plattform.

Der praktische Gewinn liegt weniger in der Bequemlichkeit als in der Reichweite. Fragen, für die es früher ein Auswertungsprojekt brauchte, sind jetzt eine Frage. Daten, die in getrennten Systemen lagen, stehen in derselben Abfrage. Und Vorgänge, die zwingend durch das Backoffice mussten, entstehen dort, wo sie anfallen.

Das eröffnet Möglichkeiten, die es bisher nicht gab, und zwar nicht als Effizienzgewinn von wenigen Prozent, sondern als andere Arbeitsweise. Wer sie sinnvoll einsetzt, kann sich damit einen erheblichen Wettbewerbsvorteil verschaffen, gerade in einem Geschäft mit engen Margen und hohem Regulierungsdruck: schneller besetzen, früher erkennen, wo Marge verloren geht, und Auskunft geben, ohne jemanden damit zu beschäftigen.

Der Hebel wächst dabei weiter. Die Modelle werden von Generation zu Generation stärker, und jede neue Fähigkeit wirkt sofort auf dem ganzen Datenbestand, weil sie über denselben Werkzeugkatalog ankommt. Wer heute vorbereitet ist, nimmt jeden dieser Sprünge mit, ohne die eigene Plattform anzufassen.

Die Fähigkeiten von Agentic AI entfalten sich nur so weit, wie die Plattform sie trägt. Sieben Eigenschaften halten wir dafür für übertragbar:

• Keine doppelte Pflege. Werkzeuge und Masken stammen aus derselben Deklaration. Eine neue Entität erscheint in beiden, ohne zusätzlichen Aufwand.
• Erweiterbar mit Bordmitteln. Fremde Daten werden deklarativ beschrieben wie eigene und erweitern damit Oberfläche, Index und Werkzeugkatalog zugleich.
• Rechte werden durchgesetzt, nicht versprochen. Die Prüfung liegt in der Command-Pipeline, nicht in der Formulierung des Prompts.
• Kein Training mit Kundendaten. Wir betreiben keine eigenen Modelle und geben keine Daten zur Weiterverwendung frei. Die Qualität kommt aus Kontext und Prüfung, nicht aus Feinabstimmung.
• Abgestufte Automatisierung. Recherche läuft durch, Schreibvorgänge standardmässig zweistufig mit Vorschau und Bestätigung, einzelne Vorgänge auf Wunsch autonom. Der Automatisierungsgrad ist eine Entscheidung, kein Nebeneffekt.
• Nachvollziehbarkeit. Jede Aktion eines KI-Agenten steht im gleichen Protokoll wie eine menschliche Eingabe, mit Person, Kanal und Feldänderungen.
• Offen für eigene Automatisierung. Ein neuer KI-Agent bringt einen neuen Auftrag mit, aber keine neue Fachlogik. Über MCP bauen auch Kunden eigene Agenten darauf.

Agentic AI ist für uns kein neues Produkt neben dem ERP, sondern ein weiterer Konsument einer Architektur, die wir seit Jahren auf Selbstbeschreibung ausgelegt haben. Dass die Werkzeuge deklarativ am Modell entstehen und zur Laufzeit aufgelöst werden, ist deshalb keine technische Spielerei. Es ist der Grund, weshalb sie nicht veralten, weshalb Rechte und Vorbedingungen von Anfang an mitkommen und weshalb beschriebene Fremddaten den KI-Agenten sofort klüger machen.

Der zweite Grund ist die Trennung von Vorschlag und Entscheidung. Ein Modell darf in einer regulierten Domäne formulieren, priorisieren und aufbereiten. Ausführen darf es nichts, was die Fachlogik nicht vorher geprüft und ein Mensch nicht bestätigt hat. Das Modell schlägt vor, das ERP entscheidet.

Für die Weiterentwicklung heisst das vor allem eines: Der Aufwand liegt nicht im KI-Agenten. Kommt eine Entität hinzu, ein Zustand oder ein Recht, ist das eine Änderung an einem Ort. Oberfläche und Werkzeugkatalog folgen. Was bleibt, ist die eigentliche Arbeit, nämlich die Fachlichkeit richtig zu modellieren. Genau dort wollten wir den Aufwand immer haben.