Eine KI-Lösung besteht meist aus mehreren eigenen und fremden Bestandteilen. Vor der Übernahme sollte Ihr Unternehmen erkennen können, was eingesetzt wird, woher es stammt und wer die Komponenten künftig betreut.
Die sichtbare Oberfläche ist nicht der gesamte Lieferumfang
Ein Assistent wirkt nach aussen wie ein einzelnes Produkt. Dahinter können eine Webanwendung, Suchsoftware, Dokumentparser, Bibliotheken, Modelldienste und weitere Werkzeuge zusammenarbeiten. Wenn später eine Komponente geändert oder eingestellt wird, muss jemand ihre Rolle kennen.
Fordern Sie deshalb bereits in der Beauftragung ein verständliches Komponentenverzeichnis. Es soll keine wahllose Liste unverständlicher Paketnamen sein. Benennen Sie zu wichtigen Bestandteilen den Zweck und die Auswirkung eines Ausfalls oder Wechsels.
OWASP beschreibt für KI-Lieferketten Risiken, die neben Software auch Modelle, Daten und Lizenzen betreffen. Für die Übergabe reicht deshalb ein Quellcodearchiv allein nicht aus, wenn wesentliche Abhängigkeiten ausserhalb dieses Archivs liegen.
Was eine SBOM leisten kann
Eine Software Bill of Materials, kurz SBOM, erfasst Softwarebestandteile und ihre Beziehungen in strukturierter Form. Die offizielle CycloneDX-Einführung erläutert diese strukturierte Darstellung von Komponenten, Versionen und Abhängigkeiten.
Eine solche Liste ist kein Sicherheitszertifikat. Sie beweist weder, dass sämtliche Schwachstellen behoben sind, noch dass eine konkrete Nutzung lizenzrechtlich zulässig ist. Sie schafft eine Grundlage, auf der zuständige Fachpersonen diese Fragen gezielter bearbeiten können.
Für ein KMU ist häufig eine Kombination sinnvoll: eine maschinenlesbare Liste für die technische Betreuung und eine kurze verständliche Übersicht der geschäftlich wichtigen Bestandteile. Die Agentur sollte erklären, wie beide zusammengehören und wann sie aktualisiert werden.
Ein praxistaugliches Übergabeverzeichnis
Unser Vorschlag ist, für wesentliche Komponenten dieselben Grundfragen zu beantworten. Dadurch wird sichtbar, wo Informationen fehlen oder Zuständigkeiten ungeklärt bleiben.
Bezeichnung, Zweck und verwendete Version beziehungsweise eindeutig dokumentierter Stand.
Bezugsquelle und verantwortlicher Anbieter oder Herausgeber.
Rolle in Ihrer Anwendung und technische Abhängigkeiten.
vorhandene Lizenz- und Nutzungshinweise mit Verweis auf die massgeblichen Unterlagen.
zuständige Person für Beobachtung, Updates und Freigabe von Änderungen.
bekannte Einschränkungen oder angekündigtes Supportende.
möglicher Ersatzweg und erwartete Auswirkung eines Wechsels.
Bei einem externen Modelldienst ist die Dokumentation anders als bei lokal bereitgestellten Modellgewichten. Behaupten Sie nicht, dass jedes Modell exportiert oder beliebig weitergegeben werden kann. Halten Sie die tatsächliche Bereitstellungsform und die für Ihr Konto geltenden Bedingungen fest.
Ein fiktiver Übergabefall
Eine Agentur liefert eine Anwendung zur Analyse interner Dokumente. Im Verzeichnis stehen eine eigene Oberfläche, ein fremder PDF-Parser, ein Suchdienst und eine Modell-API. Die Beispiele sind frei erfunden und nennen bewusst keine angeblich eingesetzten Kundenprodukte.
Drei Monate später meldet der Herausgeber des Parsers eine relevante Änderung. Mit einem gepflegten Verzeichnis kann die Betreuung feststellen, welche Version verwendet wird, welche Dokumentverarbeitung betroffen ist und welcher Testbestand vor einem Update benötigt wird.
Fehlt diese Information, beginnt die Arbeit mit einer Bestandsaufnahme. Noch problematischer wäre, wenn niemand den Parser als Bestandteil kennt und eine notwendige Prüfung deshalb gar nicht startet. Der Wert des Verzeichnisses liegt in der Handlungsfähigkeit, nicht in der Länge des Dokuments.
Lizenzhinweise und Nutzung getrennt betrachten
Lassen Sie Lizenzangaben und vorhandene Bedingungen vollständig mitliefern. Ob eine konkrete Nutzung, Veränderung oder Weitergabe erlaubt ist, muss im Einzelfall anhand dieser Unterlagen geprüft werden. Die Bezeichnung «Open Source» oder «offenes Modell» beantwortet nicht automatisch jede Nutzungsfrage.
Fragen Sie zudem, welche Teile speziell für Ihr Projekt entstanden sind und welche Bestandteile auch in anderen Lösungen genutzt werden. Diese technische und organisatorische Trennung erleichtert später die Übergabe. Vertragliche Rechte sollten dazu passend geklärt sein, werden aber nicht durch die Komponentenliste ersetzt.
Bei Datenbeständen gehören Herkunft und bekannte Nutzungsbeschränkungen ebenfalls in die Dokumentation. Eine heruntergeladene Datei kann technisch leicht eingebunden werden, ohne dass damit ihre Nutzung für jeden Zweck geklärt wäre.
Die Liste mit dem ausgelieferten Stand abgleichen
Zur Abnahme sollte die Agentur zeigen, dass das Verzeichnis den tatsächlich bereitgestellten Stand beschreibt. Eine Liste aus einem frühen Prototyp kann inzwischen andere Versionen enthalten. Dokumentieren Sie deshalb den Bezug zur konkreten Lieferung und das Datum der Erzeugung.
Vereinbaren Sie ausserdem, wie nach Updates eine neue Liste entsteht. Wenn die Pflege nur am Projektende erfolgt, verliert das Verzeichnis schnell seinen Nutzen. Ein einfacher wiederholbarer Prozess ist hilfreicher als eine einmalige besonders umfangreiche Präsentation.
Ordnen Sie die Zuständigkeiten in Ihren Ablauf für den KI-Betrieb ein. Mit einclick als KI-Umsetzungspartner können Sie den Lieferumfang so beschreiben, dass Ihr Team die Lösung nachvollziehen und später weiterbetreuen lassen kann.




