Mit PipesHub 1.0.0 ist eine Plattform erschienen, die verstreute Unternehmensinhalte zusammenführt und für zwei Zwecke nutzbar macht: für die interne Suche und als Datenbasis für KI-Agenten. Angebunden werden unter anderem Slack, Jira und GitHub – also genau die Systeme, in denen in vielen Entwicklungs- und Projektorganisationen das tatsächliche Arbeitswissen liegt.

Neu in Version 1.0.0 sind laut Projekt Code-Graphen sowie strengere Rechteprüfungen. Beide Punkte klingen technisch, entscheiden aber darüber, ob ein KI-Assistent im Arbeitsalltag belastbare Antworten gibt oder ein Risiko darstellt.

Das Grundproblem: Wissen ist da, nur nicht abrufbar

In mittelständischen Unternehmen entsteht Wissen selten an einem Ort. Eine Entscheidung wird im Chat getroffen, die Begründung steht im Ticket, die Umsetzung im Repository, die Abnahme wieder im Chat. Wer später fragt, warum eine Schnittstelle so gebaut wurde, wie sie gebaut wurde, muss drei Systeme durchsuchen – und kennt im Zweifel die richtigen Suchbegriffe nicht.

Genau hier setzen Plattformen wie PipesHub an. Sie indexieren die Quellsysteme und stellen eine gemeinsame Suchschicht darüber. Für KI-Agenten – also Programme, die Aufgaben teilautonom bearbeiten und dafür Informationen nachschlagen – ist diese Schicht die Voraussetzung dafür, überhaupt mit internem Kontext zu arbeiten statt nur mit dem Allgemeinwissen eines Sprachmodells.

Code-Graphen: Struktur statt Textschnipsel

Übliche Suchverfahren für KI-Assistenzen zerlegen Dokumente in Abschnitte und finden ähnliche Textstellen. Bei Quellcode funktioniert das nur eingeschränkt. Eine Funktion ist selten für sich allein verständlich; relevant sind die Aufrufbeziehungen, die Abhängigkeiten und die Stelle, an der ein Wert ursprünglich gesetzt wird.

Ein Code-Graph bildet solche Beziehungen als Netz aus Knoten und Kanten ab – Dateien, Funktionen und deren Verbindungen untereinander. Für Fragen wie "Welche Stellen sind betroffen, wenn wir dieses Feld umbenennen?" ist das die passendere Repräsentation als eine Liste ähnlich klingender Codefragmente. Für Projektteams ist das vor allem bei Altsystemen interessant, in denen niemand mehr den vollständigen Überblick hat.

Rechte sind kein Nachgedanke

Der zweite Punkt wiegt für Entscheiderinnen und Entscheider schwerer. Sobald Inhalte aus mehreren Systemen in einem gemeinsamen Index landen, verlassen sie den Schutzraum ihrer Ursprungsanwendung. Ein privater Projektkanal, ein Ticket mit Personalbezug, ein Repository mit Kundencode: In der Quelle greifen dort Berechtigungen, die im Suchindex erst einmal nicht mehr vorhanden sind.

Wird dieser Index dann an einen Assistenten angeschlossen, entsteht eine unauffällige Art der Rechteausweitung. Niemand bricht in ein System ein – die Information wird schlicht auf einem neuen Weg zugänglich. Dass PipesHub mit Version 1.0.0 bei den Rechten nachschärft, ist deshalb kein Randdetail, sondern die Bedingung dafür, dass solche Systeme in regulierten Umfeldern überhaupt eingesetzt werden dürfen.

Praktisch heißt das: Die Berechtigungen der Quellsysteme müssen zur Abfragezeit durchgesetzt werden, nicht nur beim Import. Wer ein Ticket nicht sehen darf, darf auch keine Antwort erhalten, die aus diesem Ticket zusammengefasst wurde – und keinen Verweis darauf in der Quellenliste.

Was vor dem Pilotprojekt zu klären ist

Unabhängig vom konkreten Werkzeug lohnt sich vor einer Einführung eine nüchterne Vorarbeit:

  • Quellenauswahl: Welche Systeme enthalten tatsächlich entscheidungsrelevantes Wissen – und welche vor allem Rauschen? Nicht jeder Chatkanal gehört in einen Wissensindex.
  • Rechtemodell: Sind die Berechtigungen in den Quellsystemen überhaupt gepflegt? Ein Suchindex macht jede über Jahre gewachsene Unschärfe sichtbar.
  • Datenkategorien: Wo liegen personenbezogene Daten, wo Kundenmaterial mit vertraglichen Auflagen? Diese Bereiche brauchen eine bewusste Entscheidung, keine Standardkonfiguration.
  • Betriebsmodell: Wer betreibt den Index, wo liegen die Daten, wie werden Löschungen aus den Quellsystemen nachgezogen?
  • Nachvollziehbarkeit: Liefert das System Belegstellen zu seinen Antworten? Ohne Quellenangabe lässt sich die Qualität nicht prüfen.

Qualität entsteht vor dem Modell

In Projekten wird die Güte von KI-Assistenzen häufig dem Sprachmodell zugerechnet. Tatsächlich entscheidet sich der Großteil davor: Wenn der Abruf die falschen oder veralteten Dokumente liefert, formuliert auch ein starkes Modell nur eine überzeugend klingende Fehlauskunft. Veraltete Konzeptpapiere, abgelehnte Lösungsvorschläge aus alten Tickets oder Codestände aus aufgegebenen Branches sind dabei die typischen Fehlerquellen.

Deshalb ist die Arbeit an der Datenbasis kein Vorprojekt, sondern der eigentliche Kern. Dazu gehören Entscheidungen darüber, welche Inhalte als verbindlich gelten, wie Aktualität erkennbar bleibt und welche Bereiche bewusst ausgeschlossen werden.

Einordnung für Web- und Softwareprojekte

Für Projektorganisationen verschiebt sich der Schwerpunkt: Nicht die Auswahl des Modells ist der kritische Schritt, sondern die saubere Aufbereitung und Absicherung des eigenen Wissens. Wer Slack, Jira und Repositories ohnehin nutzt, besitzt die Datenbasis bereits – sie ist nur nicht abrufbar und in den Berechtigungen oft ungenau gepflegt. Ein Pilot mit klar abgegrenztem Quellenumfang, durchgesetzten Rechten und belegten Antworten ist der sinnvollere Einstieg als ein breit ausgerollter Assistent, dessen Auskünfte niemand überprüfen kann.

Quellen